Computer policies are applied upon boot of the machine, are in place before logon, and are independent of the user login credentials. They apply to the computer only, regardless of who will be logging in. Types of Group Policies that are best applied in the computer policies are the following (not a complete list):

User policies are applied when the user logs in and occur after boot and during logon. They apply to the user regardless of what computer or server the user is logging into. They follow the user wherever the user goes in the domain.

Types of Group Policies that are best applied in the computer policies are as follows (also not a complete list):

Group Policy is refreshed at regularly scheduled intervals after a computer has been booted and a user has logged in. By default, Group Policy is refreshed every 90 minutes on non-domain controllers (with a stagger interval of 30 minutes) and every five minutes on domain controllers.

Refresh intervals are configurable via Group Policy by going to the following areas in Group Policy and changing the refresh interval times:

Most changes made to existing Group Policy Objects (or GPOs) or new GPOs will be enforced when the refresh cycle runs. However, the following settings will be enforced only at login or upon boot, depending on the GPO configuration settings:

The primary thing to remember with Group Policy is that less is more. Group Policy is very useful and administrators new to it frequently apply a great many Group Policies, using Group Policy as the elixir for all administrative issues. However, it’s important to remember that with each Group Policy Object that is implemented and with each new layer of Group Policy, a fraction of a second is added onto computer boot time and user login time. Additionally, the GPOs take up space in SYSVOL on domain controllers, causing replication traffic as well as adding complexity that can make troubleshooting more difficult.

The new Group Policy Management Console (GPMC) provides you with a handy tool for planning and testing Group Policy implementations prior to implementing them. Because Group Policy can cause tremendous impact on users, any Group Policy implementation should be tested using the RSoP tool in planning mode. See the sections entitled “Using Resultant Set of Policies (RSoP) in GPMC” and “Group Policy Modeling Using Resultant Set of Policy (RSoP)” for more information.

Group Policy can be configured on many different levels and, by default, is implemented in a particular order. However, by using the Block Policy Inheritance, Enforcement, and Link Enabled conditions the default order of application can be changed. It’s a good idea to use these conditions sparingly because they can add a great deal of complexity to troubleshooting problems with Group Policy application. See the sections titled “Understanding GP Inheritance and Application Order” and “Modifying Group Policy Inheritance” later in this chapter for more information.

Slow link detection can change the Group Policy that a user receives, which can be a difficult thing to troubleshoot as an administrator. Understanding the importance of slow links can make troubleshooting a great deal easier for you if you have WAN links that may go up and down or work in an environment with bandwidth issues. See the section in this chapter entitled “Understanding the Effects of Slow Links on Group Policy” for more information.

It is important to delegate the proper rights for administrators to manipulate Group Policy. For example, a very small group of users should be able to edit policies on the domain level, but it might be necessary to allow diverse groups of administrators to configure Group Policies lower down the AD tree-in areas in which they administer.

An administrator can delegate the following rights to other administrators:

Using the Group Policy Delegation Wizard makes it easy to give the right groups of administrators the rights they need to do their job, and continue to administer Windows Server 2003 in the most secure ways possible.

Avoiding cross-domain policy assignments is a recommended best practice. The more local the policies are, the more quickly the computers boot up and the users can log on, as the users or machines don’t have to go across domain lines to receive group policies from other domains. This is especially pertinent for remote users.

The impact of using Group Policy naming conventions cannot be understated. Naming conventions allow for easier troubleshooting and identification of policies and simplify managing Group Policies, especially in a large environment.

The default domain policy is the domain level policy that is installed (but not configured) when Windows 2003 is installed. It should not be renamed, removed, deleted, or moved up or down in the list of Group Policies that exist on the top level of the domain. Certain security settings will only function properly when implemented in the Default Domain Policy (see the following warning). It’s also a good idea to lock down the capability to edit the Default Domain Policy to a small number of administrators because security settings and other domainwide policies are set at that level.

By understanding and using these generic best practices, you can provide his users with a more secure, faster running, and uniform application of Group Policies.

To maximize the inheritance feature of Group Policy, keep the following in mind:

As stated previously, Group Policy objects are applied in a specific order. Computers and users whose accounts are lower in the Directory tree can inherit Policies applied at different levels within the Active Directory tree. Group Policy is applied in the following order throughout the AD tree:

