Group Policy Basics – Part 1: Understanding the Structure of a Group Policy ObjectAs a Windows administrator, you almost certainly have used Group Policies to control the settings deployed to the clients of your Active Directory infrastructure.  But with Group Policies getting such heavy use, not as many administrators fully understand how Group Policy Objects (GPOs) are structured.  In this post, I will discuss the structure of GPOs in order to help bring greater understanding to this topic.  When you’re troubleshooting Group Policies in your environment, it’s helpful to understand how they’re structured, and hopefully this post will clear up a bit of that mystery.

Group Policy Objects are actually composed of two parts, the Group Policy Container (GPC) which exists in Active Directory and the Group Policy Template (GPT) where the actual content of your GPOs resides.  A third component, known as Client-Side Extensions (CSEs) can be found on client devices and are necessary for them to properly process the Group Policies assigned to them.

Before we go through these individual pieces, take a look at how GPOs show up when viewed through the Group Policy Management Console (GPMC).

In the early days of Active Directory, the only real way to get to a GPO is to open the location where it was linked (a domain, organizational unit, or site).  This made it appear that the GPOs existed at those place in the directory when they were actually only linked to those locations so that their settings would

apply to the specified objects they contained (such as the computer objects within a particular OU).  With the GPMC, it’s much clearer to see that GPOs do not reside at these different points of the directory but instead exist separately and are only linked to these different levels.

To see an example of where a GPO is linked, you can check the Scope tab of your selected GPO within the GPMC, as shown below.

You can see from this picture that the GPO I created named Event Log Size is linked to the Workstations OU within the W2K8Forest domain.  You can further see that the link is enabled (meaning the policy will apply), but it is not enforced (meaning that the policy can be blocked if the administrator of the Workstations OU wishes to prevent the policy applying).

But even the GPMC’s view of where GPOs reside is a bit misleading as there really is no Group Policy Object container in Active Directory.  Instead, the actual structure of the GPO is laid out as follows.

Group Policy Container (GPC)

The first piece of the GPO, while not within a container called Group Plicy Objects, is still found within Active Directory.  In order to see it, there are several options.  The most common is to use Active Directory Users and Computers.  If you choose this tool, you’ll need to take the following steps to see the appropriate folder:

1. Open Active Directory Users and Computers (you can do this by typing DSA.MSC at Start/Run)

2. Select View from the menu bar and ensure Advanced Features is selected (if not, select it)

3. Expand the System container and navigate to the Policies container

If you don’t enable Advanced Features, you won’t see the System container.  But after this is enabled, you should have a screen similar to the one below:

Notice that there are two containers, each with a string of numbers.  Each of these represents a different GPO (the string of numbers is the Globally Unique Identifier, or GUID, of each GPO).  Within each of these containers you’ll see a Machine and User container.  These contain specific information related to the User and Machine nodes of the GPO itself (as you might expect, the Machine node refers to computer settings and the User node refers to user settings).

Another tool that you can use to view these folders is LDP.  To use LDP to see these folders, take the following steps:

1. Start LDP by typing LDP.EXE at Start/Run2. Select Connections from the menu bar and select Connect… to

connect to the Domain Controller of your choice.  Select OK1. enter the fully qualified domain name of the Domain Controller2. enter port 389 since you’re doing an LDAP query

3. Select Connections again and choose Bind…1. Make sure you are binding to the directory with an account that

has sufficient permissions to do an LDAP query4. Select View and choose Tree.  Enter the distinguished name of your

domain (for example: dc=W2K8Forest,dc=com).  Select OK

5. In the left-hand column, expand the directory tree and navigate to Policies under the System container

There is one big difference when using LDP, which becomes immediately obvious after selecting one of the GPO nodes.  When you double-click it, you will suddenly see a great deal of information in the right-hand pane.  This is the critical directory information that client machines use when processing GPOs.  These settings allow clients to understand where the content of the policy is, which Client-Side Extensions will be needed to process the GPO content, etc.

Here is a screenshot of what you’ll see within the LDP window:

Looking at the details of our selected GPO, there are several attributes which are of special interest to us:

displayName: This attribute is the human-friendly name of your GPO gPCFileSysPath: This attribute points clients to the location where the

