[ - 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” - http://technet2.microsoft.com/windowsserver/en/library/eb0042e3-699b-4c49-abcc-e3526dbecc0e1033.mspx?mfr=true. 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).