Windows 2000 group policy objects (GPOs) allow administrators to control the user environment in critical areas such as security, desktop functionality, software rollout, and scripting without “tattooing” the registry as NT4’s system policies do. As with all great things, there are downsides to GPO technologies; one of these is the potential to chew up a lot of processing power, both on server and client computers. To keep GPOs from slowing down your network, you should know how GPO is applied and what areas can cause delays.

A quick reminder about group policies
There are two types of group policy: computer policy and user policy. The former is applied when the computer is restarted or when a policy refresh occurs. The latter is applied at user logon and at subsequent refresh intervals.

GPO is stored in two places:

  • The group policy container (GPC), which contains version information and GPO attributes. Domain controllers use GPC to verify version information.
  • The group policy template (GPT), which is a folder hierarchy containing all the actual GPO settings. The GPT is stored in the shared Sysvol folder, which domain controllers replicate among themselves. Client PCs connect to the closest available Sysvol folder to retrieve the GPO settings contained in the GPT.

GPO changes are, by default, written to the domain controller holding the PDC-Emulator role. This can be changed, but it is best to leave this alone to avoid situations of administrative conflict. GPO is processed by clients in a specific order, namely Site | Domain | Organizational Unit (OU). GPO settings flow down this line and are applied cumulatively until all the GPO settings linked to an OU have been applied.

If there are no GPO settings at a given level, for instance at the OU level, then the OU will inherit settings from the site and/or domain level, unless the OU has specifically blocked inheritance, in which case settings may be reversed if there is a conflict. Administrators can also specify that a GPO cannot be overridden at a lower level. No Override always dominates a Block Inheritance setting.

GPO filtering regulates which policies are applied to particular users and/or computers. This involves modifying the discretionary access control list (DACL) settings for affected active directory objects. For a policy to be applied, the object must have Read enabled and Apply Group Policy enabled. In this way, policies can bypass certain objects if necessary. A good example would be where a delegated administrator of an OU would not want to have the same restrictions applied to his or her desktop.

Filtering GPO is powerful and granular, but it can cause GPO processing to slow down if the filters are applied to individual objects (i.e., users) rather than to security groups. In the example of Jill User, her W2K Access Token, generated at logon, will contain all of her security group memberships. When it comes to applying GPO, processing will happen faster if there is a short list of security groups to run through. The same goes for GPOs where objects have been specifically denied the Apply Group Policy permission.

Processing orders
When GPO links are processed, the processing occurs in reverse order, i.e., from bottom to top. This means that the topmost GPO link in an OU will be the last to be processed during GPO application. However, the opposite is true for logon scripts, which are parsed from top to bottom. The default timeout for logon scripts is 10 minutes, so if your users are experiencing very slow logons and you’re running logon scripts via GPO, test those logon scripts to see if they’re causing the slow GPO processing problems.

Computer settings in GPO are processed first, before user settings. When a client PC boots up, a W32 function called GetGPOList runs and connects to the closest available Sysvol share. Processing of GPO settings is done at the client side with the help of various DLL files, known as client-side extensions. These are as follows:

  • Userenv.dll – processes registry-based settings (i.e., Administrative Templates)
  • Dskquota.dll – processes disk quota settings (i.e., Administrative Templates)
  • Fdeploy.dll – processes folder-redirection settings (e.g., My Documents)
  • Gptext.dll – processes scripting and IPsec settings
  • Appmgmts.dll – processes software installation settings
  • Scecli.dll – processes security and EFS settings
  • Ledkcs32.dll – processes Internet Explorer maintenance settings

These extensions individually run through the GPO settings to determine whether they are required to process data. If there is no applicable data (i.e., no policy updates), then the extension does no work.

Processing modes
GPO processing occurs in one of two modes: synchronous or asynchronous. The former is the default mode, and nothing is available to the user until all computer and user GPO settings have been processed by the machine or the client-side extensions mentioned earlier. Asynchronous processing does not require all GPOs to be processed before the user can interact, and so it may appear that everything is ready to go before all policies have been applied.

Of the two, synchronous is more predictable and safer, but asynchronous can be used if there are good reasons for it, namely speed. Change the processing mode only if you’re confident that it won’t negatively impact users.

To change GPO processing modes, start the Group Policy Editor. In the left pane, go to Computer Configuration | Administrative Templates | System | Group Policy. Enable both Apply Group Policy For Computers Asynchronously During Startup and Apply Group Policy For Users Asynchronously During Logon.

GPO is refreshed at default intervals. Domain controllers refresh GPO every five minutes in order to maintain security. Clients refresh their GPO settings every 90 minutes. Policy settings called Group Policy Refresh Interval For Domain Controllers and Group Policy Refresh Interval For Computers can change the default refresh intervals.

