Windows Server 2003 on HP ProLiant Servers : Logical Structure Design (part 4) - Group Policy

5. Group Policy

Space limits the discussion here, and again, my goal is to give you design tips rather than educate you on Group Policy. Having worked for the past four years troubleshooting probably hundreds of Group Policy problems, I'll take the perspective of listing best practices and observations, with a few actual examples thrown in. Let's first list important design criteria that you need to keep in mind when defining Group Policy standards, followed by Group Policy tips, and finally a list of important Group Policy additions for Windows Server 2003 and Windows XP.

Group Policy Design

Several worksheets in each file correspond to sections of policy such as Security Settings, Administrative Templates, and so on. The worksheets contain all settings listed separately on each row. You can add the names of your GPOs in columns to the right of the setting name, and then enter “enabled” or “disabled”for each setting in each GPO. This takes considerable time on the front end and to maintain, but it will be worth the effort when you want to change something later on, or need to troubleshoot a problem. Rather than wading through the user interface (UI), you can get the information from the spreadsheet. Windows Server 2003 supports a tool called the Group Policy Management Console (GPMC), which reports all the current settings, but doesn't save them in a nice tabular form like the spreadsheet. My recommendation is to use both GPMC and the spreadsheet.

Group Policy applies only to the user or computer where the account actually exists. A common mistake is to think that Group Policies apply to groups; however, a group can be used to set permissions on a Group Policy so that it applies only to users of a group. For instance, Figure 16 shows user Russ, who is a member of the OfficeAdmins group. Russ' user account is in the Marketing OU, which has the MKTGDesktopGPO linked to it, whereas the OfficeAdmins group is in the AppAdmin OU. The GPOs that will be applied are Default Domain Policy and MKTGDesktopGPO. The OfficeAdmin GPO (if linked to this OU) is not applied. This is a basic rule that has existed since the birth of Windows 2000, but many Admins either don't understand it or have forgotten how it is applied.

When designing your GPO strategy, make sure you understand this principal. It's a good idea to make a chart like that shown in Table 3, for tracking GPOs. Identify the function of the policy and whom it applies to, and then identify the domain or OU that those security principals live in.

Group Policy Features and Limitations

A number of Group Policy features actually impose limitations on the design. Several important features are described here. Take the time to understand their implications in your environment and design the Group Policy deployment accordingly.

Multiple Instances of GPOs

You can link a GPO to multiple OUs if needed, but for performance reasons, you shouldn't link GPOs across domains if your forest has multiple domains. In essence, you are building a GPO library in the AD (per domain) and then you can link them to appropriate OUs.

GPO Functions

As was noted previously, user logon time is directly affected by the number of GPOs that apply to the user, and the computer startup time is affected by GPOs that apply to the computer. Figure 17 shows Microsoft's figures regarding traffic in Kbps generated by the number of GPOs applied to the user.

Note that network traffic increases only slightly as the number of GPOs increases. For example, one GPO (including computer startup and user logon) generated 102Kbps; five GPOs generate 130Kbps and ten GPOs generate only 155Kbps. Considering just user logon performance, you can apply only one or two GPOs containing all settings that you need to configure for the users. However, this makes the GPOs more complex, and more difficult to manage and troubleshoot. It is now a very common and recommended practice to define a number of simple, yet focused GPOs, apply them as needed, and take the hit on performance. Using the numbers in the chart in Figure 17, you can see that there is no difference between having one and five GPOs applied and only 25Kbps per user if you go up to ten. This is miniscule in comparison to the time that will be spent managing and troubleshooting one or two giant policies. 