If a setting in a Group Policy Object is set to Not Configured in a policy higher up, the existing setting remains. However, if there are conflicts in configuration, the last Group Policy Object to be applied prevails. For example, if a conflict exists in a Site GPO and in an OU GPO, the settings configured in the OU GPO will “win.”

If multiple GPOs are applied to a specific AD Object such as a site or OU, they are applied in reverse of the order they are listed. The last GPO is applied first, and therefore if conflicts exist, settings in higher GPOs override those in lower ones. For example, if a Contacts OU has the following three Group Policies applied to it and they appear in this order (as shown in Figure 6.1) the policies will be applied from the bottom up:

Figure 6.1. Group policy object order.

The Contacts Temporary Policy will be applied first. The Contacts Software Policy will apply next, and finally the Contacts Default Group Policy will be applied. Any settings in the Contacts Default Group Policy will override the settings configured in the two policies below, and the settings in the Contacts Software Policy will override any settings in the Contacts Temporary Policy.

The Block Inheritance and Enforcement and Link Enabled features allow control over the default inheritance rules.

GPOs can be configured to use the Enforcement feature. This setting does not allow the parent organizational unit to be overridden by the settings of the child OU if conflicts exist. Additionally, it nullified the effects of Block Policy Inheritance if that functionality is applied on sub-GPOs.

GPOs can also be set to Block Policy Inheritance. This feature prevents the AD object that has the GPO applied to it from inheriting GPOs from its parent organizational unit, site, or domain (unless the parent GPO had Enforcement enabled as described previously).

Finally, the option exists that allows for the disabling of a Group Policy Object, also known as the GPO’s Link Enabled status. By right-clicking on the Group Policy in the Group Policy Management Console and unchecking Link Enabled, you can disable the policy and render it unused until the time it is re-enabled. In Figure 6.2 the Contacts Temporary Policy Link Enabled state is disabled.

Figure 6.2. Disabling link enabled status.

Loopback allows Group Policy to be applied to the user logging in based on the location of the computer object, not the location of the user object in AD. Loopback applies a Group Policy based on the computer the user is using, not the user whom is logging into the computer. An example of a good use of the loopback option concerns Terminal Services. If you need to apply specific permissions to everyone who logs into a particular Terminal Server, regardless of his or her user group policies, loopback in replace mode will accomplish this objective by ignoring all user GPOs. Loopback also provides a merge mode that merges the GPOs that apply to the user and computer but gives precedence to the computer GPO’s, overriding any conflicting user GPOs.

Microsoft Windows Server 2003 has a default determination of what constitutes a slow link between sites and automatically changes what Group Policies are provided to a user on the receiving end of a slow link. Security policies and administrative templates are always loaded, no matter what the link speed. However, group policies such as Login scripts, software pushes, and folder redirection are not pushed to the user who is accessing GP via a slow link. This can be problematic for sites that don’t have local domain controllers and receive authentication across a slow WAN link.

If you have unreliable or saturated bandwidth you might want to change the configuration of what is considered a slow link in the site or disable slow link detection completely.

By default, a slow link has an average ping time of greater than 32ms using 2048 byte packets, or a time greater than 500Kbps. Microsoft uses the following formula to convert ping times to Kbps. The formula is as follows:

16,000 / ping = Kbps

Therefore, the default value of a 32ms ping times equals the following when the formula is applied:

16,000 / 32ms = 500Kbps

To determine whether a site has a slow link, perform a ping from that location to the nearest DC it would use to authenticate and obtain its Group Policy. Use the following format for the ping command to make sure the test packet is a 2048KB packet:

ping -l 2048 servername (where servername is the closest domain controller)

The time it takes to return the ping will show if the link is more than 500Kpbs and is thus a slow link and subject to the slow link restrictions.

To override Microsoft’s default definition of a slow link, change slow link behavior, or otherwise change slow link configuration, go to the following areas in Group Policy:

Group Policy also allows for changing the behavior of processes such as scripts, folder redirection, software installation, and security when slow links are in effect. These can be changed by choosing Computer Configuration, Administrative Templates, System, Group Policy and editing the Policy Processing Group Policies.

If a Group Policy will be applied to many different locations, you should create the policy once and assign the permissions, and then link the policy to the other locations rather than creating the policy multiple times. Linking the policies achieves the following objectives:

