I have been administering Active Directory for at least 10 years now, and one of the main questions I get in relation to that, is Active Directory Group Policy. (GPO). If you are unfamiliar with Group Policy, it is essentially a method to deploy settings and configuration to domain connected clients. It is one of the most widely used methods to control access to computers, users and resources, especially in a Role Based security model. In this article, I’m going to attempt to explain GPOs a little bit better, so that you can understand how it actually works, what causes it not to work, and how to troubleshoot it. Obviously, by no means does this article cover everything you need to know about GPO. This would take a full blog on its own. If you are interested in digging deeper, there are a lot of good blogs out there. Here are two: HERE and HERE. Now let’s get on with this…
The bad news is that GPOs are inherently complex, and in a large environment, can be even more so.
The good news is that there are a nice set of tools which will help with the troubleshooting of these GPOs. The newer the tools, the more elaborate and informative they become. Most recently, the RSAT 8 tools have some really nice improvements, so, if you happen to have already moved to Windows 8, I encourage you to use these tools. 95% of their functionality will work on as far back as Active Directory 2003.
The Group Policy Object:
For each Group Policy Object (GPO), there are different sections that target different parts of the end client:
This section contains settings that apply to the computer object. This is a section best configured when attempting to setup configurations that are independent of the user logged in. These GPOs are generally linked to an Organizational Unit (OU), which contains computer objects.
This section contains settings that apply to the user object. This is a section best configured for items that are user specific, for instance, setting up Internet Explorer preferences, or Folder Redirection, etc … These settings should always be available to a particular user, regardless of what computer they are logged on to. Typically, configurations within this section are linked to an OU with user objects in it.
Each of the above section has a sub section called: “Policies”, some of those are common to both computer and user configurations, however, some others are you unique to either computer or user configuration.
If you are using the newer admin tools (i.e: RSAT 7 or RSAT 8), you will notice an additional section, which has proved to be tremendously useful in controlling different parameters of an end user’s workstation or account. That section is called “Preferences”. Inside that section, you will find preferences that allow you to manage files, folder, shortcuts, registry entries and much more.
How to set it up and apply it:
Understanding each policy item is actually fairly simple, as everything is explained in very good detail. The problem arises when it’s time to create the policies, and link them to OUs, and scope them. The culmination of these 3 steps will result in a successfully applied policy.
If you look at Fig 2. you will notice that the scoping of a GPO has many layers. that said, you can use a minimal set, and still have a working GPO. However, in a later section, I will tell you why this may not be a good idea.
If we were to address the minimum requirements for a working GPO, then, we would have a couple of things in place: Assuming the GPO has both Computer, and User configurations, the GPO would have to:
- Be linked to the OU in which the computers reside
- Be linked to the OU in which the users reside.
- Have at least the “Authenticated Users” group available in the bottom section of the scoping.
The first 2 points, will allow the GPO to apply its appropriate sections to the appropriate object types. ONLY IF 3 is correctly scoped. So, for instance, if you have 1 and 2 in place you don’t have anything in the user / computer scope (the bottom section), the GPOs will simply not apply.
In some cases, you would be creating a Computer Policy without a User Policy, or vice versa. Here is a couple of tips that I found to be useful:
When creating policies, try to group them by their function, for instance, create one called: CMP_Enable Windows Updates or USR_IE Favorites, or PREF_Create Training Shortcuts. These will respectively correspond to a computer policy (hence the CMP), a user policy (USR), and a preference policy (PREF). For the former two, it is best practice to disable the unused policy from the details tab of the policy in Group Policy Management Console (GPMC). This will help speed up the processing of policies when being applied to the client.
Why Scope it?
So at this point, you may be wondering why you need to scope beyond authenticated users when simply linking the GPO to the OU will target that specific OU, and therefore does inherent scoping. There is a very good explanation to this, though, be forewarned, that if your structure is not setup for it, starting to scope GPOs will require quite a bit of prep work in your Active Directory environment. This means, that you will have to create security groups for both your users, and computers, and place the appropriate users and computers in these groups, before you can do any GPO scoping at that level. If you have been diligent in doing this in your AD from the beginning, then I congratulate for the discipline, and you are now ready to setup specific scoping for your GPOs.
Now, to answer the question, I will use an example.
Consider the OU example in Fig. 1 where the parent OU is “Test”, and there are Teachers and Workstations OUs. let’s take the workstation example, and the same concept will apply to the users. So, let’s assume that in the “Workstations” OU, we have 45 computers. comp01-comp45. Residing directly in the Worstations OU, and another 5 computers residing in the “Aeries Workstation OU”. The GPO, applied to the “Workstation” OU, targeting the “Authenticated Users” group, will effectively apply to the computers in the “Workstations” OU, as well as the one in the “Aeries Workstations” OU.
Let’s say you don’t want to apply the GPO to “Workstations” OU, but only to “Aeries Workstations”. That would be simple, you would just unlink the GPO from the “Workstations” OU, and link to the “Aeries Workstations” OU. What if, however, you wanted to do the opposite, where you want the OU to apply to the “Workstations” OU, but NOT to the “Aeries Workstations” OU. At this point, you have a couple of options:
- You would have to relocate the “Aeries Workstations” OU, to a place outside of the “Workstations” OU. Organizationally, this may not be a possible solution.
- Find a way to exclude the “Aeries Workstations” OU from the GPO.
Unfortunately for us, GPOs always work on an “inclusion” basis rather than exclusion. They don’t even allow exclusions. This means, that in order to scope only the “Workstations” OU, and exclude the “Aeries Workstations” OU, we would have to scope the GPO to include what we want, and what’s not included is automatically excluded.
To do this, create a security group in AD, and place comp01-comp45 inside that group, then add that group into the scope of the GPO, also, remove the “Authenticated Users” from the group, or you may be in for a surprise 🙂
So with that example, you should now have a much better idea as to why scoping a GPO is so important. Now, think about this when you have really big OU structures, and GPOs connected to them. So, whenever possible use this method to deploy your GPOs.
As a side note, and advantage of this method, you will have an added bonus to be able to remove a single computer or user from a security group, thereby disallowing the GPO from applying to them. This can prove very useful when you’re troubleshooting. Otherwise, you’d end up having to move the object to outside the OU, block inheritance, and selectively apply the GPO. That would be a mess, and a waste of time, so, do the leg work upfront, and save yourself the trouble in the future.
The above should at least give you a good idea on how to setup the GPOs, and have a basic understanding of their working. Now, let’s move on to the part where most people get really confused, and rightly so, especially if troubleshooting GPOs in a large environment where there are multiple domain controllers, and replication.
This section on its own probably deserves a whole book, but I will try to be brief and to the point.
For troubleshooting GPOs, there are a few tools that are absolutely necessary and useful:
Group Policy Management Console (GPMC) If you were using the traditional GPO management using Active Directory Users and Computers (ADUC), then stop now. GPMC is your friend, and allows you to see all sorts of additional information that the regular group policy editor cannot. You can very easily view the scope of the policy, the details as to the status of replication, what configurations are applied, and the last update, the details, which give you the actual settings in that GPO, the delegation, and a new feature “status” in RSAT 8. That last one will only work with Server 2008, or servers which have PowerShell and WinRM2 installed. You can obtain the GPMC for Windows 2003 from HERE. It is also part of the RSAT 7 and RSAT 8
GPUpdate, GPResult and RSOP.msc: These are tools that exist on every workstation, be it XP, Windows 7 or Windows 8. (Windows 2000 has a different command, which we won’t cover here).
- gpupdate allows you to refresh the group policy on the user computer. you can target the refresh of the computer config, user config, or both. (i.e: gpupdate /force /target:computer)
- gpresult lists out the existing applied (and/or not applied or denied) policies, the user group memberships, connection speeds, and the server from which the group policy was applied. This last piece of information is extremely important in a replicated environment. Not understanding this is the single biggest cause of frustration of admins. Note that commands like set l, and echo %LOGONSERVER% which return the domain controller which authenticated that user/computer do not return the correct result for the domain controller from which the GPO was pulled. For this information, either check GPresult, or, on Windows 7 and Windows 8, you can run the following command: nltest /sc_query:
- RSOP.msc provides some of the information of GPResult. In addition, it also lists out the effective policies currently being applied to the workstations. This information can be very useful, when trying to figure out whether a change has taken effect.
GPOTool: This tool is part of the Windows 2003 Resource Kit Tool, and can be found HERE. This, according to Microsoft is no longer supported, as there has been new changes in GPO that the GPO tools sometimes doesn’t catch. However, I have been using the tool for a while and it is very useful in determining the health of your GPOs. There is another tool which seems to work pretty nicely as well, it is made by SDM Software. It’s called the GP Health Reporter. You can download it HERE.
More important than the tools, is the process by which you proceed to troubleshoot your GPOs. The main thing to be aware of in this scenario is this: are you actually making changes on the server from which the machine is getting its GPOs? If not, then, are you waiting long enough for replication? If you are, and you’re still not able to get changes working, then you might want to use the GPO tool or the GP Health Reporter, to see whether there is an issue with replicating these GPOs to your other servers. Obviously, and we won’t get into this, you need to make sure that your replication is working correctly, your DNS, and other basic infrastructural components.
When a GPO is not applying, here is my process in order, which almost invariably gets me to the root of the problem. Brace yourself, this is a bit of a long list, you should have it handy and/or memorize it.
- On the workstation in question: run gpresult, and rsop.msc.
- Where is the server from which the GPO is applying?
- hint: check the gpresult output for this, or run nltest /sc_query:
- If your GPMC is not connected to the same server as the workstation in question, go ahead and do so.
- Upon reboots, always check the active GPO server, as this can change from one reboot to the other, always make sure that these match.
- Where is the server from which the GPO is applying?
- Check the GPO in question, and verify that it is fully replicated, by using the GPO Tool, or the GP Health Reporter. Another easy way to check, especially if you don’t have to worry about replication temporarily when connected to the direct server providing the GPO to the client, would be to click on the “Details” tab in GPMC, and check the “User Version” and the “Computer Version”. Both SYSVOL and AD numbers should be matching. If not, then there may be some problem with the GPO itself.
- Check the scope and the OU on which the GPO is applied. Make sure that if there is a User Configuration, that the GPO is linked to a user OU, and if you are using user scoping, that the user does in fact exist in the security group to which the GPO is scoped. Same applies for computers.
- If you are unsure, check whether the GPO uses the Loopback Processing Policy. This is a bit of a longer discussion than I’d want to get into now, but it is important enough to check for it. Please click on the link for quick information about it.
- Make a small and obvious change to the GPO (something that you can see easily when the GPO applies (i.e wallpaper, or add an icon or something). I use this as my indicator that the GPO change has applied. You can revert that change once you’re done with the troubleshooting.
- Force an update on the client. (i.e: gpupdate /force)
- Run rsop.msc, and check whether there are any GPO errors. In the same manner, drill down to the policy you’ve changed, and check whether it applied.
- If not, navigate to eventvwr.msc , and check the Application log for any Group Policy related errors.
If you follow these steps systematically, you will almost invariably find the issue that you’re dealing with, and resolve it. One more item to this, is patience. Sometimes, the lack of it gets the best of us. If a policy didn’t apply immediately, and you’re almost sure that it should’ve applied, do an extra gpupdate , logoff, reboot, or all of the above. Some policies are more picky than others, some can apply immediately, others (usually user policies, require a log off), and yet others (like software installations) require a full reboot.
As I mentioned in the beginning, this only scratches the surface of policies, but I hope that I was able to help you have a better understanding on how it works, and how to effectively troubleshoot it without feeling like you’re spinning your wheels with no results.
As always, if you have any questions regarding this, or if there is a GPO related topic that you’d like me to write an article about, please chime in the comments.