Figure 17.1 details the order in which multiple policies are applied when a user object logs on to the domain. In the diagram, the user object exists in the OU 4 OU, which is in the OU 3 OU of Domain 1 of Site. When the user logs on, the local policy of the computer is applied, followed by any GPOs attached to Site, then Domain 1, then OU 3, and finally OU 4. Understanding Policy Inheritance We saw in Figure 17.1 that when the user logged on, policies from the Site, Domain, and OUs were applied to the user object.The example indicated that any policies associated with OU 3 would be applied before the policies in OU 4.Through policy inheritance, the policies in OU 3 will apply to all objects in OU 3, OU 4, OU 5, and OU 6, even if no specific policies are assigned to OU4, OU5, or OU6. Objects in child containers generally inherit policies from the parent containers within a domain. If a policy setting is enabled in OU 3 and that same policy setting is not configured in OU 4, then objects in OU 4 inherit the policy setting from OU 3. If a policy setting is disabled in OU 3 but that same policy setting is enabled in OU 4, then the policy setting is enabled in OU 4, as the GPO for OU 4 overrides policy settings from OU 3.This is the way it works by default. However, administrators can block inheritance on group policy settings at the OU level. If you want to start with a clean slate at a particular OU, you can use the Block Policy Inheritance setting at that OU, and only the settings in the GPO for that OU will apply to objects in the OU. Blocking policy inheritance does not impact local computer policy settings, only Active Directory group policy settings. In addition, policies set at a higher container can be marked as No Override, which prevents any lower container settings from changing the policy settings of the higher container. Going back to Figure 17.1, if the GPO for OU 3 is marked for No Override, and a policy setting in the GPO for OU 4 conflicts with a setting from OU 3, the setting in OU 4 will not take effect.You cannot block a policy that is set to No Override. 566 Chapter 17 • Working with Group Policy in an Active Directory Environment Figure 17.1 Processing Policy Settings at User Logon User Computer Local Policy OU 3 OU 3 Policy OU 4 OU 4 Policy Site Site Policy Domain 1 Domain 1 Policy Site Domain 1 Domain 2 OU 3 OU 1 OU 2 OU 6OU 4 OU 5 User 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 566 You should use great care in using the Block Policy Inheritance and No Override settings when configuring Group Policy. Changing the default way in which policy is applied can complicate troubleshooting of policy settings if problems are encountered. Filtering Scope by Security Group Membership As mentioned, you can further control which policies are applied to which objects by filtering policy application by security group membership. Similar to setting permissions on files and folders with NTFS security settings, you can set security on a GPO so that only certain groups can see the GPO, which means that only those groups will have the policies applied. Looking back at Figure 17.1, the diagram assumes that there is no security filter on the GPOs at any level. Now let’s suppose that the user object is a member of the Accounting group, and that the GPO in OU 4 has security permissions set. If the security permissions on the GPO in OU 4 do not give members of the Accounting group access to read the GPO, then the user will not have the GPO settings for OU 4 applied when he or she logs on. If you find yourself needing to filter GPO settings based on group membership, you might need to set multiple GPOs on a container and adjust the security settings accordingly. Again, adding a number of GPOs to a container increases the complexity of the policy setting process, which can cause complications for troubleshooting. Group Policy Integration in Active Directory As mentioned earlier, non-local group policy settings are stored in objects in the Active Directory. These objects are linked to specific containers: sites, domains, and OUs. Since GPOs are objects in the directory, they are subject to all the settings and rules of other objects. Group Policy Propagation and Replication Active Directory replication has an impact on group policy application in a large directory structure. Because GPOs are objects in the directory, they must be replicated to all copies of the directory par- tition on all domain controllers (DCs) before the settings can take effect in all circumstances. Replication is a concern for GPOs linked to a site or domain with multiple controllers. When group policy is set for a domain, by default the actual object is tied to the server that has the primary domain controller (PDC) Emulator operations master token.The other DCs will receive the updated policy information as the token is passed around through replication. Users who authenticate to DCs other than the PDC might not receive the updated policies upon logon if the directory has not had ample time to replicate the settings. You can specify a particular DC to be used for editing group policy by using the DC Options command in the View menu of the GPO Editor. As mentioned, the default is the DC with the PDC Emulator operations master token, but you can change this setting. Sites that have multiple servers connected over slow WAN links have several issues related to policy propagation and replication. Obviously, a DC with an updated group policy is impacted by a slow WAN link when attempting to replicate the data across the link. Depending on how the direc- tory is configured, DCs across the slow link can be set up to replicate much less frequently than those on a faster link. Working with Group Policy in an Active Directory Environment • Chapter 17 567 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 567 Also of concern are users who authenticate to a DC across a slow WAN link. While the normal authentication process might not be all that network-intensive, more GPOs that have to be pro- cessed by the user significantly increases the time needed for full authentication. Planning a Group Policy Strategy You must consider a number of factors when planning the group policy strategy for your organiza- tion. Some of these factors include size of the organization, geography of the organization, structure of the organization, and so on. More importantly, you must determine the effective policy settings you want to have for each object in the directory. One way to test your policy plan is to create the policies and then log on with user accounts from different locations of the directory and see how the policies impact the user experience.This is time consuming, cumbersome, and has a definite impact on the production network. Fortunately, Microsoft provides a way for evaluating the proposed policy environment without impacting the production system. Using RSoP Planning Mode The Resultant Set of Policy (RSoP) tool, included with Windows Server 2003, has a special planning mode that system administrators can use to evaluate the design of the group policy within the directory.The planning mode of RSoP can simulate a number of situations where group policy settings can be affected by a number of factors, including slow network links. Opening RSoP in Planning Mode To use RSoP in planning mode, you will need to run the Resultant Set of Policy Wizard from inside the Microsoft Management Console (MMC).You can follow these steps to open RSoP in planning mode to collect information for an RSoP report. 1. Open Microsoft Management Console (MMC) and add the RSoP snap-in. ■ Select File | Add/Remove Snap-in. ■ Click Add. ■ Select Resultant Set of Policy from the list. ■ Click Add, and then click Close. ■ Click OK. 2. Right-click on Resultant Set of Policy and select Generate RSoP Data. 3. Click Next in the Resultant Set of Policy Wizard window. 4. Click the Planning Mode option button, and click Next. The RSoP wizard will walk you through the steps of gathering the data that can be collected and included in the RSoP report. On each page, there is a Skip to the final page of this wizard without collecting additional data check box. If you select the check box, only the data specified 568 Chapter 17 • Working with Group Policy in an Active Directory Environment 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 568 up to that point in the wizard will be included in the RSoP query. All other settings will take their default values. The first page of the wizard collects user and computer information on which the query will run.This is the only data that is required in the wizard, as all subsequent pages can be skipped by clicking the Skip to the final page of this wizard without collecting additional data check box. On this page, you must select a specific user or user container, and a specific computer or com- puter container.You can use the Browse buttons to search for a user or computer or the parent container, or you can enter the information directly into the fields. After the information for the user and computer selections is complete, the Next button will enable and you can move to the next page of the wizard. The next page of the wizard allows you to specify any advanced simulation options. On this page, you can specify the report to simulate a slow network connection and loopback processing options, if any.You can also specify which site’s policies to test, if there are multiple sites available. If you specified a specific user or computer in the initial page of the wizard, the next page of the wizard will allow you to specify an alternate location for the object or objects specified. Changing the location of the object will let you test what changes would occur if you moved the object to a different location in the directory. If you only select containers in the initial page, this page will not display. The next page of the wizard identifies the security groups for the user object selected. If a specific user is selected in the first page of the wizard, the security groups for that user are displayed. If a user container is specified, the Authenticated Users and Everyone groups are listed as defaults.You can add user groups to the list or remove groups from the list to see what changes will occur as a result. The next page of the wizard identifies the security groups for the computer object selected. As with the user selection in the previous page, you can specify which security groups to use when running the query. The next options page of the wizard allows you to select the Windows Management Instrumentation (WMI) filters to use on the user object or container in the query.The default selec- tion is for all linked WMI filters, or you can select only specific WMI filters. The last options page of the wizard selects the WMI filters for the computer object or con- tainer. As on the previous page, you can accept the default selection of all WMI filters, or you can specify which filters to use. After you complete all the pages of the wizard, or if you select the option to skip the remaining information pages, a summary page will display the options that will be used when running the query. Figure 17.2 shows the summary page and the information specified for a sample query. In this window, you can choose to gather extended error information or select a different DC to pro- cess the simulation. Clicking Next will start the query based on the information listed in this page. Working with Group Policy in an Active Directory Environment • Chapter 17 569 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 569 When the query has completed (which might take several minutes depending on the size and configuration of your environment), the wizard’s finish page will display. Clicking Finish will close the wizard and return you to the MMC to review the RSoP report. Reviewing RSoP Results The results of the RSoP query displayed in the MMC will look similar to the Group Policy Object Editor window, with a few important differences. Figure 17.3 shows the RSoP results window in the MMC.This particular query was run on the user chapmap and the Computers container. When looking at the policy settings in the window, you only see the policies that will be in effect for the user when logged on to a computer in that particular container.You will also only be able to view the policy settings in this interface.You will not be able to change any policy. When you right-click either the Computer Configuration or User Configuration node in the tree and select Properties, you will find information about the policies that were processed to 570 Chapter 17 • Working with Group Policy in an Active Directory Environment Figure 17.2 Reviewing the Settings of the RSoP Query Prior to Execution Figure 17.3 Reviewing the RSoP Planning Results 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 570 generate the results found in the report.You can select to view all GPOs and their filtering status to see which GPOs were processed and which were not, and why not if they were not.You can display revision information to see how many times a particular GPO has been modified, and you can dis- play scope information that tells where the GPO resides. If you click the Security button, you can see the security permissions set for the GPO. If you open a policy setting, you can view the properties of that policy setting. Figure 17.4 shows the properties of the setting selected in Figure 17.3.As shown in the figure, the option to set this particular setting as default is grayed out, because no changes can be made in this interface. If you click on the Precedence tab, you will see a list of GPOs where this particular policy is set, including the order in which this policy was processed. You can run an additional query on a different set of user and computer objects from this inter- face by right-clicking on the RSoP result object in the left pane, chapmap on Computers – RSoP in this instance, and selecting Change Query. If you go in and make group policy changes that would impact the results of the query and want to see how those changes actually affect the system, you can right-click the RSoP result object and select Refresh Query.This second option will re-run the query with the same options Strategy for Configuring the User Environment When setting group policy at the user level, you are creating an environment that will follow the user around the network. No matter what computer the user logs on to, the group policy settings inherited by that user will apply.This section covers some of the “shoulds” and “should nots” related to the user environment. One policy setting that will follow the user around no matter where he or she logs on is roaming profiles. Enabling roaming profiles for a user community will store all the user settings on a server rather than on the local computers. When a user logs on, all of his or her profile settings (Desktop items, My Documents, Registry settings, etc.) will be pulled off the server, ensuring that the user has Working with Group Policy in an Active Directory Environment • Chapter 17 571 Figure 17.4 Viewing the Properties of a Policy Setting in the RSoP Report 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 571 the same environment on each computer he or she uses.This approach has many advantages, but it has disadvantages as well. Some profile settings are hardware-dependent, and if the computers used by the user do not have the same hardware, the user could encounter difficulty upon logon (video cards can be especially problematic in this regard). Software Installation is another policy that can be of great benefit to the organization. If a certain group of users has a particular application that is critical to performing their work tasks, you can set up software installation policies that will download and install the application on any computer the user uses throughout the company.This policy also keeps unauthorized users from being able to run the application even though it is installed on the computer they are using.The same caveat applies to software installation as to roaming profiles. Not all software packages are compatible with other programs that might be installed on a computer. Before implementing this type of policy in the organization, you’ll need to make sure that the applications being installed will work well with other programs that already exist on the computer.The last thing you want to do is to break one program on a system by installing another. The vast majority of other group policy settings that you can apply to users in the directory have little chance of causing conflict with other settings on the local computer. Logon and logoff scripts, application settings, folder redirection, and environment configurations can help to stan- dardize the user’s computing experience across multiple machines, which can, in turn, ease the sup- port burden on your IT staff. Strategy for Configuring the Computer Environment When setting policy for the computer environment, the settings applied will impact every user who logs on to the computer. Unlike user settings, there are two places where computer policy is applied.The first is the local policy set at the computer each time it boots.These settings are applied first, and any subsequent policy that conflicts with the local settings will override the local settings. However, computer policy can also be set in Active Directory.These settings follow the same rules as user settings in terms of priority order. Any computer policies set at the site level will be over- written by additional policy settings at the domain or OU level when the settings conflict. One case where computer policy overrides user policy is when a GPO containing computer settings is configured to operate in loopback mode. Loopback mode is a special setting that is only used in cases where a very specific set of policies needs to be applied in a controlled environment. Loopback mode allows administrators to apply group policy based on the computer at which the user is logging on. In other words, this setting is used if a particular user should have different poli- cies applied, depending on where he or she logs on. When loopback processing is enabled, the com- puter policies set for the system override any user policy settings applied during logon. Loopback operates in two modes—replace and merge. When loopback is enabled, one of these two modes must be selected. Replace mode will eradicate any user policy settings applied at logon and only retain the computer policy settings. Merge mode will allow user settings that do not con- flict with computer settings to be applied. If there is a conflict between the two, the computer set- tings override the user settings. The philosophy of “less is more” applies directly to the approach for setting computer policy in the domain. In general, you should try to have only one set of policies apply to computers. If you do have cases where you need different policy settings to apply to different sets of computers within 572 Chapter 17 • Working with Group Policy in an Active Directory Environment 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 572 the organization, set up the separate policy objects, but restrict access to those objects so that only the systems that need to be affected by the object will process the settings. Run an RSoP Planning Query This following procedure walks you through the process of generating an RSoP planning report based on changing a user object from one OU to another. For this example, we will use the user object for Robert Smith, which exists in the Marketing OU, and build an RSoP report showing the policy settings that would apply to the object if it were moved into the Accounting OU. As long as you have appropriate permissions to run an RSoP query on a system, you should be able to emulate the steps in this example on a system to which you have access, as you will not be changing any set- tings on the system in the process. 1. Open an MMC window and load the RSoP snap-in (see the steps outlined earlier in this section if needed). 2. Right-click the Resultant Set of Policy object in the console tree, and select Generate RSoP Data. 3. In the Resultant Set of Policy Wizard, click Next. 4. Select the Planning Mode option button, and click Next. 5. In the User and Computer Selection window, select the User option button, and click the Browse button in the User information frame. 6. In the Select User dialog box, choose a user object and click OK. 7. In the User and Computer Selection window, click the Computer option button, and click the Browse button in the Computer information frame. 8. In the Select Computer dialog box, choose a computer object and click OK. 9. The User and Computer Selection window should now appear as in Figure 17.5. Click Next. Working with Group Policy in an Active Directory Environment • Chapter 17 573 Figure 17.5 Specifying the User and Computer Objects in the RSoP Wizard 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 573 10. In the Advanced Simulation Options page, select the appropriate site from the Site drop-down list, shown in Figure 17.6, and click Next. 11. In the Alternate Active Directory Paths page, change the location for the user and computer objects. When the new locations have been selected, click Next. 12. In the User Security Groups page, change the security groups to match those of the new location. Select the groups that the user would no longer belong to, and click Remove. 13. To add new security groups to the query, click the Add button and select the appropriate groups. Click Next. 14. In the Computer Security Groups page, you can leave the security group setting as it is, or you can change group assignments by using the Add and Remove buttons. Figure 17.7 shows the settings used for this query. When complete, click Next. 574 Chapter 17 • Working with Group Policy in an Active Directory Environment Figure 17.6 Specifying a Site in the Simulation Options Page Figure 17.7 Selecting Computer Security Group Settings 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 574 15. In the WMI Filters for Users page, select the All linked filters option button to include all WMI filters in the query, as shown in Figure 17.8, or select the Only these filters option button to specify which filters to use. When finished, click Next. 16. In the WMI Filters for Computers page, select the All linked filters option button to include all WMI filters in the query, or select the Only these filters option button to specify which filters to use. When finished, click Next. 17. Review the selections made in the Summary of Selections page, and click Next to start the query. 18. When the query has completed, click the Finish button to close the wizard and view the RSoP report, shown in Figure 17.9. 19. Browse through the report looking at the policies that would be enabled for user smithb on computer MKTG01. Close the MMC when done. Working with Group Policy in an Active Directory Environment • Chapter 17 575 Figure 17.8 Selecting WMI Filters for Users Figure 17.9 Viewing the RSoP Report 301_BD_W2k3_17.qxd 5/12/04 2:18 PM Page 575 . default the actual object is tied to the server that has the primary domain controller (PDC) Emulator operations master token .The other DCs will receive the updated policy information as the token. when running the query. The next options page of the wizard allows you to select the Windows Management Instrumentation (WMI) filters to use on the user object or container in the query .The default. point in the wizard will be included in the RSoP query. All other settings will take their default values. The first page of the wizard collects user and computer information on which the query