You can think of a policy as a set of rules that helps you manage users and computers. You can apply group policies to multiple domains, individual domains, subgroups within a domain, or individual systems. Policies that apply to individual systems are referred to as local group policies and are stored on the local system only. Other group policies are linked as objects in the Active Directory data store.

To understand group policies, you need to know a bit about the structure of Active Directory. In Active Directory, sites represent the physical structure of your network. A site is a group of TCP/IP subnets, with each subnet representing a physical network segment. A domain is a logical grouping of objects for centralized management, and subgroups within a domain are called organizational units. Your network might have sites called NewYorkMain, CaliforniaMain, and WashingtonMain. Within the WashingtonMain site, you could have domains called SeattleEast, SeattleWest, SeattleNorth, and SeattleSouth. Within the SeattleEast domain, you could have organizational units called Information Services (IS), Engineering, and Sales.

Group policies apply only to systems running Windows-based operating systems. Group Policy settings are stored in a Group Policy object (GPO). You can think of a GPO as a container for the policies you apply and their settings. You can apply multiple GPOs to a single site, domain, or organizational unit. Because Group Policy is described by using objects, many object-oriented concepts apply. If you know a bit about object-oriented programming, you might expect the concepts of parent-child relationships and inheritance to apply to GPOs—and you’d be right.

A container is a top-level object that contains other objects. Through inheritance, a policy applied to a parent container is inherited by a child container. Essentially, this means that a policy setting applied to a parent object is passed down to a child object. For example, if you apply a policy setting in a domain, the setting is inherited by organizational units within the domain. In this case, the GPO for the domain is the parent object, and the GPOs for the organizational units are the child objects.

The order of inheritance is site, domain, organizational unit. This means that the Group Policy settings for a site are passed down to the domains within that site, and the settings for a domain are passed down to the organizational units within that domain.

As you might expect, you can override inheritance. To do this, you specifically assign a policy setting for a child container that is different from the policy setting for the parent. As long as overriding the policy is allowed (that is, overriding isn’t blocked), the child container’s policy setting will be applied appropriately. To learn more about overriding and blocking GPOs, see the “Blocking, overriding, and disabling policies” section later in this chapter.

When multiple policies are in place, policies are applied in the following order:

If policy settings conflict, the policy settings applied later have precedence and overwrite previously set policy settings. For example, organizational unit policies have precedence over domain group policies. As you might expect, there are exceptions to the precedence rule. These exceptions are discussed in the “Blocking, overriding, and disabling policies” section later in this chapter.

As you’ll discover when you start working with group policies, policy settings are divided into two broad categories:

Computer policies are normally applied during system startup, and user policies are normally applied during logon. The exact sequence of events is often important in troubleshooting system behavior. The events that take place during startup and logon are as follows:

Group policies apply only to systems running professional and server versions of Windows. As you might expect, each new version of the Windows operating system has brought with it changes to Group Policy. Sometimes these changes have made earlier policies obsolete on newer versions of Windows. In this case, the policy works only on specific versions of Windows, such as only on Windows Vista and Windows Server 2008.

Generally speaking, most policies are forward-compatible. This means that in most cases, policies introduced in a previous release of Windows can be used in the current release of Windows. It also means that policies for Windows 8.1 and Windows Server 2012 R2 usually aren’t applicable to earlier releases of Windows. If a policy isn’t applicable to a particular version of the Windows operating system, you can’t enforce the policy on computers running those versions of Windows.

How will you know if a policy is supported on a particular version of Windows? Easy. The Properties dialog box for each policy setting has a Supported On box. This text-only field lists the policy’s compatibility with various versions of Windows. You don’t have to open it if you select a policy in any of the Group Policy editors and also have selected the Extended tab (rather than the Standard tab). A Requirements entry is displayed that lists compatibility.

You can also install new policies when you add a service pack, install Windows applications, or add Windows components. This means a wide range of compatibility entries are available.

