Learning Windows Server 2003
6.2. Group Policy Implementation
Now that you know the components of GP, let's take a look at how they are implemented. Like NTFS permissions, GPs are cumulative and inheritedcumulative in that the settings modified by a policy can build on other policies and "amass" configuration changes, and inherited in that objects below other objects in Active Directory can have any GPs that are applied to their parent object be applied to themselves automatically. GPOs are associated with, or linked, to any number of objects, either within a directory or local to a specific machine. To implement a GP on a specific type of object, follow these guidelines:
Windows applies GPs in the following order, which you can remember with the acronym "LSDOU":
The only exception to this rule occurs when you're using NT 4.0 system policies that are created and set with the NT System Policy Editor. Recall from NT administration days that the system policies are called NTCONFIG.POL, so if Windows finds that file present, it applies these policies before the local GPO. Of course, these policies can be overwritten by policies that come farther down in the application chain.
6.2.1. Introducing the Group Policy Management Console
You'll find that GPOs themselves are much easier to create and edit using Microsoft's Group Policy Management Console (GPMC ), a drop-in replacement for the more limited Group Policy Object Editor that ships installed with Windows Server R2. While it's certainly possible to perform the actions I'll describe in this chapter with the native Group Policy Object Editor, the tool has limitations: the biggest by far being the lack of ability to see the exact scope of a GPO's application, making troubleshooting very difficult. The GPMC fixes this and also offers a cleaner interface, scripting functionality, and enhancements to troubleshooting and modeling features. It's very easy to get the GPMC: simply visit:
and click on Group Policy Management Console. Follow the Download link and double-click on the resulting MSI file to install the GPMC. Once the installation wizard is finished, you can begin managing GP through the utility. Launch the Group Policy Management Console from the Administrative Tools menu off the Start menu; you'll see a screen much like Figure 6-1. To navigate around in the GPMC, you need to expand the forest you want to manage in the left pane. Then you can select specific domains and sites within that forest, and OUs within individual domains. When you expand, for example, a particular domain, links to the GPOs that exist are listed within their respective OUs. They also are listed under the Group Policy Objects folder. Clicking on a GPO brings up a four-tabbed screen in the right pane. Figure 6-1. The Group Policy Management Console The first tab is the Scope tab, which examines how far-reaching the effects of this GPO are. Sites, domains, and OUs that are linked to the GPO you've selected are listed at the top of the window. You can change the listing of pertinent links using the drop-down box, where you can choose to list links at the current domain, the entire forest, or all sites. At the bottom of the window, any security filtering done by ACLs is listed. Clicking the Add button brings up the standard permissions window, as you would expect from the Group Policy Object Editor. At the very bottom, you can see any WMI filters to which this GPO is linked. You can choose to open the WMI filter for editing by clicking the Open button. You can associate only one WMI filter with any particular GPO, and WMI filters work only with Windows XP and Windows Server 2003. We'll get to these in a bitfor now, let's move on. The next tab, Details, simply shows the domain in which the current GPO is located, the owner of the GPO, when the GPO was created and modified, the version numbers for the user and computer portions, the GUID of the object, and whether the GPO is fully enabled or fully disabled, or whether just the computer or user configuration portions are enabled. Of particular interest is the Settings tab, as shown in Figure 6-2. The Settings tab is one of the most useful tabs in the GPMC. The GPMC will generate HTML-based reports of all the settings in a particular GPO, and you can condense and expand portions of the report easily for uncluttered viewing. You can print the report for further reference, or save the report for posting to an internal web site for your IT administrators. It's a much, much easier way to discern what settings a GPO modifies than the Group Policy Object Editor. To edit the GPO that is displayed in the report, simply right-click it and select Edit. To print the HTML report, right-click it and select Print; to save the report, right-click it and select Save Report. Figure 6-2. Examining a standard GPO via the Settings tab Finally, the Delegation tab lists in a tabular format the users and groups that have specific permissions for the selected GPO, what those permissions are, and if they're inherited from a parent object. Clicking Add brings up the common Select User, Computer, or Group dialog box that you are familiar with from reading this chapter. You can remove a delegated permission by clicking the appropriate user or group in the list and then clicking the Remove button. The Properties button will bring up the standard Active Directory Users and Computers view of the selected user and group. You'll see more of this interface in action as we proceed through the chapter. 6.2.1.1. Creating and editing Group Policy Objects
To start off, you need some GPOs to work with. Use the tree in the left pane to navigate through the various forests and domains on your network. Then, when you've settled on a location, right-click on that location and select Create and Link a GPO Here. In the New GPO box, enter a name for the object, and then click OK. You'll see the new GPO listed in the righthand pane; the GPO creation process is finished. To edit the object, right-click the object and select Edit. You're presented with a screen much like that shown in Figure 6-3. Figure 6-3. The Group Policy Object Editor screen
You'll note there are two branches to each GPO: Computer Configuration and User Configuration. Each contains the same sub-trees: Software Settings, Windows Settings, and Administrative Templates. The Computer Configuration tree is used to customize machine-specific settings, which become effective when a computer first boots. These policies are applied across any users that log on to the system, independent of their own individual policies. Using computer policies, you can lock down a group of computers in a lab or kiosk situation while still maintaining an independent set of user policies. The User Configuration tree, as you might suspect, contains user-specific settings that apply only to that user regardless of where she is on the network. 6.2.1.2. Administrative templates
Microsoft has kindly chosen to provide sample sets of GPs, located in the %SystemRoot%\Inf directory, which you can apply to domains or OUs to establish a standard configuration for certain aspects of Windows functionality. Table 6-1 shows the policies included and their respective functions.
You can access these templates through the Group Policy Object Editor (they are loaded automatically by the Group Policy Management Console the first time you run it) by navigating through each node, the Computer Configuration and User Configuration branches, and clicking Administrative Templates. Then you will see the categories of policies available to you under each template and can simply make the changes you want. Once you make changes to one of these templates, the registry.pol files inside the GPT subfolders USER and MACHINE keep up with the changes and ensure that the proper policy versions are applied to the appropriate computers, depending on how you have assigned the GPO. 6.2.1.3. Disabling portions of policies
A GPO has the potential to be large because it can contain numerous computer and user settings. If you don't intend to populate either your computer or user settings, you can disable that portion of the GPO. By doing this, you're speeding up propagation time over the network and processing time on the computers that need to load the settings in the object. So, if you have a GPO that applies only to computers, you can disable the user configuration branch of the policy and significantly improve the performance of your network. To do so, follow these steps:
The portion of the policy you selected is now disabled. (Of course, you can disable the computer portion of policies using the same method.) 6.2.1.4. Refreshing computer policies
Speaking of changes to policies, it can take some time for modifications to propagate across domain controllers within a domain and finally to the objects for which they're destined. Policies are refreshed on a client when the computer is turned on, a user logs on, an application requests a policy refresh, a user requests a policy refresh, or the interval between refreshes has elapsed. The latter part of that sentence is key: there's a GPO you can enable that will allow you to customize the interval at which computer and domain controller policies refresh. It's best to make this change at either a domain or OU level for consistency. Figure 6-4. Disabling a portion of a policy
To enable the policy refresh interval, follow these steps (I'll assume you're changing this on a domain-wide basis):
You also can also manually force a policy refresh from the command line on client computers with the gpupdate command. To refresh all parts of a policy, issue this command: gpupdate /force To refresh just the Computer Configuration node of the policy: gpupdate /target:computer /force To refresh just the User Configuration node of the policy: gpupdate /target:user /force
To manually refresh GPOs on Windows 2000, the syntax is a little different. To refresh only the computer policy: secedit /refreshpolicy machine_policy
To refresh only the user policy: secedit /refreshpolicy user_policy
You can force updates of objects, even if they haven't been modified since the last update, by adding the /enforce switch at the end of the command. Then Windows will enforce all policies, regardless of whether the actual policy objects have changed. This is useful if you are having network difficulties and want to ensure that every computer has a fresh application of policy, or if you have a large contingent of mobile users that connect to the network briefly and unpredictably. For either clients or domain controllers, exercise extreme caution when modifying the default refresh interval. On large networks, altering the refresh interval can cause hellish amounts of traffic to be unleashed over your networka costly move that's unnecessary for 95% of sites with domains installed. Although clients will pull down new policies only if those policies have changed, the increased traffic results from clients just contacting a domain controller every x minutes to get new policies and updates. There's very little reason to alter this value. Here's a good rule of thumb: if you don't know of a good justification to increase the refresh interval, it isn't necessary for your site.
If you want, you also can elect to disable background policy refreshing completely. You might do this if you're having trouble tracking down an intermittent GPO problem, or if you don't want to have a GP applied during the middle of a client session because it might disrupt an application. Again, it's best to do this on a domain-wide or OU-wide basis for consistency and best performance. To disable background processing, follow these steps:
In some situations, you might want a policy setting to be applied, even if no setting has changed. This goes against default GPO behavior because usually, only changes trigger a policy refresh and reapplication. For example, a user might change some Internet Explorer settings within his session. You might want that change to be reversed, but Windows won't trigger a refresh because the policy itself hasn't changed. To prevent this, you can use the configuration option called Process even if the Group Policy Object has not changed. (This is like the /enforce switch described a bit earlier.) You've probably caught on by now that it's best to do this on a domain-wide or OU-wide basis for consistency and best performance. To do so, follow these steps:
Policy settings related to computer security follow a refresh policy that is a bit different from normal GPOs. The client computer still refreshes security policy settings even if the GPO has not been changed or modified. There are registry settings whose values indicate the maximum acceptable time a user or client computer can wait before reapplying GPOs, regardless of whether they are changed. They are as follows:
6.2.1.5. Policy enforcement over slow network connections
Windows Server 2003 will detect the speed of a client's connection to the network and, based on its measurements, disable enforcement of certain policies that would bog down a slow connection. Policies that Windows will disable include disk quotas, folder redirection, scripts, and software installation and maintenance. By default, Windows considers a speed of less than 500 Kbps a slow link, but you can change this on a per-GPO basis. To change the slow link threshold, follow these steps:
6.2.2. The Scope of Group Policy Objects
So, how far do these GPOs go? What types of objects can GPOs affect? To deploy a GP to a set of users, you "associate" a GPO to a container within Active Directory that contains those users. By default, all objects within a container with an associated GPO have that GPO applied to them. If you have a large number of GPOs or Active Directory objects, it can be confusing to track the scope and application of GPOs. Luckily, you can find out to which containers a specific policy is applied by selecting the GPO in the Group Policy Management Console and looking in the right pane at the Scope tab. The Links section will reveal the sites, domains, and OUs that are affected by the GPO. To adjust the view of links, you can use the drop-down list box under the Links section and choose the sites and domains you wish to see. You can see this section in Figure 6-5. Of course, in practice there always are exceptions to any rule; for example, most likely there will be some computers within a container that shouldn't have a policy applied to them. The most straightforward way to limit the scope of a GPO within a specific container is to create security groups that contain only the objects that are to be included in the policy application. Once you've created the necessary groups, follow these steps:
Figure 6-5. Enabling security group filtering
The GPMC makes it simple to limit the application of a GPO to a specific group, as you just saw. But what if you want more granular control than this? You also can play more tricks with groups and GPO ACLs to further limit the effects of policy application to objects, but you'll need to dive into the advanced security settings of the object itself to get more complex operations done. To get there, navigate to the Delegation tab in the right pane of the GPMC and click the Advanced button in the lower-right corner. The screen shown in Figure 6-6 will appear. Figure 6-6. Manually setting security group filtering
The following is a list of appropriate ACL permissions to grant to obtain the desired result:
6.2.3. Enforcement and Inheritance
Policies applied to parent objects are inherited automatically by child objects unless there are conflicts; if a child's directly applied policy conflicts with a general inherited policy from a parent, the child's policy will prevail, on the assumption that the administrator really wanted the result of the specifically applied policy and not one that is granted indirectly because of directory tree position. Policy settings that are currently disabled migrate to child objects in the disabled state as well, and policy settings that remain in the "not configured" state do not propagate at all. Additionally, if there are no conflicts, two policies can coexist peacefully, regardless of where the initial application occurred. As with permissions, you can block GPO inheritance by using two options available within the user interface: Enforced, which instructs child containers to not replace any setting placed higher on the tree than they are; and Block Policy Inheritance, which simply eliminates any inheritance of parent object policies by child objects. If both of these options are set, the Enforced option always trumps the Block Policy Inheritance feature.
To set a GPO to not override parent GPO settings, you need to set the GPO status to "enforced." Follow these steps:
Figure 6-7. Setting the Enforced option on a GPO To block any inheritance of parent policy settings for the current administrative container, first double-click the forest containing the domain or organizational unit for which you want to block inheritance for GPOs, and then do one of the following:
Finally, click Block Inheritance, as shown in Figure 6-8. Figure 6-8. Setting the Block Policy Inheritance option You'll see a small blue exclamation point in the icon beside the domain or OU for which you've blocked inheritance, indicating the operation was successful. To remove the inheritance block, use the aforementioned procedure, and simply uncheck Block Inheritance on the context menu.
6.2.4. WMI Filters
A new feature of Windows Server 2003 is the ability to filter how Group Policy is applied based on Windows Management Instrumention (WMI) data. Using WMI filters , you can construct a query with WMI Query Language (WQL) that will return various results onto which you can apply a GP. WMI allows you to pull various characteristics otherwise unavailable through the GPMC, such as a computer's manufacturer and model number, the installation of certain software packages, and other information. You might use WMI when applying policies using these criteria. To create a WMI filter in the GPMC, right-click on the WMI Filters link in the left pane and select New. The New WMI Filter is shown in Figure 6-9. Enter a name and description for the filter, and then create the query that will represent the dataset against which the GPO will be filtered by clicking Add, selecting the namespace, and then entering the syntax of the query. Note that you can add more than one query to a filter. While constructing WMI queries is outside the scope of this book, you'll find that such queries are very similar in format to SQL queries. For this example, I'll use a simple query that retrieves machines running Windows XP on the network, as shown in the figure. Figure 6-9. Creating a new WMI filter
Once you've entered the query and are satisfied with it, click Save. To enable a WMI filter on a particular GPO, click the GPO in the GPMC and look at the bottom of the Scope tab in the right pane. There, you can select the WMI filter to apply to the GPO, as shown in Figure 6-10. Keep in mind that if you set a WMI filter for a GPO, it's an all-or-nothing affair: you can't individually select certain policy settings to apply only to the filtered objects. Either the entire policy applies to the list of filtered objects, or the entire policy doesn't apply. This might unfortunately result in an inordinate number of GPOs in your directory, each servicing a different list of filtered objects. Keep this is mind when structuring policies. Also be aware that you can apply only one WMI filter per GPO, although each WMI filter can contain multiple WMI queries as I noted before. Figure 6-10. Adding a WMI filter to a GPO If you're not familiar with WMI, Microsoft has provided a utility called Scriptomatic that, although unsupported by Microsoft, helps you construct and use WMI queries for many different Windows administration tasks. You can find the Scriptomatic utility at:
If you're curious, here is a brief sample WMI filter from above that can reside as a simple XML file on a hard drive; these types of filters use a .MOF extension. This will give you an idea of the structure of a filter and how to create one: <?xml version="1.0" encoding="utf-8" ?> <filters> <filter> <description>XP Machines</description> <group>MYDOMAIN\Windows XP Computers</group> <query namespace="ROOT\CIMv2"> SELECT * FROM Win32_OperatingSystem WHERE Version = 5.1.2600 </query> <!-- More queries --> </filter> <!-- More filters --> </filters>
If you have a lot of WMI filters in separate files, you can import them by right-clicking on WMI Filters in the left pane of the GPMC and selecting Import. You can browse for your MOF files and then import them for use in filtering. 6.2.5. Resultant Set of Policy
In Windows 2000, there was no easy way to see all the policies that were applied to a specific object, nor was there a way to easily project the potential changes to an object that a policy modification would make. However, Microsoft decided in Windows Server 2003 to include the Resultant Set of Policy (RSoP) tool, which can enumerate the following situations:
You can access each using the Group Policy Modeling and Group Policy Results items in the left pane of the GPMC. Right-click on the appropriate item and select the option that runs each wizard. 6.2.5.1. Planning mode
In RSoP planning mode, accessed through Group Policy Modeling, you can simulate the effects of the deployment of GPOs, change the GPO in accordance with those results, and then re-test. You can specify a particular domain controller, users, security groups, and user memberships within, the location of a machine or site, and any applicable WMI filters, and then model the results of applying a specific GPO. To get started in planning mode, right-click Group Policy Modeling and, from the context menu, select Group Policy Modeling Wizard. Click Next from the introductory screen. The Domain Controller Selection screen appears, as shown in Figure 6-11. Here, select the domain controller to use when processing the RSoP request. This domain controller must be running Windows Server 2003. You can choose a specific domain controller from the list, or let Windows choose a domain controller. You also can select a given domain to use its respective domain controllers using the Show domain controllers in this domain drop-down list. Click Next to continue. Figure 6-11. Modeling Group Policy: selecting a domain controller The User and Computer Selection screen appears, as shown in Figure 6-12. On this screen, you specify the user and computer settings you want to have analyzed when you apply GP. You also can choose a container if you want to analyze Group Policy objects that have been linked to a particular site, domain, or OU. Note also at the bottom of the screen the option to skip to the end of the wizard. If you have a simple query that is complete at any point during the wizard, simply select this option to bypass the remaining screens and go straight to the results of the query. Click Next to continue. The Advanced Simulation Options screen appears, as shown in Figure 6-13. On this screen, you can tell Windows to simulate a very slow link between domain controllers and clients, whether to merge or replace loopback processing, and the site to which these settings should apply. This is a very useful algorithm for testing real-world conditions. Click Next to continue. You'll next see the Alternate Active Directory Paths screen, as shown in Figure 6-14. On this screen, you can simulate the effects of moving your targets to different locations within your AD structure. You can use the default entries, which reflect the current location of the target objects, or change them using the Browse button to see what would happen if you moved the target to a new location. Click Next to continue. Figure 6-12. The User and Computer Selection screen
Next comes the User Security Groups screen, as depicted in Figure 6-15. On this screen, you can see the results of applying Group Policy if you change the existing user or computer's security group memberships. The current group memberships are listed in the box, and you can add and remove them using the Add and Remove buttons. To undo your changes, just click Restore Defaults. Click Next when you have the list as you want it. If you have selected a computer or container of computers in the initial step of the wizard, the Computer Security Groups screen will appear next. It operates exactly like the User Security Groups screen does, as just described. Click Next to continue. The WMI Filters for Users screen appears next, as shown in Figure 6-16. Here, you instruct Windows to assume that the user (or container of users) you've selected meets either all configured WMI filters or the specified WMI filter as shown in the box. Click Next when you've selected the appropriate filters. If you selected a computer or container of computers in the first step of the modeling wizard, the WMI Filters for Computers screen appears next; this screen functions exactly like the WMI Filters for Users screen I just discussed. Click Next to continue. Figure 6-13. The Advanced Simulation Options screen
The next screen is a summary of your selections. Confirm that all is well, and then click Next to begin the simulation. When the process is complete, the wizard will let you know. When you click Finish, the results will appear. A sample results screen is shown in Figure 6-17. The result is an HTML file that you can collapse and expand as needed. You can see each computer configuration and user configuration result, including GPOs that would be applied and denied, any WMI filters that would be used, how each GP component would survive the deployment, and general information about the query. You can right-click the report and either print or save it. And, if you change your GP settings and want to rerun the same query on the new settings, simply right-click the results page within the GPMC and select Rerun Query. 6.2.5.2. Logging mode
The RSoP logging mode with the GPMC, called Group Policy Results, operates in much the same way as the planning mode does. To get started, right-click Group Policy Results in the left pane of the GPMC and select Group Policy Results Wizard from the context menu. Figure 6-14. The Alternate Active Directory Paths screen
Click away from the introductory screen in the wizard, and the Computer Selection screen appears, as shown in Figure 6-18. Here, select the computer for which you want to obtain results. You can analyze the current computer or another computer on the network. You also can limit the results to only the User Configuration portion of GP using the checkbox in the middle of the screen. Click Next to continue. The User Selection screen appears next. This is reproduced in Figure 6-19. On this screen, you can select which user to report the results of the User Configuration section for. The list is limited to those who have logged on to the computer at some point in time and for whom you have permission to read the results. You also can limit the results displayed to computer configuration information only by using the radio button at the bottom of the screen. Click Next to continue. Figure 6-15. The User Security Groups screen
Figure 6-16. The WMI Filters for Users screen Figure 6-17. Group Policy Modeling results The Summary of Selections screen appears. Confirm your choices, and click Next to perform the query. When the process is complete, the wizard will notify you. Click Finish to view the results; a sample result screen is shown in Figure 6-20. Like the other GPMC reports, this one is HTML-based and can be saved and printed by right-clicking anywhere in the report and selecting the appropriate option. For each of the Computer Configuration and User Configuration portions of GP, the report shows the following:
Figure 6-18. The Computer Selection screen
Figure 6-19. The User Selection screen
Figure 6-20. Results from the Group Policy Results Wizard
6.2.5.3. Using RSoP without the GUI
You also can script some functions using the RSoP APIs. The sample script provided in Example 6-1, courtesy of http://ActiveDir.org with some modifications, logs the user and computer objects being applied to a particular set of objects within Active Directory. To use it, copy and paste the following text into your favorite text editor, and save it using a .vbs extension. Then, run it from the command line using the following: Cscript filename.vbs
Example 6-1. Creating an RSoP report with VBScript
You can retrieve information on the RSoP application in a few other ways as well. Microsoft includes a tool with the Windows 2000 Resource Kit, called GPRESULT.EXE, which you can run on a client computer. (Windows XP and Windows Server 2003 have this utility installed by default.) GPRESULT will return a listing of all policies applied to a user and computer, the OUs in which the computer and user are located, the site they are in, and a lot more information. You can find the GPRESULT executable and technical information on the tool at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp. The remote computers need to run Windows XP or Server 2003, however, for GPRESULT to return accurate information. For example, to get information for the user jhassell on the remote workstation JH-WNXP-LTP using GPRESULT, run: gpresult /s JH-WNXP-LTP /USER jhassell
Likewise, to get information for the user ljohnson on the remote workstation LJ-WNXP-DSK, run: gpresult /s LJ-WNXP-DSK /USER ljohnson You also can add the /V option to enable verbose logging, which will display detailed information and not just a summary view, or /Z, to enable extended verbose logging (even more details). Use the /SCOPE MACHINE option with /Z to look at only computer configuration policies; similarly, use /SCOPE USER to look at user configuration policies. You can redirect the output of GPRESULT to a text file using the standard > DOS redirect operator.
6.2.6. Other Administrative Tasks
The GPMC also supports a few more functions, which I'll describe in this section. 6.2.6.1. Searching for GPOs
Using the GPMC, you can search for specific GPOs or for the values of properties of some GPOs. To do so, right-click a forest or domain in the lefthand pane of the GPMC and select Search from the context menu. The Search for Group Policy Objects screen appears, as shown in Figure 6-21. Figure 6-21. Searching for GPOs
You can select the scope of your search to be all domains within a forest, or within a specific domain that you select from the drop-down list at the top of the screen. Then you specify your search criteria by selecting the item to search, the condition to match, and the value that the condition should match. Here are the possible search terms:
You can stack criteria to have multiple conditions in your search by selecting the appropriate query and clicking Add to add the current criteria to the query list. Then you can select more criteria and add them to create more complex searches. You can remove selected criteria from the query list by clicking the Remove button. Click Search to start the search, and Stop Search to stop it before it has finished. The results of the search appear at the bottom of the screen. You can select a particular GPO that results from the search and go directly to editing it by selecting it and clicking the Edit button. You also can save the set of results by clicking the Save Results button, which puts the results in a text file of comma-separated values (CSVs). Finally, to clear the current results and perform a new search, click the Clear button. 6.2.6.2. Backing up, copying, importing, and exporting GPOs
The GPMC also supports copying, importing, backing up, and restoring GPO information. Previously, GPO backups were not possible unless you performed a system state backup of a domain controller. When you back up a GPO using the GPMC, only data pertinent to that particular GPO is backed up. Linked objects are not backed up because restoring that information becomes troublesome. However, when you restore, Windows automatically assigns the previous GUID of the backed-up GPO, which is wonderful for simply resurrecting an inadvertently deleted GPO. It is not uncommon for administrators to spend a great deal of time configuring GPOs exactly as needed and then to find themselves having to repeat the process manually on several other OUs for which they are responsible. The GPMC can save hours upon hours with its copy capability. You simply can copy a GPO or set of GPOs and then paste them elsewhere into another OU. However, a copy isn't the same as a backup because the copy process doesn't replicate the information in a file that can be moved elsewhere for safekeeping. Also, a copy of a GPO has a different GUID than the original GPO. To perform a GPO copy, you need rights to create GPOs in the destination location and read access to the GPOs in the original location. The GPMC also supports the ability to import and export GPOseven to a separate domain with which no trust exists to the original domain. This is useful when you need to copy the same GPO settings to multiple domains or when moving between development and productions forests. You don't need to meticulously re-create all your GPOs on the other domains; simply export them using the GPMC and import them on the new domain. It's a faster and less error-prone procedure. Importing GPOs across domains can be a bit complex because you'll need to create a migration table to specify how the GPMC should translate domain-specific data from one domain into the other. Most GPOs contain information such as users, groups, computers, and UNC paths that refer to objects available in a specific domain. These might not be applicable in the new domain, so you'll need to tell Windows how to translate these objects stored within the source GPO to other objects applicable to the destination GPO's location. Here's a more specific list of GPO aspects you can modify within the migration process:
Let's walk through several examples for backing up, copying, exporting, and importing GPOs with the GPMC. To back up a specific GPO, follow these steps:
To copy a specific GPO, follow these steps:
Figure 6-22. Backing up GPOs
Figure 6-23. Copying GPOs
Your GPO has been copied. To import a specific GPO, you need to create a new GPO in the location to which you want to import settings. For example, if you want to import the lockout policy from one domain into a new domain, you'll need to create a new GPO in the new domain. Then, follow these steps:
6.2.6.3. Managing GP across multiple forests
Using the GPMC, you can quite easily browse and set up GPOs in several distinct forests and domains. In fact, even the default setup of the GPMC allows you to select Add Forest from the Action menu and then to type the name of a forest you want to manage. The GPMC will add that to the list of available forests in the left pane. Managing GP for multiple forests comes with a few requirements:
6.2.6.4. Delegating administration of GPs
Windows 2000 introduced a feature that allowed you to delegate administrative authority for any number of privileges to certain users; this was an extremely useful and cost-effective way to spread out the workload and increase business unit responsibility for their own IT costs. In Windows Server 2003, Microsoft extended this ability to GPOs, allowing an administrator to extend supervisory privileges (to use old Netware terminology) over some actions with regard to GPOs. Here's how it works: By default, the creation of GPOs is restricted to members of the Domain Admins or Enterprise Admins groups or to those users who belong to the Group Policy Creator Owners group. The key distinction between those security groups is that although those in an administrator group can create and edit any and all GPOs in a directory, the members of the Group Policy Creator Owners group (hereinafter referred to as the GPCO group) can edit only those policies they created themselves. (If you are familiar with LDAP terminology, this is the managedBy concept.) In addition, members of the GPCO group cannot link GPOs to containers within a directory unless a special permission, known as Manage Policy Links, has been explicitly granted to them. If you take advantage of delegation in your organization and empower group or department managers to administer IT assets within their own scope of control, you might want to enable them to administer some GPOs for their group. It's likely that these managers aren't members of the Domain Administrators, Enterprise Administrators, or Group Policy Administrators groups, so you'll need to delegate individual privilegeseither the ability to create and edit GPOs themselves, or the ability to link GPOs to objects within Active Directory. The two privileges are independent; they are not required in tandem. To delegate the ability to create and edit GPOs to a user or group, follow these steps:
To delegate the ability to link GPOs to objects, follow these steps:
If you prefer to do this via scripting, a couple of sample scripts are included with a default GPMC installation, located in the Program Files\Group Policy Management Console\Scripts directory, that can delegate these two abilities. You can delegate GPO creation and ownership with the SetGPOCreationPermissions.wsf script, and you can link with the SetSOMPermissions.wsf script. |