Using the example in Table 3, the UserScripts1 GPO is applied to the users in Finance and HR OUs. Thus, we store a single GPO and create links to multiple GPOs. Note also that the Finance OU has DesktopL2 as well as UserScripts1 GPOs applied. The alternative, of course, would require us to combine the settings of DesktopL2 and UserScripts1 into a single GPO and apply it to Finance. Because the MKTG OU needs DesktopL2 and UserScripts2, another GPO would have to be created for MKTG OU. Splitting the GPOs up into smaller functions makes them more flexible. Also, if an error occurs in the logon script, you only have to debug the script's GPO and you don't have to deal with desktop settings.

The important thing here is to define the function of each GPO and define which domain(s) and OUs they should apply to.

Account Security Settings

The account security settings, including Password Policy, Account Lockout Policy, and Kerberos Policy, can only be applied at the domain level. Thus, you can have only one Password Age Setting for the entire domain, rather than allowing each OU to dictate this setting to its users. DCs, however, behave differently in applying security.

Track GPO Settings

I have used columns to the right of the setting label and indicated which GPO uses that setting and what the setting is. A simplistic example is shown in Table 4. You can see from Table 5.4 that defining each setting for each GPO could be prohibitive in a large enterprise with many GPOs, each having potential for nearly a thousand settings. Some organizations have a staff of several Administrators that does nothing but administer GPOs. This is usually a political requirement in which organizations want their own GPO control, but it's a poor administration model. It's difficult to troubleshoot problems with so many Admins making changes, and multiple people trying to solve the problem.

GPO Filtering

GPO filtering is available in Windows Server 2003 just as it was in Windows 2000. GPO filtering allows the Administrator to restrict a GPO from applying to certain users, computers, or groups. For instance, suppose you have a policy applied to an OU that prevents users from accessing the Internet, called InetLockDn Policy. However, there are five users in that OU that need Internet access. Rather than creating a separate OU for those users, you could simply define a filter so that the policy doesn't apply to those five users. This is done from the Group Policy Editor by selecting the Properties button, and then choosing the Security tab in the policies properties page.

Figure 18 shows that we have filtered user Jim Shoos by denying Read and Apply Group Policy rights. In this case, authenticated users still have Read and Apply Group Policy permissions. Thus, the policy applies to all authenticated users except Jim Shoos. Note that we could do the reverse and have the policy apply to only a user or group. Figures 19 and 5.20 demonstrate this. Figure 19 shows that we had to set the authenticated users group to not have Read or Apply Group Policy rights, which means no one will get the policy applied. Then, as shown in Figure 20, we give the rights to the user (Jim Shoos in this case). If you don't remove Read and Apply Group Policy from authenticated users, then all users will have the policy applied to them.

Filtering takes considerable additional processing time to enumerate the Access Control Lists (ACLs) and affects user logon performance. If you have to filter a large number of users from getting a GPO, it might make sense to create a separate OU. Be sure to test the performance hit that users will have if you use filtering.

WMI (Windows Management Instrumentation) Filtering

Windows Server 2003 and the GPMC provide new capabilities for customizing queries using WMI, including the WMIC interface and the WMI filters in Group Policy.The WMI filter in Group Policy basically uses the WMI Query Language (WQL) to allow a WMI query (filter) to be applied from within a policy, and determines whether to apply the GPO to a target computer based on that computer's attributes.  A single filter can contain multiple queries to be evaluated against the WMI repository of the target computer. If the evaluation of all queries in the filter is determined to be FALSE, the GPO is not applied; if they are TRUE, the GPO is applied. Important features and functionality of WMI filtering in Group Policy include

• Uses WQL.

• Only one WMI filter can be applied to any single GPO. Multiple filters require additional GPOs. (Note that multiple queries can be defined in a single filter.)

• A single WMI filter can be linked to multiple GPOs.

• WMI filters are applied to domain objects.

• WMI filters only apply to the Windows XP and Windows Server 2003 family of operating systems (OSs). These filters are ignored by Windows 2000 computers and thus the GPO will always apply to them.

• You must have successfully run the ADPrep/DomainPrep utility in the domain that the WMI filtered GPO applies. A Windows Server 2003 DC need not be installed.

