Group Policy is a fantastic tool for managing all of the computer and user objects in your Active Directory infrastructure, but it (sometimes fairly, sometimes unfairly) gets a bad rap for degrading overall responsiveness of some machines in your forests.
Check out these top five tips for ensuring you get the management benefits of Group Policy with minimal performance overhead.
Admit you have a problem. According to Microsoft, “startup and logon times [for client computers and other members of a domain] are directly proportional to the number of GPOs that must be processed.” If you have lots of Group Policy Objects (GPOs) that need to be processed at either machine startup or user logon, it very logically follows that you’ll have a bottleneck at either—or both—of those points. While the GPOs themselves are fairly small, and the effect is minimized if you use only a couple of settings for each (and follow some of the other tips in this guide), the more you have, the longer it takes to sort through the list.
Limit network-intensive Group Policy object settings. Take it a step further, though: processing time increases directly proportional to the number of individual settings configured within each GPO . While relatively simple configurations like desktop settings or Internet Explorer policies might not take long, heavily network-dependent options like folder redirection of software deployment policies may take a long time and really make your users angry. They may also represent a bottleneck on your network at peak times (at the beginning of the workday, a lesser but still significant blip around lunchtime and then at the end of the day) and then apply this same formula to all of your organization’s geographic locations.
Split your GPOs into computer and user GPOs, and then disable the unused portion of a policy. One best practice to both improve performance and also decrease management confusion is to create separate GPOs for settings that will apply to computers and separate ones for users. Then, once you’ve configured the appropriate settings, disable the unused portion of each GPO. For example, if you have a GPO setting a startup script, disable the user portion of that policy. Then on a logon script GPO, disable the computer portion. This way, Windows simply ignores the remainder of the options and reduces network traffic transmitting the GPOs around the replication network.
Resist the temptation to go overboard with the Windows Management Instrumentation filtering feature of Group Policy. By using WMI filters, you can dynamically apply certain GPOs to computers or users that match the criteria you set up using a WMI query. This type of power in targeting certain applications or computers can be very attractive for an administrator, but you should know that WMI is not a particularly efficient language, and especially when you have multiple other GPOs attempting to apply themselves at one time (say, startup), WMI filters can take a long time to process. So try to put WMI filtering into play only when they’re absolutely necessary; in other scenarios, consider linking GPOs to specific organizational units, or OUs, within Active Directory to limit the scope of those settings based on where a target object sits in the AD hierarchy.
Enable fast logon optimization. Starting with Windows XP, Microsoft included the ability for Windows clients to simultaneously process both machine and user policies—in Windows 2000, the policies were applied sequentially and one set couldn’t start before the other finished. Fast logon optimization (FLO) changes this equation, but it comes at a cost: you may find that users who reach a desktop before policies are finished applying may have a time window in which they can do things you’re trying to prevent. It also makes applying new policies a bit of a crapshoot, because it can take up to three reboots (or three logons) before new policies make it to the client. Still, the FLO feature improves performance significantly in an enterprise environment; the trade-off is worth it.