Where are site-linked Group Policy Objects Stored? And why should you care?

Background:

A couple of weeks ago I was in the office writing up a report for a Group Policy Health Check that I was doing for a customer. As I was going through the results I asked myself this question. I didn’t know the answer so I asked two of my PFE colleagues - Jimmy and Marc. Since none of us were able to answer the question straight away (and they are both pretty smart fellas) I deemed the question worthy of a blog post.

The Short Answer: Site-Linked GPOs are stored in the domain where you created them.

The Long (and geekier) Answer:

There are two main components to group policy objects (GPOs):

•  Group Policy Container (GPC) – This is the Active Directory portion of a GPO. It lives in the “domain” naming context under System\Policies. The GUIDs correlate with the GUID of the GPO. The GPC is replicated with Active Directory according to the configured replication cost, schedule and interval. It’s got an attribute called gPCFileSysPath which points to the location of the GPT in SYSVOL.

Figure 1 - You can view the GPC in Active Directory Users and Computers. gPCFileSysPath points to the UNC path of the GPT.

•  Group Policy Template (GPT) – This is the “other half”. The GPT lives in the SYSVOL directory and contains lots of good stuff such as .pol files. The GPT is replicated to other domain controllers in the domain by using either File Replication Service (FRS) or Distributed File System Replication (DFSR) depending on your configuration. Note that SYSVOL is only replicated domain-wide.

Figure 2 - GPOs are stored in SYSVOL under the "Policies" folder

There is one more piece that glues group policy together: GPLINK

• GPLink –. This is an attribute of the AD Object where the group policy is linked. The value points to the location of the GPC in Active Directory.
• When a GPO gets linked to an OU, the GPlink attribute of the OU object is updated
• When a GPO gets linked to the domain, the GPLink attribute of the domain object is updated
• When a GPO gets linked to a site, the GPLink attribute of the SITE OBJECT is updated. The site Object is stored under “Configuration\Sites” – this is important because unlike the domain partition, all DCs in the forest have a copy of the Configuration Partition.

Figure 3- You can view the GPLink value on the domain/OU object where a GPO is linked

Here’s a diagram to piece it all together: I’ve colour coded the major events to show what happens from a client perspective in a GPSvcLog.

To summarise:

• GPO = GPT + GPC
• GPC – Stored in the Active Directory Domain partition under System\Policies. Replicated to all DCs in the domain. (not forest)
• GPC – Stored in SYSVOL and replicated by FRS or DFSR to all DCs in the same domain. (not forest)
• GPLink – Stored in Active Directory on the object where a GPO is linked.
  • If a GPO is linked to the domain or OU object the GPLINK is replicated domain-wide (with the Domain partition).
  • If a GPO is linked to a site object it is replicated Forest-wide (with the Configuration partition.)

That answers the first part of the question. Now for the second part:

Why is it important to know where your site linked GPOs are stored (why should you care)?

Consider this example:

• You have two domains in the your forest – contoso.com and corp.contoso.com
• You have three sites (Canberra, Sydney and Brisbane) configured as below. You have clients from both domains located in every site.

• You configure a new GPO called “VeryImportantBrisbaneSiteSettings- GPO” on DC5. You edit the GPO on DC5 because your GPO management machine is in the corp.contoso.com domain and DC5 is the PDC.
• “VeryImportantBrisbaneSiteSettings- GPO” contains some settings that you want to reach all of your computers in Brisbane regardless of which domain they are in. You link it to the BRISBANE site because this involves the least amount of administrative steps.

Now you can probably start to see why you should plan carefully when you link GPOs to a site. I’ll explain..

• Brisbane clients that belong to the Contoso.com domain are going to authenticate with their local DC (DC1).
• They will read the GPLink value on CN=BRISBANE,CN=Sites,CN=Configuration,DC=Contoso,DC=com
• The GPLink value will be:

<[LDAP://cn={GPOGUID},cn=policies,cn=system,DC=Corp,DC=Contoso,DC=com;0]>

• Since the local DC (DC1) does not store a copy of the Corp.contoso.com partition, the client will have to find the closest DC that does.
• The GpcFileSyspath value on the GPC will then point the client at a SYSVOL UNC path

\\Corp.contoso.com\SysVol\Corp.contoso.com\Policies\{GPOGUID}

Since the local DC (DC1) only holds a copy of SYSVOL for Contoso.com the client must pull the GPT from a remote DC in the Corp.Contoso.com domain.

Here lies the problem. Depending on the WAN connection, pulling the GPC/GPT from a remote Domain Controller on every boot/logon and background refresh could have a massive impact on group policy performance which usually means a long boot and logon time - which generally makes people upset. A better solution would be either:

•  Duplicate the “VeryImportantSiteSettings” GPO in each domain. Link both to the BRISBANE site but use some clever security filtering to ensure that computers in the Contoso domain get the GPO that is stored in Contoso and computers in the corp domain only have access to the Corp GPO. Im talking about computer settings here, if there were some user settings in this GPO you would have to apply Security groups that contain Users, Not computers.
• Avoid linking GPOs to sites at all. This is my preference. Instead of linking the GPO to the BRISBANE site, just create a new GPO in each domain and link it to an appropriate OU. You could use a child BRISBANE OU, Security or WMI filtering to ensure that this GPO is only applied by computers in the BRISBANE site.

[edit] One more important bit of information that was kindly pointed out to me by my mate Steve Moore...

If you created site-linked GPOs on a Windows 2000 domain controller the default behaviour was to store the GPC and GPT in the forest root domain. So its possible that if you have some really really old GPOs in your forest you could be hitting this issue and dont even know about it.

- Scott Duffey