4 More Windows Group Policy Tips and Tricks

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.

1. Local GPOs
2. Site-level GPOs
3. Domain-level GPOs
4. 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.

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.

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

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

Related Courses
Configuring and Troubleshooting Windows Server 2008 Active Directory Domain Services (M6425)
Managing Windows Environments with Group Policy (M50255)
Administering Windows Server 2012 (M20411)