Deploying GPOs efficiently and effectively requires careful attention. As we have seen in this chapter, you must consider many factors when you design and implement Group Policy in your enterprise. How you design your GPOs depends on your Active Directory structure, replication, site design, and more—and that’s a lot of information to evaluate. If you do not evaluate these factors, troubleshooting Group Policy can be much more difficult, and Group Policy processing can suffer performance degradation as well.
There is no secret recipe or procedure that you can follow to bypass all possible issues involved in deploying Group Policy, but the following best practices can help you avoid many pitfalls.
You can link GPOs to sites, domains, and OUs: which level is best when deploying GPOs? As a general rule, there are more ramifications when linking GPOs to sites and domains due to the scope of the accounts that are affected. Also, GPOs that are linked to sites and domains typically contain generic settings, whereas the GPOs that are linked down through the OU structure usually contain specific settings that are based on the type of computer or user. Let’s look at some general rules and guidelines for each level.
It is rare to have a lot of GPOs linked to sites in a typical Active Directory implementation. When you link a GPO to a site, it affects computers and users based on the IP address of the computer. In most cases, Active Directory administration, computer types, and user types don’t follow the network topology, so it is difficult to organize GPO settings in such a way that they can be deployed to sites. Here are a few scenarios where you might decide to link a GPO to a site:
IPSec settings. A branch office or other network segment might need to have IPSec security configurations for all computers on that network.
Software Update Services (SUS). When clients and servers receive information from Group Policy about SUS, they are typically directed to a SUS server. Since they are targeted to a SUS server to receive their updates, the GPOs containing SUS settings can be linked to sites to automatically affect all computers within a specific range of IP addresses. This will lead to computers being directed to the SUS server that is nearest them, increasing performance of applying the updates and reducing network traffic across the slower links.
Remote Access Services (RAS). If you have your RAS server configured to use a specific range of IP addresses, it is a good design decision to link a GPO to a site to configure the RAS clients. You can target computer and user accounts based on whether the computer is coming in over dial-up or VPN. You can thus control software installation, profiles, security configurations, and more. In most cases, the RAS clients must have increased security configurations and decreased network access privileges.
By default, a GPO named the Default Domain Policy is linked at the domain level and is typically used to configure account policies for all domain users. Additional GPOs can be linked to the domain level as well however. You might be tempted to link numerous GPOs to the domain level or configure numerous GPO settings at this level, but you will find that only a few GPO settings can be successfully configured at the domain level because these GPO settings affect all computer and user accounts in the domain.
When you consider linking GPOs at the domain level, evaluate the computer and user settings configured in the GPOs to determine whether they should be applied to every account in the domain. For computers, this would include domain controllers, file servers, print servers, application servers, SQL Servers, executive clients, IT staff clients, and developer clients. For users, this would include executives, power users, IT staff, developers, and service accounts.
Here are some best practices for configuration at the domain level:
Account policies. Although account policies are already configured in the default GPO, they are worth mentioning again. The only GPOs that can establish the account policies for domain user accounts are those that are linked to the domain level.
Legal notice. Display a legal notice at logon on all computers of any type in the organization.
Screen saver. Many companies require that computers be configured to use a standardized company screen saver. You should configure each user account to password-protect the screen saver after a set amount of idle time. Set a reasonable idle time for your environment, but the shorter the idle time, the better the security. In many companies, the idle time is set between 15 to 30 minutes.
Scripts. Some scripts configure drive mappings, printers, and other settings that are required for all computers and users throughout the domain.
Security settings. Many security settings such as SMB signing, authentication protocols, and anonymous access, can be configured for all computers in the domain.
Software installation. Your organization might have anti-virus or patch agent software that runs on all computers in the domain and can be deployed from the domain level. It is common to also deploy administrative tools to all computers for when administrators need to troubleshoot problems directly from a client or a server.
Internet Explorer. Because Internet Explorer is the main tool for Internet and intranet resource access, these settings are typically required for all computers in the domain. These settings might include proxy, caching, or security settings.
GPO processing. Ensure that all computers and users process GPOs in the same way, to eliminate working with different GPO implementation designs during the troubleshooting process. Configuring settings for GPO processing at the domain level ensures that all computer and user accounts are configured consistently across the forest. Settings such as synchronous/asynchronous, refresh intervals, and script timeouts are all usually appropriate to configure at the domain level.
Besides configuring the recommended GPO settings above at the site and domain levels, all other GPO settings should generally be applied at the OU level. This includes most GPO settings, which proves how important it is to design the OU structure of each domain with GPO deployment in mind.
You will typically have multiple levels of OUs within a domain, with some OUs toward the top of the structure and some OUs lower down. It is common to have fewer computer and user accounts in the higher-level OUs, while most of these accounts will reside in the lower-level OUs.
The same can be said of the GPOs linked to your OUs. Try to have fewer GPOs linked to higher-level OUs because too many accounts would be affected at this level. If any GPOs are linked at the higher-level OUs, their settings are typically generic enough to span multiple computer or user types.
Most GPOs are linked to lower-level OUs. These OUs typically contain accounts based on type, department, security needs, software requirements, or delegation of administration requirements.
When you have software that is being deployed using GPOs, organize your source files on servers that are on the same network as the target machines. The shares that contain application source files are specified within the software packages created in a GPO. You should specify shares that reside on file servers with fast network connections to the target accounts.
The same goes for SUS servers that are configured through GPOs. You should have multiple SUS servers provide updates for clients throughout the enterprise. The GPOs should be designed to lead target computers to SUS servers that have fast network connections to them.
Finally, you can combine domain-based DFS links with the specific shares that you need to specify for software and SUS server configurations in your GPOs. Domain-based DFS links allow multiple servers to respond to a single shared folder. Clients are directed to the share on the server that is within their site, providing fast, reliable access to software and SUS update resources.
More Info
For more information on DFS, go to http://www.microsoft.com/windowsserver2003/techinfo/overview/dfs.mspx.
When you deploy software based on a computer and user accounts, you have a choice of when you install the software and how the user will access the software for use or installation. The options are different for deploying software based on computer accounts versus user accounts.
For computer accounts, your options are limited because a computer can’t interact with itself to install or initialize some behavior to start the installation. Therefore, if you deploy software based on a computer account, your only option is to have the software install automatically when the computer starts.
For user accounts, you have three options:
Publish. When you publish software, it shows up only in the Add/Remove Programs list. The user is not even aware that the software is available unless she checks this list. This option is appropriate if you want to provide software to users but not have the software available to them until they need it. You can also choose to install the software when the user attempts to open a file associated with the software—for example, if Microsoft Excel has been published and the user opens a file with an .xls file extension. In this case, Excel is installed when the user attempts to open the file.
Assign, But Don’t Automatically Install At Logon. Assigning software to users makes the software available on the Start menu as a shortcut. This means the software is available for installation but is only installed when the user clicks the shortcut on the Start menu for the application or attempts to open a file associated with that software. This is a good approach if you plan to deploy software to a large group of people because it spreads the installation load across the network and source servers and across multiple hours and days rather than concentrating it at a time like early morning when all of users typically log on.
Assign And Install When User Logs On. This option is identical to the previous one except that the software is installed when the user logs on. This is a good option when the software is being deployed to only a few people or when the software (such as HR applications or security applications) need to be installed when the user accesses the desktop after logon.
When you organize your GPOs based on the kinds of settings they contain, they become easier to manage. Depending on the overall requirements of your organization, you could typically use security, software deployment, desktop control, Internet Explorer, scripts, Windows components, system configurations, and network settings as initial categories. Using such categories makes the following management tasks much easier:
Documentation of GPO settings
Troubleshooting of GPO processing
Multi-user administration of GPOs
Delegation of administration within Active Directory
You should allow GPOs to be processed according to their default inheritance behavior as much as possible. This means that when you link a GPO to the domain level, it should affect all accounts in the domain. Likewise, when you link a GPO to an OU of Sales employees, all Sales employee user accounts will be affected.
The Enforced option can push the settings in a GPO down through the Active Directory structure even if another GPO with higher precedence attempts to override the settings in the Enforced GPO. The Block Policy Inheritance option allows you to stop all lower-precedence GPO settings from applying to accounts at a certain level in the Active Directory structure. Both the Enforce setting and the Block Policy Inheritance setting should be used only when other recommended design options are not available. Here are some best practices for using these options:
Enforced. This is a good configuration option for the Default Domain Policy. It ensures that all settings related to the account policies and other miscellaneous security settings always override weaker settings farther down in the Active Directory structure.
Block Policy Inheritance. The Domain Controllers OU contains all domain controllers for the specified domain. It is a good idea to use the Block Policy Inheritance option here so no surprises are configured on domain controllers if an errant GPO is configured at the site or domain level.
By default a GPO has an ACL that allows it to affect all accounts in the container to which the GPO is linked. This should not be changed unless security filtering of the GPO’s ACL becomes necessary. The reason you should avoid modifying a GPO’s ACL is because it is hard to document and troubleshoot such detailed configurations. However, in some situations using security filtering on a GPO’s ACL is preferred:
When Active Directory delegation is more important. As you design your Active Directory structure, you might find areas where you need to place two types of user accounts in the same OU even though the user accounts need to have different GPO settings. In this case, you can use security filtering to control which user accounts receive the proper GPO settings.
GPOs are linked higher in the OU structure. When you link GPOs high in the OU structure, you will find that the GPO settings can affect too many accounts. You are forced to configure the GPO ACL to indicate which accounts should apply these settings.
WMI filters are very useful, but they can cause more harm than good if they are overused or configured improperly. The main problem with WMI filters is that they are expensive to process and therefore lead to slow response times and poor logon performance for users. It is best to design your OU structure to eliminate the need for WMI filters wherever possible. However, in some situations WMI filters are the only way to control which accounts receive the settings configured in the GPOs where the WMI filter is linked.
You might want to limit the use of WMI filters the following situations:
When software installation takes a large amount of hard disk space but not all target computers have sufficient disk space.
When a setting or application depends on the current service pack or update level.
When you are installing software or updates that rely on a certain operating system or operating system version.
When you need to verify memory installed on a computer.
Whether you are rolling GPO settings out to accounts or are updating a critical security setting, you must consider network topology, replication, and convergence when you make these changes. You should make sure that your Group Policy infrastructure is well documented so you know how to get updates from one domain controller to all domain controllers.
Here are some guidelines on updating GPOs with consideration for network topology:
GPO updates. By default, all GPO updates occur on the domain controller that houses that PDC emulator role. You can modify which domain controller updates Group Policy, but you still need to know where these changes occur.
More Info
For more information about how to control which domain controller updates Group Policy changes, see Chapter 2.
Convergence of GPO changes. When a change is made to a GPO, that change must be replicated to all domain controllers in the domain. When a computer or user attempts to apply GPO updates, the domain controller that authenticates the account must have the GPO changes or else the account will not be updated. Knowing how to force replication and check for convergence of GPO changes on all domain controllers is essential.
More Info
For more information about how to control replication of GPOs and verify convergence of GPO changes on all domain controllers, see Chapter 13.
Slow links. Because so many GPO settings are affected by slow links, you must know the link speed from the computer to the domain controller and resource servers when you configure certain GPO settings. Settings that control software application, SUS updates, scripts, and user profiles should have fast connections to the servicing servers to ensure that the user can use his computer in a reasonable amount of time. This requires limiting all of these settings to fast links and omitting these settings for computers that connect across slow links; as a result, you must develop solutions for controlling these settings in some other way.
You must protect your GPO implementation and the management of your Group Policy infrastructure by controlling which users have permissions to manage GPOs and their settings. You should determine which administrators should have control over the creation, modification, and management of GPOs at every level within that Active Directory structure. Here are some recommendations for tasks related to GPO management:
Creating GPOs. This ability should be limited to a few administrators within your organization—perhaps two to five—but not to a single person only. This limitation protects against errant GPOs from being created throughout your enterprise.
Editing GPOs. You should delegate configuration of GPO settings to the administrators who are responsible for the computer and user accounts that are affected by each GPO. In this way, there typically is not a large number of administrators per GPO—perhaps 2 to 10 administrators. You don’t want too many administrators to be able to modify the contents of GPOs because this might cause conflicting settings and errant configurations.
Modifying security. The list of administrators who have the ability to modify the ACL on a GPO as well as establish delegation to the GPO should limited to two to five administrators.
Linking GPOs to a level. When a GPO is linked to a site, domain, or OU, all of the accounts are immediately affected by the settings in that GPO. Therefore, the ability to link GPOs to a level is a very powerful one. You should limit the number of administrators who can link GPOs to any given level to between two and five.
Viewing GPO settings. By giving help desk employees, and some power users the ability to view GPO settings, you can help offload some of the administrative responsibilities around resolving and troubleshooting GPO issues from the shoulders of administrators. This might mean delegating a number of groups the ability to view GPO settings. It is reasonable to allow up to 100 users the ability to view GPO settings.
After you complete your final GPO design, you should develop a method for naming and documenting your GPOs. You shouldn’t have any duplicate GPO names because it would then be difficult to track which settings were within each GPO. You must come up with a naming scheme that makes sense to you yet is flexible enough for easy implementation.
Here are some best practices for naming your GPOs:
Don’t name GPOs after sites, domains, or OUs. This will only make your Group Policy design rigid and more complex.
Name GPOs based on the types of settings they contain. These might include the different GPO categories, such as security, software applications, scripts, and so forth.
Organize your GPO settings based on the account types they will service. This is also a good way to refer to your GPO names—for example, IT, developer, Help-Desk, file_server, SQL_server, and so forth.
Add a version number to the GPO name. In a large organization, documentation and management of Group Policy can be difficult to control. In this case, you can add a version number to the GPO name to help you track and document the GPOs and the current version of the settings. This is also an excellent way to create an archive of your old GPO settings, in case you need to refer back to them for troubleshooting purposes.