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 upon 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

Launch Active Directory Users and Computers, right-click the domain name, and select Properties from the context menu. Navigate to the Group Policy tab, and create or edit a policy from there.

OU within Active Directory

Launch Active Directory Users and Computers, right-click the OU's name, and select Properties from the context menu. Navigate to the Group Policy tab, 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:

1. Local GPOs

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

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

4. OU-specific GPOs, from the child OU up through the ranks to the parent 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. Creating and Editing Group Policy Objects

To look at how GPs are created and edited, launch Active Directory Users and Computers, right-click the domain name, and select Properties from the context menu.

You also can launch tools to access GP from the command-line by running DSA.MSC for Active Directory Users and Computers or DSSITE.MSC for Active Directory Sites and Services.

Navigate to the Group Policy tab, and click the New button to create a new GPO. Enter a name for the object, and choose one of the following buttons:

Add

To link the policy with an object

Edit

To open the policy object for modification

Options

To disable the policy or to set the policy to No Override

Delete

Either to remove the link for the policy to the object, or to remove it from the directory entirely

Properties

To limit the scope of the policy through ACL permissions and security groups

Click the Edit button to edit the object. You're presented with a screen much like that shown in Figure 6-1.

Figure 6-1. 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 subtrees: 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, you might suspect, contains user-specific settings that apply only to that user, regardless of where she is on the network.

6.2.1.1 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 after you load them 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 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.2 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 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 users, you can disable the computer configuration branch of the policy and significantly improve the performance of your network. To do so, follow these steps:

1. Open the Group Policy Object Editor.

2. Right-click the GPO in question and select Properties from the context menu.

3. Navigate to the General tab, and uncheck either the Computer Configuration or User Configuration nodes of the policy.

4. Click OK.

The portion of the policy you selected is now disabled.

6.2.1.3 Refreshing 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 (assuming this option is enabled, which it is by default).

To enable the policy refresh interval, follow these steps:

1. Open the Group Policy Object Editor.

2. Edit the target GPO as described earlier.

3. 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.

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

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.

Domain controllers make refresh requests every five minutes by default. If you want to change this value, you can use the same procedure noted earlier, except in step 5 double-click the setting Group Policy Refresh Interval for Domain Controllers.

For either clients or domain controllers, exercise extreme caution when modifying these default settings. 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.

To disable background processing, follow these steps:

1. Open the Group Policy Object Editor.

2. Edit the target GPO as described earlier.

3. 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.) To do so, follow these steps:

1. Open the Group Policy Object Editor.

2. In the Computer Configuration tree, navigate through Administrative Templates and System.

3. Select the policy you want to change.

4. Check the Process even if the Group Policy Object has not changed checkbox.

   

   Checking the box in step 4 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.4 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. Open the GPO for which you want to change the threshold in the Group Policy Object Editor.

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 the 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 an object within Active Directory. 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, right-clicking it, and selecting Properties. On the Links tab, click Find Now, and all links will be detected and displayed.

Of course, in practice there always are exceptions to any rule; most likely there will be some computers within a container that shouldn't have a policy applied to them. To limit the scope of a GPO, you can create security groups that contain the objects that are to be excluded from the policy application, and then not grant them the ability to read the GPO, effectively removing them from the policy's effects. You also can play more tricks with groups and GPO ACLs to further limit the effects of policy application to objects. The following is a list of appropriate ACL permissions to grant to obtain the desired result:

• If you 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, allow; Read, allow. All members of the group will have the policy applied, except for those who are a member of another group with either of the former permissions set to Deny.

• 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.

To limit the scope of a GPO to certain groups of objects within Active Directory, follow these steps:

1. Create the groups of objects that don't need the policy to be applied to them.

2. Open the GPO you want to administer within the Group Policy Object Editor, right-click the GPO, and choose Properties from the context menu.

3. Click the Security tab.

4. Add the groups that do not need the policy applied.

6.2.3. Inheritance and Overriding

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: No Override, 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 No Override 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, follow these steps:

1. Open the GPO for which you want to set the policy.

2. Right-click the object and select No Override from the pop-up context menu. This is shown in Figure 6-2.

   Figure 6-2. Setting the No Override option on a GPO

   
   
   

3. Click OK to apply the changes.

To block any inheritance of parent policy settings for the current administrative container, follow these steps:

1. Right-click the domain that the GPO resides in and select Properties.

2. On the Group Policy tab, select the GPO for which you want to set the policy.

3. Check the checkbox under Block Policy inheritance to enable the setting. The resulting screen is shown in Figure 6-3.

   Figure 6-3. Setting the Block Policy inheritance option on a GPO

   
   
   

4. Click OK to apply the changes.

   

   If multiple GPOs are assigned to an object, GPOs at the bottom of the list (on the Group Policy tab of an appropriate object) 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. 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 RSoP tool, which can enumerate the following situations:

• Show policies in effect, in the "logging" mode

• Show the results of a proposed policy addition or change, in the "planning" mode.

To run a query using the RSoP tool, open Active Directory Users and Computers. You also can open Active Directory Sites and Services as well if you want to run a query over an entire Active Directory site. Choose the object against which you want to run the query, such as an OU, right-click the object, and select Resultant Set of Policy (Logging) or Resultant Set of Policy (Planning) from the All Tasks menu.

To run a query in logging mode, run the tool as just described. You'll be asked to confirm your object selection, and then prompted to select the user context in which the effective policies will be displayed. Then, the tool will run and will bring up a consoleshown in Figure 6-4that looks similar to the Group Policy Object Editor.

Figure 6-4. The RSoP logging tool results console

To run a query in planning mode, run the tool as described earlier. The Resultant Set of Policy Wizard will come up. In the User Information and Computer Information sections of the wizard, browse for the computer, user, or container against which to run the query, and click Next. Then you can configure additional options for the process, as shown in Figure 6-5 and as described next.

Figure 6-5. The RSoP planning tool options

• Slow network connection allows you to simulate a policy's application over a slow link.

• Loopback processing allows you to simulate a user policy's effect on a computer controlled by a different set of policies. This is useful when you want to see whether user policies are different on various computers that have a variety of policies assigned to them.

• Site name lets you identify a specific subnet on which to run the "what-if" scenario.

The next two screens offer you the following options, respectively:

• Security groups allow you to look at the different results of policy applications based on changes made to objects' group memberships.

• WMI filters allow you to use Windows Management Instrumentation filters to query machines and users for properties and to effect changes only on those users.

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.

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 ways. Microsoft includes a tool with the Windows 2000 Resource Kit, called GPRESULT.EXE, which you can run on a client computer. (Windows XP has this already 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.

Using GPRESULT, to get information for the user jghassell on the remote workstation ODYSSEY, run:

gpresult /s ODYSSEY /USER jghassell

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.