When computers are being used in a stand-alone configuration rather than a domain configuration, you might find that multiple local GPOs are useful because you no longer have to explicitly disable or remove settings that interfere with your ability to manage a computer before performing administrator tasks. Instead, you can implement one local GPO for administrators and another local GPO for nonadministrators. In a domain configuration, however, you might not want to use multiple local GPOs. In domains, most computers and users already have multiple GPOs applied to them—adding multiple local GPOs to this already varied mix can make managing Group Policy confusing.

Computers running current versions of Windows have three layers of local Group Policy objects:

These layers of local Group Policy objects are processed in the following order: Local Group Policy, Administrators and Non-Administrators Local Group Policy, User-Specific Local Group Policy.

Because the available user-configuration settings are the same for all local GPOs, a setting in one GPO might conflict with a setting in another GPO. Windows resolves conflicts in settings by overwriting any previous setting with the last-read and mostcurrent settings. The final setting is the one that Windows uses. When Windows resolves conflicts, only the enabled or disabled state of settings matters. A setting set as Not Configured has no effect on the state of the setting from a previous policy application. To simplify domain administration, you can disable processing of local Group Policy objects on computers running Windows Vista or later releases by enabling the Turn Off Local Group Policy Objects Processing policy setting in a domain GPO. In Group Policy, this setting is located under Administrative Templates for Computer Configuration under SystemGroup Policy.

All computers running current releases of Windows have an editable local Group Policy object. Although a domain controller has a local Group Policy object, you shouldn’t edit its settings.

The quickest way to access the local GPO on a computer is to enter the following command in the Everywhere search box:

gpedit.msc

This command starts the GPOE in a Microsoft Management Console (MMC) with its target set to the local computer. To access the top-level local GPO on a remote computer, enter the following in the Everywhere search box:

gpedit.msc /gpcomputer:"RemoteComputer"

Here RemoteComputer is the host name or fully qualified domain name of the remote computer. Note that the double quotation marks are required and that there must not be a space between /gpcomputer: and the remote computer value, as shown in the following example:

gpedit.msc /gpcomputer:"corpsvr82"

When you are connected to a remote computer, the root node lists the name of the remote computer, as shown in Figure 6-1. Otherwise, the root node label is shown as Local Computer Policy.

Figure 6-1. Use the policy editor to manage local policy settings.

You can also manage the top-level local GPO on a computer by following these steps:

Whether you access the Local GPO directly or by adding GPOE to an MMC, you can now manage local policy settings by using the options provided (see Figure 6-2).

Figure 6-2. Use the policy editor to manage local policy settings.

Local group policies are stored in the %SystemRoot%System32GroupPolicy folder on each computer running Windows Server. In this folder, you’ll find the following subfolders:

By default, the only local policy object that exists on a computer is the Local Group Policy object. You can create and manage other local objects as necessary (except on domain controllers). You can create or access the Administrator Local Group Policy object, the Non-Administrator Local Group Policy Object, or a user-specific local Group Policy object by following these steps:

Figure 6-3. Select the local user or group to manage.

Policy settings for administrators, nonadministrators, and users are stored in the %SystemRoot%System32GroupPolicyUsers folder on each computer running Windows Server. Because these local GPOs apply only to user configuration settings, user-specific policy settings under %SystemRoot%System32GroupPolicyUsers have only a User subfolder, and this subfolder stores user scripts in the Script folder and registry-based policy information for HKEY_CURRENT_USER in the Registry.pol file.

When you work with Active Directory–based Group Policy, you’ll find that each domain in your organization has two default GPOs:

Typically, the Default Domain Policy GPO is the highest-precedence GPO linked to the domain level, and the Default Domain Controllers Policy GPO is the highest-precedence GPO linked to the Domain Controllers container. You can link additional GPOs to the domain level and to the Domain Controllers container. When you do this, the settings in the highest-precedence GPO override settings in lower-precedence GPOs. These GPOs aren’t meant for general management of Group Policy.

