Section 6.2. Group Policy Implementation


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:


Local computer

Use the Local Security Policy snap-in inside Control Panel Administrative Tools. Or, for a more complete look, use Start Run gpedit.msc.


A specific computer

Load the MMC, and then select Add Snap-in from the File menu. Browse in the list and add the Group Policy Object Editor to the console. On the Select Group Policy Object screen, peruse the list to find the specific object you want.


Entire domain

Install and launch the Group Policy Management Console, and then right-click on the domain and create or edit a policy from there.


OU within Active Directory

Install and launch the Group Policy Management Console, and then right-click on the OU, and create or edit a policy from there.


Active Directory site

Launch Active Directory Sites and Services, right-click the site's name, and select Properties from the context menu. Navigate to the Group Policy tab, and create or edit a policy from there.

Windows applies GPs in the following order, which you can remember with the acronym "LSDOU":

  1. Local GPOs

  2. Site-specific GPOs, in an order that the site administrator configures

  3. Domain-specific GPOs, in an order that the domain administrator configures

  4. OU-specific GPOs, from the parent OU down through the ranks to the child OU

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.

Here's an easy rule of thumb to remember: for domain-based GPs, the lowest-level Active Directory container has the last opportunity to override inherited policies. For example, a policy applied to a site will be overwritten by a policy applied to an OU, and a local policy will be overwritten by an Active Directory object-based policy.


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:

http://www.microsoft.com/windowsserver2003/downloads/featurepacks/default.mspx

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.

Table 6-1. Administrative templates with Windows Server 2003

Template

Function

Common.adm

Sets Windows 95, 98, and NT 4.0 policies

Conf.adm

Sets policies for Microsoft NetMeeting

Inetcorp.adm

Sets policies to restrict Internet Explorer

Inetres.adm

Sets policies to restrict Internet activities

Inetset.adm

Sets policies for common Internet Explorer configuration

System.adm

Sets Windows 2000-specific policies

Windows.adm

Sets Windows 95- and Windows 98-specific policies

Winnt.adm

Sets Windows NT 4.0-specific policies

Wmplayer.adm

Sets policies to restrict and configure Windows Media Player

Wuau.adm

Sets the policy on automatic updates


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:

  1. Open the Group Policy Management Console.

  2. In the left pane, find the GPO in question and click on it to select it.

  3. In the right pane, navigate to the Details tab, and under the GPO Status dropdown box, select User configuration settings disabled, as shown in Figure 6-4.

  4. Click OK.

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):

  1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

  2. Right-click on Default Domain Policy, and choose Edit.

  3. The Group Policy Object Editor window appears. In the Computer Configuration tree, navigate through Administrative Templates and System.

  4. Click Group Policy.

  5. In the right pane, double-click the setting Group Policy refresh interval for computers, or Group Policy refresh interval for domain controllers, whichever is applicable.

  6. Select Enabled, and then enter an interval for the refresh. Be sure to make this a healthy interval; otherwise, you will degrade your network's performance with constant traffic updating policies across the domain. For smaller networks, 15 minutes should be an acceptable timeframe. Allow 30 to 45 minutes for larger networks.

  7. Click OK.

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 

Domain controllers make refresh requests every five minutes by default.


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.

Folder redirection and software installation policies are not processed during a background policy refresh.


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:

  1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane .

  2. Right-click on Default Domain Policy, and choose Edit.

  3. The Group Policy Object Editor screen appears. In the Computer Configuration tree, navigate through Administrative Templates and System.

  4. Click Group Policy.

  5. In the right pane, double-click the setting Turn off background refresh of Group Policy.

  6. Select Enabled.

  7. Click OK.

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:

  1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

  2. Right-click on the Default Domain Policy GPO and choose Edit.

  3. In the Computer Configuration tree, navigate through Administrative Templates, System, and Group Policy.

  4. You'll see a list of options ending in "policy processing," such as Scripts policy processing and Wireless policy processing. These GPOs exist to allow you to tweak the functionality of these types of policies. Open the appropriate policy (which one is best for you depends on the type of policy that you're trying to trigger to change) to view its Properties.

  5. Click the Enabled button.

  6. Finally, check the Process even if the Group Policy Object has not changed checkbox.

