A well-considered Group Policy design is essential to a stable and successful Active Directory infrastructure. When you design your Group Policy infrastructure and deploy GPOs, you must consider more than just the settings in the GPOs. Because Group Policy is an integral part of every Active Directory domain, you must also consider its interaction with all of the networks, computers, and services related to Active Directory.
The most important consideration is the design of Active Directory itself. Many facets of Active Directory design affect Group Policy, so your Group Policy design should be integrated into every step of your Active Directory design process. If you don’t consider Group Policy when you design your Active Directory implementation, you could end up making major changes to one or the other to make everything work. The following section provides some design guidelines to help you avoid this kind of situation.
Group Policy depends on Active Directory for almost every aspect of how it operates. It is easier to list what aspects of Group Policy don’t rely on Active Directory than list what aspects do rely on Active Directory. In fact, the former list has only one item: the local GPO. Every computer in a domain has a local GPO. This LGPO is responsible for controlling the security, environment, and software on the computer where it is located. The LGPO on a local computer is the only aspect of Group Policy that is not directly dependent on Active Directory, although the LGPO is involved in how Group Policy is processed in an Active Directory environment.
Let’s now look at the Active Directory–related functions, features, and services that directly affect Group Policy:
Some components of Group Policy are stored in the Active Directory database, and the location of that database is important for Group Policy for two reasons. First, the database must be protected so it can’t be altered or accessed by an attacker or negligent user. Second, the database must be located on a hard drive with enough room to allow the database to grow, as some GPOs can become rather large as additional templates and configurations are added to them.
More Info
For more information about what is stored in the Active Directory database that affects Group Policy, see Chapter 13.
Group Policy also stores some information in the system file on domain controllers. This file system includes a SYSVOL folder, which in turn includes a subfolder named Policies where GPO configurations are actually stored. The location of these files is only important when an administrator needs to troubleshoot or fix issues concerning the files stored in the Policies folder—Group Policy tools automatically find this location when you use them.
More Info
For more information about what is stored in the Active Directory system files (SYSVOL folder) that affects Group Policy, see Chapter 12.
A key aspect of designing Active Directory and Group Policy is directory replication between domain controllers. Replication ensures that the entire Active Directory database and the contents of the SYSVOL share are copied to all domain controllers in a domain. This is essential because domain members can communicate with any domain controller within a domain. If the domain controller that communicates back to the domain member does not have the latest Active Directory information or Group Policy settings, that computer cannot receive the correct information. Convergence means making sure that all domain controllers receive updated information related to Active Directory objects and Group Policy. Convergence depends on several things, including intersite and intrasite replication topologies. Unless you have considered convergence time when you designed your Active Directory implementation, the changes you make to Active Directory and within Group Policy may never converge to all domain controllers. Although this is unlikely, it is possible.
Tip
For more information about Active Directory replication, convergence, and site design, see "What is the Active Directory Replication Model?" at http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr_repup_what.asp.
By far the most important aspect of Active Directory design that affects Group Policy is the design of the organizational units (OUs) within Active Directory. Because Active Directory is used mainly as a tool to organize, manage, and control user, group, and computer accounts, the design of OUs is integral to the design of Active Directory also.
When you consider the design of OUs, you should focus on two essential aspects: delegation of administration and Group Policy deployment.
Delegation of administration. This powerful feature of Active Directory should receive the majority of your attention during the design phase. Delegation of administration within Active Directory refers to the administrator of Active Directory "delegating" the tasks of controlling objects within Active Directory to other administrators and users. Examples of administrative tasks that could be delegated might include:
Resetting passwords for user accounts in the Sales department only
Adding user accounts to security groups that are associated only with the Marketing department
Controlling the ability for computer accounts to be joined to the domain and added to a specific OU
Delegation of administration can be configured at any level within Active Directory, but it is best to use it at the OU level. This requires that you incorporate the following in your OU design:
Define the administrative model of controlling user, group, and computer accounts.
Define which administrators and users will have control over specific user, group, and computer accounts.
Define the specific tasks that administrators and users will be delegated authority over for their respective user, group, and computer accounts.
Do not create OUs that do not facilitate delegation of administration or Group Policy deployment.
Group Policy deployment. Almost as important as delegation of administration to your OU design is Group Policy deployment. (GPO deployment has somewhat lower priority because it is more flexible than delegation of administration.) When you do think about OU design and how to deploy Group Policy, keep these points in mind:
Group Policy applies only to user and computer accounts. (GPOs don’t apply to group accounts.)
GPOs affect the level in Active Directory at which they are applied, as well as all subordinate levels.
GPOs affect all objects at the level at which they are deployed, including domain controllers, administrative groups, and administrative user accounts
GPOs can be limited in their scope of influence by an administrator configuring Block Policy Inheritance, Security filtering, and WMI filters
Once you begin to interweave the concepts of delegation of administration and Group Policy deployment into your OU design, you might find that the OU structure can become quite large. As a best practice, you should limit your OU structure to no more than 10 levels deep. This guideline is based on the premise that there will be at least one GPO linked to each OU, combining for approximately 10 GPOs. Performance will suffer if too many GPOs are applied to a computer or user account at logon.
More Info
For more information on other factors that can affect computer and user logon performance due to GPO configurations, see the "Controlling GPO Processing Performance" section in this chapter.
You must consider several aspects of Active Directory sites during the design phase. First, sites are created to control replication between domain controllers in different geographical locations. Second, sites can differentiate domain controllers that are "poorly connected" (which typically means using any network connection that is less than 10 Mbps). Third, sites control client and server access to Active Directory–aware resources and functions. Active Directory–aware resources and functions include:
Authentication of computer and user accounts
Renewal of Kerberos tickets
Distributed File System
Group Policy application
More Info
For more information about the process a computer goes through when applying GPOs, see Chapter 13.
Sites control other aspects of Active Directory and Group Policy administration and management. When you design the replication topology and the site itself, it is important to remember that sites are designed and implemented to control replication. The replication topology that you configure within the site determines what the convergence time will be for all Active Directory and Group Policy changes. (The "Replication" section in this chapter explains convergence time.)
Sites also indirectly control the administration of Group Policy. By default, the domain controller running the Primary Domain Controller (PDC) master operator role is referenced for administration of Group Policy. Therefore, when you create, edit, or manage GPOs, the updates are made on the domain controller responsible for the PDC role. However, this behavior can be changed in the Group Policy Management Console (GPMC).
Tip
To change the domain controller that the GPMC references, right-click the domain name in the GPMC console and select Change Domain Controller. In the dialog box that appears, select Any Available Domain Controller. The GPMC will first try to pick a domain controller in your site, and then it will move to domain controllers in other sites.
More Info
For more information on the GPMC, see Chapter 3. For more Active Directory design tips, see "Best Practice Active Directory Design for Managing Windows Networks" at http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.
As you can see, Group Policy and Active Directory are highly dependent on one another. Make sure that all Group Policy considerations are carried throughout the entire Active Directory design process. Forgetting Group Policy issues and needs can cause serious problems.
You must consider a few physical aspects of your network in conjunction with your overall Group Policy design. We have already identified one of these aspects, which is directly tied to the network topology: Active Directory site design. The site design controls which domain controllers the target computer will communicate with during the authentication process. The site also directs the computer to the nearest domain controller and resource server when it needs to obtain resources that are Active Directory site-aware.
Another important consideration is the link speed of the connection between the target computer and the domain controller that is servicing it. GPOs make a distinction between slow and fast link speeds. By default, the cutoff between fast and slow links is 500 Kbps. This means that any connection with a speed of less than 500 Kbps is considered a slow connection and some GPO settings might not apply. Several situations can cause the computer to have a slow network connection to the domain controller:
A connection with speed degradation due to poor network configuration or interference
A connection to the domain controller over a slow link from a branch office
A congested network, which causes the computer connection to slow down
You can control what connection speed is considered slow for each GPO. This means you also have control over whether the settings in a GPO apply to computers that don’t have very good connections to domain controllers.
Note
The GPO settings that control the connection speed are located under both the Computer Configuration and User Configuration nodes in a GPO. Here are the paths to each of the settings:
Computer ConfigurationAdministrative TemplatesSystemGroup PolicyGroup Policy slow link detection
User ConfigurationAdministrative TemplatesSystemGroup PolicyGroup Policy slow link detection
You also have control over which major components of the GPO are processed over slow connection links. Some GPO components are always processed, regardless of the connection speed:
Administrative template settings
Security policies
The following are other settings that are processed over slow connection links by default but can be configured to not be processed over slow links:
EFS Recovery policies
IP Security policies
Software restrictions policies
Wireless policies
Internet Explorer Maintenance policies
The following components of a GPO aren’t processed over slow links by default but can be configured to be processed over slow connection links:
Application deployment
Logon/logoff scripts
Folder redirection
Disk quotas
When a computer connects to the network over a remote access connection, Group Policy is processed differently from a slow link connection. The main reason for this is that the computer policy is processed before the logon screen appears. In a remote access connection scenario, however, the computer is already at the logon screen when an attempt to communicate with the remote access server is initiated.
To control the behavior of Group Policy during a remote access connection, you can select the Logon Using Dial-up Connection check box at the logon prompt. This triggers the applicable computer and user Group Policy settings to apply if the computer is a member of the domain that the authenticating remote access server belongs to or trusts. The computer settings are applied as a background refresh during the logon process. However, computer-based software installation settings and startup scripts are not processed at this point because these computer settings are normally processed before the logon screen appears. The user Group Policy settings are applied as a foreground process during the logon.
If you decide not to select the Logon Using Dial-up Connection check box for your remote access connection but you still authenticate to the domain through the remote access server, you still receive Group Policy settings. The settings are applied during the background refresh interval for the computer and user Group Policy settings. This means the computer-based software installation settings and startup scripts do not run. It also means that the user-based software installation settings, logon scripts, and folder redirection policy settings do not run because these user-based Group Policy settings can be run only during a foreground application period, which is at the initial logon.
The other components of Group Policy behave in a similar manner to that of a typical slow link connection. This means that registry settings and security settings are always applied, either at logon or during a background refresh. Other Group Policy components can be controlled according to the link speed, as described in the "Physical Design Considerations" section of this chapter.
More Info
For more information about best-practice configurations for slow link settings that apply to remote access clients, see Chapter 11. For more information about how remote access clients process Group Policy at logon, see Chapter 13.
The design criteria for your overall Group Policy deployment plan should include details regarding GPO application—how GPOs are created, linked, configured, processed, and controlled. Many of these GPO controls allow the administrator to control key aspects of the target computer and user accounts within Active Directory. These settings also allow users to access their desktop and network resources without having to wait for their computer to load all of the scripts, applications, and settings. However, these settings can also be configured too tightly. You must find a balance that does not leave the computer and user environment insecure while not forcing users to wait a long time for Group Policy processing to complete before they can use their computers.
Here are four key points that you need to consider for the design, configuration, and implementation of your GPOs:
Group Policy affects only computer accounts and user accounts.
GPOs do not apply to security groups.
GPOs can be linked to sites, domains, or OUs.
Multiple GPOs can be linked to a single site, domain, or OU.
More Info
For more information about the basics of Group Policy, GPO processing, and GPO linking, see Chapter 2.
Two important design considerations come into play when you consider linking GPOs to sites, domains, or OUs. By the time your sites and OUs have been created, your Active Directory design is already done, and you finalize your GPO deployment by linking your GPOs to these objects in Active Directory.
However, before you link GPOs to sites, domains, or OUs, you must think about the objects the GPO settings will affect, as well as the interaction between the different GPOs. You need to be aware of two main considerations with regard to linking GPOs to sites, domains, and OUs:
GPOs have two distinct sections.
GPOs interact with sites, domains, and OUs
Although the Group Policy Object Editor shows two completely different sections in a GPO, administrators often tend to forget this simple fact. The two sections of a GPO are Computer Configuration and User Configuration, as shown in Figure 4-1. This is important to remember because the policy settings located under the Computer Configuration section apply only to computer accounts, while the policy settings located under the User Configuration section affect only user accounts.
Take a look at an example of when this design consideration might come into play. In our scenario, there are two OUs: Sales_employees and Sales_computers. The Sales_employees OU contains all user accounts for employees in the Sales department. The Sales_computers OU contains all of the computer accounts for the Sales employees. A GPO named Security Message is linked to the Sales_computers OU. The Security Message GPO has both the Message Title and Message Text policies configured, to show a security warning to the user when she attempts to log on to the computer. When any Sales employee attempts to log on to any sales computer, he will see this security message.
There are two other OUs in this scenario: IT_employees and IT_computers. User accounts are in the IT_employees OU, and computer accounts reside in the IT_computers OU. No GPOs are linked to these OUs. You need to consider whether a security message will appear when an employee from Sales logs on to a computer in IT. Similarly, you need to consider whether a security message will appear when an employee from IT logs on to a computer in Sales.
To determine the results in each case, you must remember that the Message Title and Message Text policies are "computer-based" because they reside in the Computer Configuration section. Therefore, when any user logs on to a computer in Sales, she will receive the security message. However, because the policy doesn’t apply to computers in IT, no user will see a security message when logging on to a computer in IT.
To ensure that you keep these settings straight, here are some tips to keep in mind when you design OUs, place accounts in OUs, and link GPOs to OUs:
Place user accounts in different OUs than those where computer accounts reside.
When creating GPOs, keep computer account settings in different GPOs than user account settings.
Make sure all of the desired accounts you want to target by a GPO are located in an OU to which that GPO is linked.
When troubleshooting processing of some specific policy setting, be aware of whether that policy setting applies to computer accounts or user accounts.
Another key design consideration is how GPOs linked to sites, domains, and OUs interact when Group Policy is applied. You must remember that GPOs follow inheritance rules down through the Active Directory structure. For example, any GPO that is linked to the domain will affect all accounts within the domain by default. This includes domain controllers, servers, IT staff, the Administrator account, executives, and service accounts.
If two GPOs are linked to the same domain, they are processed according to the link order specified in the GPMC, as shown in Figure 4-2.
Important
GPO precedence works in the opposite direction from the link order numbering. In other words, a GPO with a lower link-order number has precedence over a GPO with a higher link-order number. The result of this ordering can be seen when the same policy setting is configured in two GPOs linked to the same level. In this situation, the policy setting configured in the GPO with the lower link number takes precedence over the policy setting configured in the GPO with the higher link number.
More Info
For more information on GPOs linked at the same level within Active Directory, see Chapter 2.
The behavior of multiple GPOs linked to a single level in Active Directory becomes more complicated when you consider the larger picture of having additional GPOs linked to sites, the domain, and OUs. As we have already seen, the overall GPO precedence order is as follows, from lowest to highest:
Local GPO
GPO linked to site
GPO linked to domain
GPO linked to OU
As you consider where GPOs will be linked within Active Directory, you must consider what the final policy settings will be on the target object. Like GPOs linked at the same level, GPOs linked to sites, domains, and OUs, as well as the local GPO, must resolve conflicting policy settings. The GPO with the highest precedence will always have control over a GPO with lower precedence when there is a conflicting policy setting.
If your Active Directory design and infrastructure includes multiple domains, you will have still more options than just linking GPOs to sites, the domain, and OUs. You will also be able to link a GPO from one domain to the domain node or an OU in a different domain. At first glance, this feature appears to offer an avenue for streamlining the number of required GPOs, by having one domain use an existing GPO in another domain that meets the GPO design and security requirements. However, linking GPOs across domains has drawbacks in three areas: performance, administration, and troubleshooting.
Performance. When a GPO is linked from one domain to another, communication is required between domain controllers in the two domains when the GPO is referenced—for both the computer and user portions of the GPO. This additional communication is needed because of the trust relationship between the two domains, which forces the domain controllers to pass credentials back and forth to authenticate computer and user accounts. This additional communication slows down the GPO processing for the domain that does not contain the GPO.
Administration. When a forest has more than one domain, it is common to have separate administrative staff responsible for each domain, including separate administration for linking GPOs to OUs, creating GPOs, and managing GPOs. This separation makes it difficult for administrators in the remote domain to be aware of how GPOs are managed in the originating domain and what functionality they contain.
Troubleshooting. Once a GPO is linked across domains, the complexity of the GPO design increases, making the task of troubleshooting Group Policy processing more difficult. This issue, which can be further complicated by use of GPO permissions, enforcing GPOs, WMI filters, and disabling sections of GPOs can make cross-domain GPO linking scenarios extremely difficult to troubleshoot.
One key design decision is whether the GPOs should be processed synchronously or asynchronously. These two processing methods have a very different effect on how GPOs are processed. You must understand what each of these processing methods does to the application of GPO settings before you can make a prudent design decision.
Synchronous. Each process that applies policy must finish running before the next one begins. Applying all of the GPO settings to the target object can take a long time. However, if you choose this approach then you are guaranteed that the policies will be applied before the user gains access to the network. This increases security and ensures that the user’s desktop environment is configured properly before he can use the computer.
Asynchronous. Multiple processes can run at the same time. With this approach, the user gains access to her computer faster than with synchronous processing. However, it is possible for the user to gain access to her computer before all of the policy settings have been applied to the computer. This can lead to strange consequences. For example, if the policy that removes the Run command from the Start menu is enabled, asynchronous processing might allow the user to access to computer before this policy takes effect. The result is that the user can then access the Run command for a brief moment before the policy effectively takes the Run command away.
More Info
For more information on how GPOs are processed, see Chapter 13. For more information on network communication and security scenarios, see Chapter 11.
Similar to the synchronous/asynchronous policy processing, there is a policy setting that can affect the startup behavior with regard to applying GPO settings. The Fast Logon Optimization policy is named Always Wait For The Network At Computer Startup And Logon. This policy applies policy settings asynchronously when the computer starts and when the user logs on. The result is that users can begin working on their computer faster than if synchronous processing were enabled. Fast Logon Optimization is enabled for Windows XP by default for both domain and workgroup members. Fast Logon Optimization is always off during logon under the following conditions:
When a user first logs on to a computer
When a user has a roaming user profile or a home directory for logon purposes
When a user has synchronous logon scripts
Fast Logon Optimization is supported only by Windows XP Professional. Windows 2000 and Windows Server 2003 computers are still controlled by the synchronous and asynchronous policy setting, even though the results are similar. The policy setting for enabling or disabling Fast Logon Optimization can be found at:
Computer ConfigurationAdministrative TemplatesSystemLogonAlways wait for the network at computer startup and logon
Enabling this policy setting forces the computer to process Group Policy synchronously in the foreground when logging on. (Background processing during Group Policy refresh is always asynchronous.). However, it makes the computer appear to be working more slowly and does not give the user access to their desktop as quickly. Disabling this policy setting forces the computer to process policy asynchronously in the foreground. The user then gets access to the computer faster, but not all policies may apply until processing completes.
The default GPO inheritance scheme (GPOs at higher levels apply to lower levels) will suffice in most cases. However, in some cases such inheritance might conflict with your overall Active Directory design. This might be due either to administrative requirements or because inheritance might need to be uniquely controlled for a few accounts in an OU based on the user’s needs, application requirements, or security requirements.
You can alter the default GPO inheritance in four ways. Each option gives you ultimate control over which policy settings affect specific accounts. These options are:
Enforce (No Override)
Block Policy Inheritance
Security Filtering
WMI Filters
These options let you be very specific about exactly which user and computer accounts the GPOs and their settings will ultimately affect. However, overusing these options can lead to problems with the following aspects of GPO deployment:
Determining the Resultant Set of Policies
Logon performance
Troubleshooting GPO application
As a result, you should generally try to avoid these four inheritance-altering options. Later in this chapter, you will look at when and how you should use these options when deploying GPOs.
More Info
For more information on Enforce (No Override), Block Policy Inheritance, security filtering, and WMI Filtering, see Chapter 3.
We have considered where GPOs can be linked, as well as some specific settings that can be made in a GPO to control how Group Policy is processed and applied. However, we also need to consider the structure of the GPOs with regard to the number of settings per GPO, the type of settings per GPO, and additional settings that can be placed in a GPO. Failure to take these considerations into account can result in slower startup times and longer logon times.
When you consider the types of computers and users that will be receiving policy settings, you must decide how to organize these policy settings into GPOs. You will inevitably have many different categories of policy settings for each type of computer. Here are examples of some commonly used types of computers:
Domain controller
File server
SQL server
IT staff client
Developer client
Executive client
We will investigate additional types throughout this chapter. As a reminder, here are some of the categories of policy settings that are possible within a GPO:
Security
Application deployment
Internet Explorer maintenance
Scripts
It is common during the design phase to develop a matrix based on the type of computer and listing the policy settings by categories. One intuitive design approach places all of the policy settings for each type of computer into a single GPO. This is called the monolithic approach. As you can imagine, this produces a GPO implementation that yields one GPO for each type of computer. However, the monolithic approach is typically the least flexible for working into your Active Directory design. This approach is also harder to delegate administrative control over and is more difficult to troubleshoot.
The other approach for implementing GPO policies is the functional approach. Instead of placing all of the GPO settings into a single GPO for each computer type, you set up the GPOs based on the category for each computer type. This yields more GPOs, but they are typically easier to work into your Active Directory design, simpler to delegate administrative control over, and easier to troubleshoot.
Even though a typical GPO includes thousands of possible settings, you might have certain applications or services that require additional or custom GPO settings. You should consider these additional settings as their own category within your matrix.
For example, the Microsoft Office suite has many component applications that can be installed individually or all together. Office also has a set of administrative templates (.adm files) that provide additional GPO settings to configure how Office works. You can install these templates for the individual Office components or all at once. The Office components with their own .adm file include:
Access
Excel
FrontPage
Outlook
Word
Other components and features of Windows also have special .adm files. They include:
Internet Explorer security
Outlook Express
Windows Media Player
There are more areas where you might encounter additional GPO settings. You can consider each area as its own category as you develop the design matrix for what settings each type of computer will include in its GPO. These additional areas can include:
Applications (Microsoft or third-party)
Custom .adm file settings (registry values)
Custom security template settings
More Info
For more information about developing custom .adm files, see Chapter 14. For more information on developing custom security template settings, see Chapter 15.