At the recent TechEd North America talk I gave, entitled, “Best Practices for Group Policy Design with Performance and Security in Mind”, one of the areas I covered was the impact of Client Side Extensions (CSEs) that only run during a synchronous GP processing cycle. These include the follow 4 CSEs:

1. Software Installation
2. Folder Redirection
3. Microsoft Disk Quota
4. Group Policy Preferences Drive Mappings

So why are these important? Because each of these can only run during a synchronous, foreground (i.e. machine startup or user logon) processing cycle, when they do have to run, they will force the machine to “go synchronous” even when it is not configured to do so. In order to understand the impact on this, let’s step back and look at how GP processing works.

By default, client OS’ starting with Windows XP and extending to current versions, support something called “Fast Logon Optimization”. This is a fancy term for asynchronous GP processing. In other words, when a machine boots up, computer policy processes while Windows presents the user the logon GINA. Then when the user logs on, user policy processes while the user’s desktop builds and becomes available for use. In both cases computer and user policy is happening on a separate “thread”, if you will, and neither the logon screen nor the desktop wait for policy processing to finish. This speeds up the experience for the user in going from booting a machine to having a functional desktop.

Unfortunately, for some CSEs, notably folder redirection or software installation, it also means that these policies can sometimes take two reboots or logons to go into effect. Not a big deal in the overall scheme of things–but annoying. So, these CSEs as well as the two others I mention above, will tell a machine using “Fast Logon Optimization” that the next reboot or logon will be synchronous, so that they can run properly. This means a slower logon experience for the user during that next logon, but it means that the CSE will do what it’s supposed to do, which is generally good.

Well that’s all well and good, but how does that impact GP design and processing performance? Here’s a scenario. You have a GPO (let’s call it GPOA) that contains GP Preferences Drive Mappings and Administrative Template policy. The user has already logged on and mapped their drive so life is good and their logons are working asynchronously from then on. Then you decide to make a change in one of the Admin. Template settings in that GPOA, totally unrelated to GPP drive mapping policy. What happens at the client? Well, during the next background refresh, the GP engine detects that *something* has changed, but doesn’t know what, because it doesn’t keep track of which CSE was changed in the GPO. As a result, when the GPP drive mappping CSE fires up, it thinks it has to do work because something in the GPO has changed, so it flags the machine that the next foreground refresh for the user should be synchronous! Suddenly, for no good reason, the user gets a performance penalty on their next logon because you’ve changed an unrelated policy.

I’ve illustrated this process in the video attached to this blog item–to make it more clear.

The moral of the story here–be careful how you group your policy areas within your GPOs. Avoid grouping one of the 4 synchronous CSEs listed above with other policy areas that change frequently. This avoids the unwanted side effect of having your users have to wait for a synchronous processing cycle for no good reason!

Darren