GPO content can be found.  Collectively, this is known as the Group Policy Template, which is housed in a share known as SYSVOL

gPCMachineExtensionNames: Here is the list of Client-Side Extensions (CSEs) that will be needed by the client in order to process all of the machine-side settings configured for this GPO

gPCUserExtensionNames: This attribute contains the list of CSEs that will be needed to process the user-side settings.  As there are no user-side settings configured in this GPO, the attribute is not populated (and thus not displayed)

Another important attribute is gPLink and while it’s not found as part of the GPO itself, you can find this attribute everywhere that the GPO is linked.  This allows objects within these other containers to know that there is a GPO it needs to process.  In the screenshot below, you can see that the gPLink attribute points to a single GPO found within the policies container of the system partition:

So now we’ve seen the Active Directory portion of the Group Policy object.  It contains settings so that the client can learn which GPOs it must process, which tools it will need to process them, and how to locate the GPO contents in order to process.  Now that we’ve seen the first part, let’s take a look at how and where the GPO content itself is stored.

Group Policy Template (GPT)

The Group Policy Template is where the meat of the GPO resides.  By way of comparison, think of how Active Directory represents a computer object.  It lists all the relevant attributes of the computer, but the object in Active Directory is not the computer itself.  In a similar way, the portion of the GPO in Active Directory merely represents the attributes relevant to the GPO content.  The content itself is known as the Group Policy Template, or GPT, and it resides in a share known as SYSVOL.  This share, like the portion of the GPO stored in Active Directory, is replicated to every DC in the domain.  This way, when a client

queries for the GPOs it needs to process, it can locate the contents of those GPOs on the same (in most cases) DC where it’s conducting the query.

NOTE: The only exception to this rule is cross-domain GPOs where a GPO is defined in another domain, but is linked in such a way that clients from neighboring domains need to apply them (a Site-level GPO is an example, since Active Directory Sites can span multiple domains).  In the case of a cross-domain GPO, the client will need to pull content from a DC in the neighboring domain which can be a very slow process.  For this reason, cross-domain GPOs are not generally recommended.

To see the content of your GPOs, you’ll want to look at the SYSVOL share on one of your DCs.  You can find the SYSVOL share by navigating to %windir%/sysvol/sysvol (yes, there is a shared SYSVOL folder within a parent SYSVOL folder).  The actual sysvol share is set to \\<servername>\sysvol  Within this folder, you will see the same list of GPOs that appear within Active Directory’s System/Policies container.  These folders are where the actual settings of your GPO are contained.  Depending on the number of settings you’ve put in place, there will be more or less present in each folder.  Regardless, you are guaranteed to have at least the following folders/files within each of your GPOs:

%windir%o sysvol

sysvol (shared as \\servername\sysvol) <domain name>

Policies scripts

Within the policies folder, you’ll find the various GPOs and their configured settings.  Again, the following folders/files are guaranteed to be present for every GPO in your domain:

Policieso <GPO GUID>

Machine (folder containing the computer-side settings of the GPO)

User (folder containing the user-side settings of the GPO) GPT.INI (file containing the GPO’s configuration settings)

Depending on what you’ve configured, the Machine and User folders may or may not contain additional content.  As an illustration, lets take a look at the contents of a GPO I’ve configured to set the various Event Logs on my clients to their maximum size.  First, here is the Group Policy Management Editor showing the settings I’ve configured.  This is the tool you’ll be working with when you configure the settings for your own environment.

If you need to know how to launch this tool, you do so from within the Group Policy Management Console by right-clicking your GPO and selecting Edit… as shown below.

So now that you understand how to make these changes, what does the GPT look like once you’ve made them?  Below is a series of screenshots to answer that question.

First, here is the file structure of the GPT, showing the GPO I’ve edited with its top level folders visible in the right-hand pane

You’ll notice the file called GPT (it’s actually GPT.INI, though the screenshot hides the file extension).  This file contains the configuration settings for this GPO, which includes its current version number (which is updated every time a change to the GPO is made) and the default GPO display name (which is the same for every GPO you create, so don’t worry that it’s not the name you gave it in the GPMC).  Here is how that file looks (NOTE: You can open GPT.INI with Notepad, but make sure you don’t accidentally save it as a .txt file or it will impact your GPOs ability to do its job)

To see the actual settings we’ve configured for this GPO, we need to expand the Machine folder (because this is a computer-side setting), which reveals the following:

You’ll notice that there is a folder called SecEdit, which contains the security-specific settings of this GPO.  The file within the SecEdit folder is GptTmpl.inf.  It’s this file that contains the specific information that your client needs to configure its settings.  Because we’ve configured this GPO so that its Event Logs are set at the maximum size, we would expect that this file would contain information directing the client to make this change.  By opening the file we can see that its contents do exactly as we would expect, as shown below (NOTE: you can edit it with Notepad, but make sure you don’t accidentally save it [or GPT.INI] as a .txt file after looking at it!).

We can see from this picture that GptTmpl.inf has clear instructions for our client machine to set its Application, Security and System Event Logs to their maximum size.

As I said earlier, there can be numerous different settings in the GPT file structure depending on how you’ve configured your GPO.  Other possible folders and files that might appear include:

Scripts folder – This folder can contain information on which scripts to run, or may include the scripts themselves.  The possible types of scripts include:

o Startup/Shutdown: applies to Computerso Logon/Logoff: applies to Users

Applications folder – if you’ve published or advertised software through a GPO, this folder will contain an advertisement file (.aas file extension) notifying clients of the software being made available

Adm folder – Older GPO versions had Administrative Templates stored within the GPT on each Domain Controller.  These templates were actually copied from client machines into the SYSVOL share of the Domain Controller.  Starting with Vista, GPOs no longer do this (though if you edit a GPO with an pre-Vista OS, it will still behave this way).  GPOs

now leverage ADMX files that are stored in a Central Store on client machines (typically c:\windows\policydefinitions) instead of the GPT.  But given that many older devices are still out there, you may see this folder in your GPT.

Documents and Settings folder – this folder contains any Folder Redirectoin settings configured by the GPO.

IEAK folder – this user-side folder contains settings related to Internet Explorer Maintenance.

Registry.pol – this file contains the registry settings the GPO has been configured to apply.  This file also contains any Software Restriction Policy settings that have been configured.

In part 2 of this series, we’ll look at details of GPO processing, with an emphasis on Client-Side Extensions (CSEs).  We’ll also discuss how GPOs are replicated, and how a client knows it’s getting the latest version of its GPO (including knowing whether the GPC and GPC are synchronized with each other).

Group Policy Basics – Part 2: Understanding Which GPOs to ApplyIn the previous post, I talked about the structure of a GPO.  Now, I’ll turn to the question of what a client does in order to apply the settings that we’ve configured in our GPOs.  The processing of GPOs is initiated from the client side rather than being pushed from your Domain Controllers.  As such, your client have to understand several things to process the correct GPOs in the correct way.  In order to properly understand this, we need to look at a few additional concepts.

How Does a Client Know Which GPOs to Apply?

There are two types of GPOs.  There are GPOs that are configured locally on the client machine and are always processed, and there are GPOs linked within the Active Directory structure itself.  While the client knows that is needs to process its local GPO, it’s not as clear which GPOs in the directory structure apply to it.  Within the directory, GPOs can be linked to the following levels:

Site Domain Organizational Unit

Depending on where the client object is located determines which GPOs it applies.  For example, consider the following scenario:

Here we see that the workstation named Windows 7 is within the Workstations OU that is part of the W2K8Forest.com domain.  Though we don’t see it on this screenshot, the Windows 7 client also belongs to the Active Directory site known as ‘Default-First-Site-Name’.  Given this, which GPOs need to be considered by our client machine?  We already know that any local settings on the client itself will need to be processed.  And if we look at the GPMC, we can see that two additional GPOs exist that the client must consider:

These two GPOs are the Default Domain Policy linked at the domain level and the Event Log Size linked to the Workstations OU.  We can also see that there are no GPOs linked to any sites.  So we know that our possible list of GPOs includes:

Local GPO Default Domain Policy Event Log Size

The way the client actually sees these is a bit different.  In order for your workstation or server to determine whether it needs to process any policies, it looks for the gPLink attribute that exists within certain Active Directory objects.  This attribute, when populated, points to the name and location of the GPO that the client must consider.  Take a look at an example of this below:

Using the LDP tool, we can see that the gPLink attribute is populated for the Workstations OU.  Looking at it closely, we can also see that it is pointing the

client to the Group Policy Container for a specific GPO (which we already know is the Event Log Size GPO).  In the previous post, we’ve already seen how the GPC function so I won’t cover that again.  Here it’s just enough to know that this is how the client learns which GPO it needs to look up.

Sticking with our scenario, we learn that gPLink is also populated on our domain object, but that it isn’t populated on the site where our client belongs.  So we end up with the list of GPOs already enumerated above.  Now what do we do with them?

Processing GPOs: Precedence

Because it’s possible (and even likely) that you may have multiple GPOs to apply, there is always the possibility that these GPOs will have conflicting settings.  In this case, how do we know which GPO will win and have its settings applied?  The simple rule to remember is that the last GPO applied will overwrite any settings applied earlier.  And the GPOs closest to the client location in the directory structure will be applied last.  The order goes as follows:

Local Site Domain Organizational Unit

What this means is that if you’ve set something on your Local GPO but your domain administrators require a different setting, your local setting will be overwritten.  The same thing applies to situations where the domain may have a default policy but your busines unit may have more specific needs.  In this case, a default setting can be configured and your business unit can override this setting to apply the one your group requires.

In our example above, suppose that the Default Domain Policy GPO set a disk quote for the domain at 50 MB.  However, your business unit requires that your workstations have 100 MB quotas.  Your administrators could set a policy at the OU level to allow these settings for your group.  Your directory structure might look like this:

Note here that we have a new OU within the Workstations OU that we’ve named Accounting.  We have also created a new GPO called Disk Quota (Accounting) that we’ve linked to the Accounting OU.  Now, objects within the Accounting OU will have the following GPOs to apply:

Local GPO Default Domain Policy Event Log Size Disk Quota (Accounting)

In this case, if the Default Domain Policy assigns a value of 50 MB as the default disk quota for the domain, the Disk Quota (Accounting)policy will overwrite it because it’s applied last.

One final point about precedence and which GPO will apply in what order.  What if you have configured two GPOs at the same OU level?  How do we know which GPO will apply first and which one will win if they have competing settings?  In this case, you must rely on the GPMC to tell you this.  You can also configure the order in which these GPOs will be processed as needed.  The following screenshot shows two GPOs that will be applied at the Accounting OU level:

From looking at the screen, you can see that these two GPOs are numbered.  The way in which GPOs  are applied is from the highest number to the lowest number.  So in this case, the Audit Logon Events GPO will apply before the Disk Quote (Accounting) GPO.  If you want to alter this order, all you need to do is

select the GPO you want to move and use the arrows on the left-hand side of the screen to move it up or down in the list.

Filtering a GPO

Before we go any further, we need to look at two more concepts that will determine whether GPO settings are applied to your client.  The first is GPO Filtering.  This feature allows further granularity in the way that GPOs are applied in your environment.  Even when a GPO is linked within a part of your directory (say, an OU) you may not want that GPO to apply to every object within that container.  You can control this by assigning permissions for who can process your GPO.  This is known as filtering.

When you filter a GPO, you specifically designate which users, group and computers are allowed to apply a GPO.  For example, you may only want the team leads within the Accounting group to get 100 MB of disk space for their disk quota, so you decide to configure a group called Team Leads – Accounting and filter the GPO on that group.  If you did this, it would look like the following:

You’ll notice that in the Security Filtering pane we now have only the Team Leads-Accounting group.  This means that even if an object is within the Accounting OU, it will not apply the Disk Quota (Accounting) settings unless it belongs to the Team Leads – Accounting group.

NOTE: It is easy to allow your GPOs to become VERY complicated very quickly through the use of security filtering.  Use of security filters should be carefully planned beforehand (as should everything with your Group Policy infrastructure).

Security Filtering Under the Hood