The Default Domain Policy GPO is used to manage only the default Account Policies settings and, in particular, three specific areas of Account Policies: password policy, account lockout policy, and Kerberos policy. Several security options are also managed through this GPO. These include Accounts: Rename Administrator Account, Accounts: Administrator Account Status, Accounts: Guest Account Status, Accounts: Rename Guest Account, Network Security: Force Logoff When Logon Hours Expire, Network Security: Do Not Store LAN Manager Hash Value On Next Password Change, and Network Access: Allow Anonymous SID/Name Translation. One way to override these settings is to create a GPO with the overriding settings and link it with a higher precedence to the domain container.

The Default Domain Controllers Policy GPO includes specific User Rights Assignment and Security Options settings that limit the ways domain controllers can be used. One way to override these settings is to create a GPO with the overriding settings and link it with a higher precedence to the Domain Controllers container.

To manage other areas of policy, you should create a GPO and link it to the domain or to an appropriate organizational unit within the domain.

Site, domain, and organizational unit group policies are stored in the %SystemRoot%SysvolDomainPolicies folder on domain controllers. In this folder, you’ll find one subfolder for each policy you defined on the domain controller. The policy folder name is the policy’s globally unique identifier (GUID). You can find the policy’s GUID on the policy’s Properties page on the General tab in the Summary frame. Within these individual policy folders, you’ll find the following subfolders:

You can run the GPMC from the Tools menu in Server Manager. At a prompt or in the Everywhere search box, type gpmc.msc, and then press Enter.

As shown in Figure 6-4, the console root node is labeled Group Policy Management, and below this node is the Forest node. The Forest node represents the forest to which you are currently connected and is named after the forest root domain for that forest. If you have appropriate credentials, you can add connections to other forests. To do this, press and hold or right-click the Group Policy Management node, and then tap or click Add Forest. In the Add Forest dialog box, enter the name of the forest root domain in the Domain box, and then tap or click OK.

Figure 6-4. Use the GPMC to work with GPOs in sites, forests, and domains.

Expanding the Forest node displays the following nodes:

GPOs listed under the domain, site, and organizational unit containers in the GPMC are GPO links and not the GPOs themselves. You can access the actual GPOs through the Group Policy objects container of the selected domain. Note that the icons for GPO links have small arrows at the bottom left, similar to shortcut icons, whereas GPOs themselves do not.

When you start the GPMC, the console connects to Active Directory running on the domain controller that is acting as the PDC emulator for your logon domain and obtains a list of all GPOs and organizational units in that domain. It does this by using Lightweight Directory Access Protocol (LDAP) to access the directory store and the Server Message Block (SMB) protocol to access the SYSVOL directory. If the PDC emulator isn’t available for some reason, such as when the server is offline, the GPMC displays a prompt so that you can choose to work with policy settings on the domain controller you are currently connected to or on any available domain controller. To change the domain controller you are connected to, press and hold or right-click the domain node for which you want to set the domain controller focus, and then tap or click Change Domain Controller. In the Change Domain Controller dialog box, the domain controller you are currently connected to is listed under Current Domain Controller. Using the Change To options, specify the domain controller to use, and then tap or click OK.

With the GPMC, you can edit a GPO by pressing and holding or right-clicking it and then selecting Edit on the shortcut menu. As Figure 6-5 shows, the policy editor has two main nodes:

Figure 6-5. The configuration of the policy editor depends on the type of policy you’re creating and the add-ons installed.

Under the Computer Configuration and User Configuration nodes, you’ll find the Policies and Preferences nodes. Settings for general policies are listed under the Policies node. Settings for general preferences are listed under the Preferences node.

The exact configuration of Computer Configuration and User Configuration depends on the add-ons installed and which type of policy you’re creating. Still, you’ll usually find that both Computer Configuration and User Configuration have subnodes for the following:

