A key consideration during the design and implementation of GPOs is performance—not only the speed at which GPO settings are applied to computers and users, but also the potential performance degradation of the network, servers, and domain controllers that are all associated with Group Policy. The degradation to the network and servers can be attributed to replication of numerous GPO changes and the application of many GPO settings (especially software installation).The speed at which GPOs are applied can also be affected by many settings and implementation flaws.
Although the design considerations described earlier can all contribute to the degradation of performance when GPOs are applied, certain factors are most influential—the network topology, the number of GPO settings that need to be applied, the complexity of scripts, and so on. You must be aware of these factors and try to design your GPO implementation to reduce their effects.
Too many settings in a single GPO. If there are too many policies configured in a single GPO, it can lead to slow response times for the computer startup and user logon. This slow response time is common for many implementation of GPOs, but you should be aware of it when you consider the policy settings to implement and you should make users aware of the potential lag time in accessing their computer. Another facet of having too many GPO settings in a single GPO is if too many settings have to be reversed in other GPOs. It is best to not reverse or negate too many GPO settings when policy settings are applied at the local, site, domain, and OU levels.
Too many GPOs. A similar problem to having too many settings in a single GPO is having too many GPOs. The result can be the same as having too many settings overall, but with too many GPOs the processing time is multiplied because each GPO must be evaluated for the computer or user account’s access control list (ACL). If there are WMI filters or scripts in each GPO, this also can significantly increase the time it takes for GPOs to be applied.
Slow links. Sometimes several physical networks are traversed when a single GPO is applied. Not only does the domain controller need to communicate with the computer, but other servers might be involved that store applications or updates. If any of the networks between the client and servers involved with the application of GPO settings and configurations have slow links, application of Group Policy will be slower.
Too many scripts. Sometimes you need to configure a user’s environment, applications, and other features through scripts. If these scripts become large or complex, it can take a long time to apply the settings to the computer. In some cases, the computer might appear to be not responding, which might lead the user to manually shut down her computer and restart it. Because the script goes through the same process at the next startup, the user will still see the same "problem." The solution is to make sure that scripts are optimized and users are well educated.
Software installation. When GPOs are used to install software, startup and logon times can be affected dramatically. When software is deployed to computer accounts, the software installs automatically the next time the computer starts up. For user accounts, this behavior can be controlled to install the application when the GPO setting is applied or when the user triggers the need to use the application. These triggers can be an attempt by the user to open a file that has an extension associated with the application, or an attempt to access a shortcut to the application’s EXE file. We will offer some tips for optimizing the deployment of applications using GPOs later in this chapter.
File system and registry entries are slow on deep trees. If you are controlling permissions on files, folders, and registry keys using the Security Settings section within a GPO, this can slow down the application of the GPO settings to the target computer. The settings that control the files, folders, and registry keys can be found in one of two nodes within a GPO: File System or Registry, as shown in Figure 4-3.
Your best intentions in deploying Group Policy settings can be negated if the user experiences too much delay during startup or logon. This section provides you with some tips for speeding up Group Policy processing.
The GPO design stage is a great place to start optimizing GPO application. A design matrix that depicts which policy settings apply to each type of computer can help. Once you have the matrix, you can decide which settings to place in specific GPOs. Remember that each GPO must be evaluated for each account that it applies to.
Let’s look at a simple scenario. You have five types of computers, and you have broken down the GPO settings into 20 categories. Your options range from using 100 different GPOs based on category, or 5 different GPOs based on computer type. The best approach will probably fall somewhere in the middle.
The first option of using 100 different GPOs would require that each type of computer apply 20 different GPOs. While this approach has the most flexibility from the design point of view, it is likely to result in users experiencing extremely slow startup times and logons. The second option of using only 5 different GPOs means that each type of computer will apply only one GPO. Even though this second option is ideal from the performance point of view, troubleshooting this scenario would be difficult. With the GPO settings separated into different GPOs, it is easier to find the settings, as well as enable and disable entire GPOs to try to identify where problems in the GPO processing are occurring.
Thus, you generally need to consider a solution that falls somewhere in the middle. How you break up the GPO settings into different GPOs is up to you, and your solution should take into consideration all of the GPO design considerations that we looked at earlier in this chapter. Your solution should also try to facilitate delegation of administration for tasks like GPO creation, linking, editing, and viewing. Finally, your final GPO structure should be designed to simplify troubleshooting.
You might decide to link your GPOs to the domain level to reduce the total number of GPOs required. However, in the long run this can cause more work once you evaluate all the types of computers you will deploy, plus the work that it will take to design your GPO filtering requirements to ensure that only the proper accounts receive certain GPOs.
One important factor in linking GPOs is to only have the target accounts that need to apply the GPO settings evaluate them for application. If you link all of the GPOs to the domain and use GPO filtering, all GPOs will need to be evaluated by all accounts in the domain. This will slow down the processing of GPOs for all accounts in the domain.
The alternative is to link GPOs to OUs that are as close to the target accounts as possible. This reduces the load on all accounts, forcing only the target accounts to evaluate the GPOs for processing.
In most Active Directory implementations, the computer and user accounts are separated into different OUs. This is not a requirement of Active Directory design, but it is common practice to separate the different types of computer accounts (domain controllers, file servers, Web servers, SQL servers, and so on) and user accounts (IT staff, executives, developers, service accounts, employees, and others) and place each type of computer or user account in a different OU.
With computer accounts in their own OUs and user accounts in separate OUs, the GPOs that are linked to each of these OUs will be specific to each type of account. For example, if a GPO is linked to the OU that contains only file servers, there is no need to have any of the User Configuration settings configured. If the User Configuration settings were configured, they would not affect any users anyway because there are no user accounts in an OU that contain only file servers.
Because the GPO settings associated with user accounts will not be useful in this scenario, you should disable the User portion of the GPO to reduce the overall processing required by computer accounts in the OU. Doing this for a single GPO won’t make much difference, but if you disable the User section of every GPO that computer accounts need to process, it can make a significant difference in the total processing time.
More Info
For more information on how to disable the Computer or User section of a GPO, see Chapter 2.
You can change the background refresh interval to modify the time it takes to reassess whether new GPO settings have been made. The default refresh interval is different for domain controllers, domain members, and user accounts.
The interval can be set anywhere from 7 seconds to 45 days. A longer interval reduces how often a computer or user refreshes new GPO settings; 45 days is a long time to wait between GPO updates. If you configure the refresh interval too low, however, network traffic will increase and the user’s work can be adversely affected.
The default refresh interval for domain members and user accounts is 90 minutes, which is an efficient interval for most organizations. This value should be modified only if a smaller interval is required or the bandwidth is too small to support even the 90-minute default setting.
Domain controllers update GPO settings every 5 minutes by default. The interval for domain controllers is lower to increase security on these computers and to ensure that critical settings are pushed down to these computers as quickly as possible. Again, this is a reasonable setting unless your environment warrants a smaller interval. For domain controllers, a larger interval is typically not recommended for security reasons.
More Info
For more information on how to configure the refresh interval for domain controllers, domain members, or user accounts, see Chapter 3.
Because scripts can configure the user’s environment in important ways, they are often used in enterprise environments. It is common to have scripts map drives, configure printer ports, modify services, and more. In some cases, the scripts that run against computer or user accounts can become too large or complex, causing the logon time to become too long.
Sometimes startup or logon scripts can only finish their work when the network and key servers are available. In this case, when the network or a server resource is temporarily unavailable, the processing time for the scripts slows down and can make the user wait an unreasonable amount of time to start using her computer. In this situation, you should consider configuring a reasonable timeout for scripts, both startup and logon. If your scripts typically take 2 to 3 minutes to run, you might want to add 1 to 2 additional minutes to allow for slow response times or network congestion.
When GPO settings take too long to apply, the problem might be due to an abundance of security settings, desktop environment settings, Internet Explorer settings, and so on. In this case, you might want to consider configuring GPOs to apply asynchronously. By default, GPOs apply synchronously (except for Windows XP, which takes advantage of the Fast Logon configuration described above), which means the user cannot access the desktop and applications until all GPO settings have been successfully applied.
Asynchronous application of GPOs speeds up the user’s access to his computer but also leaves the computer vulnerable for a brief amount of time between when the user has access to his desktop and when all of the GPO settings have successfully been applied.
More Info
For more information on how to configure synchronous and asynchronous policy processing, see Chapter 13.
Configuring the use of loopback processing for a GPO can hurt performance on the computer it applies to. If the computer needs to evaluate the GPO settings within the User Configuration section in the GPOs for both the computer account and the user account, this can take extra time.
Loopback processing has two modes. The first is Replace mode, which takes only the settings for the user account from the User Configuration section of the GPO and applies those settings to the computer account. Because this is a simple replacement of the user-based GPO settings, the processing time required is not great. However, if you have configured loopback processing for Merge mode, the computer must evaluate the User Configuration sections in multiple GPOs, determining which settings should have precedence. This additional processing causes a slower response time for the user’s access to his desktop. As a result, you should limit your use of loopback processing to computers that need the additional control that this feature can provide.
A new GPO is configured to apply to all computer and user accounts by having the Authenticated Users group configured on the ACL of all GPOs by default. In most cases, this is the best configuration because there is no need to administer the ACL on the GPO.
If you have GPOs linked to OUs that contain both accounts that need to have the GPO settings applied and accounts that should bypass the GPO settings, you should filter the GPOs. This filtering reduces the time that it takes to process GPOs because the accounts do not evaluate the GPOs for which they are not listed on the ACL.
In this case, the best method for filtering your GPOs is to remove the Authenticated Users group and add the specific security groups that contain the accounts for which the GPO settings should apply. These entries in the ACL must have both the Read and Apply Group Policy permissions.