When a site administrator opens the GPMC or the Group Policy through ADUC the domain controller that is used to make Group Policy changes and will process the changes is, by default, only the one that holds the FSMO role of PDC Emulator Operations Master. Although this was configured to help eliminate replication problems, this can cause frustration and delays for remote administrators making changes to Group Policy under their control by having to wait for the changes to replicate from the remote PDC Emulator DC. To force the GPMC and Group Policy snap-in to use the most available domain controller, enable the following Group Policy:

User Configuration, Administrative Templates, System, Group Policy, Group Policy Domain Controller Selection.

Choose Use Any Available Domain Controller or Inherit From Active Directory Snap-ins to use the DC to which the open snap-in is connected. The default that points to the PDC Emulator is the choice to Use the Primary Domain Controller. Figure 6.3 shows the domain controller selection of Inherit from Active Directory Snap-ins.

Figure 6.3. Configuring domain controller selection.

To speed up login and boot times for users, it is recommended that if the entire User Configuration or Computer Configuration section is not being used in a GPO, the unused section should be disabled for the GPO. This expedites the user logon time or the computer boot time, as the disabled sections aren’t parsed upon boot or login.

To disable configuration settings using Active Directory Users and Computers:

To disable configuration settings using the GPMC:

Searching through Administrative Templates for a particular Group Policy that is configured can be very time consuming. However, ADUC and the GPMC can be configured easily to show only the Administrative Templates objects that are configured. It removes from the view any policies or policy folders that don’t have policies configured within them, making it much easier and faster to find a specific configured policy. Figure 6.4 shows what a GPO looks like when viewed using the Show Configured Policies Only.

Figure 6.4. Standard group policy object screen.

To view only the configured policies while using ADUC or the GMPC:

When a Group Policy object is deleted, you have two choices: whether to just delete the link or delete the entire policy. Each option carries certain consequences.

If the Group Policy object should be removed from being applied at that location but it is or will still be applied elsewhere, choose to remove just the link. This leaves it in the available Group Policy list for future use. If the GPO will not be used elsewhere or ever again, delete the object permanently. This removes the policy from SYSVOL permanently and removes it from Active Directory.

If the policy won’t ever be used again and the policy isn’t fully deleted, this results in the Group Policy being left unused in the SYSVOL area on each domain controller. This adds unnecessarily to the time it takes to create a new domain controller, and increases replication time and storage space on the domain controller.

If you are using ADUC to access Group Policy, Windows 2003 presents you with two choices when trying to delete a Group Policy: Remove the Link From the List or Remove the Link and Delete the Group Policy Object Permanently.

If you are using the GPMC, delete the link by right-clicking on the Group Policy object under the object to which it is applied. A pop-up box appears that asks, “Do you want to delete this link? This will not delete the GPO itself,” thereby leaving the GPO available for linking elsewhere. To delete the link, click OK in the box.

To fully delete the GPO, click on the folder in GPMC entitled Group Policy Objects. Right-click the GPO and choose Delete. A pop-up box appears asking “Do you want to delete this GPO and all links to it in the domain? This will not delete links in other domains.” To complete the deletion, click OK.

As with many aspects of Group Policy, the choices and configuration methods of deployment are numerous. However, no matter which software package is being pushed, some basic best practices apply and can help make software deployment easier and less troublesome:

Without additional software it is not possible from a single centralized location to determine whether a software package was pushed successfully. All evidence of software pushes is seen locally on the client machines. On the local machines, there are three areas to check to determine whether a software installation was successful:

A crucial improvement in Group Policy is the ability to back up (or export) the data to a file. Then you can restore the Group Policy data into the same location. Note that the backup only backs up data specific to that GP itself. Other Active Directory Objects that can be linked to GPOs such as individual WMI filters (although the WMI links are backed up and restored) and IP Security policies are not backed up, due to complications with restores. Note also that performing a restore actually restores the original GUID of the GPO. This is useful when replacing a misconfigured GPO or especially one that was deleted.

The importing functionality allows for the importation of exported GPO data into a different location than the one from which it was exported, even to one with which no trust exists. Imports can be done in different domains, across forests, or within the same domain. This is most useful to move a GPO from a test lab into production without having to manually create what was done in the test lab, or, conversely, to update a test lab with the most current GPOs in production.