Checking the box in step 6 provides the same functionality as issuing the command gpupdate /enforce from the command line.


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:

  • To change the refresh interval for computers, set:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime

    The type is REG_DWORD, and the valid range for data (in minutes) is 0 to 64,800.

  • To change the offset interval for computers, set:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffset

    The type is REG_DWORD, and the valid range for data (in minutes) is 0 to 1,440.

  • To change the refresh interval for domain controllers, set:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeDC

    The type is REG_DWORD, and the valid range for data (in minutes) is 0 to 64,800.

  • To change the offset interval for domain controllers, set:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffsetDC

    The type is REG_DWORD, and the valid range for data (in minutes) is 0 to 1,440.

  • To change the refresh interval for users, set:

    HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime

    The type is REG_DWORD, and the valid range for data (in minutes) is 0 to 64,800.

  • To change the offset interval for users, set:

    HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffset

    The type is REG_DWORD, and the valid range for data (in minutes) is 0 to 1,440.

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:

  1. Edit the GPO for which you want to change the threshold in the Group Policy Management Console.

  2. Navigate through Computer Configuration or User Configuration, as well as through Administrative Templates, System, and Group Policy.

  3. Double-click the Group Policy Slow Link Detection policy in the righthand pane.

  4. Click the Enabled option, and enter the connection speed you want to be the new threshold. Enter 0 to simply disable slow link detection.

  5. Click OK when you're finished.

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:

  1. Select the GPO you want to administer in the left pane of the Group Policy Management Console

  2. On the Scope tab in the right pane, click the Add button under Security Filtering, and then add the groups that do not need the policy applied.

  3. Verify the group was added to the Security Filtering list, as shown in Figure 6-5.

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:

  • If you do not want the policy to be applied to all members of a certain security group, add all the members to a group, add the group to the ACL for the object, and set the following permissions for the group: Apply Group Policy, deny; Read, deny. All members of the group will not have the policy applied, regardless of their existing memberships to other groups.

  • If group membership (at least in a specific group) shouldn't play a part in the application of this policy, leave permissions alone.

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.

Explicit permissions, be they Allow or Deny permissions, always will trump inherited permissions, even if Deny permissions on an object are inherited from a parent. Explicitly granting access to an object cannot be overridden by an inherited denial.


To set a GPO to not override parent GPO settings, you need to set the GPO status to "enforced." Follow these steps:

  1. In the GPMC, select the domain in which the GPO resides in the left pane.

  2. In the right pane, navigate to the Linked Group Policy Objects tab.

  3. Right-click the object and select Enforced from the pop-up context menu. You'll receive a confirmation notice, which is shown in Figure 6-7.

  4. Click OK to apply the changes.

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:

  • To block inheritance of GPOs for an entire domain, double-click Domains, and then right-click the domain.

  • To block inheritance for an OU, double-click Domains, double-click the domain containing OU, and then right-click on the OU.

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.

If multiple GPOs are assigned to an object, GPOs at the bottom of the list in the right pane of the GPMC are applied first, and objects at the top are applied last. Therefore, GPOs that are higher in the list have higher priorities.


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:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9ef05cbd-c1c5-41e7-9da8-212c414a7ab0&displaylang=en

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:

  • Show policies in effect, in the "logging" mode. In the GPMC, this is called "results ."

  • Show the results of a proposed policy addition or change, in the "planning" mode. In the GPMC, this is called "modeling."

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:

  • General information about the query

  • GPOs that were applied and GPOs that were denied

  • The user and/or computer's membership in security groups when GP was applied

  • WMI filters that "catch" the user or computer

  • The status of each component of GP, including GPOs themselves, EFS recovery, the registry, and security (permissions)

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

     '------------------------------------------------------------------------     ComputerName = InputBox("Enter the name of a computer running " & _     "Windows XP or Windows Server 2003", _     "Information","")     UserName = InputBox("Enter a user name under which to run the report", _     "Information","")     resultpath = InputBox("Enter a location to store the report", _     "Information", "c:\temp")     resultpath = resultpath&"\"&UserName&".HTML"     Set GPMC = CreateObject("GPMgmt.GPM")     Set Constants = GPMC.GetConstants( )     Set RSOP= GPMC.GetRSOP(Constants.RSOPModeLogging,"",0)     RSOP.LoggingComputer=ComputerName     RSOP.LoggingUser=UserName     RSOP.CreateQueryResults( )     RSOP.GenerateReportToFile Constants.ReportHTML, resultpath     msgbox("RSoP report complete! A full report has been placed at " & _     resultpath)     '------------------------------------------------------------------------ 

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.