Administrative templates provide easy access to registry-based policy settings that you might want to configure. A default set of administrative templates is configured for users and computers in the policy editor. You can also add or remove administrative templates. Any changes you make to policies available through administrative templates are saved in the registry. Computer configurations are saved in HKEY_ LOCAL_MACHINE, and user configurations are saved in HKEY_CURRENT_USER.

You can view the currently configured templates in the Administrative Templates node of the policy editor. This node contains policies you can configure for local systems, organizational units, domains, and sites. Different sets of templates are found under Computer Configuration and User Configuration. You can add templates containing new policies in the policy editor when you install new Windows components.

You can use administrative templates to manage the following:

The best way to get to know which administrative template policies are available is to browse the Administrative Templates nodes. As you browse the templates, you’ll find that policies are in one of three states:

You can enable, disable, and configure policies by following these steps:

When you work with a policy object, creating an object and linking an object to a specific container within Active Directory are two different actions. You can create a GPO without linking it to any domain, site, or organizational unit. Then, as appropriate, you can link the GPO to a specific domain, site, or organizational unit. You can also create a GPO and link it automatically to a domain, site, or organizational unit. The technique you choose primarily depends on your personal preference and how you plan to work with the GPO. Keep in mind that when you create and link a GPO to a site, domain, or organizational unit, the GPO is applied to the user and computer objects in that site, domain, or organizational unit according to the Active Directory options governing inheritance, the precedence order of GPOs, and other settings.

You can create and then link a GPO to a site, domain, or organizational unit by following these steps:

You can create and link a GPO as a single operation by following these steps:

When you create a GPO in the GPMC, you can base the GPO on a starter GPO. The settings for the starter GPO are then imported into the new GPO, which allows you to use a starter GPO to define the base configuration settings for a new GPO. In a large organization, you should create different categories of starter GPOs based on the users and computers they will be used with or on the required security configuration.

You can create a starter GPO by following these steps:

In Active Directory, all administrators have some level of privileges for performing Group Policy management tasks. Through delegation, other individuals can be granted permissions to perform any or all of the following tasks:

In Active Directory, administrators can create GPOs, and anyone who has created a GPO has the right to manage that GPO. In the GPMC, you can determine who can create GPOs in a domain by selecting the Group Policy Objects node for that domain and then tapping or clicking the Delegation tab. On the Delegation tab is a list of groups and users that can create GPOs in the domain. To grant GPO creation permission to a user or group, tap or click Add. In the Select User, Computer, Or Group dialog box, select the user or group, and then tap or click OK.

In the GPMC, you have several ways to determine who has access permissions for Group Policy management. For domain, site, and organizational unit permissions, select the domain, site, or organizational unit you want to work with, and then tap or click the Delegation tab in the right pane, as shown in Figure 6-6. In the Permission list, select the permission you want to check. The options are as follows:

Figure 6-6. Review permissions for Group Policy management.

To grant domain, site, or organizational unit permissions, complete the following steps:

For individual GPO permissions, select the GPO you want to work with in the GPMC, and then tap or click the Delegation tab in the right pane. One or more of the following permissions are displayed for individual users and groups:

To grant permissions for working with the GPO, complete the following steps:

Inheritance ensures that every computer and user object in a domain, site, or organizational unit is affected by Group Policy. Most policies have three configuration options: Not Configured, Enabled, or Disabled. Not Configured is the default state for most policy settings. If a policy is enabled, the policy is enforced and is applied directly or through inheritance to all users and computers that are subject to the policy. If a policy is disabled, the policy is not enforced or applied.

You can change the way inheritance works in four key ways:

For Group Policy, the order of inheritance goes from the site level to the domain level and then to each nested organizational unit level. Keep the following in mind:

When multiple policy objects are linked at a specific level, you can change the link order (and thus the precedence order) of policy objects by following these steps:

Overriding inheritance is a basic technique for changing the way inheritance works. When a policy is enabled in a higher-level policy object, you can override inheritance by disabling the policy in a lower-level policy object. When a policy is disabled in a higher-level policy object, you can override inheritance by enabling the policy in a lower-level policy object. As long as a policy is not blocked or enforced, this technique achieves the effects you want.

