AD DS: 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 settings 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) in Active Directory for each one 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 to 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 GPOs 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 ‘131078’.  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, you'll see the raw information that is interpreted before it's displayed in the GPMC.  This is also the information you see displayed in LDP if you choose to use that tool, as shown below:

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.

Based on the versionNumber of 1313078, I can see the following using the built-in calculator tool:

First I start with 131078 represented in decimal:

Then I convert this to hexadecimal (notice that the leading zeroes are missing so I need to pad the number out until I get ‘00020006):

From here, I take each number (0002 for the User-side version of the policy and 0006 for the Computer-side version) and convert them back to decimal.  In my case because I’m working in a lab environment the numbers convert back to 2 and 6 respectively.  But this won’t typically be the case in a production environment.

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 (which will be the version from the perspective of the GPO content that’s replicated by DFS-R in SYSVOL).  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.  In our case, we want the following GPO (found in C:\Windows\SYSVOL\sysvol\cert.local\policies):

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 (or, if you prefer, from the perspective of SYSVOL).  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 131078.  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.  It tells us that the GPO from the perspective of SYSVOL is the same as it is from the perspective of AD.

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.

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 at nearly the same time.  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 a bit about 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 5 GPOs listed under its version of GPO-List.  The expanded User SID does as well.  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, 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 12 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 the computer is online.  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 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 its 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 this is the user’s initial login 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 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 must 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:

To confirm what this setting does, check out the details of this setting by double-clicking it.  Below is a screenshot of what this looks like in my lab (as can be seen, the description of the GPO specifies the potential need for multiple reboots to apply certain policy settings):

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. There are new tools that allow you to assess the time it takes to process GPOs on a client device. Look for details on that in a future blog post, or if you prefer take a look at the Group Policy Results component of GPMC (this requires either Windows 2012 or Windows 8)

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. On Windows 2012, it’s also possible to right-click a node in the GPMC and select ‘Group Policy Update’ which causes GPUpdate /force to be run at every device within the scope of the node you’ve selected. These tools are 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.

Group Policy Status

In earlier environments, there was a tool named GPOTool that allowed us to verify the health of our GPOs.  It was command-line based and may still work in Windows 2012 R2 (it did in Windows 2008).  But with Windows 2012, there is a new and preferred way to verify the status of GPOs that’s known as GPO Status.

Remember that a GPO consists of two components, one found in Active Directory and replicated via AD replication and the other found in SYSVOL and replicated via (hopefully, by this point) DFS-R.  These two components replicate in different ways and at different times, and if there is a problem with one of these it is possible that your GPOs will be inconsistent.  This could mean that you might see your GPOs showing one version for AD and a different one for SYSVOL.

Within the GPMC for Windows 2012, there is now a way to determine whether your GPOs are fully replicated throughout your environment.  And the nice thing is that you can do this on a per-GPO or per-Domain basis (sorry but Sites and OUs do not have this feature).  If you want to know whether a specific GPO has fully replicated, check the GPO itself.  And if you want to know whether all of your GPOs have replicated, check the domain.

To check the status of a specific GPO, select the GPO (either the link or the GPO itself under Group Policy Objects) and choose the Status tab.  By selecting the ‘Detect Now’ button, you can tell what the status of the GPO is on each of the DCs to which this GPO replicates:

Note in the case above, I have 1 DC to which I am replicating the ‘Access this Computer from the Network – NAA’ GPO.  If it were still in the process of replicating, this would be noted.  But in my case, replication is in sync, which is why DC2 is showing in the bottom drop-down category.

To check replication for the entire domain is essentially the same thing.  Simply select the domain node itself in the GPMC, go to the Status tab and take the same steps mentioned just above.  Below is what this looks like in my lab:

Since I have just finished promoting DC2 to be a domain controller, several of the GPOs are still replicating.  I have also taken the extra step of ensuring that all categories are reported on by right-clicking the details pane and selecting every category.  This is shown below:

By doing this, I get additional detail and can look at things like the date that both the Active Directory and SysVol portions of my GPOs were last modified.  All I need to do is select the ‘Modified date’ hyperlink as shown above and I’ll get a nice pop-up like the one below:

This sort of information can be invaluable when attempting to troubleshoot why a policy might not have replicated to each of the DCs in your domain.  Sometimes this is merely a function of the time needed to allow replication to complete.  But if your domain has not converged within the expected timeframe, it may be necessary to look into it further.

NOTE: If you are checking the entire domain, be prepared for some additional network traffic. Every GPO will be checked against every DC to make sure what all of them report. While this additional traffic shouldn’t be a problem, it’s something to at least be aware of.

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 on a client.  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 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 I prefer, I could also run Group Policy Results from the GPMC and get the GPO results of remote computers (this is a much better way of getting RSOP data as it will provide significant additional detail that will help to troubleshoot any issues found on a client system). 

GPUpdate works great if you’re troubleshooting a single device (or even a handful of devices if you don’t mind using this tool on each one).  But if you make a policy change and need to have all client devices impacted by this change apply the policy immediately, the better way to do this in Windows 2012 is to select the parent OU (no domains or sites, unfortunately) where the clients reside and choose ‘Group Policy Update…’ as shown below:

By selecting this, a pop-up will be invoked to verify that you do want to update the computers that are within the scope of that OU.  By selecting ‘Yes’, the GPMC runs GPUpdate /force against every machine in the scope of the OU you’ve selected.  Below is a screenshot of the confirmation pop-up itself.  Note that it states that you’ve chosen to force a Group Policy update and will tell you the scope where this will occur.  Read this carefully to make sure this is, indeed, the desired scope before selecting ‘Yes’.

Group Policy Update isn’t a new tool so much as a way to run GPUpdate /force across multiple machines without requiring you to log into each one (or write some sort of script).  While it’s not essential that you ever use this, it’s nice to know it’s there if needed.

Summary

And with that, we come to the end of this series on GPO basics.  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.