“Under the Hood” of Group Policy

by [Published on 17 June 2010 / Last Updated on 17 June 2010]

Taking a deep dive into how the Group Policy engine works.

Introduction

People often ask me how Group Policy works. It’s not always from a standpoint of editing a GPO, checking check boxes for policies, and what each policy setting does, but  rather how Group Policy is intelligent enough to get from the boot process to the domain controller, to finding the right GPOs. Well, that is what this article is all about. We are checking “under the hood” to see how the Group Policy engine works. When you are done with the article, you should have a much better understanding of how and when Group Policy works and does not work. It is an excellent lesson in troubleshooting hard to reach Group Policy issues!

Initially, the Computer Boots Up

We will be discussing a desktop for your Active Directory infrastructure in our example.

Your Windows desktop boots up and must get an IP address. If the IP address is statically configured, the IP address configured for DNS “MUST” be the DNS server that supports the Active Directory itself. If the IP address is dynamic, the DHCP server must have all of the correct IP address info, including the IP address for the DNS server supporting Active Directory.

At this point, you have your desktop configured with the correct IP address information, which at a minimum would include:

  • IP address for desktop
  • Subnet mask
  • DNS server IP address for Active Directory

Talking With DNS

Now that the desktop has the IP address for DNS, it will use the NETLOGON service to communicate with the DNS server to find out the list of IP addresses for all of the domain controllers for the domain for which the desktop belongs. The domain controllers are listed in the DNS database under SRV (service resource locator) records. These entries are entered dynamically when the domain controller is upgraded from a server to a domain controller for that domain. (If using a DNS that does not support dynamic updates, then it would need to be input manually!)

The list of domain controllers is not arbitrary however, it is somewhat sophisticated. The list of domain controllers will be controlled by the Active Directory Site that the desktop is located in. Sites are controlled by the IP address subnets, configured by the Enterprise Admin after Active Directory is configured. The initial list of domain controllers returned from DNS will be those domain controllers in the desktops site. After this list of domain controllers will be the list of all other domain controllers in the domain.

For more details on this part of the process, check out this link.

Communicating with the Domain Controller

Now that the list of DCs is obtained, the desktop will now communicate with the domain controller to authenticate. This communication occurs via a secure channel between the desktop and the domain controller. The communication occurs through the shared folders available on the domain controller. These shares are the SYSVOL and NETLOGON shares. SYSVOL is C:\Windows\SYSVOL\sysvol and netlogon is C:\Windows\SYSVOL\sysvol\<domain name>\SCRIPTS.

The Group Policy Objects are stored under the SYSVOL share and the logon scripts are stored under the NETLOGON share. It is through this communication and share that the settings in the GPO are delivered.

Determination of Group Policy Objects

Since we are only talking about the computer (desktop) logon at this point, the only GPOs that matter are those that pertain to the Computer Configuration portion of all GPOs. The domain controller will determine which GPOs should apply to the desktop based on the desktops computer account location in Active Directory. It will also determine which site the desktop belongs to, so the GPOs linked to this site are also delivered to the desktop. The parts of Active Directory that matter for where the desktop exists include:

  • Domain
  • Site
  • Organizational Unit

All of the GPOs that are linked to the domain, site, and organizational unit where the desktop computer account resides will be delivered down to the desktop. (Of course, there are other factors that play into this list of GPOs. Security filtering, WMI filtering, nested OUs, etc.)

Keeping Track of GPOs on the Desktop

The list of GPOs that is delivered down to the desktop is tracked on the desktop, so that the next time the policies need to be refreshed, the desktop remembers what happened last time. This list of GPOs is tracked in the Registry. You can find this list in the Registry at:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

This list can be seen in Figure 1.


Figure 1: List of desktop related GPOs stored in the Registry

Notice that the list of GPOs uses the GUID of the GPO, not the friendly name of the GPO. This is common, as the operating system and Active Directory does not care about the name of the GPO, only the GUID.

Now, The User Logs On

It is pretty clear that the desktop has already received all of the GPO settings related to the Computer Configuration of the GPO, solely because it has booted up. However, that is only half of the picture. Now, the user must logon and receive the User Configuration portion of the GPOs that apply to where the user account is located in Active Directory.

Since the IP address information, DNS related communications, and connection to the domain controller is already established, that portion of the picture is complete. What is important is where the user is located in Active Directory, so the correct GPOs can be applied. When the GPOs are applied to the user account, the storage of them is similar to that of the computer, but they are stored under the HKEY_Current_User part of the Registry at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

Figure 2 illustrates what this list looks like.


Figure 2: User stored GPOs in the Registry

Group Policy Refresh

Each GPO has a version number, which is used during the background and even foreground Group Policy refresh. Both the client and the domain controller store this version number, so that at next refresh, it is simply a comparison.

For the client, this version number is stored in the Registry under the History\GUID number, from Figures 1 and 2. Figure 3 illustrates what the version number for one of the GPO GUIDs listed would look like.


Figure 3: Version number of GPO listed in Registry of desktop

The domain controller stores the version number in the GPT.ini under the GUID for the GPO in the SYSVOL. It also stores the version number in the Active Directory database with the object for the GPO. This ensures that both the SYSVOL and AD database are in synch with the correct version and data stored in the GPO.

Summary

The Group Policy processing is quite complex, with many moving parts. This discussion only discusses some of the high level aspects, where there are many more aspects that are under the hood. However, this should give any administrator a good idea of what is important during the logon process of both the computer and user, as well as where the Group Policy processing might fail. With so many moving parts, it is essential to track down all of the key configurations when you are troubleshooting GPOs. DNS, SRV records, SYSVOL, GUIDs, security filtering, WMI filters, location of objects in AD, etc. At any point the Group Policy settings you want can be altered, if the settings and locations are not correct.

Featured Links