Unless absolutely necessary, Microsoft recommends that you not change refresh intervals, especially if large numbers of client PCs will be affected. It doesn’t take a rocket scientist to understand that the more often GPO is refreshed, the greater the volume of network traffic, resulting in overall lower performance and higher processing overhead.

Three things are noteworthy here:

  • If you were to set the refresh interval at 0, GPO would be refreshed every seven seconds. This applies both to domain controllers and client PCs.
  • Whenever GPO is updated, the user’s desktop may change/flicker and any open context menus may get closed without user intervention. Obviously, this not only chews up processing time, but it also has the potential to significantly lower user productivity.
  • GPO settings relating to software rollout and/or folder redirection are applied only at computer boot or when a user logs on. These GPOs are not refreshed at the standard intervals. This can help GPO processing speeds.

In the same vein, by default, only GPO settings that have been changed are reapplied during the refreshing of GPO. This, too, can be changed by a policy setting if there are compelling reasons to do so. You can make this change by enabling the Disable Background Refresh Of Group Policy setting in Group Policy Editor. As with the other settings, you’ll find it in Computer Configuration | Administrative Templates | System | Group Policy.

This setting allows you to define whether background computer policy updates occur while the machine is in use. If enabled, GPO updates will occur only when a user logs off. As we saw above, background refreshes can be disruptive, but bear in mind that many users don’t bother logging off at the end of a workday. So unless you’re specifically forcing logoffs, enabling this policy setting may put you in a situation where only a reboot will reapply computer policy.

Finally, GPO refreshes can have an offset time assigned to them so that not all users and computers poll domain controllers for policy updates at the same time. This is a useful feature and, depending on your situation, you may need to give this item special thought.

If need be, a command line parameter can be invoked to immediately refresh both computer and user policies at a specific machine. You can use the Secedit utility by dropping to a command line and typing secedit /refreshpolicy machine_policy /enforce for computer policies or secedit /refreshpolicy user_policy /enforce for user policies.

Upon running this command, you’ll be informed that GPO propagation has been initiated and that any errors will appear in the application log.

GPO and slow links
GPO can detect slow links. By default, a slow link is defined as anything less than 500 Kbps (can be changed). If a slow link is detected, not all of the Client Side Extensions will process GPO. Here is how processing happens under a slow link:

  • Registry-based settings (Administrative Templates) – ON (cannot be turned off)
  • Disk quota settings (i.e., Administrative Templates) – OFF
  • Folder-redirection settings (e.g., My Documents) – OFF
  • Scripting and IPsec settings – OFF
  • Software installation settings – OFF
  • Security and EFS settings – ON (cannot be turned off)
  • Internet Explorer maintenance settings – OFF

Slow links affect GPO processing speed and which settings are applied.

Delays in GPO processing
With so much control over GPO, the temptation always exists to use every possible permutation of GPO. The outcome is predictable enough: GPO processing delays. An example to illustrate:

Company X’s administrators are excited by how much control GPO gives them over users’ environments. To avoid confusion in the multitude of settings available in GPO, they decide to create one GPO per setting and then link each GPO to relevant OUs. They end up with 15 different GPO templates, each of which controls only one item such as Hide The Run Command or Remove My Network Places From Desktop.

The administrators are also concerned about security, so they decide that every time GPO refreshing occurs, all policy settings should be reapplied, regardless of whether they have changed since the last refresh operation. Now, the Accounting OU has nine of the 15 GPOs linked to it, and remember, they all have to be processed individually. The users in Accounting OU are not going to be over the moon when it takes them not only an unreasonable amount of time to log on and use their PCs, but also when their machine freezes every hour (yes, the administrators also reduced the computer and user GPO refresh intervals from 90 to 60 minutes) as GPO settings are reapplied. Of course, their accounting application also gets shut every time the refresh occurs too. Last time that happened, the month’s payroll data was lost.

This example is perhaps a little extreme, but it does serve to highlight some of the potential problems with GPO processing. While GPO is extremely useful and often essential, it is important to leverage its power sensibly.

Avoiding bottlenecks
There is no point in pulling out all the GPO stops if it means workers grind to a halt because of GPO refreshes. Many problems can be avoided by following a simple set of best practices:

  • If you’re involved in the planning of GPO, take all the time you can to get it right and working properly under testing; if you skimp on the planning phase, you may put your job at risk. Without enough planning, things can rapidly get out of hand in a production environment.
  • Minimize the number of GPOs in use because this not only slows processing, but it also makes it very difficult to troubleshoot policy problems.
  • Limit the use of GPO filtering and, if you must use it, use security groups rather than individual objects to speed up processing.
  • Avoid linking GPO to sites with multiple domains because all machines and users will need to contact a domain controller in which the site-GPO resides. This can cause a lot of traffic and thereby reduce processing speeds. A better way would be to link a GPO to each domain in a site so that machines and users only need to contact a domain controller in their own domain.