What You Need to Know About Troubleshooting Group Policy to Pass a Microsoft Exam
If you work in the world of IT as a network admin, in a Windows-based domain environment, you are bound to have come across group policies (commonly referred to as GPOs or Group Policy Objects). When it comes to carrying out any network based task, whether it is mapping a network drive, changing security settings or installing software on multiple computers, GPOs are an excellent tool for the job. As a result, having good knowledge of group policy is essential for the day-to-day work of a network admin, and Microsoft make sure it plays a major part in both their core and design networking series of Microsoft certification exams. This includes setting up new group policies, choosing the appropriate level to assign them, as well as highlighting the integrated nature of group policy and an active directory domain controller. However, one of the most important parts of the group policy learning process is troubleshooting when they don’t work. In fact, you can often spend more time troubleshooting a Microsoft group policy than you do creating it in the first place. So in order to make sure that the troubleshooting element of your GPO studies is covered, here is a summarized checklist of what you need to know for your Microsoft exams.
Understand group policy
As with any Microsoft exam preparation, it is important that you get hands-on practice to back up your book knowledge. It is common to get simulation questions in the Microsoft networking exams that require you to setup a group policy and apply it at the right level to the right computers or users. I would highly recommend setting up a test server to practice on that allows you to get hands on practice with a domain controller and in this case the group policy management console (GPMC). This allows you to follow the practical exercises in your Microsoft press books so that you get confident in using the GPMC. Improve skills such as creating and linking group policies, and familiarize yourself with the hundreds of possible settings you can apply. Also make sure you understand the processing order that group policy follows. The natural order is to apply computer polices first, and apply user policies second (which makes sense as you turn on your computer, and the computer policies apply themselves, then as a user you logon and the user policies apply). This may sound like common sense, but it is a common mistake to apply a computer policy to an organizational unit (OU) of users! Also, when we discuss features like loopback processing later, this will be a key point to remember.
Now although group policy is covered in great detail in the Microsoft networking series, what actually makes up a group policy object isn’t. However, when it comes to understanding some of the troubleshooting elements of group policy, it pays to know a bit more detail.
In short, group policy objects (GPOs) are made up of two parts: the group policy container (GPC) and the group policy template (GPT). The GPC lives in the group policy container within the Active directory and acts as the reference point for the GPT, which stores the actual template settings for the applied GPO. The GPT lives on the domain controller with the GPC and resides in the SYSVOL folder. The GPC and the GPT are represented together with a unique id, called a GUID (global unique identifier), and they also share a version number, which is incremented every time a change is made to the GPO as a whole. You’ll see why this extra level of detail is important when we talk about troubleshooting synchronization and replication.
Levels of GPO application
One of the first facts you learn about GPOs in the Microsoft networking series is at which level you should apply the policy to. Group policies apply in the following order, with each level superseding the previous one:
- Local level
- Site level
- Domain
- Each subsequent nested OU
It might make it easier to remember that you always start from the bottom up when troubleshooting GPO application.
It is likely that any exam questions related to group policy troubleshooting will mention that a policy is being applied at two different levels to a computer or user, so which GPO settings will apply.
Also, as mentioned above, a group policy doesn’t actually live in the active directory; it is simply referenced at whatever level you choose. Once you get used to the GPMC, you will see how easy it is to link and unlink group policies at all levels of the active directory without the need for creating multiple versions of the same GPO.
Permissions
As with any domain environment tool, especially one as powerful as group policy, there have to be permissions in place to govern who can do what and to whom. Group policy is no different; however, when the permissions are wrong, this can stop a group policy applying altogether. Make sure that you know what names make up the group policies access control list.
As usual, the domain administrators and the creator owners have full control. You can delegate permissions to active directory users to allow them to manage group policy objects, so they will also appear in the permissions list with special permissions. The authorized users group are assigned the read and apply group policy permissions by default. One way to restrict who can apply a group policy is by adding the users or groups who should have the policy applied and then explicitly denying those that shouldn’t.
Also be aware that in most cases, network administrators create and apply GPOs, and in large networks, there may be more than one network administrator. It is common to see exam questions related to multiple domain administrators unwittingly changing the order of each other’s group policies, applying conflicting policies, or moving objects around in the active directory so policies aren’t applying correctly.
As a side note, you should also consider that if permissions on the SYSVOL folder are changed, this can effect group policy application from the GPT side of the GPO.
Synchronization and Replication
As mentioned earlier, GPOs are made up of two parts: the GPC and the GPT. These two parts work together to apply the group policy at the specified level; however, be aware that if they go out of sync it can cause issues with group policy application. The main reason that the GPC and the GPT may go out of sync is if there is an issue with the domain replication.
Initially when a GPO is created, both the GPC and the GPT exist on the primary domain controller. When multiple domain controllers exist on the domain, the GPO is replicated to all of them. So far, so normal; however, the GPC uses active directory replication to be replicated across the domain, and the GPT uses File Replication Services (FRS) to replicate across the domain. Both methods use different replication schedules, and this can lead to the GPO parts becoming out of sync and therefore not applying correctly.
In order to troubleshoot issues related to GPO replication, you can use the command line GPOTOOL to view the two parts of the GPO and check that their version numbers match. The version number is shared by the GPC and the GPT and is incremented every time a GPO changes, so if the version numbers are different, this will be source of the problem. This may be heading into “overkill” territory, but the importance of version numbers to troubleshooting group policy application is important, so I’ll summarize it for you briefly before you nod off! When a client queries the domain controller for the group policies to be handed, out the version number is checked in comparison to the last time the GPO was applied. If the version number is the same, then the client ignores the GPO and it isn’t applied, as nothing has changed. If the version number is different from the previous GPO applied, then the whole GPO is pulled down by the client and applied accordingly. So in a scenario where the GPC and the GPT are not in sync, the version number may be the same on one and not on the other; thus, the GPO is not applied, as the client believes it has the most up-to-date version. A useful tool to check the health of the active directory replication is REPLMON. For the exams, you should be aware of this tool and the different checks that can be run to check that domains are replicating without errors. In regards to FRS, you can use the file replication event log to look for errors. More on event log troubleshooting later.
Additional group policy settings
There are a number of additional settings that you can apply to GPOs at the active directory level which help you to get around certain policy application issues. You will cover these thoroughly in your study materials; however, it can be these additional features that cause the most headaches when you are troubleshooting why a group policy isn’t working.
A common group policy setting is slow link detection. This is designed to test the speed of the connection between the client and the server, and then, based on the feedback, only apply certain policies that won’t use up too much bandwidth. Make sure you are aware of what default policies can and cannot be applied over a slow bandwidth. This is another common exam question area, often appearing in scenarios where a domain is split over multiple sites with varying WAN link speeds and a group policy is failing to apply at one of the sites. Alternatively, you may also get a scenario where users’ software firewalls are blocking the initial ICMP test packets used by slow link detection, again leading to the policy not applying.
There is the option within a GPO to turn off inheritance so that the group policies assigned at one level don’t apply to the levels below. This is straightforward enough, but when coupled with the no override option (which forces the group policy to be applied), it can cause issues. Both options on their own are quite straightforward but just know that if both options are applied, the no override option wins.
Another important group policy tool is group policy loopback processing. Make sure that you know the two modes it hasmerge or replaceand when you would use each one. The purpose of loopback processing is to ensure that a locked down computer stays locked down, regardless of the logged on user’s group policy settings. As discussed earlier, group policies apply to the computers first, then the users. When loopback processing is in place, the same order is followed, but with an extra step: the computer applies its settings a second time, while pretending it is a user. If the merge mode is chosen then all permissions apply together. If the replace mode is chosen then the usually more restrictive computer (as a user) permissions apply last and override the user settings of whoever is logged on. You would normally use this in public computer environments such as a kiosks or production computers.
Additional logs and tools
In terms of common group policy troubleshooting problems, it is often a matter of deciphering who, what, and where a group policy has been applied or why it hasn’t applied at all. There are a number of tools which are at hand for troubleshooting; we have mentioned the GPOTOOL and REPLMON already. It is important that when troubleshooting a GPO failure, you know which one is right for the job.
One of the main tools to learn is the GPresult command line. This can produce comprehensive outputs to view group policy settings from either a remote location or at the local user’s computer. The GUI versions of the GPresult tool is called the Resultant setting of policy (RSoP) tool, which is now part of the GPMC. Make sure you check how it works, as Microsoft still likes to make reference to it. There is also a version of RSoP in the help and support center of a computer too. You should be familiar with the outputs of these commands and be able to make sense as to why the policies haven’t applied.
When it comes to logging in group policy you can get a good source of information in the event logs. From the client perspective, the USERENV entries in the application event log can help provide you with the answer. You can also tune these up to increase the detail of what’s occurring during group policy processing. The output is located in the windows\debug\userenv.log file. However, for the exam, you don’t need to know them in that much detail, just that the information is there for troubleshooting purposes.
From the server side, as mentioned in the “Synchronization and replication” section, you can view the file replication logs to troubleshoot any NTFRS errors which may be affecting your GPT portion of your GPOs.
A few additional bits to consider
There are quite a few other variables in a domain environment which can have an effect on group policy processing, so be aware that looking outside of the console might be where the solution lies. For example: is your domain healthy? Is DNS working correctly? Is the system date and time correct? Are computers properly installed on the domain? It is a common misconception that the domain controllers push out the group policies to the clients. When what actually happens is that the group policies are queried for by the clients, so if they are not querying the domain controller, there is a problem with the domain.
Back at the GPMC there are a few “gotchas” to watch out for. For example in Windows server 2008 you can now apply account policies at the OU, whereas in Windows server 2003 you can only apply account policies at the domain level.
In terms of applying multiple GPOs to a single OU, you must consider that the GPO that applies itself last is the winner. In order to adjust this, you can move the GPOs up and down to suit.
You may be sitting back now thinking that group policy is a right pain in the neck, “I’d rather skip it and manually apply two hundred changes!” Would you really? I wouldn’t, and anyway, like it or not Microsoft group policies and their foibles are a big part of the Microsoft networking exam series. This is mainly because group policies are applied to domain controllers straight out of the box, so you have to know installing, administering and of course troubleshooting them, not just for the exam but for the real world too.