This is the 199th article in the Spotlight on IT series. If you'd be interested in writing an article on the subject of backup, security, storage, virtualization, mobile, networking, wireless, DNS, or MSPs for the series PM Eric to get started.
I started working in IT support pretty much as soon as I left school at 16, and I’m glad I did. Since that fateful day eight years ago, I’ve worked on everything from desktop support to managing Microsoft SCCM to setting up new AD domains from scratch.
But one area that has always been of particular interest to me has been Active Directory and Group Policy, and over the past few years I’ve learned quite a lot about the technical details behind both. Group Policy is so widely used in AD domains these days that I think it’s crucial to have a good understanding of it — especially in larger networks where changing something without understanding the potential side effects can cause big problems.
If you’re anything like me, you probably enjoy learning about the nuts and bolts that make things work, so this post is focused on how GPOs actually work and how different parts work together to make the magic that is Group Policy actually work.
What is a GPO really?
A GPO (Group Policy Object) is made up of two things: an object in Active Directory and a folder in the domain’s SYSVOL share. You can view the latter by simply browsing to \\YourDomain.local\SYSVOL and then going into the Policies folder. Each of the folders in there represents a GPO in your domain — they’re named with the GUID of that GPO (you can see a GPO’s GUID by selecting it in the Group Policy Management Console, clicking on the Details tab, and looking at the Unique ID field).
If you look in these folders you will see a MACHINE and USER folder (more on that later) and within each of them the files will vary depending on the settings that have been used in that particular GPO. Some settings are stored in relatively simple INI files, others are much more complex. It’s up to the CSE (Client Side Extension — more on that later also) that processes that particular GPO setting to parse these files and perform actions based on their contents.
As for the other part of a GPO (the object in AD), that can be viewed by using a tool like ADSI Edit to view the objects in the following location: YourDomain.local\System\Policies. Again you will see each GPO named with its GUID, and if you view the properties of one of these objects you will see several key bits of information that make everything work the way it does.
I’ll highlight some important ones and explain them:
- DisplayName: The friendly name you see for a GPO in GPMC instead of a GUID (e.g., Default Domain Policy).
- GPCFileSysPath: The path to the SYSVOL folder that this GPO is stored in.
- VersionNumber: This is actually a combination of two numbers — the version number of the user section of the GPO and the version number of the computer section of the GPO. The fact that they are actually two separate 16-bit numbers stored next to each other in one 32-bit number is what makes the value seem completely random when viewed as a normal 32-bit number. (Explaining this in more detail is beyond the scope of this article.) These version numbers are important as a Windows client will only apply a Group Policy setting if it thinks the GPO has been changed since last time it applied it. Every time you modify a GPO through the Group Policy Management Console the relevant section’s version number is incremented so that all clients know to apply this GPO again.
- GPCMachineExtensionNames: This list of GUIDs specifies the Client Side Extensions that should be used to process this GPO on the client and also the MMC snap-in that’s used to edit those GPO settings.
- GPCUserExtensionNames: Same as above but for the user section of a GPO rather than the computer section.
User and Computer sections
This is something I see a lot of people misunderstanding so, though it’s fundamental, I think it’s worth explaining.
As mentioned above, a GPO is split into a User section and a Computer section. Any GPO can store both User and Computer settings in it, but personally I think it would have been better if when you created a GPO you had to specify if it was going to store User or Computer settings. Unfortunately, though you can indeed have both in the same GPO, this leads to some confusion. It sounds obvious, but anything under the Computer Configuration section of a GPO will only apply to computer objects in AD, and anything under the User Configuration section will only apply to user accounts (unless you enable loopback processing). So if you have an OU that only has user accounts in it, any computer based settings in GPOs linked to this OU will not have any effect. I would advise just sticking to one set of settings (User or Computer) in each GPO, making sure you go into the Details tab and disable the side you aren’t using as this improves GPO processing performance.
When user-based settings are applied, any scripts or programs launched from GPO settings will usually run in the user’s security context (although it is up to the CSE processing the GPO to decide if it wants to run in the user’s context, as by default they will all be running as the Local System account). Launching scripts and programs from computer-based settings always means they will be run in the Local System security context, which means they have full admin permissions and will run in a separate session that can’t be seen by the user.
Policies vs. Preferences
Most people are now familiar with the GPO “Preferences” feature that was added in Server 2008/Vista, allowing you to do lots of very useful things with GPOs that you couldn’t previously do without writing scripts — like map network drives based on group membership, install printers, create VPN connections, adjust power settings, etc.
However, there is often still a misunderstanding of what the difference is between a Preference and a normal GPO setting, referred to as a Policy. There are two main differences. Firstly, a preference isn’t enforced. That is, there’s usually nothing stopping a user just changing or deleting whatever it is that the preference modified or created. It’s called a preference because you as an admin are saying you would prefer that this item existed on all computers/users in the GPO’s scope but you aren’t able to say that this must exist.
With a Policy however, the setting is enforced and the user can’t change whatever it is that you have set via this GPO — unless they have local admin permissions and know which registry key to modify to change the setting you set via GPO.
For example, if you enable the Windows Firewall via GPO, even a local admin user can’t turn it off through control panel. Note though that this is entirely down to the program that this Policy affects behaving “correctly.” A poorly designed program could still allow the user to change a setting that was set via a GPO policy, but in reality GPOs are commonly only used to control Windows settings rather than third-party program settings, so there is little risk of this.
The second difference between a Preference and a Policy is that a Policy will automatically be reverted back to its default setting when the GPO is no longer applied to this user/computer — it does not “tattoo” the registry. For a setting to be considered a Policy it must store its data in the following registry key: HKLM\Software\Policies or for user based settings: HKCU\Software\Policies
GPO processing on the client
Workstations check for new/modified group policies every 90 minutes by default, with a 30-minute random offset to avoid every PC checking in at the same time if they were all booted up at the same time. As mentioned earlier, when a client processes GPOs, it remembers the version numbers of each GPO and then next time it checks for Group Policy updates it only processes GPOs that have had their version number incremented since last time. This version information is held in the following registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History (replace HKLM with HKCU for user-based settings)
So if you have an issue with a client not picking up the fact that a GPO has changed then you can always try deleting that History registry key so that the client processes all GPOs from scratch again. In theory, running “GPUPDATE /FORCE” should do the same thing (the /FORCE argument tells it to process all GPOs instead of just new/changed GPOs) but I have come across a couple of examples in the past where deleting that History registry key was the only way to get a GPO to update properly on a particular PC. You may also notice that there’s a GroupMembership registry key in the same location that caches the SIDs of all security groups a user is a member of, and, again, I have had to delete this in the past to force it to be updated correctly. Of course, this is a last resort and it’s rare that this is your problem. Usually a GPO not applying correctly is due to user error (in this case, the user being us administrators). See the troubleshooting section below for tools you can use to help find out why a GPO isn’t applying.
When a workstation has checked in for new/updated GPOs, it calls each of the CSEs (Client Side Extensions) that were listed in the GPCUserExtensionNames attribute on the GPO object in AD mentioned earlier (or GPCMachineExtensionNames if it’s processing computer policy rather than user policy). It’s the CSE that actually performs the work and does what you’ve asked the Group Policy to do (redirect a user’s folder, add a new wireless network, install a printer, etc.).
Windows comes with several CSEs pre-installed, but it’s possible to install additional ones — which is what you need to do with the GPO Preferences CSEs if you want the new GPO Preferences mentioned earlier to work on Windows XP machines. For each CSE that is installed, a registry key is created in the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
It’s the individual CSE sub keys in here that actually tell Windows what to execute when a particular CSE is required to do some work. Within each one is a value named DllName and a value named ProcessGroupPolicyEx. The DllName value specifies the DLL that contains the function code that will process this GPO, and the ProcessGroupPolicyEx value contains the name of the function within that DLL to call. When Windows calls this function in the specified DLL, it passes on information about the new/updated GPOs along with the user’s token and other information, as documented here: http://msdn.microsoft.com/en-gb/library/windows/desktop/aa374383(v=vs.85).aspx
Note that the majority of settings in the Administrative Templates section of a GPO are just registry settings so they don’t require a special CSE as Windows can handle simple registry writes itself without any additional logic or processing being required.
Troubleshooting
When troubleshooting Group Policies that aren’t applying, the GPRESULT command is usually my first port of call, as this will show all of the GPOs that have been applied along with any that haven’t been applied (and the reason why they haven’t).
You can also use the RSOP.MSC tool, and using Group Policy Modelling and Group Policy Results from the Group Policy Management Console can often help show you where your configuration is wrong and why a particular GPO isn’t applying or being overruled by another GPO.
Of course, the information provided in the earlier sections of this post can also come in handy when troubleshooting to confirm everything is as it should be.
It’s always worth checking the advanced permissions on a GPO as well, as the Security Filtering section of a GPO in GPMC doesn’t show you everything. It’s possible to deny users or groups permission to apply a GPO (useful if you want all users apart from a few to get a particular GPO applied and don’t want to move those users into their own OU) so check that as well by going to the Delegation tab of a GPO and clicking the Advanced button. Oh, and don’t forget to check the event logs on client PCs for useful information — some CSEs are very good at logging issues in there (like the folder redirection CSE, which also has its own verbose debug log file you can enable).
A lot of this information (and much more) can also be found in my video here. (Get comfy before you press play — it ended up being quite long!) And please note that everything I’m saying here is what I’ve learned from my own experiences, tests, and MS documentation — feel free to correct me if you know any of it’s not completely technically accurate. I’m always keen to learn more and don’t mind admitting when I’m wrong :)
I hope you’ve found this brief dip into the inner workings of Group Policy interesting. Let me know if you have any questions or comments.