• Full editing and linking features for WMI filters are contained within the GPMC. WMI filters add additional ways you can filter GPOs. In addition to applying or denying GPO application based on users or groups, as was provided in Windows 2000, Windows Server 2003 permits creation of WMI filters.

The following WMI filter checks to see whether the physical memory of the computer is greater than 128MB, and if so, the GPO will be applied:

Select TotalPhysicalMemory from win32_ComputerSystem
where TotalPhysicalMemory >= 134217728

Using the GPMC, you can define the WMI filter and associate it with a GPOas follows:

1.	Right-click the WMI Filters folder, and select New. The New WMI Filter dialog box appears.
2.	Click the Add button to display the WMI Query dialog box. In the Query field, enter a valid WMI filter to apply the GPO if the physical memory is greater than 128MB, as shown in Figure 21. Figure 21. Dialog box for creating a WMI filter in the GPMC snap-in.
3.	Click OK and return to the New WMI Filter dialog box. You can add other WMI filters at this point, but it's best to do one at a time.

1.	Click the Save button. If the WMI filter you added is correct (syntax, and so on), it is added to the list.
2.	Close the New WMI Filter dialog box and you'll see the filter added under the WMI Filter folder in the left pane of the GPMC.
3.	Click the filter just created and in the left pane, shown in Figure 22, you'll see the WMI filter description at the top and a list of GPOs That Use This WMI Filter at the bottom. Figure 22. Linking a WMI filter to an existing GPO in the GPMC snap-in.
4.	Right-click in the white area of the GPOs That Use This WMI Filter section and select Add. A list of GPOs is displayed. Select a GPO to have the filter apply to and click OK. To add the filter to additional GPOs, repeat this procedure. You can't add more than one GPO at a time.

You've created a WMI filter on the accounting policy (in the example in the figures) so that this policy only applies to computers that have greater than or equal to 128MB memory. This is similar to the security filtering we did in Windows 2000, in which we could apply or deny a policy only to certain users or groups.

It is critical that you understand there is a price to be paid for WMI filters. Microsoft is very emphatic about the fact that WMI filters should be used sparingly, preferably when the policy in question has a specific lifetime. In addition, evaluating WMI filters can significantly add to the amount of time needed to apply and process policy. These filters also add considerable complexity. Besides the normal Group Policy processing issues like block inheritance, no override, ACL filtering and so forth, now you must contend with WMI filters added to the mix. It is also important to note that since Windows 2000 clients can't ever apply WMI filters, any Windows 2000 clients that receive the policy will always return TRUE when evaluating a WMI query. That is the GPO containing a WMI filter will always apply to Windows 2000 clients.

In terms of troubleshooting, note that the new GPResult.exe and the Group Policy Results option in the GPMC (both give the same information) provide an excellent list of filters that are applied.

Since WMI filters are new to Windows Server 2003, and because many administrators typically aren't skilled in using WMI, I asked Microsoft for some details on how to use WMI filters and some sample filters. Tim Thompson graciously offered the following examples and description.

• Operating system-based targeting: An administrator wants to deploy an enterprise-monitoring policy but needs to limit the target set to computers running either Windows 2000 Server or Advanced Server.

  The administrator chooses the following filter:

  Root\CimV2; Select * from Win32_OperatingSystem where
  Caption = "Microsoft Windows 2000 Advanced Server"
  OR Caption = "Microsoft Windows 2000 Server"
  

• Hardware inventory-based targeting: An administrator wants to deploy a new connection-manager but needs to avoid wasting space on desktop computers without modems where the connection manager would be useless. An administrator can deploy the package across the enterprise with the following WMI-filter:

  Root\CimV2;Select * from Win32_POTSModem
  

