In my previous article Best Practices for Designing Group Policy, I described how to get Group Policy right from the start by planning your Active Directory structure carefully. The reason is, if you don’t take Group Policy into consideration before you start creating your domains, OUs and sites, you may end up having to employ so-called “advanced” Group Policy features like Block Inheritance, Enforced, or Loopback to make your Group Policy implementation do what you want it to do, and using these features makes troubleshooting more difficult later on. A well-designed Group Policy implementation however can usually get along fine without having to use any of these “advanced” features (apart from the use of security filtering and occasionally WMI filters) and the result is a simple GPO structure that is easy to understand and troubleshoot.
Part of Group Policy design however is consideration of end-user experience. In a poorly designed Group Policy Implementation, users may experience long delays before the Welcome To Windows box appears inviting them to press CTRL+ALT+DEL to log on, or they may experience additional long delays after they have entered their logon credentials and before their desktop appears so they can begin their work. In fact, long logon delays are usually the most frustrating aspect of a user’s experience as far as Group Policy is concerned, although a close second is when users complain that administrators have locked down their desktops too tightly using Group Policy to the point that users feel they can’t do their jobs properly. Let’s look then at some tips for how Group Policy can be optimized to speed logon performance while still maintaining the level of security an implementation of Group Policy is intended to provide.
A Common Myth
A common myth regarding Group Policy is that the more Group Policy Objects (GPOs) you have, the longer it takes for them to be processed during startup and logon. In fact, a Microsoft Knowledge Base article actually says that “startup and logon times are directly proportional to the number of GPOs that must be processed.” This is somewhat misleading for the following reasons.
First, the article is indeed right when it says that startup and logon times can depend on “the number of GPOs that must be processed.” The key word here is “processed.” In other words, it’s not how many GPOs you’ve created on your network that matters, it’s how many GPOs that are actually processed during startup or logon that matter. So for example, say you have twenty top-level OUs in your domain and each top-level OU has two lower-level OUs beneath it (one for user accounts and one for computer accounts) and that every OU has a unique GPO linked to it. And let‘s say also that you only have one domain-linked GPO (the Default Domain Policy) and no site-linked GPOs. So altogether you will have 20 + 40 + 1 = 61 GPOs, which seems like a lot. But for each particular user/computer combination, the startup/logon process will only see four GPOs processed: the Default Domain Policy, a GPO linked to a top-level OU, and GPOs linked to the two lower-level OUs beneath the top-level OU. More precisely, during startup three GPOs are processed (Default Domain Policy, top-level GPO policy, and computer account GPO policy) while during logon three GPOs are likewise processed (Default Domain Policy, top-level GPO policy, and user account GPO policy). So while you have 61 GPOs, few are actually processed for any particular user or computer. So remember, it’s not how many GPOs you have, but how many are processed that actually matters.
Secondly, the statement that startup/logon times are “directly proportional” to the number of GPOs processed is also somewhat misleading. What actually happens is that if x is the default logon time with no GPOs processed and y is the time to process any one GPO, then total logon time is approximately x+Ny where N is the number of GPOs processed during logon (the same applies to startup but we’ll focus here on logon for simplicity). This formula is only approximate however since the value of y can differ for each GPO. In fact, the more policy settings you’ve enabled or disabled within a GPO, the bigger y is for that GPO. Furthermore, when only a few settings are configured in a GPO, the value of y for that GPO is usually much less than x, and in that case total logon time is just x plus a wee bit longer rather than x+Ny.
What really affects logon time then is not how many GPOs are processed but rather how many settings are configured within each GPO. If you have only a few GPOs processed during logon but those GPOs have hundreds of settings configured, with conflicting settings in one GPO overwriting those of another GPO during processing, then users are likely to experience frustrating logon delays—at least when users log on the first time after you’ve configured a large number of settings in a GPO they process during logon. But even with hundreds of settings enabled or disabled in a GPO this might only cause the “Applying your personal settings” box to be displayed for a few additional seconds and thus add only a few seconds to a logon process that usually takes a few seconds anyway, so even having lots of GPOs with lots of settings configured won’t always draw the ire of your users and cause them to complain that “the network sure seems slow today” and so on.
What’s even more important than the number of GPOs processed during startup/logon and the number of settings configured in those GPOs is what the settings in those GPOs are designed to do. For example, if you configure a new Folder Redirection setting then users targeted by that setting may experience an initial delay as their folders are redirected to a network file server. Or if you assign software using a GPO then users will experience a startup delay as the new program is installed. But simple security settings or desktop lockdown settings generally don’t cause excessive startup or logon delays for users.
Other Performance Tips
Another thing that can significantly affect start or logon time is the size of the GPOs being processed. By size of a GPO, I mean the number and size of the administrative templates (.adm files) you’ve imported into your GPOs. For example, if you manage Microsoft Office using Group Policy then you’ve imported some of the office .adm files into your GPOs, and this can significantly increase the size of the GPOs and hence the time it takes Windows to process them on client machines. So the moral here is, only import such additional .adm files into GPOs that target users and computers which actually need those settings. This is especially true for managing user and computer settings remotely over a slow WAN link, as any way you can minimize the amount of Group Policy process you can achieve over WANs can definitely help remote users avoid frustrating delays.
Another performance tip that can speed up Group Policy processing is to disable either the User or Computer portion of a GPO if this portion is not needed during processing. For example, if a GPO is linked to an OU that contains only computer accounts and no user accounts, then there’s no reason for the User portion of that GPO to be enabled since no settings configured in that portion will be processed by computer accounts anyway. Similarly, if a GPO is linked to an OU that contains only user accounts and no computer accounts, there’s no reason for the Computer portion of that GPO to be enabled since no settings configured in that portion will be processed by user accounts. To disable the User or Computer portion of a GPO, do the following:
- Open the Group Policy Management Console (see this article on WindowsSecurity.com for more info) and expand the domain node until you find the GPO link for your GPO.
- Select the Details tab in the right-hand pane.
- Click the GPO Status drop-down box and choose whether to disable user or computer settings accordingly (see Figure 1).
Figure 1: Disabling the User portion of a GPO that targets only computer accounts
Another tip for optimizing Group Policy processing is this: use WMI filters judiciously. What I mean is this: WMI filters are a powerful tool that let you target Group Policy to highly specific things. For example, you could create a WMI filter that would apply a certain GPO only to those computers that are running a Pentium III processor, that have 256 MB RAM or less, and so on. While WMI filters make it possible to be incredibly specific in how you target policy, you should realize that executing a WMI filter against a collection of remote machines can take a significant amount of time, so it’s best to avoid using this advanced feature of Group Policy unless you have some absolutely compelling reason to do so.
Finally, if your client machines are running Windows XP Professional then by default they have Fast Logon Optimization enabled (unless you’re using roaming user profiles in which case this feature is disabled). Fast Logon Optimization makes startup/logon processing of Group Policy behave exactly the same way that background refresh of Group Policy takes place, in other words, asynchronously. The result of having Fast Logon Optimization enabled on Windows XP computers is that users will be able to log on to their computers before Group Policy has finished processing. The reason this feature was introduced in XP was to resolve the issue of long delays users often experienced when they logged on to their Windows 2000 Professional. These delays were caused by the fact that Windows 2000 processed Group Policy in a synchronous fashion during startup/logon, which meant that processing of machine policy had to finish before the logon screen was displayed and processing of user policy had to be finished before the user’s desktop appeared.
Unfortunately, while Fast Logon Optimization speeds the time it takes for a user to reach their desktop from booting their machine, it can have some negative side effects. Most obviously, if a user reaches their desktop before policy has finished processing, they may be able to briefly do certain things that policy was designed to prevent. For example, you may have enabled a policy to prevent users from accessing Control Panel, but if that policy is applied a few seconds after their desktop appears, they may have a brief window in which they are able to access their Control Panel, which kind of defeats the whole purpose of policy, right? So while Fast Logon Optimization can have a big effect on speeding Group Policy processing, it can also introduce a security risk into your desktop environment by giving users an opportunity to perform actions you don’t want them to perform. For more information on this feature and how to disable it if desired, see this article in the Microsoft Knowledge Base.