Group Policy Basics – Part 3: How Clients Process GPOs

So now that we've investigated the structure of a GPO and looked at how clients know which GPOs to apply, it's time to look at how they apply them.  For a client to know which GPOs are assigned to it, and in which order it should apply them, the client needs to check several things:

• Whether its own Local GPO is configured with it should apply
• Which site it belongs to (for site-level policies
• Which domain it belongs to (for domain-level policies)
• Where in the OU structure it resides (for OU policies)

As we said previously, the client identifies which GPOs are assigned to it from within Active Directory by looking at the gPLink attribute of the various containers where it belongs.  From the gPLink attribute on each of its container objects, the client is able to assemble a list of the GPOs it will need to apply, including the order it should apply them (based on location of the GPO, filtering, and Enforcement/Blocking rules).  The previous post in this series discussed these things, so I'll refer you there for further explanation.

Once the client has its list of GPOs, it checks the Group Policy Container (GPC) for each and gets information on where the GPO contents can be located.  You'll remember that the GPO contents are located in the Group Policy Template (GPT) within the SYSVOL share.  The first time the client does this, it has all new policies to apply and will go through each to apply what's needed.  But a client doesn't just apply a GPO once and never again.  It's an ongoing process.  With that in mind, we need to understand how GPO Processing works on an ongoing basis.

GPO Versions

As I said above, a client doesn't just process a GPO once and never again.  It will continually check to see if there are any changes in those GPOs assigned to it (or if there are new GPOs, GPOs that have been removed, etc.).  The way a client knows whether it has new settings to apply is through a GPO's version number.  Every change that is put into a GPO causes its version number to increase.  If a client checks the GPO and sees that there is a newer version number than the one it is aware of, that GPO is processed.

To see the GPO version numbers, you can look in several places.  First, the GPMC contains the information as shown below:

You can see from this screenshot that there is a different version for the User and Machine nodes.  This allows clients to decide on which of the nodes the changes have occurred so it only processes the necessary portions of the policy (and also, if the client is a user or a group it likely won't have any use for the Machine node policies).

The GPMC also records the SYSVOL version number as well as the AD version number.  This can be very important in troubleshooting.  If the AD portion (the GPC) of the GPO is showing one version number and the portion of the GPO in SYSVOL (the GPT) is showing another, this means the GPO is not fully synchronized and the client may be applying the wrong settings.  Under Windows 2000, a GPO wouldn't even apply if these version numbers were different.  This produced some problems, so starting with Windows 2003 a GPO will still apply if the AD and SYSVOL versions are different.  But this doesn't change the fact that we always want these to be as much in sync as possible.  As for why they may be out of sync, it's possible that this is only due to replication latency.  We'll discuss that in a moment.

Another way you can see the version of a GPO is to look within the GPC itself.  In the following screenshot I've used ADSI Edit to navigate to the System/Policies container of my domain and I've selected one of my GPO and opened its properties.  Here is what it shows me:

As you can see, there is a versionNumber attribute for the GPO (you need to look at the GPO itself and not the machine or user nodes).  You can see that the number is a fairly large one.  In this case it's '65540'.  But I know that if I look at the GPO version for this same GPO through the GPMC I'll see the following:

Why this difference?  The difference is that in ADSI Edit (and LDP, if you check using that tool) you'll see the raw information that is interpreted before it's displayed in the GPMC.  So how do we interpret the versionNumber ourselves?  Surprisingly it's pretty simple.

First, versionNumber represents both the User and Machine node version numbers.  The versionNumber attribute contains a 32-bit number stored as a decimal.  The way this single number stores both version numbers is for it to store the User node as the first 16 bits and the Machine node as the last 16 bits.  This can be represented as follows:

versionNumber = {User Node: upper 16 bits}{Machine Node: lower 16 bits}

To actually see the numbers the way that they are represented by the GPMC, you can take the following steps:

1. Convert versionNumber to a hexadecimal number (you can easily do this with a scientific calculator)
2. Take the first four digits of your converted number as your User version and the final four digits as your Machine version (if necessary, append the number with leading zeros until you get 8 digits)
3. Convert each of these four-digit segments back to decimal separately
4. The resulting number will be the version number you see in the GPMC.

Following these steps, let's take the versionNumber attribute we've located and see if the process works:

1. We convert 65540 from decimal to hex.  The result is 10004 (which we convert to 00010004).
2. We take the first 4 digits (0001) as the User Node version and the last 4 digits (0004) as the Machine node version
3. We convert each of these individually back to decimal:
1. 0001 converts to 0001
2. 0004 converts to 0004
4. From this we can see that the current version of our User Node is 1 and our Machine Node is 4, which agrees with the information in our GPMC window

I realize this is a really easy example and we didn't really need to go through step 3 to know what the version numbers are in this case.  However, in a production environment you will almost certainly not have such easy numbers for your GPOs and you likely won't be able to quickly eyeball the answer in the way we were able to do here.

NOTE: The versionNumber attribute will only show you the version number of the part of the GPO stored within the GPC. 

As just noted, the versionNumber attribute won't show the version number as reflected in the GPT.  For this, we need to look within the Group Policy Template itself.  When looking there, we also need to drill down to the GPO that interests us.  Here we will find a file called GPT.INI.  This is the file responsible for recording the version number of the GPO from the perspective of the GPT.  GPT.INI is a very simple file as you can see from this screenshot:

As you can see, the GPT.INI file tells us that the version of the GPO from its perspective is also 65540.  It should not be surprising to learn that this number represents both the User and Machine node version number in the same way it did within the GPC, or that you should follow the same procedure to convert this number to see what the version number is for each node.

In fact, even if you don't convert this number, just the fact that it agrees with the versionNumber attribute in the GPC is a very good sign.

AD Replication/FRS Replication

I mentioned earlier that the GPC and GPT might be out of sync when it comes to GPO Version number.  While this could mean that you have a problem in your environment, this isn't necessarily the case.  The reason is that SYSVOL and AD replicate in different ways and at different times.  Going into a full discussion of these two types of replication would take a long time and is beyond the scope of our present discussion.  Instead, I'll just give a brief thumbnail of each.

FRS Replication

FRS uses a form of replication known as change notification.  Within SYSVOL, if a change is made to a file the underlying mechanism notifies its partners 3 seconds after the change is made and the partner immediately begins requesting those changes.  For this reason, the GPT content should be replicated very quickly between Domain Controllers after you've made a change to a GPO.

NOTE: With Windows 2008, it is highly recommended that you switch from the older File Replication Server (FRS) to the newer and much improved Distributed File System Replication (DFSR).  The mechanics of how to make this change are beyond what we'll talk about here, but I encourage you to check out our official white paper on making this migration here.

AD Replication

In contrast to FRS Replication, the replication engine responsible for Active Directory is schedule-based.  Depending on whether the Domain Controllers receiving updates are within your Active Directory site or not, replication can take awhile.  Within Active Directory, there are two types of replication.  These are known as Intrasite and Intersite.

When two Domain Controllers belong to the same Active Directory site, replication will be quite fast.  A change on one DC will begin replicating 15 seconds later to other DCs within the same site.  With DCs in remote sites, the default wait period before replicating a change is 3 hours, though this can be configured and shortened to as little as 15 minutes.

So what does this mean for your client attempting to process a GPO?  If it belongs to the same site as the Domain Controller (typically the PDC Emulator) where the GPO was configured, it will most likely get the latest version of both the GPC and the GPT.  If, on the other hand, it belongs to a remote site, it may attempt to process its GPOs before both the GPT and GPC are fully updated.  In Windows 2000, GPOs that weren't fully synchronized were not processed, but beginning with Windows 2003 that was no longer the case.  But if your client isn't getting all of the settings you expect them to, this could potentially be one of the reasons why.

NOTE: Intersite replication latency is one of the reasons to limit the number of your Active Directory sites and only build a new site when it's necessary.  Sites are well-connected groupings of computers and as long as you have sufficient bandwidth, it makes sense to leave them all within one site.  The only time you'll typically want to create a new site is if you have a slower WAN link that the data must traverse, or if you have a special business need to replicate data only at specifically scheduled intervals.

A good article that goes into depth about Active Directory replication can be found here.

Clients and GPOs - Comparing Version Numbers

So now we know how GPOs store version numbers and how that information is replicated throughout your Active Directory infrastructure.  But the question that still remains to be answered is "how does a client know if its copy of the GPO is older than the current one?"  We know it's tied to version numbers, but how does the client even know if it has the current version number?  Where does it maintain this information?  For the client to know whether it's processed a particular version of a GPO already, it needs to have its own copy of the GPO version to reference.

 To see the GPOs that your client is currently aware of as well as the versions it has applied of each, you will need to look at the following location in its registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State

Within this registry key, you'll see two nodes.  These are:

• Machine - this key contains the GPOs that apply machine-side settings to your client
• User SID - this key is the user's security identifier and contains the GPOs that apply user-side settings to your client

Both the Machine and SID keys have a node called GPO-List.  Within this key you'll find a listing of every GPO that has been applied.

In this screenshot, you can see that the Machine node has 3 GPOs listed under its version of GPO-List and the User node has 1 GPO in its version of that location.  By looking at the details of one of the GPOs in the Machine node's list, you can see that a great deal of information is available about that GPO, including its DisplayName, the GPO ID number, etc.  What interests us, however, is the Version value.  This value works much like the Version number as seen through ADSI Edit or within the GPT.INI file.  However, as you can see, it also does the first step for us by converting the decimal number to hexadecimal.

In the case of the Version value, what you see is not the user node and machine node version.  Instead, you see the GPT and GPC versions.  In this case, the first four digits record the version as found in the GPT and the last four digits reference the GPC's version.

Looking at the information from the screenshot above, we see the following:

Looking at this, we can see that the most recent version of this GPO that has been applied on the client is version 4 of both the GPT (the first 4 digits of the hexadecimal number) and GPC (the last 4 digits of the hexadecimal number).  If it checks again and finds that the machine node of the GPO is still at version 4, it will know that no changes have been made and it won't need to process anything.

NOTE: There is one caveat when it comes to processing security settings, since these will always be processed again after a defined interval regardless of whether a change has occurred.  This is to make sure no one has made any manual security changes that were enforced by the GPO, but which have been undone by a malicious or unwitting user or application.  More on this is discussed under the next section.

Foreground and Background Processing

There are several different ways that a client will process GPOs, and different parts of the GPO will be applied depending on what type of processing is happening.

The two types of processing are known as Foreground and Background processing.  These are defined below:

• Foreground Processing - occurs during computer startup/shutdown and user login/logoff.  All policies are processed during this time.
• Background Processing - occurs at a regular interval in the background while clients are logged in and connected to Active Directory.  The processing interval is 90 minutes + up to 30 minutes offset (in other words, every 90 - 120 minutes) for client machines and every 5 minutes on Domain Controllers (due to the need for DCs to have a higher level of security).

To understand and how it may impact what you see when applying policies in your environment, a bit of history is necessary.  When Windows 2000 came out, GPOs actually were processed differently than they are today.  Every time the computer started up, it would go through the following process:

• Apply any local settings configured in its local GPO
• Contact it's Domain Controller in Active Directory and learn which Site, Domain and OU it belonged to
• Pull any GPOs linked to those locations and process them in the order previously described
• When the machine policies were finished applying, the Ctrl+Alt+Delete logon prompt was presented to the user
• When the user logged in, the same process repeated to check where the user object was located, discover which policies were linked to that location, and process those GPOs in the standard order

From the standpoint of knowing what's happening during login and making sure that the correct settings are being applied, this was very clean.  However, customers complained about slow logon times, so changes were made starting with Windows XP:

1. If the computer is booting for the first time and and the user is logging in for the first time to an Active Directory domain, it processes GPOs as mentioned above.  This is known as initial startup.  During this time, the client locates all GPOs it needs to apply and pulls every setting that is needed, applying them synchronously.  By synchronously, I mean that the settings are applied before clients are allowed to logon.
2. After the initial startup, processing of GPOs occurs in the background only.  Even when you're restarting your computer, it won't go through the initial startup phase as it did the first time.  Instead, it will process any GPO changes it finds asynchronously (after the user has been allowed to login).  This allows the user to log in faster (known as Fast Boot), but it may also result in policies not applying as quickly as you need.

There are some categories of Group Policy that only apply during Foreground processing.  These are:

• Logon/Logoff and Startup/Shutdown scripts
• Folder Redirection
• Software Installation
• Disk Quotas

The logic behind these categories not applying during background refresh is solid.  Imagine if you were logged on and using a piece of software, but your administrator decided to swap it for another version.  If this new version were to be automatically pushed to your desktop during background processing, it might corrupt the files you were working on.  For reasons like these, the settings listed above are only applied during Foreground processing.

The problem is that, as I said above, after initial startup (as long as your client is later than Windows 2000) the first time you log into your new device, there won't be any foreground processing.  So how do these settings ever get applied.  What happens is that when one of these settings much be applied, your client will switch briefly to allow foreground processing until these settings are applied.  The way it happens can be a bit confusing, so let me describe it briefly:

1. When a GPO is processed, your client checks to see whether any settings have been configured which require foreground processing.
2. If it finds any of these settings configured, it makes a note of this and schedules these settings to be applied the next time the client reboots or logs in (depending on what is required for the particular setting)
3. The next time a startup or login occur, the settings identified are processed using foreground processing rules

What this means is that in order for some settings to apply, it may take 2 or even 3 restarts to your system.  This can be confusing and certainly may be painful in your environment (getting your client to boot faster seems to have its price!).

You can make a change on your clients to cause them to use the old Windows 2000 way of processing GPOs.  This will eliminate the need for multiple reboots to get a setting to apply, but it could also slow down your users' login time and result in complaints.  The way to make this change is described below.

1. Create a new GPO or edit an existing one (it will need to be linked to either the Domain, Site or OU where your targeted clients can be affected).
2. Within the GPMC Editor, expand the Computer Configuration Node and go to Policies/Administrative Templates/System/Logon
3. Within the Logon settings, choose Always wait for the network at computer startup and logon.
4. Enable this setting to cause your clients to process GPOs synchronously at startup/logon

This screenshot gives you an idea of what you should see when you're configuring this setting:

NOTE: if you decide to make this change, it's a good idea to test it in a lab first so that you know how much slower your login times are likely to be.  You don't want to roll this out to your customers and suddenly be deluged with phone calls complaining about slow login times!

Security Settings in GPOs

One final note about GPO processing is important before we move on.  Though I've already mentioned that your client will only apply GPO settings if they've been changed (why apply something that hasn't been changed, after all?), there is one exception and this is Security settings in your GPOs.  Microsoft recognizes that unscrupulous people may be able to get onto a client or server machine and manually undo the security settings your GPO has put in place.  In this case, the GPO will not have changed, and if the client only updates GPOs when they've changed, this could leave the bad guys in charge of your client or server.

To prevent this from happening, all security settings in GPOs are re-applied at a regular interval even if they haven't changed.  This enforcement mechanism is used to protect clients and servers by re-applying security settings that may have been undone in the meantime.  The refresh interval for client machines is every 16 hours, and for Domain Controllers it's every 5 minutes (due to the heightened security concerns when it comes to DCs).  You can configure this mandatory refresh interval, but unless you have a compelling reason to do so it's probably better to leave it at the defaults.

NOTE: There will be times when you need to update a GPO immediately on a client.  In these cases, Microsoft provides a tool called GPUpdate to allow for this.  This tool is discussed in more depth at the end of this post.

Client-Side Extensions (CSEs)

Now we've reached the final point.  We know how clients identify which GPOs belong to them.  We know how they process GPOs (and how often).  Now we just need to know how they take the information in the GPOs and apply them.  To do this, they need a series of files known as Client-Side Extensions, or CSEs.

A Client-Side Extension is nothing more than a  file (in most cases it's a .dll file, but not always) that has been installed on the client machine which has the ability to interpret and process certain of the settings in a GPO.  Because there are many different types of settings, there are different Client-Side Extensions.  In order for your client to process a portion of a GPO, the CSE associated with that portion of the GPO will need to be present on the client machine.  An example of this is the security settings that are found under Policies/Windows Settings/Security Settings on both the Machine and User nodes of a GPO.  To process any settings that have been configured within these containers, your client will need the scecli.dll file.

You can see the various Client-Side Extensions that are loaded on your client by checking your registry.  The following screenshot illustrates where this is located:

As you can see from the screenshot, the Registry key GPExtensions contains the list of CSEs installed on your client device.  To see this key, navigate to the following location in your client's Registry:

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/GPExtensions

Each of the keys located beneath GPExtensions represents a different CSE.  Looking just at the one shown in the screenshot above, we can see that this CSE is used with Security settings.  We also see that the file used to process the security settings in the GPO is named scecli.dll.  As new settings for your GPOs are released, the number of CSEs may end up growing as well.  Typically you won't have to do anything with these, but it's good to know nonetheless.

So, in summary, we see that when a client pulls its list of GPOs it follows a well-defined process as described above.  And once it gets the settings that it should apply, it relies on the various files that are collectively known as Client-Side Extensions.  Like I've said, in most cases, this all happens behind the scenes and you don't even need to be aware of it.  But it's nice to know how the process works "under the hood".

Group Policy tools

Finally, let's wrap up with a discussion of a couple of administrative tools that are useful in managing your GPO environment.  These tools certainly aren't the only ones you'll want to know about to manage your GPO infrastructure, and I'm not going to cover every possible thing you can do with each of these tools.  But the information below should prove helpful when trying to troubleshoot the sorts of issues we've covered as part of this topic.

GPOTool

GPOTool is an older command-line tool that seems to still work fine on Windows 2008.  It's purpose is to verify whether the GPT and GPC are synchronized throughout your Active Directory environment.  You can run the tool without any switches and it will check every GPO on every DC, which can quickly become a very cumbersome and lengthy process in a large enterprise environment.  Or, if you are only interested in a specific GPO, you can list it by name or GUID and GPOTool will return only the results you care about.  Also, if you are only interested in testing the policies as they appear on a particular Domain Controller, you can do that as well.

Here is an example of how you would use GPOTool in each case:

In this first screenshot, you can see that we've run GPOTool without any switches and it has returned a list of the policies it found, given us their name and GUID, and told us whether the policy was okay or not (if you ever get any other result than Policy OK, this points to GPT and GPC being out of sync).  If you use the /verbose switch, you will get a great deal more information about each policy, as I've shown below:

As you can see, if you really want to understand what's happening under the hood, you'll probably want to use the /verbose switch.  You can see quite a bit of additional information for each GPO, including:

• GPO Name
• GPO GUID
• Version of the GPO in Active Directory (GPC version)
• Version of the GPO in SYSVOL (GPT version)
• Whether user and/or machine side policies are configured

Of course, if you only care about a single GPO, you can run GPOTool with the /gpo switch and this will be your result:

As usual, you can set the /verbose switch and get additional information about this single GPO if you so desire.

Finally, if you only want to target a specific DC, just add the /dc switch and specify the fully-qualified name of the Domain Controller you want.  Below, I've combined all of the switches to get verbose details of a single GPO as it looks on one DC:

GPOTool is helpful to you in your troubleshooting, but don't immediately jump to conclusions if it reports as inconsistent.  Because of the differences between FRS and AD replication, there may be some lag before you will see both the GPT and GPC replicated to each of your DCs.  If you test this and the inconsistency persists, however, you likely have an issue with either AD or FRS replication that needs to be investigated.

GPUpdate

As I mentioned above, there will almost certainly be times when you need to make a change to a GPO and have it update immediately.  With GPUpdate, you can force the background refresh on a client to kick in immediately (note: you cannot force the foreground process through GPUpdate).  GPUpdate runs only on the local client since it's telling the client to pull updates immediately and to do this, we need to be on the client that initiates the request.

GPUpdate is a command-line tool and it has a number of parameters that are of interest to us:

• /Target: {Computer|User} - this switch allows your client to request only the machine or user-side settings from its GPOs.  If this switch is not used, both user and computer settings are updated
• /Force - this switch causes your client to re-apply all of the policies assigned to it, though it only assigns policies that have been changed (it won't cause the client to re-apply every setting if some of them have not been changed since the last update)
• /Logoff - using this switch, you can force a logoff which will allow policies that process in the foreground to be processed
• /Boot - this switch causes your client to reboot after the policies are applied (again, to allow for processing of policies that only apply after a reboot)

Here is an example of what this might look like in your environment:

As you can see, the interface doesn't tell you much.  In this screenshot, I have asked my client to pull the computer-side settings for its GPOs and I've selected /force to ensure that the policies are refreshed.  This caused background processing to start immediately and we can see that it finished successfully.  If I had configured a particular setting on a GPO, I could run a tool like the Resultant Set of Policies (RSOP) to find out if that setting had taken effect.  If you're doing troubleshooting and need to know whether policies are applying, this is probably the easiest way to verify policy updates are working.

I know this has been a very long post (and the end of several other very long posts), and I apologize for packing in so much.  I felt it was necessary to be thorough and finish covering the core details necessary to understand GPOs and how they are processed within your environments.  Now that we've got the basics covered, we should be in good shape to move forward with other, more focused topics related to Group Policies.