• Resource-based targeting: To encourage field engineers and consultants to use documentation, a company wants to make Help systems available directly on users' hard disks. But because users complain that the Help files consume too much space, a manager decides to only deploy the documentation on computers that have at least 600 megabytes (MB) available.

  An administrator can accomplish this with the following WMI filter:

  Root\CimV2; Select * from Win32_LogicalDisk where FreeSpace
  > 629145600 AND Description <> "Network Connection"
  

• Computer-based targeting: An administrator wants to set up a policy to encrypt all “My Documents” folders on notebook computers. The administrator determines that all the company's notebook computers are HP Pavillion models zd7140 and zx5280.

  To set up the policy, an administrator uses the following WMI filter:

  Root\CimV2; Select * from Win32_ComputerSystem where
  manufacturer = "HP" and Model = "Pavillion zd7140"
  OR Model = "Pavillion 5280"
  

• Asset tag-based targeting: An administrator wants to set hardware inventory monitoring policy for all computers with an “asset tag” of 300,000-355555.

  To set up the policy, an administrator uses the following WMI filter:

  Root\Cimv2 ; Select * from Win32_SystemEnclosure where
  SMBIOSAssetTag > '300000' AND SMBIOSAssetTag < '355555'
  

• An administrator wants to apply a policy only on computers that have a specific hot fix or QFE: The administrator chooses the following filter:

  Root\cimv2 ; select * from Win32_QuickFixEngineering
  where HotFixID = 'q147222'
  

• Test to verify machine is a 32-bit platform: An administrator has a mixture of 32- and 64-bit clients, and wants to apply a policy to only 32-bit platforms. The administrator chooses the following filter:

  Root\Cimv2; Select * from Win32_ComputerSystem
  where SystemType = X86-based PC
  

• Want to bust users that have a hidden Music share? An administrator wants to apply a policy only on machines where users have a hidden music share. The administrator knows that most users name their music shares Music, Music$, Tunes, or Tunes$. The administrator chooses the following filter:

  Root\Cimv2; Select * from Win32_Share where Name = "Music"
  OR Name = "Music$" OR Name = "Tunes" OR Name = "Tunes$"
  

XP Settings in Windows 2000

Windows XP came with a new set of Group Policy settings that Windows 2000 did not have. Microsoft KB article 314953 “HOW TO User Group Policy to Deploy Windows XP in a Windows 2000-Based Network” describes these settings and the process used to incorporate them in Windows 2000. Essentially, you bring an XP client into the domain, and then edit the local Group Policy, which allows you to upload the XP policy settings to a DC of your choosing in the domain (it provides a browse list of DCs). The settings are then uploaded to the DC and appear when you open a Group Policy Editor in that domain. Note however, that these settings only apply to XP clients; they don't affect Windows 2000 Professional clients. This process of adding the XP settings into the domain's policy settings allows XP settings to be managed with other GPO settings in the domain context. These new XP settings are included in Windows Server 2003 without requiring this process to add them.

Group Policy Tools

Microsoft has made some significant improvements in Group Policy management tools, including GPResult, a command-line utility that has been considerably enhanced in Windows Server 2003, and the GPMC, available for download from Microsoft.

GPResult Tool

Windows 2003 and XP provide a new version of the GPResult tool. GPResult provides a client-side view of the policies that were applied to the computer and the user. Part of the Windows 2000 Resource Kit, GPResult is built-in to XP and Windows Server 2003. The tool provides excellent information not available in the Windows 2000 version including

• Resultant Set of Policies (RSoP) data: This provides verbose data about the Group Policy extensions.

• Security settings: The Windows 2000 version simply listed the GPO that the security settings were applied from. The XP/2003 version lists all the individual settings, such as Password Length, Account Lockout, and so on. This is an excellent way to troubleshoot security issues.

• GPO filtering information: This excellent feature lists all the GPOs that were filtered and not applied to the user or computer. In Windows 2000, the only way to see this was to edit the GPO and look at the ACL.

