How to speed up Group Policy processing

[ - or: How can I speed up the user's logon time? ]

Nothing annoys people more than waiting for a machine to start up. You know those conversations when people meet in the lobby, next to the coffee machine: “So, you’re waiting for the network, too?” “Yeah, Bob, you know, starting takes so long.” “True, True.”.

You as the Group Policy administrator can do certain things to ensure that Group Policy application on computer startup or user logon complete as fast as possible. I’ll provide you with some tipps and tricks that helps clients process Group Policy faster.

But first, let’s clear up some rumors about Group Policy processing. It is not true, that Group Policy processing time increases with the number of policies you create and link to an OU. Well, it partially is true. It only slightly makes a difference between the two common methods, administrators create Group Policy-hierachies:

(a) some admins create many policies with only a few settings each,
(b) other admins create few policies with a bunch of policies to group them in a logical fashion.

Both approaches are valid, I’ve seen both working well in the field. As of my experience, it doesn’t _really_ matter which approach you follow and it doesn’t really matter how many settings you configure. The big change makes what settings you configure.

Policy processing is handled by so-called Client Side Extensions (CSEs). Little pieces of software on the clients that process the settings you dictate. There’s a CSE for Software Installation, one for registry entries, one for Folder Redirection and so on.

So when on Group Policy application takes place, a list of all GPOs is created. For each CSE that is registered on the client system, every GPO is opened and evaluated whether there are settings to process. So you can think of holding a certain CSE in your hand and testing every GPO if there are settings to process for it. If all GPOs are through, you take the next CSE into your hand. You can read more about this here: “How core Group Policy works” – It might take longer if your settings are spread across multiple GPOs and your CSE need to process each one of them.

Another good point to speed up policy processing a little is to disable unused “portions” of a policy. If you separate machines and users in different OUs in order to be able to separate the policy settings and GPOs you configure and link, you are able to just disable the “User Configuration” portion for all machines and disable the “Computer Configuration” portion for all users. You don’t need these portions if you have OUs with users-only and OUs with machines-only. That way, CSE processing will notice that no further settings are made and processing can complete faster.

You might find that filtering is a good thing. There are two ways you can accomplish filtering of Group Policy scopes other than using a good OU structure: WMI filtering and security filtering. This might be the right point to repeat my words: If you can organize your infrastructure and your AD design in a way that let’s you comfortably administer Group Policy so that you can leave WMI filtering and security filter out as far as possible, implement it! The processing of WMI filters and security filters might be a good thing in the first place, but the processing of those filters (calling up the engine or evaluating those permissions (ACLs “Read” and “Apply Group Policy”) take a considerable amount of time to complete. Excessive usage of WMI filters and modified ACLs on Group Policies can increase processing time.

If you can, have a special eye on those file servers that host Software Installation packages and user profiles. Ensure that those machines are fast to respond to users even under load. Roaming or Redirected Profiles on slow servers keep bugging users. If it takes ages to load and save files on those servers, or Software Installation takes too long to complete, people will not get a “positive user experience”. Software Installation packages should be on DFS – that’s best practice as this shares the load between the roots and you’re not lost and lone if it comes to replace the distribution point.

If you’re already experiencing long logon and startup times, you’ll surely want to revisit all kinds of scripts that you’re running on client computers or for users. Classics are network operations that run into timeouts or resources that can’t be accessed because of lack of permissions. I’ve also seen scripts causing trouble because they were connecting to a legacy server that has moved to a remote site – and the connection was sort of slow (64k or something like that).

4 Comments so far

  1. Eugen Munteanu on December 11th, 2008

    I have this scenario:
    -workstations behind WAN link
    -WAN Link is always with problem, is not reliable
    What is happening with GPO Settings applied to workstations if the WAN Link is down for a longer time. Are those settings applied for ever? Are they cached somewhere? Is there any posibility to be deleted automatically after 30 days or so?
    many thanks for your answer

  2. florian on December 12th, 2008


    GP is cached on the local machine. When the WAN link is down, GP will still be applied. It cannot check whether there are new policies or changes made, but it will apply the policies it downloaded the last time it was online.

    No builtin possibility to delete them after x days. Policies stick with the machine.

    Think of a lockdown scenario where you want mobile computers with remote users be locked down so they can’t get infected while on the road and at foreign sites. The policies apply no matter if the corp network is there or not.

  3. Frenske on February 8th, 2009

    What I experience is that laptops without network connections, let say at home, are taking very long to startup. It takes about 2-3 minutes to get from th XP screen to the ctrl-alt-del screen.

    I have been testing with GPO’s for some time now, but I have not been able to find a suitable solution for that.

    Anyone any ideas



  4. florian on February 8th, 2009


    I’ve seen this with machines that have DNS Server-IPs configured that matched IPs of home-LAN servers and take that long.

    Are there scripts configured that do a copy job and take some time to time out?