Copying GPOs is a very useful tool, as well. If you have configured a complex GP on a certain OU and want to duplicate the GPO(s) on other OUs, you need only copy the GPO and a new GPO is automatically created with the copy process. This new GPO can then be placed in the new location. You don’t need to re-create the GPOs manually. This is quicker and also eliminates the possibilities of mistakes. Note however, that the data isn’t saved to a file as it is in the backup or export of the GPO data. Trusts must be in effect for cross-domain or forest copies, or the Stored User Names and Passwords utility can be used if no trust exists. Note that copying a GPO requires creation of GPO rights in the target area as well as read access to the source GPO.

During a cross-domain or cross-forest restore or copy operation, it might not be the best method to import all the exact configuration settings that exist in the backed up GPO to the new area. For this purpose, migration tables are useful. A migration table can be used to convert values from a source to values that apply in the new target location or destination. The source and destination mappings can be changed to accommodate any differences in configuration between the two.

The GPMC enables you to easily view and configure Group Policy in multiple forests and domains. The default view shows multiple forests, and you can configure which forests and domains to view and administer from the GPMC. It is not possible to link a GPO from a domain in a forest to another domain in another forest. However, it is possible to configure Group Policies to reference servers in another forest.

By default, a forest can only be managed if a two-way trust exists between it and the forest of the administrator. You can configure it to work with only a one-way trust or no trust at all by choosing View, Options, clicking the General tab, and un-checking Enable Trust Delegation.

If you are supporting Group Policy in a forest with which you don’t have a trust, you will need to use the Stored User Names and Password tool to access the other forest. Find the Stored User Names and Password tool by choosing Start, Control Panel, User Accounts, Advanced, Manage Passwords in Windows XP or Start, Control Panel, Stored User Names & Passwords in Windows Server 2003. When the Stored User Names and Password tool appears, you will see a screen similar Figure 6.6.

Figure 6.6. Stored user names and password tools screen.

The Settings tab is a very useful area in the GPMC. You can use it to view the HTML reports on the GPO. These HTML reports state what is configured in the individual GPO. It provides an area to see all the settings, allows for looking easily at the descriptions (the “explain” sections) of the selected objects, and lets you condense and expand the details of the report by clicking on Show All. Additionally, the reports can be saved or printed.

Linking WMI Filters enables you to apply group policies and establish their scopes based on attributes of target computers. You can do this by using the WMI filters to query the WMI settings of the target computers for true/false and apply group policies based on the true/false WMI queries. A “false” on the target computer results in the GPO not being applied. Conversely, a “positive” results in the application of the GPO.

Because WMI filters are separate from GPOs, they must be linked to GPOs in the GPO Scope tab to function properly. Only one WMI filter can be applied to each GPO. Additionally, WMI filters will only work on Windows XP and later workstations, not Windows 2000 or before, or non–Microsoft operating systems.

The GPMC enables you to search for specific group policies or data within the GPOs. Data such as permissions, GPO name, linked WMI filters, user configuration contents (what is configured), computer configuration contents, and GPO GUID can be searched for using the granular searching functionality in the GPMC.

RSoP Planning mode enables you to simulate the deployment of a specified Group Policy, check the results, change, and then test the deployment again. This is very helpful in a lab environment where you can create and test a new set of policies. After RSoP shows that the GPO is correct, you can then use the backup functionality to back up the GPO configuration and import it into production.

To run RSoP in simulation mode, right-click on Group Policy Modeling in the forest that will be simulated, and choose Group Policy Modeling Wizard. The wizard allows for inputting the possibility of slow links, Loopback configuration, and WMI filters as well as other configuration choices. Each modeling is presented in its own report as a sub-node under the Group Policy Modeling Node.

RSoP in logging mode enables you to view what exact policies a user or computer might be receiving. It shows in a readable format what polices are enforced, where conflicts exist, and what different policies are being applied to the user/computer. It can be run either on the local computer or on a remote computer by choosing the proper options in the wizard. To run RSoP in logging mode, right-click on Group Policy Results in the GPMC, and then click on the Group Policy Modeling Wizard selection and follow the wizard that appears.