New to the Windows Server 2003 Resource Kit is WINPOLICIES.EXE, a system tray tool that can show and troubleshoot client-side GPO processing.


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:

  • GPO name "contains," "does not contain," or "is exactly" your value.

  • GPO links "exist in" or "do not exist in" certain sites or all sites.

  • Security group; you simply select one or more security groups using the standard selection dialog.

  • User configuration "contains" or "does not contain" folder redirection, Internet Explorer branding, registry, scripts, or software installation values.

  • Computer configuration "contains" or "does not contain" EFS recovery, IP security, Microsoft disk quota, QoS packet scheduler, registry, scripts, software installation, or wireless GP values.

  • GUID "equals" your value.

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:

  • Security policy settings, including user rights assignments, restricted groups, services, filesystem entries, and registry keys and values

  • Advanced folder redirection policies

  • The ACL on a GPO itself, which can be preserved or discarded at your discretion

  • The ACL on software installation GPOs (I'll discuss software installation later in this chapter), which relies on your selecting the option immediately preceding this one

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:

  1. Open the GPMC.

  2. Expand the Forest and Domain trees in the left pane, and then select Group Policy Objects under your domain.

  3. In the right pane, select the GPO you want to back up.

  4. Right-click the GPO and select Back Up.

  5. The Back Up Group Policy Object dialog box appears, as shown in Figure 6-22. Enter the location you want to store the backed-up GPO files in the first box, and then enter a helpful description for yourself so that you can identify the backed-up files later.

  6. A progress box will appear, indicating how far Windows has progressed in the backup procedure. A message in the Status box will appear noting a successful backup when the procedure is finished.

  7. Click OK to finish.

To copy a specific GPO, follow these steps:

  1. Open the GPMC.

  2. Expand the Forest and Domain trees in the left pane, and then select Group Policy Objects under your domain.

  3. In the right pane, select the GPO you want to copy.

  4. Right-click the GPO and select Copy.

  5. Find the OU within Active Directory to which you want to paste the copied GPO and select it.

  6. Right-click the OU and select Paste from the context menu. A message, shown in Figure 6-23, will appear asking you if you want to link the GPOs you copied to the destination OU. Click OK to continue.

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:

  1. Open the GPMC.

  2. Expand the Forest and Domain trees in the left pane, and then select Group Policy Objects under the new domain.

  3. In the right pane, select the GPO you want to use.

  4. Right-click the GPO and select Import Settings. The Import Settings Wizard appears.

  5. The wizard will prompt you to back up the settings currently within the destination GPO. Click the Backup button to do so, and follow the procedure earlier in this section to step through that process. When you are done, click Next.

  6. Select the location where the GPO that you want to import is located. Then, click Next.

  7. The Source GPO screen appears. All the GPOs that are stored in the location you input in step 6 are listed on this screen. You can select an individual GPO and click View Settings to refresh your memory as to the settings the GPO contains. Select the GPO you want to use, and then click Next.

  8. The Migrating References screen may appear (if not, skip to step 13). Depending on the settings contained within the GPO, you might need to "map" entries using a migration table. You can select to copy the existing entries directly from the source (using the first bulleted option), or you can create a new migration table by clicking New. This results in the Migration Table Editor window appearing.

  9. From the Tools menu, select Populate from Backup, and then select the source GPO you are importing. Windows will populate the objects that need to be retranslated automatically.

  10. In the Destination Name column, simply enter the correct name for the source property in its new location. Be sure these properties already exist within the destination location; the GPMC can't create them on the fly. Also, if some properties don't need to be changed, simply enter <Same As Source> in the Destination Name column.

  11. You can save this migration table for use in other GPO import procedures by selecting Save from the File menu and specifying a location. This can be anywhere on your filesystem.

  12. Close the Migration Table Editor. The Migrating References screen will reappear, and the migration table you just created will appear. Click Next to continue.

  13. The Completing the Import Settings Wizard screen will appear. Confirm your settings are correct, and then click Finish. Your settings will be imported.

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:

  • To make everything work out of the box, you need to have a two-way trust between the target forest and the forest that the machine on which you are running the GPMC is in.

  • If you have only a one-way trust, choose Options from the View menu, and then on the General Tab uncheck Enable Trust Delegation, a feature which allows permissions for managing GPOs to be assigned to the other forest for reciprocal management.

  • If you don't have a trust, you'll need to use the Stored User Names and Passwords applet in the Control Panel of Windows Server 2003 or the User Accounts applet in Windows XP to keep your login information for the remote forest.

  • Most likely you will need Enterprise Administrator credentials to manage GP in other forests.

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:

  1. Open the GPMC.

  2. In the Tree view, select Group Policy Objects.

  3. Navigate to the Delegation tab in the righthand pane.

  4. Add the user or group to whom you want to delegate the privilege.

To delegate the ability to link GPOs to objects, follow these steps:

  1. Open the GPMC.

  2. Select the OU or other object for which you want to give the ability to link GPOs.

  3. Navigate to the Delegation tab in the righthand pane.

  4. Add the user or group to whom you want to delegate the privilege.

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.



Learning Windows Server 2003
Learning Windows Server 2003
ISBN: 0596101236
EAN: 2147483647
Year: 2004
Pages: 171

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net