Sometimes you will want to block inheritance so that no policy settings from higher-level containers are applied to users and computers in a particular container. When inheritance is blocked, only configured policy settings from policy objects linked at that level are applied, and settings from all high-level containers are blocked (as long as there is no policy enforcement).

Domain administrators can use inheritance blocking to block inherited policy settings from the site level. Organizational unit administrators can use inheritance blocking to block inherited policy settings from both the domain and the site level. By using blocking to ensure the autonomy of a domain or organizational unit, you can ensure that domain or organizational unit administrators have full control over the policies that apply to users and computers under their administration.

Using the GPMC, you can block inheritance by pressing and holding or right-clicking the domain or organizational unit that should not inherit settings from higher-level containers, and then selecting Block Inheritance. If Block Inheritance is already selected, selecting it again removes the setting. When you block inheritance in the GPMC, a blue circle with an exclamation point is added to the container’s node in the console tree. This notification icon provides a quick way to tell whether any domain or organizational unit has the Block Inheritance setting enabled.

To prevent administrators who have authority over a container from overriding or blocking inherited Group Policy settings, you can enforce inheritance. When inheritance is enforced, all configured policy settings from higher-level policy objects are inherited and applied regardless of the policy settings configured in lower-level policy objects. Thus, enforcement of inheritance is used to supersede the overriding and blocking of policy settings.

Forest administrators can use inheritance enforcement to ensure that configured policy settings from the site level are applied and to prevent the overriding or block-ing of policy settings by domain and organizational unit administrators. Domain administrators can use inheritance enforcement to ensure that configured policy settings from the domain level are applied and to prevent the overriding or blocking of policy settings by organizational unit administrators.

Using the GPMC, you can enforce policy inheritance by expanding the top-level container from which to begin enforcement, pressing and holding or right-clicking the link to the GPO, and then tapping or clicking Enforced. For example, if you want to ensure that a domain-level GPO is inherited by all organizational units in the domain, expand the domain container, press and hold or right-click the domain-level GPO, and then tap or click Enforced. If Enforced is already selected, selecting it again removes the enforcement. In the GPMC, you can easily determine which policies are inherited and which policies are enforced. Simply select a policy object anywhere in the GPMC, and then view the related Scope tab in the right pane. If the policy is enforced, the Enforced column under Link Enabled will display Yes, as shown in Figure 6-8.

After you select a policy object, you can press and hold or right-click a location entry on the Scope tab to display a shortcut menu that allows you to manage linking and policy enforcement. Enable or disable links by selecting or clearing the Link Enabled option, respectively. Enable or disable enforcement by selecting or clearing the Enforced option.

Figure 6-8. Enforce policy inheritance to ensure that settings are applied.

When you make changes to a policy, those changes are immediate. However, they aren’t propagated automatically. Client computers request policies at the following times:

Computer configuration settings are applied during startup of the operating system. User configuration settings are applied when a user logs on to a computer. Typically, if there is a conflict between computer and user settings, computer settings have priority and take precedence.

After policy settings are applied, the settings are refreshed automatically to ensure that they are current. The default refresh interval for domain controllers is 5 minutes. For all other computers, the default refresh interval is 90 minutes, with up to a 30-minute variation to avoid overloading the domain controller with numerous concurrent client requests. This means that an effective refresh window for nondomain-controller computers is 90 to 120 minutes.

During a Group Policy refresh, the client computer contacts an available domain controller in its local site. If one or more of the policy objects defined in the domain have changed, the domain controller provides a list of the policy objects that apply to the computer and to the user who is currently logged on, as appropriate. The domain controller does this regardless of whether the version numbers on all the listed policy objects have changed. By default, the computer processes the policy objects only if the version number of at least one of the policy objects has changed. If any one of the related policies has changed, all the policies have to be processed again because of inheritance and the interdependencies between policies.