Microsoft provides predefined security templates for Group Policy, based on the type of users and environment needed (secure workstations and servers or highly secure workstations and servers). These templates can be imported into Group Policy objects where they can then either be implemented as-is, or changed, as the environment requires. However they are used, they are a great security starting point with which to obtain a base level of security. The templates can be used to configure settings such as account policies, event log settings, local policies, system service settings, Registry permissions, and file and folder permissions.

The following list describes the security templates that can be added after installation:

As stated earlier, Account Policy settings applied at the OU Level affect the local SAM database, not Active Directory accounts. The Account Policy settings must be applied on the Default Domain Policy to affect Active Directory accounts. The Account Policy settings that must be configured in the Default Domain Policy to affect the accounts in AD are located in the following areas in the Group Policy:

Restricted Groups can be used to set the membership of local groups such as Administrators and Power Users on servers and workstations. However, this cannot be applied to domain controllers because they don’t have local groups. Restricted Groups can be useful in extremely secure environments where the addition of users to local groups on workstations or servers would be problematic or if group membership were accidentally changed. Assigning local groups would automatically remove the incorrect group membership and replace it with the membership specified in Group Policy.

For example, you can create an OU that is used only to replace local workstation administrative group membership that was changed. You would create a local group, and if the workstation were discovered to have incorrect group membership, the workstation would be moved to the OU. The next time the workstation was rebooted, the incorrect group membership would be removed and the proper group added. The computer could then be moved back to the proper location.

To create a Restricted Group:

Folder redirection configures the user’s folders—such as My Documents, the desktop, application data, and the Start menu—to be redirected to another location, such as a server. This allows for critical data that is frequently located in these areas to be located on both the local desktop and the server. Because the redirected folders are automatically made available offline, if the file server is offline, the user can still access the data. Also, if the data is on a server, it can be easily backed up.

This is very useful for mobile users who need their data backed up and available while offline. However, if the user has a great deal of data, the synchronization can slow down log out/log on speeds, depending on when the synchronization is set to occur.

It is a best practice to configure the folder redirection using UNC paths as shown in Figure 6.8. You can also choose the option to redirect to the Home directory to configure the user’s My Documents to automatically redirect to a personal drive already established on a server. This option is available only for Windows XP and Server 2003, although it can be configured using a more manual fashion on Windows 2000 machines.

Figure 6.8. Setting up folder redirection in group policy.

Roaming profiles enable users to access their data, including redirected folders, wherever they log in. Items such as data on their desktop, application configuration, printers, and display options follow the users wherever they log on. The roaming profiles are stored on the local workstation(s) where the user logs in and also in a central repository on a server that can be accessed from any location from which the user might log in. This increases user productivity by giving users the tools and data they need, no matter where they are logging in. However, it does leave a copy of the user data, including offline files if configured, in every location where the user has logged on.

The GPUpdate utility comes with Windows 2003 and replaces Windows 2000 Server secedit/ refreshpolicy command line utility. When run, it refreshes the Computer Policy or User Policy, both locally and AD-based, including security settings. This eliminates the need to have the user reboot or log out/in to receive the new policy changes immediately. The syntax is as follows:

Gpupdate [/target:{computer | user}] [/force] [/wait:Value] [/logoff] [/boot]

For more information on the syntax commands, type the following at the command prompt to access help.

Gpudate /?

GPresult is a free utility from Microsoft that comes with the Server Resource Kit. It’s a small program that has to be installed before use. It must be run via a command line on the machine that is being investigated. The GPresult.exe tool will discover where the computer and the logged in user are receiving their Group Policy and what policies are applied to them. Although a great deal of the information output by the gpresult.exe tool is available in other areas and using other tools, it is convenient to have it all displayed in one place.

GPmonitor.exe is the Group Policy Monitor tool. It is used to gather information collected during GP refresh intervals and send the data to a specified central location. There, the tool can be used to analyze the data, as well. The gpmonitor.exe is available in the Windows Server 2003 Deployment Kit.

The GPOTool should be used for troubleshooting Group Policy issues in domains with more than one domain controller or across domains. The tool scours all the domain controllers in a domain or across domains and checks for consistency between the group policies located in the SYSVOL share on each domain controller and reports on what it finds. It also checks the validity of the group policies on all domain controllers, checks on object replication, and displays detailed information about the GPOs. The GPOTool.exe is available with the Microsoft Windows 2000 Server Resource Kit and is also available for downloading on Microsoft’s Web site.