This version of GPResult can be used in a Windows 2000 domain, but must be run from an XP client or Windows Server 2003 server in that domain. This tool is so valuable for troubleshooting, I actually made one customer buy XP just so I could use the new version of GPResult and shorten the diagnosis time. It really helped.

Group Policy Management Console (GPMC)

Microsoft has also given us another great tool called the GPMC. GPMC is a GUI-based tool available for download from Microsoft at http://www.microsoft.com/downloads/details.aspx?FamilyId=C355B04F-50CE-42C7-A401-30BE1EF647EA&displaylang=en. This tool allows management and troubleshooting of all GPOs in all domains in a forest. Figure 23, for example, shows management for two domains: Qamericas.qtest.cpqcorp.net (top) and Qtest.cpqcorp.net (bottom). Note the left-hand pane shows domains and OUs, and there is also a Group Policy Objects folder for each domain. I have selected the Group Policy Objects folder in the Qtest domain, and all GPOs defined for the domain are listed on the right-hand pane. Windows 2000 required multiple snap-ins to manage GPOs in multiple domains and OUs.

Figure 23. GPMC permits management of the Qtest.cpqcorp.net parent domain and the Qamericas.Qtest.cpqcorp.net child domain.

The GPMC can be used to see the policy settings that are applied to a user or computer. Although it doesn't track the settings like the spreadsheet does, it allows you to see effective settings in an easy-to-use console.

Other important features of the GPMC tool include

• When GPMC is installed, you cannot open the old Group Policy Editor using AD Users and Computers, Domain or OU Properties, Group Policy tab. If you try to do it this way you will get a notice that GPMC is installed and you must use it instead. That notice provides an option to select to launch GPMC. GPMC can also be launched from Administrative Tools or by going to Start-Run and entering gpmc.msc.

• You can define settings using the Group Policy template just as in the old Group Policy Editor.

• GPMC allows a tabular view of all GPOs showing the link status, if WMI filtering is applied, when it was modified, and the owner, as shown in Figure 24. The Delegation tab shows who has GPO Modification rights. Note that the GPO “testing link” has the user configuration settings disabled.

  Figure 24. GPMC shows GPO link status, WMI filters applied, last modified date, and the owner, in a single view.

  

• Provides an easy-to-read listing of all applied settings for a GPO. Figure 25 shows the Domain EA Child Restriction Policy settings. Note the friendly Web-like presentation. At the right of each policy setting is a link to hide/show. Clicking the hide link toggles it to show and displays all the settings that are defined for that GPO. In this figure, some settings such as the Audit Policies have been exposed. This is a huge timesaver because the Administrator doesn't have to drill down through each category looking for enabled or disabled settings.

  Figure 25. GPMC displays all settings for any selected GPO and allows for modification of those settings.

  

• Displays security and WMI filters. Figure 26 shows that the InetLockDn Policy is applied to domain users. You also can add and remove security principles on this screen.

  Figure 26. GPMC shows all successfully applied policies to a user or group.

  

• Lists GPO-related events from the Event Viewer, security properties for each GPO, GPO properties, and delegations.

• Group Policy Results feature allows you to run GPResults for any user on any computer and display the report in GPMC. This allows you to diagnose a user's GPO problems without having to use his computer or account to log in, and then run gpresult.exe. This is a powerful troubleshooting tool.

• Group Policy Modeling allows you to analyze a “what if” scenario. That is, you can get a report on how application of a new GPO would affect users or computers before actually applying it!

• The Save As feature is another powerful troubleshooting tool that allows you to save the GPMC report—the settings, security, and so on—as an HTML file. A support engineer can then open up that file and view the information just as you see it in the GPMC. Another huge timesaver for troubleshooting.

• It's free!

Furthermore, a major benefit of GPMC is that it allows the Administrator to back up and restore GPOs in a forest or even in a multiforest environment. Without using GPMC, acci dentally deleted or badly misconfigured GPOs would otherwise have to be manually re-created or recovered via a complex SYSVOL restore.