Security settings are a notable exception to the processing rule. By default, these settings are refreshed every 16 hours (960 minutes) regardless of whether policy objects contain changes. A random offset of up to 30 minutes is added to reduce the impact on domain controllers and the network during updates (making the effective refresh window 960 to 990 minutes). Also, if the client computer detects that it is connecting over a slow network connection, it informs the domain controller, and only the security settings and administrative templates are transferred over the network. This means that by default, only the security settings and administrative templates are applied when a computer is connected over a slow link. You can configure the way slow-link detection works in Group Policy.

You must carefully balance the update frequency with the actual rate of policy change. If policy is changed infrequently, you might want to increase the refresh window to reduce resource usage. For example, you might want to use a refresh interval of 20 minutes on domain controllers and 180 minutes on other computers.

You can change the Group Policy refresh interval on a per-policy object basis. To set the refresh interval for domain controllers, follow these steps:

Figure 6-9. Configure the refresh interval for Group Policy.

To set the refresh interval for member servers and workstations, follow these steps:

As an administrator, you might often need or want to refresh Group Policy manually. For example, you might not want to wait for Group Policy to be refreshed at the automatic interval, or you might be trying to resolve a problem with refreshes and want to force a Group Policy refresh. You can refresh Group Policy manually by using the Gpupdate command-line utility.

You can initiate a refresh in several ways. Entering gpupdate at a prompt or in the Everywhere search box refreshes settings in both Computer Configuration and User Configuration on the local computer. Only policy settings that have changed are processed and applied when you run Gpupdate. You can change this behavior by using the /force parameter to force a refresh of all policy settings.

You can refresh user and computer configuration settings separately. To refresh only computer configuration settings, enter gpupdate /target:computer at the command prompt. To refresh only user configuration settings, enter gpupdate /target:user at the command prompt.

You can also use Gpupdate to log off a user or restart a computer after Group Policy is refreshed. This is useful because some group policies are applied only when a user logs on or when a computer starts. To log off a user after a refresh, add the /Logoff parameter. To restart a computer after a refresh, add the /Boot parameter.

Modeling Group Policy for planning is useful when you want to test various implementation and configuration scenarios. For example, you might want to model the effect of loopback processing or slow-link detection. You can also model the effect of moving users or computers to another container in Active Directory, or the effect of changing security group membership for users and computers.

All domain and enterprise administrators have permission to model Group Policy for planning, as do those who have been delegated the Perform Group Policy Modeling Analyses permission. To model Group Policy and test various implementation and update scenarios, follow these steps:

Figure 6-11. Review the report to determine the effects of modeling.

The GPMC features built-in copy, paste, and import operations. Using the copy and paste features is fairly straightforward. The Copy and Paste options are available when you press and hold or right-click a GPO in the GPMC. You can copy a policy object and all its settings in one domain and then browse to the domain into which you want to paste the copy of the policy object. The source and target domains can be any domains you can connect to in the GPMC and for which you have permission to manage related policy objects. In the source domain, you need Read permission to create a copy of a policy object. In the target domain, you need Write permission to write (paste) the copied policy object. Administrators have this privilege, as do those who have been delegated permission to create policy objects.

Copying policy objects between domains works well when you have connectivity between domains and the appropriate permissions. If you are an administrator at a remote office or have been delegated permissions, however, you might not have access to the source domain to create a copy of a policy object. In this case, another administrator can make a backup copy of a policy object for you and then send you the related data. When you receive the related data, you can import the backup copy of the policy object into your domain to create a policy object with the same settings.

Anyone with the Edit Settings Group Policy management privilege can perform an import operation. The import operation overwrites all the settings of the policy object you select. To import a backup copy of a policy object into a domain, follow these steps:

As part of your periodic administration tasks, you should back up GPOs to protect them. You can use the GPMC to back up individual policy objects in a domain or all policy objects in a domain by following these steps:

Using the GPMC, you can restore a policy object to the state it was in when it was backed up. The GPMC tracks the backup of each policy object separately, even if you back up all policy objects at one time. Because version information is also tracked according to the backup time stamp and description, you can restore the last version of each policy object or a particular version of any policy object.

You can restore a policy object by following these steps:

You can use Group Policy modeling for logging Resultant Set of Policy (RSoP). When you use Group Policy modeling in this way, you can review all the policy objects that apply to a computer and the last time the applicable policy objects were processed (refreshed). All domain and enterprise administrators have permission to model Group Policy for logging, as do those who have been delegated the permission Read Group Policy Results Data. In the GPMC, you can model Group Policy for the purpose of logging RSoP by pressing and holding or right-clicking the Group Policy Results node, and then clicking Group Policy Results Wizard. When the Group Policy Results Wizard starts, follow the prompts.

Another way to disable a policy is to disable an unused part of the GPO. When you do this, you block computer configuration or user configuration settings, or both, and don’t allow them to be applied. When you disable part of a policy that isn’t used, the application of GPOs will be faster.

You can enable and disable policies partially or entirely by following these steps:

In Group Policy, computer configuration settings are processed when a computer starts and accesses the network. User configuration settings are processed when a user logs on to the network. In the event of a conflict between settings in Computer Configuration and User Configuration, the computer configuration settings win. It is also important to remember that computer settings are applied from the computer’s GPOs, and user settings are applied from the user’s GPOs.

In some special situations, you might not want this behavior. On a shared computer, you might want the user settings to be applied from the computer’s GPOs, but you might also want to allow user settings from the user’s GPOs to be applied. In a secure lab or kiosk environment, you might want the user settings to be applied from the computer’s GPOs to ensure compliance with strict security rules or guidelines for the lab. By using loopback processing, you can allow for these types of exceptions and obtain user settings from a computer’s GPOs.

To change the way loopback processing works, follow these steps:

Slow-link detection is used by Group Policy clients to detect increased latency and reduced responsiveness on the network and to take corrective action to reduce the likelihood that processing of Group Policy will further saturate the network. After a slow link is detected, Group Policy clients reduce their network communications and requests, thereby reducing the overall network traffic load by limiting the amount of policy processing they do.

By default, if the connection speed is determined to be less than 500 kilobits per second (which could also be interpreted as high latency/reduced responsiveness on a fast network), the client computer interprets this as a slow network connection and notifies the domain controller. As a result, only security settings and administrative templates in the applicable policy objects are sent by the domain controller during a policy refresh.

You can configure slow-link detection by using the Configure Group Policy Slow Link Detection policy, which is stored in the Administrative Templates for Computer Configuration under SystemGroup Policy. If you disable this policy or do not configure it, clients use the default value of 500 kilobits per second to determine whether they are on a slow link. If you enable this policy, you can set a specific slow-link value, such as 384 kilobits per second. You also can specify that 3G connections should always be treated as slow links. Alternatively, if you want to disable slow-link detection completely, set the Connection Speed option to 0. This setting effectively tells clients not to detect slow links and to consider all links to be fast.

You can optimize slow-link detection for various areas of Group Policy processing as necessary. By default, policy areas that are not processed when a slow link is detected include the following:

Security Policy Processing is always enabled automatically for slow links. By default, security policy is refreshed every 16 hours even if security policy has not changed. The only way to stop the forced refresh is to configure security policy processing so that it is not applied during periodic background refreshes. To do this, select the policy setting Do Not Apply During Periodic Background Processing. However, because security policy is so important, the Do Not Apply setting means only that security policy processing is stopped when a user is logged on and using the computer. One of the only reasons you’ll want to stop security policy refreshes is applications failing during refresh operations.

You can configure slow-link detection and related policy processing by following these steps:

Figure 6-12. Configure slow-link detection.

To configure slow-link and background policy processing of key areas of Group Policy, follow these steps:

In the GPMC, you can stop using a linked GPO in two ways:

Removing a link to a GPO stops a site, domain, or organizational unit from using the related policy settings but does not delete the GPO. Because of this, the GPO remains linked to other sites, domains, or organizational units as appropriate. In the GPMC, you can remove a link to a GPO by pressing and holding or right-clicking the GPO link in the container that it is linked to, and then clicking Delete. When prompted to confirm that you want to remove the link, tap or click OK. If you remove all links to the GPO from sites, domains, and organizational units, the GPO continues to exist in the Group Policy Objects container, but its policy settings have no effect in your organization.

Permanently deleting a GPO removes the GPO and all links to it. The GPO will not exist in the Group Policy Objects container and will not be linked to any sites, domains, or organizational units. The only way to recover a deleted GPO is to restore it from a backup (if one is available). In the GPMC, you can remove a GPO and all links to the object from the Group Policy Objects node. Press and hold or right-click the GPO, and then select Delete. When prompted to confirm that you want to remove the GPO and all links to it, tap or click Yes.

When you are trying to determine why policy is not being applied as expected, one of first things you should do is examine the Resultant Set of Policy for the user and computer experiencing problems with policy settings. You can determine the GPO that a setting is applied from by following these steps:

Using the Gpresult command-line utility, you can also view RSoP. Gpresult provides details about the following:

Gpresult has the following basic syntax:

gpresult /s ComputerName /user DomainUserName

Here ComputerName is the name of the computer you want to log policy results for, and DomainUserName indicates the user you want to log policy results for. For example, to view the RSoP for CorpPC85 and the user Tedg in the Cpandl domain, you would enter the following command:

gpresult /s corppc85 /user cpandl	edg

You can view more detailed output by using one of the two verbose options. The /v parameter turns on verbose output, and results are displayed only for policy settings in effect. The /z parameter turns on verbose output with settings for policy settings in effect and all other GPOs that have the policy set. Because Gpresult output can be fairly long, you should create an HTML report by using the /h parameter, or an XML report by using the /x parameter. The following examples use these parameters:

gpresult /s corppc85 /user cpandl	edg /h gpreport.html
gpresult /s corppc85 /user cpandl	edg /x gpreport.xml

The Default Domain Policy and Default Domain Controller Policy GPOs are vital to the health of Active Directory Domain Services. If for some reason these policies become corrupted, Group Policy will not function properly. To resolve this, you must use the GPMC to restore a backup of these GPOs. If you are in a disaster-recovery scenario and do not have any backups of the Default Domain Policy or the Default Domain Controller Policy, you can use Dcgpofix to restore the security settings in these policies. The state that Dcgpofix restores these objects to depends on how you modified security and on the security state of the domain controller before you ran Dcgpofix. You must be a member of Domain Admins or Enterprise Admins to run Dcgpofix.

When you run Dcgpofix, both the Default Domain Policy and Default Domain Controller Policy GPOs are restored by default, and you lose any base changes made to these GPOs. Some policy settings are maintained separately and are not lost, including Windows Deployment Services (Windows DS), Security Settings, and Encrypting File System (EFS). Nondefault Security Settings are not maintained, however, which means that other policy changes could also be lost. All other policy settings are restored to their previous values, and any changes you’ve made are lost.

To run Dcgpofix, log on to a domain controller in the domain in which you want to fix default Group Policy, and then enter dcgpofix at an elevated prompt. –Dcgpofix checks the Active Directory schema version number to ensure compatibility between the version of Dcgpofix you are using and the Active Directory schema configuration. If the versions are not compatible, Dcgpofix exits without fixing the default Group Policy objects. By specifying the /ignoreschema parameter, you can enable Dcgpofix to work with different versions of Active Directory. However, default policy objects might not be restored to their original state. Because of this, you should always be sure to use the version of Dcgpofix that is installed with the current operating system.

You also have the option of fixing only the Default Domain Policy or only the Default Domain Controller Policy GPO. If you want to fix only the Default Domain Policy, enter dcgpofix /target:domain. If you want to fix only the Default Domain Controller Policy, enter dcgpofix /target:dc.