FRS replication is the replication service that is used to replicate Group Policy Objects between domain controllers. It can be very difficult to troubleshoot, due in no small part to the troubleshooting tools that were available for use up to this time. However, Microsoft now has an excellent new tool called FRSDiag that provides a GUI interface through which an you run tests easily to analyze FRS replication. You can choose to look at single or multiple domain controllers at a time, check their event logs for errors, run NTFRSUTL options, run REPADMIN /showreps and REPADMIN /showconn, and run many other of the previously available FRS tools. However, the results are much clearer and easier to understand when output to the GUI interface. When the tool is configured to output the results to a screen, it lists any DCs with failures in red and any successes in green. The output can also be put into cab files. FRSDiag.exe can be downloaded from http://www.microsoft.com/downloads.

A highly useful test available within FRSDiag is the Canary File Tracer. The Canary File Tracer can be configured to check the SYSVOLdomain namepolicies directory (or any directory specified in the Share Root text area) for the correct number of folders or files. For example, if domain controllers cannot replicate Group Policies successfully and have a different number of policy folders present in their SYSVOLdomain_namepolicies folder, this tool will, in minutes, check the number of folders on each domain controller across the domain to see if they match across the domain controllers and output this data to the screen. It even tells how many policies above or below the target number the domain controller is off by. To do this, follow these steps:

The Canary File Tracer will then output the data to the screen, showing the results of the tests. Obviously, the Canary File Tracer can be used to troubleshoot other issues and search for other files and folders as well. It’s not just limited to the search capabilities listed previously.

Figure 6.9 shows the configuration options for the Canary File Tracer.

Figure 6.9. The Canary File Tracer configuration.

Sonar.exe can be downloaded from http://www.microsoft.com/downloads. It provides a GUI interface that enables you to check the FRS replication health of all domain controllers in the domain, which can help with troubleshooting Group Policy replication problems. Sonar can be configured to poll the domain controllers at different intervals for FRS health and will output the results such as backlogged files waiting to be replicated, down FRS services, and other error states to the GUI screen. Sonar is also a useful tool for monitoring DFS health because it uses FRS as well.

Both preferences and Policies are controlled through the Registry. Preferences are changes to the Registry that the user has control over and are not found in the Registry keys listed previously. These are options, such as wallpaper or screensavers. Policies are changes to the Registry in the keys listed previously which are protected by ACLs. Although Group Policy can overrule preferences, the basic user would normally have access to change the Registry settings through the operating system or an application. The Policy does not overwrite the preference keys, and if the policy is removed, the preferences will return. The preference settings remain in effect until they are removed or changed via the Registry.

It is a good idea to use policies rather than preferences when you want to control a certain aspect of an application or want something the user accesses to remain static. You can disable users from being able to change the appearance, configuration, or functionality of the item. For those items, using Administrative Templates is your best answer.

Microsoft provides additional Administrative Templates for use with Microsoft Office—usually as part of the Office Resource Kits. Installing these administrative templates provides you with many more Group Policy options for each Microsoft Office product.

Beyond using the custom and default templates, it is possible for you to create your own customized Administrative template to enforce a Registry change. The changes appear in the Group Policy GUI format and can be configured through the GPMC or ADUC the way normal Group Policy would be configured. Customized templates can be very useful in a highly customized environment or one where the default choices are not sufficient.

To best determine how to write a custom template, you must first consider what you are trying to control or change. You must also discover whether the Registry change is in the User or Computer hive area and then also note the actual Registry path and Registry value. After you have determined these items, coding a new basic administrative template is not too complex.

Administrative templates vary from the very basic to the extremely complex (look at the common.adm that is installed with Windows 2003). However, they can be extremely useful tools with which to customize any environment using Group Policy. Read Microsoft’s white paper entitled “Implementing Registry-Based Group Policy for Applications” for detailed instructions on how to build a custom Administrative Template.

Microsoft provides a Web page with links to sources of information about Group Policy on the Group Policy TechNet Page at

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/management/gp/default.asp

Any updated information about Group Policy will be there, including white papers, best practices, and other technical reference documents.

The white papers that Microsoft provides about Group Policy are numerous and very helpful. There are white papers about all sorts of topics such as the following: