AD DS: Group Policy Basics - Part 2: Understanding Which GPOs to Apply

In 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 clients 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 it needs to process its local GPO, it's not as clear as to 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 Win8is within the Computers OU that is part of the cert.local domain.  This is represented by the following distinguishedName: CN=Win8,OU=Computers,OU=Lab,DC=cert,DC=local. Though we don't see it on this screenshot, the Win8 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 Computers 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 (known as the Local Policy)
• 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 Computers 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 functions so I won't cover that again.  Instead, 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 business 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 are still using the Computers OU that we leveraged before, but now we have created a new GPO called Disk Quota (Accounting) that we've linked to it as well.  At this point, objects within the Computers OU will have the following GPOs to apply:

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

Briefly, let’s look at the Disk Quota settings in both the Default Domain Policy and the newly created Disk Quota (Accounting) policy.

First, on the Default Domain Policy, we can see that we have assigned a value of 50MB which applies to the entire domain.

By contrast, here are the settings applied to the Disk Quota (Accounting) OU.

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 should overwrite it because it's applied last.  But can we confirm that?  To do so, it’s as easy as logging into a client machine within the scope of both of these policies to see which one has taken effect.

By using the MMC Snap-in known as the Resultant Set of Policy (RSOP), we can see what the currently applied settings are for our test computer as well as which GPO provided the settings:

When I ran RSOP from my Win8 device, I was able to verify that my Disk Quota settings did, in fact, come from the Disk Quota (Accounting) GPO and that the effective setting was 100 MB.

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, as we have in the Computers OU?  How do we know which GPO will apply first and which one will win if they have competing settings (in our examples, the GPOs do not have competing settings, but in the real world this is always a possibility)?  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 if needed.  The following screenshot shows two GPOs that will be applied at the Computer 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 Disk Quota (Accounting) GPO will apply before the Event Log Size GPO.  If you want to alter this order, all that’s needed is to 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, groups 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 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 group.  This means that even if an object is within the Computers OU, it will not apply the Disk Quota (Accounting) settings unless it belongs to the Team Leads 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 security 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.  WMI is not a Microsoft-specific thing, but is an industry standard that Windows leverages.  Within Windows computers, there are thousands of management settings which an admin may want to access.  WMI provides a central repository for that information to allow easy (well, somewhat easy) access.  From within the repository, standardized ways exist to locate and leverage the available management data.

Examples of the type of data stored in the WMI Repository would be information relating to a computer’s BIOS, its physical disk layout, aspects of its desktop or the services it has running.  GPOs can leverage WMI filtering so that only computers meeting certain criteria (running a specific motherboard, for example) will process a GPO.  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 (using the WMI Query Language, or WQL, which is similar in structure to the SQL language), 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:

• In the GPMC, right-click the WMI Filters node and select New... as shown below

• Give your WMI Filter a name and a description and then select Add.

• Most of the time you will want your Namespace to be root\CIMv2, though many different namespaces exist within the WMI Repository depending on the individual computer’s configuration.  You can see this by clicking the browse button and scrolling through the various namespaces present in your WMI Repository

• Once you have selected the Namespace, type your query in the Query window as shown below

Note that this WQL Query will find Windows 8 Computers and filter out anything that does not meet this criteria.  If you don’t know WQL (and most don’t, which is why WMI Filters aren’t used that much), I highly recommend the book PowerShell and WMI by Richard Siddaway.  This is an excellent way to learn about WMI and how to manipulate it with PowerShell.

After you have completed these steps, save your query.  The query will appear in the right-hand pane as well as beneath your WMI Filters node on the left of the GPMC as shown below:

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

• Select the GPO and choose the Scope tab in the right-hand pane
• At the bottom of the Scope pane, locate the WMI Filtering section
• Select the drop-down box entitled This GPO is linked to the WMI filter you just created

The screenshot below illustrates this:

 

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).

To extend our example above, let's assume we have a child OU under the Computers OU.  Lets call it Executives, and let’s say we’ve decided to move our Win8 computer object into this OU (it belongs to our CEO and needs to be handled more carefully).  We have made a decision that the members of the Executives OU should not have the Event Log Size GPO 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 Executives 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 Executives 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 Executives OU:

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

• Event Log Size
• Disk Quota (Accounting)
• 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 Disk Quota (Accounting) , then the setting in Disk Quota (Accounting) will win.

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

As can be seen from the screenshot above the previous policies in the Group Policy Inheritance tab are missing.  I have also created a new GPO called Audit Accounting Events and linked it directly to the Executives OU (if I had not created this new GPO linked directly to the Executives OU, the Inheritance tab would have been blank.

Now that blocking is in place, only the policies specifically defined for the Executives OU will be applied (again in bottom-to-top order if more than one GPO is linked directly to this OU).  You will also note that there is now a blue circle with an exclamation point showing next to the Executives 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 beneath Executives called Executives - Europe along with a new GPO called Retain Security Events (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 GPO from the Executives OU (though none above the Executives OU) still inherit to the Executives - Europe OU and are applied from bottom to top so that the GPO linked directly to the Executives – Europe OU takes precedence.

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 (you’re not a big fan of them choosing to block your GPOs at the Executive OU level).  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 the Enforce option (note, this is done on a per-policy level so every policy you wish to be enforced will have to be configured this way individually).  When we do this, a small lock symbol will appear beside that GPO to let us know it's being enforced.

Once a GPO is enforced, it overrides any attempts to block it, as we can see below.  Here, the Executives 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 notifies 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.

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

For our example, the Executives – Europe OU applies its GPOs as follows:

1. Audit Accounting Events (inherited from the Executives OU)
   1. Note that due to blocking being in place we do not start with GPOs higher than the Executives OU in this case
2. Retain Security Events (linked directly to the Executives – Europe OU)
3. Event Log Size (linked to the Computers OU)
4. Default Domain Policy (linked at the domain level)

The normal order of precedence  is in effect until the enforced GPOs are considered and then the order is reversed for each enforced GPO (note the GPOs above the point of blocking which are not enforced are never processed).

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 starting in Windows 2003 and continuing in Windows 2008/R2 and 2012/R2.  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 multiple purposes, our need here is 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> .

To get the Resultant Set of Policy (RSOP), I will run the following:

gpresult /R>c:\scripts\gpresult.txt

I will also run it a second time and specify the output should be HTML format using the following:

gpresult /H>c:\scripts\gpresult.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 the Add 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.

In the next post I'll finally get to Client-Side Extensions (CSEs) and we'll try to wrap this series up.