How Group Policy Impacts Logon Performance #2: Internals

This article is based on my Citrix Synergy 2015 session and is the second in a mini-series on Group Policy performance. All measurements by uberAgent on Windows Server 2012 R2 with Citrix XenApp 7.6 in a steady state. Please start reading with the first article.

Foreground vs. Background Processing

Group Policy can be applied in the foreground and in the background.

Foreground processing occurs when:

• The computer starts up (computer policy)
• A user logs on (user policy)

Background processing occurs:

• Every 90 minutes with a random offset of 0-30 minutes (can be changed)

During background processing many CSEs are invoked even when their settings are unchanged. This is governed by the registry value NoGPOListChanges and policy settings in Computer Configuration > Administrative Templates > System > Group Policy

Synchronous vs. Asynchronous Processing

Group Policy processing can be synchronous (the system waits for completion) or asynchronous (other things happen at the same time). Background processing is always asynchronous. Foreground processing can be either.

In order to reduce perceived startup duration Microsoft changed the default processing mode from synchronous to asynchronous in Windows XP. The caveat is that users are logged on without the full set of policies applied. This is typically not what we want in controlled enterprise environments. To force synchronous processing enable the policy setting Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon – which is really horribly named, by the way.

Important: During synchronous foreground processing all CSEs are invoked even if there have been not been any changes to their settings! This disables optimizations and may prolong the total policy processing time. As you may recall from part 1, some CSEs are always invoked, but others are normally only called when their settings have changed.

Timeouts

There are various timeouts built into Group Policy.

Everything

Timeout for Group Policy processing from start to end: 60 minutes. If a CSE has not finished after that, it is still being processed, but asynchronouosly. This may affect software installations, for example, but you should not use Group Policy for software distribution anyway. Did anybody even try? I mean, except those poor souls writing technical documentation for Microsoft?

Scripts

Startup, shutdown, logon and logoff scripts started through Group Policy are limited to 10 minutes. I have not tested what happens when a script reaches that age but I guess it will be terminated along with its child processes.

WMI Filters

WMI filters have a timeout of 30 seconds. Longer running WMI filters are aborted and treated as false.

Drive Mappings

Group Policy Preferences drive mappings are limited to 30 seconds – each.

Important: if target servers are unavailable, logons become slow. The typical delay is 5-7 seconds – per mapping. Trying to map three drives to nonexistent servers in some obscure part of the logon script may easily cost your users 20 seconds. Every single time they log on or start a published application. This happens way more often than one should think it does.

Loopback Modes

Merge Mode

Merge mode forces two Group Policy passes for user settings. The first pass according to the position of the user object in the OU hierarchy (as usual), the second pass according to the position of the computer object in the OU hierarchy. The results from both passes are then merged.

I strongly advise against using merge mode, only partly because of the performance degradation. The main reason I cannot recommend it is that it easily causes confusion as to which settings apply when.

For completeness sake: even with merge mode there is only one pass for computer settings.

Replace Mode

In replace mode the location of the computer object replaces the location of the user object. Apart from that everything happens as always. There is no change in policy processing duration and maintenance is a lot easier than with merge mode.

Logging

Group Policy logging can be enabled by setting the DWORD registry value GPsvcDebugLevel to 0x30002 in the key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics. Additionally, and this is easily forgotten, the directory %windir%\debug\usermode must be created.

Once the registry key is in place and the directory exists logging is enabled (no need to reboot). Log messages are written to the file gpsvc.log in the usermode directory.

Deciphering gpsvc.log is not the easiest task. This 7,700 word article on Microsoft’s Ask the Directory Services Team blog tries to help.

Group Policy Preferences logging can be enabled through Group Policy. Take a look at these settings: Computer Configuration > Policies > Administrative Templates > System > Group Policy > Logging and tracing.

Multithreading

The Group Policy service is single-threaded, so it does not benefit from multiple CPUs. Only exception: during background processing user and computer run in separate threads.

Disabling GPO Sides

Let’s conclude this post by answering the following question: Is it worth disabling the computer or user side of a GPO?

I must admit have applied this “optimization” since the days of Windows 2000. The basic idea is that if Group Policy has less things to worry about processing should be faster. So, if we have GPOs that only contains user settings anyway, why not disable the computer side of that GPO, and vice versa?

To determine the effects of disabling one GPO side I created 40 GPOs and measured the processing time per GPO. Then I disabled each GPO’s user side and repeated the process. The result:

As you can see, the performance gain of disabling one GPO side is negligible.

This is because if a policy side is unused, the only overhead will be in querying Active Directory to determine that, and the same query must be performed to view the disable option as the one that occurs to determine whether any CSEs have been implemented for that side of the GPO.

Continue reading with part 3 of this series.