Worldwide Locations
For the experienced or novice Group Policy Administrator this article will serve as an important reference in optimizing and stabilizing your Group Policy Deployment. It is also important for desktop support staff to understand how Group Policy works and how to identify when Group Policy Objects (GPOs) are not being applied properly. Situations might exist where GPOs were created by other support staff or even outside consultants. There exists a need to properly read, deploy, and examine the results of Group Policy. By its architecture, Group Policy Deployment to the Clients or Servers can be erratic and latent, or even non-existent throughout your Enterprise Organization, frustrating Administrators who are rolling out the Group Policy to Client or Server computers. To help mitigate this behavior, I have compiled these insights from real-world examples, experiences, and fixes that have worked for me. I know that these Tips and Tricks will work for you, too.
Tip-n-Trick 1: Which Domain Controller are you updating? Why you care!
Maybe not the one you thought. The Domain Controller (DC) closest to your clients might not have the GPOs or their changes. Almost all Administrators are using the Group Policy Management MMC tool (GPMC). This tool is a free download to Windows 2003 operating systems. It is a built-in tool on Windows 2008 operating systems and included in the free download toolkit for Windows 7 machines. This popular toolkit download is known as the Remote Server Administration Toolkit (RSAT).
But which DC are you updating while using the GPMC? Take a look at Figure 1. By default, it's the PDC emulator, one of the five FSMO roles of a DC. You can easily discover your PDC by opening a command prompt and running the following command: Netdom Query FSMO. The five operations master roles will be shown in one list. You can also launch the Active Directory (AD) Users and Computer or the AD Domains and Trust, and right click your domain name and select Operations Masters. This view shows the three domain-wide FSMO roles, and your PDC will be one of them. If you choose to transfer the role to another DC, you can accomplish it from here with a just a couple more mouse clicks.
So here's the "catch". Which DC are you updating? Go see. Open the GPMC console, expand your Domain tree, right -click your Domain name, and select Change Domain Controller. You will see that it's set for the PDC emulator by default. It can be a problem if your DC is not the PDC. The PDC Emulator will update the other DCs. You will have to wait until your local DC gets the change. This becomes more of an issue as AD Site configuration grows larger and replication between sites is customized.
The fix for this issue is to point your GPMC management tool to your local DC as shown in Figure 1. Simply right-click your Domain name and select Change Domain Controller from the Context menu; select your DC. This way the DC closest to you will be updated with the group policies setting you are trying to roll out. This enables the local Clients that read the shared SYSVOL folder on your local DC to get the updated policy first. This DC will update the PDC, and the PDC will update the other DCs.
Figure 1. the Domain Controller selection screen
Tip-n-Trick 2: What's your GPO Version Number?
I will assume all networking is functioning as it should and DNS name resolution is behaving properly. That said, if your computer won't refresh the group policy not matter what you do, it could be that the client thinks it downloaded it already. Refer to Figure 2 to see the version number for the GPO in question. The idea here is to increment the version number in order to force the client to reread the group policy. Edit the particular GPO you are trying to deploy to clients and make an insignificant change; any change will work as long as you enable or disable something that won't have a negative impact to your organization. One caveat: get the GPMC to increment and show the new version number as it will not do so automatically. You have to close the GPMC and open it again to refresh the Details tab of the GPO. Your version number for the User Version or Computer Version will increment appropriately. And by the way, this number needs to be consistent across all your DCs.
Figure 2: Details of a GPO
Tip-n-Trick 3: Delete the Registry Location on the Client and why you do it.
The Client Side Extension (CSE) stores the GPO downloaded inside the registry and compares it the GPO on the AD DC. This is known as the Group Policy History inside the Registry of the local client computer. If the CSE thinks that it already downloaded the GPO(s) it won't download it again. In that case, you can try deleting the registry location on the client to force the client to refresh the policies. This location is HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft \Windows\CurrentVersion \Group Policy\History.
Figure 3 shows the Regedit tool the on client opened to the registry location of the unique Contoso.com Default Domain Policy.
Figure 3: Understanding GPO history with the Registry Editor
My fix is to delete all the unique GUID numbers under the History key and run a gpupdate /force. It will repopulate with the same GUID numbers from the AD DC location and also load back into the registry to Local Group Policy.
There is a great web link on the support site at Microsoft that gives an explanation of the unique GUID numbers under the History key in the registry. The Identifying Group Policy Client-Side Extensions paper was originally written for Windows 2000, but the same GUID numbers are used today. This can be found at http://support.microsoft.com/kb/216357.
By default, Group Policy processing on Windows servers is Synchronous, which means that Windows servers complete the Group Policy processing for computers before they present the Ctrl+Alt+Delete dialog box, and that the Group Policy processing for users completes before the shell is active and available for the user to interact with it.
The problem with this is that Group Policy processing on client computers is Asynchronous. Typically, client computers do not wait for the network to initialize fully at startup and logon. The client computers logon existing users by using cached credentials, which results in a shorter logon period. Windows applies Group Policy in the background after the network becomes available.
The exception to this is if a user with a roaming profile, home directory, or user-object logon script logs on to a computer. The computer always waits for the network to initialize before completing the logon. If a user has never logged on to the computer before, the computer always waits for the network to initialize, because there are no cached credentials, but this is not generally the case. To mitigate this, there is a Group Policy that you can set called Always wait for the Network at Computer Startup and Logon that, as Microsoft's explains will "guarantee the application of Folder Redirection, Software Installation, or roaming profile settings in just one logon."
Tip-n-Trick 4: Get your Links in Order! And the winning policy is...
For most policy settings, the GPO with the highest precedence and that contains the specific settings determine the setting's final value. For a few settings, the final value is actually a cumulative combination of all GPOs linked, including the local Group Policy.
GPOs that Windows processes last have the highest precedence. GPOs follow the Local, Site, Domain, or Organizational Units (OUs) rule for processing: first, the local GPO, then site, then the domain, and lastly the OU, including nested OUs, which are OUs that have another OU as their parent. In the case of nested OUs, GPOs associated with the parent OUs are processed prior to GPOs associated with the child OUs. In this processing order, Windows 7 applies local GPOs first, but they have the least precedence. Windows processes OUs last, and they have the highest precedence. Several Group Policy options can alter this default inheritance behavior. These options include
Link Order: The precedence order for GPOs linked to a given container. The GPO link with a Link Order of one has the highest precedence on that container. Changing the Link Order has no effect unless GPOs that link to the same location have conflicting settings.
Figure 4 shows three GPOs linked to the IT OU. You can use the move up button on the left side of the Linked GPOs tabs. The link order has been arranged so GOP 3 has the highest precedence. For example, if all three of the GPOs have the same setting conflict, GPO 3 is in first position and is the "winning" GPO.
Figure 4: Link Order Rearrangement
Additional tricks to managing and trouble-shooting Link Order
Other settings that affect the processing of GPO are:
Enforced: This is the ability to specify that a GPO takes precedence over any GPOs that link to child containers. Additionally, a GPO that Windows enforces at the domain level overrides a GPO that it enforces at an OU. You typically enforce a GPO to ensure that computers use company-wide settings and that departmental administrators do not override these settings by creating a new GPO.
Block Inheritance: This is the ability to prevent an OU or domain from inheriting GPOs from any of its parent containers. Note that Enforced GPO links will always be inherited. You typically use blocking inheritance to allow a department to manage Group Policy settings separate from the rest of the organization.
It's a "No Brainer" to see the Winning GPO. Simply run the Group Policy Results Wizard from the GPMC tool. This wizard provides HTML output that shows which GPO is the winner. In another words, it shows which GPO was applied and where it deployed from. Or, you can run from a CMD prompt on a local client machine using the GPResult /h switch. This new /h switch provides HTML output that shows practically the same result and the Wizard-driven results of the GPMC as well
Tip-n-Trick 5: You need a new Replication Engine! What's wrong with the old one?
Group Policy Objects and their templates are store in SYSVOL, a storage area under the Windows directory. This has been the storage area as far back as I can remember. The old replication engine that handles (among other things) the replication of SYSVOL is File Replication Service (FRS). This engine has been problematic. Microsoft admits that a SYSVOL that has a lot of GPOs is overweighed and becoming a possible problem for Replication.
In another words, SYSVOL stops replicating to other DCs. Here is an excerpt from the Microsoft Official Curriculum (MOC 6424) Active Directory 2008 R2 class has to say about your old FRS.
"SYSVOL, a folder located at %SystemRoot%\SYSVOL, contains logon scripts, group policy templates (GPTs), and other resources critical to the health and management of an Active Directory domain, by default. Ideally, SYSVOL should be consistent on each domain controller. However, changes to Group Policy objects (GPOs) and logon scripts are made often, so you must ensure that those changes are replicated effectively and efficiently to all domain controllers. In the previous versions of Windows, the FRS was used to replicate the contents of SYSVOL between domain controllers. FRS has limitations in both capacity and performance that causes it to break occasionally. Unfortunately, troubleshooting and configuring FRS is quite difficult. In Windows Server 2008 and Windows Server 2008 R2 domains, you have the option to use DFS-R to replicate the contents of SYSVOL."
You will need to manually migrate the SYSVOL from FRS to DFS-R. In short, you want to use the new Distributed File Replication Service-Replication (DFS-R) to overcome any limitations of the FRS. One major caveat: if you upgraded from AD 2003 to AD 2008, you are still using the old FRS. Your Domain Functional Level (DFL) needs to be 2008, and you have to run the DFSRmig utility to create and migrate your SYSVOL to the new SYSVOL_DFSR folder.
Tip-n-Trick 6: Group Policy Hierarchy: How and where you apply group policy means a lot.
Client computers download GPOs and apply them in specific ways, so it is important for you to understand how Windows processes them so that you can identify when Windows is not processing correctly. By default, Windows computers download GPOs at startup and every 90 minutes thereafter, with a 20-minute offset, so all domain-joined computers don't update at the same time. This can be changed in Group policy. You also can force an update by running GPUpdate.exe at a command prompt. Best word on the street is to run the gpupdate /force switch, which reads all GP setting - changed or not. Local GPOs apply to Local Users and also to Domain Users, but the User Settings in AD GPOs do not apply to local users.
Inside a GPO, there are User Configuration settings and Computer Configuration settings. Computer Configurations apply when the computer boots up, and the User Configuration applies when the user logs in. The User Configuration settings apply to user accounts, and the Computer Configuration settings apply to computer accounts. Most importantly, if the user account and computer account are in different OUs, a single GPO may apply to the user who logs on, but not to the computer itself, and vice versa.
Within the User Configuration and Computer Configuration, there are policies and preferences. Polices are Microsoft Windows configuration setting that are enforced on the client; preferences are settings that are applied to the client, but the user has the option to change them. Preferences include a lot of desirable items such as drive mappings, desktop shortcuts, hardware configurations, and printer deployment. Best of all, a great majority of these preferences are available to both the user and the computer; and you can target these setting to a long list of GUI-based targeting criteria.
Group Policy Objects are processed in the following order.
Local GPOs
Site-level GPOs
Domain-level GPOs
Organizational Unit (OU) GPOs, including any nested OUs, starting with the OU further from the user or computer object
GPOs that are applied to higher-level containers pass through to all sub-containers in that part of the AD tree. For example, a policy setting that is applied to an OU also applies to any child OUs below it. The local GPO is processed first, and the organizational unit to which the computer or user belongs is processed last. The last GPO processed is the effective setting.
Another factor that can influence the processing of GPOs is Security Filtering. An individual GPO can have security filtering applied that controls which users and computers are able to apply the GPO. By using security filtering, you limit a GPO to a specific group of users or computers. By default, Windows applies a GPO to Authenticated Users, which allows all users and computers to apply it.
Tip-n-Trick 7: Removing and unlinking policies for troubleshooting with Event Viewer
Link Enabled specifies whether Windows processes a specific GPO link for the container to which it links. When you do not enable a link, Windows does not process the GPO. This is typically done during troubleshooting when you want to disable processing of a GPO to eliminate it as a source of configuration errors. The fact is when you simply unlink the GPO it reverses the settings that were applied. What was configured to be turned on will now be turned off, and vice versa. To unlink, you simply right-click the GPO and in the Context Popup menu and deselect Linked.
Before the GPMC was launched and we only had the old style group policy management tool, this un-linking would display a message saying something to the effect of: "Are you sure you want to do this? Your GPO will be reversed back to the default."
Use the redesigned Event Viewer and check out the new category for Group Policy Events. It will indicate any errors and successes in group policy processing, when the next refresh of group policy will take place, and much more. It can be found under the Application and Services Logs\Microsoft\Windows\GroupPolicy and double-click Operational (see Figure 5).
Figure 5: The New Event Viewer GP Container
Tip-n-Trick 8: Wake up those Lazy Clients to download the Group Policy Object settings!
Yes, the Clients are lazy; and it's up to the Client Side Extensions (CSE) to "Pull Down" the GPO to "hack and tattoo" the local Registry Database of the Client Computer. Most Windows NT Administrators are aware and use the command gpupdate /force in the line command. Perhaps you did not know that it can be run as a Standard User from the Desktop of the operating system they are running. If instructing the user to launch a command prompt is too difficult, you can instruct them to click Start-Run on Windows XP or click Start-Search on Windows 7, and type gpupdate /force. Although gpupdate.exe run without any switches is supposed to refresh only the GPOs that have changed, this command falls into the "sometimes" category; sometimes it does and sometimes it doesn't refresh. If you use the command with the /force switch, you get a reread of all GPOs, regardless of whether there are changes or not.
Sure, I know you're saying, "Why not re-boot?" Yes, as a matter of fact, Group Policy deployment such as Mapped Drives, Home Directories, Software Installations, and Scripts, to mention a few, do require a reboot. If all works as it should, then Gpupdate executed at the command line will prompt the user for a reboot as it reads these types of changed policies. As a last resort for users who don't understand your instructions to run commands as above, then, yes, two reboots will usually be required: one to read the policy to pull it down, and one to apply the policy to the running computer.
Be aware that you can do the above procedure over and over again and still not get the results you are looking for. That's because the Client thinks it has already downloaded the Policy. For the more advanced AD Administrator there are other ways to force the client to read the policy. Refer back to Tip-n-Tricks 2 and 3.
Summary
Troubleshooting client configuration failures and GPO application issues is one of the most important and sometimes difficult problems IT Administrators face in our Enterprise Networks. This article is composed from my real-world fixes for what can be one of the most bizarre and erratic settings in the Microsoft Operating Systems. These TIPS-N-TRICKS can be used to address both the Server and Desktop sides of your AD Structure and will result in a smoother, more efficient, and reduced Total Cost of Ownership (TCO) in maintaining your networks. Feel free to reach out and contact me with questions or comments, or for help with any of these tried and proven methods. My e-mail address is below. Happy Computing to All.
About the Author
Mark Mizrahi has been a Microsoft Certified Systems Engineer (MCSE) since Windows NT3.51. He holds a CEH Certified Ethical Hacker Security Certification and is a CEI Certified EC-Council Instructor. He is a Microsoft Certified Trainer (MCT) and MCTS and MCITP for Windows Server 2008, Vista, and Windows 7. He currently teaches Microsoft curriculum for Global Knowledge and other training vendors. Mark is president of Standard Computer Services and consults for various Fortune 500 companies. He designs and implements web-based Internet Security and Video Surveillance Systems for a diversified customer base. Keeping up the various hacking methods is part of his daily intake of information, and he loves sharing it with this clients and students. He can be reached at: markmiz@comcast.net
