system for managing changes to your Group Policy Objects (GPOs), there are several low- and high-tech approaches you can take to ensure a consistent GPO environment. A key factor in the success of designing and deploying a substantial GPO-based infrastructure is the ability to manage and maintain that infrastructure over time. Similar to other aspects of your IT
infrastructure, you need to be able to track and document changes to GPOs, and support formal release-management processes that most companies require. Unfortunately, there are no
mechanisms within the GPO product to do so; thus, we have to create our own.
When I refer to the lack of version control within GPOs, I am not referring to the internal versioning mechanism that GPOs use to ensure their Group Policy Container (GPC) and Group Policy Template (GPT) are in sync as they are replicated to your Active Directory (AD) domain controllers. In most cases, this internal versioning scheme won’t be useful for your company’s version-control needs because it keeps numerical track of only each individual change that you make to a GPO.
Embed Version Information in a GPO’s Friendly Name
As I mentioned, you can take several approaches to overcome the lack of version control within GPOs. The first approach I’ll talk about is simple but can meet your needs in many cases. Specifically, you can embed version information within the “friendly name” of your GPOs. Thus, the name of the GPO becomes the place where you keep track of changes you make to your GPOs. Figure 4.1 shows an example of how this scheme might work.
As Figure 4.1 shows, I have three GPOs linked to my domain that contain version information. Each time I make a set of changes to a GPO, I change the version in the friendly name to reflect that. Of course, the version information isn’t meaningful without some information as to what is behind the number. For that, you can use a spreadsheet to track each change you’ve made to your GPO. You’re probably thinking that creating such a spreadsheet would take forever, given the number of settings that are contained within a default GPO. Fortunately, you can get some help. Microsoft has created a spreadsheet for Windows XP (that works for Win2K as well) that
contains all the default Administrative Template settings within a Windows XP-based GPO. You can find the spreadsheet at
http://www.microsoft.com/windowsxp/pro/techinfo/productdoc/gpss.asp. This spreadsheet serves as a good starting point for keeping version information, though you will have to add rows for other policy areas such as security and software installation. Figure 4.2 shows an example of how you might use this spreadsheet as a way to track version info for your GPOs.
Figure 4.2: Using the Microsoft GPO settings spreadsheet to track version information for your GPOs.
Create Custom .ADM Files
GPO a computer or user has received, but also provides a good way to tell whether GPOs are being processed correctly—if the version information is not delivered to the registry correctly, you know there is a problem with the GPO. To use this approach, you have to create a custom .adm file. I’ve created just such a file, which Listing 4.1 shows.
CLASS MACHINE CATEGORY !!Custom
Policy !!MachineGPOVersion
KEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy" EXPLAIN !!GPOVersion_Help
PART !!Blank EDITTEXT
VALUENAME "CURRENTVERSION" END PART
END POLICY
END CATEGORY ; MY CUSTOM MACHINE POLICIES CLASS USER
CATEGORY !!CUSTOM
POLICY !!UserGPOVersion
KEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy" EXPLAIN !!GPOVersion_Help
PART !!Blank EDITTEXT
VALUENAME "CURRENTVERSION" END PART END POLICY END CATEGORY ; [strings] Custom="Custom Preference"
MachineGPOVersion="Set current GPO version for machine" GPOVersion_Help="Enter the version number for this GPO" Blank=" "
UserGPOVersion="Set current GPO version for user"
Listing 4.1: A custom .adm file for inserting GPO version information into the registry.
The name of the GPO (for example, “Desktop Lockdown Policy”) is embedded within the .adm file. You will need to customize the .adm file for each GPO for which you embed version information. In case you’re wondering what this customization will look like within the Microsoft Management Console (MMC) Group Policy editor tool, Figure 4.3 shows you.
Figure 4.3: Viewing the custom .adm policy created for storing GPO version information in the registry.
And, finally, Figure 4.4 shows what this customization looks like if I go to the registry on a machine that has processed this GPO.
In Figure 4.4, we’re viewing the version information for the computer
(HKEY_LOCAL_MACHINE) rather than the user. Although you might want to keep the version number of a GPO the same across both computer and user settings, you can, of course, maintain different numbers, depending upon your needs. You will still want to keep a
spreadsheet that describes what each version number corresponds to within the GPO.
Third-Party Tools
Although the two approaches I’ve just described are easy to implement, they lack several key features that you might need for a fully functional version-control environment within your infrastructure. The high-tech approach is to use a product such as FullArmor’s FAZAM GP Repository. The Repository is an offline store that solves a number of GPO management
problems at once. In addition to letting you make changes to GPOs offline before they are live in your AD, the Repository can keep track of version information for your GPOs. More
importantly, the product can keep a history of GPO changes that tracks who made the change, when the change was made, and why it was made. This kind of thorough change management is key if your company starts to rely more heavily on GPOs to support your Win2K or Windows XP infrastructure.
Q 4.2: How many Group Policy Objects can I create in a domain
before I start affecting the performance of my workstations?
A:
There are many factors that affect Group Policy Object (GPO) processing performance. There are things you can do to reduce the time it takes to process a GPO, and thus allow more GPOs to run before your users notice a significant impact.There are a number of behaviors within the normal GPO processing cycle that affect how long a computer or user(s) takes to process a GPO. There is no one answer to how many GPOs you can use before you affect the user experience. However, understanding the behaviors that affect performance can go a long way toward helping you gauge how many GPOs your infrastructure can support.
Asynchronous vs. Synchronous Processing
By default in Win2K computers and users process GPOs synchronously. This means that, when the computer boots up, it processes all computer-specific GPOs it is subject to before presenting the logon dialog box to the user. Similarly, when the user logs on, all user-specific GPOs are processed before the desktop is shown to the user. In Windows XP, just the opposite is true. Windows XP uses asynchronous GPO processing, also known as fast logon optimization.
Fast logon optimization in Windows XP is just asynchronous GPO processing, which allows the computer to present the logon dialog box to the user without waiting for all computer-specific GPOs to finish processing.
Asynchronous processing allows the computer to start up and present a logon dialog box to the user even though all computer-specific GPOs have not finished processing. Asynchronous
processing before moving on to the next step. However, the downside is that some policy
features within the GPO—such as folder redirection and software installation—can take two user logon cycles to take effect.
You can set asynchronous vs. synchronous behavior on a per computer basis through an Administrative Template policy. In Win2K, the policies that control synchronous and asynchronous processing are found in Computer Configuration, Administrative Templates, System, Group Policy. Specifically the policy items are Apply Group Policy for computers
asynchronously during startup and Apply Group Policy for users asynchronously during logon.
If you enable these policy items, GPOs are processed asynchronously. In Windows XP, because GPOs are set to asynchronous processing by default, you need to set only one policy item to configure synchronous policy processing. Namely, in Computer Configuration, Administrative Templates, System, Logon, the Always wait for the network at computer startup and logon policy item, which Figure 4.5 shows, should be enabled to enable synchronous policy processing.
Figure 4.5: Enabling synchronous GPO processing in Windows XP.
GPOs that Don’t Change Aren’t Processed
time it was processed (and thus its version number is the same as the history information stored in the registry), the GPO is not processed; it is simply skipped.
If you have a large number of GPOs, but they are fairly static, your computers and users will incur a performance penalty the first time they are processed, but after that the processing time will be short because the GPO is not actually processed. You can, of course, override this
behavior and force all GPOs to be processed regardless of whether their version numbers change. You set the Administrative Template policy to control this behavior on a per client-side
extension (for example, per folder redirection, software installation, security, and so on) basis and can be found in the same location within Win2K and Windows XP—namely Computer Configuration, Administrative Templates, System, Group Policy. Figure 4.6 shows an example of how you can modify the Security Policy Processing item to process security policy even if the GPO hasn’t changed since the last processing cycle.
Figure 4.6: Modifying client-side extension behavior to process a GPO even though it hasn’t changed.
By processing only those policy extensions that are required, regardless of whether the GPO has changed, you can further minimize GPO processing time and thus process more GPOs.
Disable Portions of a GPO that Aren’t in Use
policy—there is no user policy defined. You can disable the user side of the GPO, and a system processing that GPO at user logon will simply not take the time to try and read the GPO. To disable one side or another of a GPO, open the Group Policy Microsoft Management Console (MMC) snap-in tool focused on the GPO, and right-click the GPO’s name in the left-hand scope pane. Choose Properties from the context menu. You will see the dialog box that Figure 4.7 shows.
Figure 4.7: Disabling the computer or user portions of a GPO to speed GPO processing.
As Figure 4.7 shows, you can select either the Disable Computer Configuration settings or
Disable User Configuration settings check boxes to disable the unused portion of the GPO and
thus improve overall GPO processing throughput.
These are the principal behaviors that exist within an AD domain that reduce the time it takes to process GPOs. There are some things you can do in your GPO design that will further improve the processing speed of a GPO, and thus increase the number of GPOs that a given user or computer can process before their experience is significantly degraded. Some of these design points include:
• Ensure that any startup, shutdown, logon, or logoff scripts that you write are tested thoroughly to ensure that they don’t hang during processing. If a script delivered by a GPO hangs, the client will wait until the script times out (10 minutes by default) before proceeding to process the rest of the GPOs. This behavior can cause interminable delays in the overall GPO processing time.
• Minimize GPOs linked across domain boundaries. In AD, you can define a GPO in one domain within your forest, and link it to a container in another domain. However, this cross-domain linking can cause increased processing time as the client computer must authenticate across domain trust boundaries to access the remote GPO. A better solution is to copy the GPO from the source domain to the target domain using tools such as those found in FullArmor’s FAZAM utility.