4 Tips and Tricks for Microsoft Windows Group Policy

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 compiled these insights into a two part series 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? 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. 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.

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. 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.

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

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.

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.

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.

Reproduced and available for download from Global Knowledge White Paper: In the Trenches: Eight Tips-n-Tricks For Microsoft Windows Group Policy

8 Tips and Tricks for Microsoft Windows Group Policy Series

4 Tips and Tricks for Microsoft Windows Group Policy

Please support our Sponsors here :