Though we can certainly add and remove users, computers and groups from the securtiy filtering window in the GPMC, it’s also helpful to know what’s actually happening under the hood when we do this.

In order for a GPO to apply to an object, that object must have two rights over that GPO.  These are:

Read Apply Group Policy

When a user, computer or group is added to the security filtering window, it is being granted these two rights (and vice versa).  To see the exact permissions being applied via security filtering (and to get to the security properties of a GPO in general, do the following:

1. Within the GPMC, select the GPO you’re interested in and choose the Delegation tab in the right-hand pane.

2. Within the Delegation tab, select the Advanced… button in the lower right-hand corner.

3. Select the object of interest in the Group or user names: pane and look at the permissions assigned in the lower pane.

The following shows an example of what I’m talking about:

You can also manage permissions directly in this window and that’s how we used to have to do it before the GPMC came along.  But unless you have some specific need to make changes here, it’s generally better to simply add/remove objects in the Security Filtering window.

WMI   Filtering

WMI stands for Windows Management Instrumentation and it’s been created as a way to specify and act on computers based upon chosen characteristics.  Examples of this would be computers running the Windows 7 Operating System, computers with a particular brand of motherboard or with a certain size hard drive, etc.  In short, it’s a way to say “I am only interested in these specific computers”.  Group Policies allow you to use WMI queries to specify in a very granular way which GPOs will apply to which computers.  You’ll need to learn how to write a WMI query, but if your environment has a need for this level of granularity, the functionality is present.

To write your own WMI Filter, you’ll need to create the filter and then apply it to your GPO of choice.  To do this, take the following steps:

1. In the GPMC, right-click the WMI Filters node and select New…2. Give your WMI Filter a name and a description and then select Add.3. Make sure the Namespace window shows root\CIMv2 and then type your

query in the Query window.4. Save your query (you will see the query appear in the right-hand pane as

well as beneath your WMI Filters node on the left of the GPMC).

Now that the WMI Filter has been created, you can apply it to the GPO of your choice by doing the following:

1. Select the GPO of interest and choose the Scope tab in the right-hand pane.

2. At the bottom of the Scope pane, locate the WMI Filtering section.3. Select the drop-down box entitled This GPO is linked to the following WMI

filter:4. Choose the WMI filter from the provided list (when you select it, you’ll get

a pop-up confirming you want to change the WMI filter for this GPO.  If you’re sure, select Yes).

At this point, the WMI filter is assigned to your GPO and only those computers meeting the specifications of this filter will receive the GPO.  Because WMI filtering can become very complex, it is always a good idea to thoroughly test these settings before applying them in production.  If the computers which are the target of your filter aren’t receiving the GPOs they should, it’s likely that the filter has been written wrong.

NOTE: Even if you write a WMI query to include a particular computer object, it will still need to have ‘Read’ and ‘Apply Group Policy’ permissions over the GPO in order to apply its settings.

Inheritance, Blocking and Enforcement

The second concept that we need to address is the idea of GPO inheritance and the ways administrators can control whether a higher-level GPO is applied to the objects further down in the directory.  This can become especially relevant when you have a large number of GPOs and you don’t need the clients within a particular OU to apply all of those settings (applying all of those settings requires more time for your client to start, after all).

Going back to our example above, let’s assume that the members of the Accounting OU don’t want the Event Log Size GPO to apply to their client machines for some reason.  Unless something is done to prevent it from applying, its settings will go into effect on client machines in the Accounting OU.  You could make the decision to create a second GPO to overwrite the settings in the Event Log Size GPO, but then your clients have two GPOs to process, one applying some settings and the other removing those same settings.  It seems a bit cumbersome.  Thankfully, there’s a better way.

Instead of creating yet another GPO whose purpose is to undo the settings of a higher-level GPO, administrators have the ability to block higher-level GPOs so that they don’t apply to your OU.  It’s important to note that when you choose to block higher-level GPOs, you are blocking all of them.  So any GPO that is inherited will no longer apply.  Only those GPOs that you configure directly on your local object will apply (if you create child OUs, inheritance will apply to these, starting at the parent OU where the blocking is in effect).

A couple of screenshots should help explain this.

In this screenshot, you can see how to block inheritance of higher-level GPOs.  All that is required is for you to right-click the OU (in this case, the Accounting OU) and select Block Inheritance.  A check will appear beside it and all higher-level GPOs will be blocked from applying within your OU or any child OUs you might configure.

Below, we see a before/after picture of the GPOs that will apply to the Accounting OU:

Before we block inheritance at the Accounting OU, we can see that 4 policies will be applied (starting with the bottom and working up).  These are:

Disk Quota (Accounting) Audit Logon Events Event Log Size Default Domain Policy

As already mentioned, these policies apply from the bottom to the top.  So, for example, if a setting in Default Domain Policy conflicts with a setting in Audit Logon Events, the setting in Audit Logon Events will win.

By contrast, after we set Block Inheritance, we can see that the higher-level GPOs no longer apply to the Accounting OU:

Here only the policies specifically defined for the Accounting OU will be applied (again in bottom-to-top order).  You will also note that there is now a blue circle with an exclamation point showing next to the Accounting OU.  This is how the GPMC notifies you that Block Inheritance is in effect.

For the sake of clarity, let’s look at one final screenshot to clear away any lingering questions.  We’ve said that any inherited GPOs are blocked when Block Inheritance is set.  But even with this setting in place, child OUs created beneath the blocking point will still inherit everything from that point on down.  In our example, this means that if we create a child OU under the Accounting OU, it will inherit the policies created at the Accounting OU as well as any GPOs linked directly to the child OUs.  We can see this in the following screenshot:

Here you can see that I’ve created a child OU called Accounting – Europe along with a new GPO called Retain Security Log (maybe we’ve got a security investigation going on in our European office and we have to be sure that security log isn’t overwritten).  You can see from this screenshot above that, even with Block Inheritance set, the GPOs from the Accounting OU (though none above the Accounting OU) still inherit to the Accounting – Europe OU.

Finally, to throw one more bit of complexity into the mix, let’s assume that you’re the domain administrator and you want to make sure that none of the admins responsible for any of your child OUs is able to block a particular GPO.  It turns out that you have the ability to force all of your clients to receive your policies even if they want to block them.  This process is called Enforcing.

Looking at the screenshot below, we can see that if we want to enforce a particular policy, we just need to right-click it and choose theEnforce option. 

When we do this, a small lock symbol will appear beside that GPO to let us know it’s being enforced.

One a GPO is enforced, it overrides any attempts to block it, as we can see below.  Here, the Accounting OU still has blocking set but we can now see that the Default Domain Policy is once again being processed within that OU.  To help us to understand why it’s being processed even when blocking is in place, the GPMC lets us that it’s being (Enforced).

Before leaving the topic, here are a couple of additional notes about enforcement.  First, when a policy is enforced, its settings will be applied last as the screenshot above shows.  This means that it will override even GPOs that are created and linked closer to where the user or computer object is located.  If it contains a setting and a GPO closer to the client object contains a conflicting setting, the enforced setting will win.

Second, if you have multiple enforced policies the one higher up the OU tree will have its settings enforced over ones lower in the tree structure.  To illustrate this, look at the following screenshot.

What I’ve done is to create 3 OUs (OU1, OU2 and OU3) and link 1 GPO to each of them as you can see in the left-hand pane.  Then I setBlock Inheritance on OU3 and configured GPO1 and 2 to be Enforced.  Default Domain Policy is still being enforced from our previous example.

In the screenshot, you can see that the order of precedence is actually reversed from what you would expect (where the GPO closest to the client object is applied last).  Instead, these rules apply:

1. GPOs without enforcement set are applied first, using the normal precedence rules

2. GPOs with enforcement set are applied last, with their precedence rules reversed

So we see that even though the GPO named GPO3 – Linked to OU3 is is applied directly to OU3 it is applied first and will have its settings potentially overwritten by the GPOs applying later.  Then GPO2 – Linked to OU2 is applied followed by GPO1 – Linked to OU1 and finally Default Domain Policy.  If enforcement was not in place, we would expect it to be the exact opposite, but with enforcement in place the rules of precedence are reversed

Resultant Set of Policy

Resultant Set of Policy is the phrase that is used to indicate which policies apply to client machines and users.  When the settings of all your GPOs have been sorted out and the system knows which policies need to be applied based on the rules you’ve put in place, the Resultant Set of Policies is that list of settings.  In this section, we’re going to spend a bit of time talking about two tools that will help show you what policies will apply to a particular client.  One of them even allows you to model which settings will apply before you put them into production, so it serves as a great planning and troubleshooting tool.

GPRESULT

I’ll start with GPRESULT because it’s been around longer and is the command-line tool you’ll use to see which policies are applying to your clients.  GPRESULT was originally included as part of the Windows 2000 Resource Kit, but is present by default in both Windows 2003 and 2008.  You can read about the various things you can do with this tool by opening a command prompt and typing

gpresult /?

While GPRESULT can be used for a number of things, our purpose here is to use it to generate Resultant Set of Policy data.  Specifically, we’re going to look at the following combinations of commands:

gpresult /R

By using the /R switch with nothing else, summary data for the various policies and settings will be printed to your command prompt.

gpresult /V

This is the same as the /R command, only the results will be verbose.

If you don’t want all of the settings, you can set the /SCOPE option and choose either USER or COMPUTER, which will result in only the User or Computer node settings being returned.

If you want to save the results to a file, you can do so by either piping the results to a text file using a command similar to gpresult /R>c:\gpresult.txt.  Another option is to create your output in HTML format by typing gpresult /H <filename.html>.

Below are sample outputs in both the .txt and .html formats

GPResult.txt

GPResult.html

Resultant Set of Policy (RSOP)

The newer tool that’s been created specifically to see Resultant Set of Policy for your client is called, oddly enough, Resultant Set of Policy.  You access this tool by taking the following steps:

1. From your client machine, go to Start/Run and open a blank MMC by typing mmc.exe.

2. Within the blank MMC console go to File and choose Add/Remove Snap-in….

3. From the Add or Remove Snap-ins window, scroll down until you see the Resultant Set of Policy snap-in.  Highlight it and select theAdd button.

Select OK and you’ll be looking at the Resultant Set of Policy tool.  Not much shows in the window at first, but we’ll quickly change that.  To see policy settings, the tool will need to gather data.  It does this through a wizard that is started when you select Action from the menu bar and choose Generate RSoP Data…

When generating your RSoP Data, you can choose Logging or Planning mode.  If you choose Planning mode, the system will show you what settings would apply if an object were located at a particular place in your directory structure.  This is a great “what if” tool in cases where you’re considering migrating objects to new containers within Active Directory and you want to know what effect this will have on them from a Group Policy perspective.  Planning mode is also great in a test environment where you’ve configured the directory and GPO structure that you think will do what you need.  Using this tool, you can generate the resultant set of policy which will show you the settings that will take effect on your client objects.  If the settings aren’t what you expect, you can make the necessary changes and test again.

The other way to use the Resultant Set of Policy tool is in Logging mode.  This mode will review the settings currently being applied to a particular computer or user (or both).  You can select either the local computer or a remote device and when the wizard runs the results will display the resultant policy settings that are applying to that device.  This is especially useful when you’re trying to understand whether a particular setting should be applying to a computer or user.  If RSOP doesn’t show the setting, it may mean something has happened in your GPO implementation that is preventing that setting from taking effect.

A screenshot of what the RSOP tool looks like is below:

Resultant Set of Policy is a powerful tool that is especially useful in understanding ahead of time what settings will apply to objects before you make modifications to your directory.  It is also very useful as a diagnostic and troubleshooting tool (though I personally prefer GPRESULT since I don’t have to drill down through as many containers if I’m looking at the report in the command line or a text file).

Summary

So now you should understand how a GPO determines which GPOs it should process and how to find them (through the gPLink attribute).  You should also understand the order in which they are processed, how decisions are made about which policy settings to apply when there are conflicts, and how to block and enforce settings within your environment.  I also showed how to use a couple of tools to see which policies should be applying to your GPOs, which will be helpful to you when understanding and troubleshooting policies in your environment.

Group Policy Basics – Part 3: How Clients Process GPOsSo 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 separately4. 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 00012. 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.