How to troubleshoot Group Policy object processing failures that occur across multiple forests

This article describes how to troubleshoot Group Policy object (GPO) processing failures that occur across multiple forests. Specifically, this article discusses the following three scenarios:

• A GPO does not apply when a user logs on in a trusted domain.
• A cross-forest GPO application fails if Internet Control Message Protocol (ICMP) is not enabled.
• Resultant Set of Policy (RSoP) Planning mode is not supported in a cross-forest scenario.

Scenario 1: A GPO does not apply when a user logs on in a trusted domain

Symptoms

This problem occurs even though the Allow Cross-Forest User Policy and Roaming User Profiles Group Policy setting is enabled. An external trust exists between the domain in which the user is logging on and the user's domain.

For example, this problem occurs in the following scenario:

• A Microsoft Windows Server 2003 Terminal Server belongs to the Terminal Server organizational unit (OU) in a Windows Server 2003-based domain.
• A user who belongs to a Microsoft Windows 2000 Server Service Pack 4 (SP4)-based domain logs on to the Windows Server 2003 Terminal Server.
• The Windows Server 2003-based domain and the Windows 2000-based domain are in separate forests.
• Two external trusts exist between the Windows Server 2000 SP4-based domain in Forest 1 and the Windows Server 2003-based domain in Forest 2.
• A GPO that is linked to the Terminal Server OU has the following settings:
  • The Allow Cross-Forest User Policy and Roaming User Profiles policy is enabled. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    823862  (http://support.microsoft.com/kb/823862/ ) User policies are not applied when you log on to a computer that is running Windows 2000 SP4
  • The User Group Policy loopback processing mode policy is set to Merge Mode.
  • User-based policy settings are configured to hide the Search, Run, and Help commands on the Start menu.

Note This scenario is specific to external trusts between domains in separate forests. This scenario does not apply to forest trusts. Forest trusts and external trusts differs as follows:

• External trusts are used in Windows 2000 to enable trust relationships between two domains that are in different forests.
• Forest trusts resemble external trusts between the root domains of two forests. However, a forest trust encompasses all the domains in each forest. Forest trusts require that all the domain controllers in both forests be running Windows Server 2003.

Cause

The issue occurs because the security context of the computer account is being used. Therefore, NTLM cannot be used. Kerberos authentication is required.

Troubleshooting steps

To troubleshoot this issue, follow these steps:

1. Use Network Monitor to take simultaneous traces from the client computer in Forest 1 and from the logon domain controller in Forest 2.
2. Enable USERENV logging. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
   221833  (http://support.microsoft.com/kb/221833/ ) How to enable user environment debug logging in retail builds of Windows

The Network Monitor trace shows that Kerberos authentication fails and that NTLM authentication is not used.

The following information is logged in the Userenv.log file:

Resolution

To resolve this problem, apply the hotfix that is described in the following Microsoft Knowledge Base article to the Windows Server 2003-based domain controller in Forest 2:
This hotfix enables the GPO without requiring Kerberos authentication.

Note This issue does not apply to forest trusts between two Windows 2003-based forests that provide full Kerberos support. For more information about how to plan and how to implement federated forests in Windows Server 2003, visit the following Microsoft Web page:

Scenario 2: A cross-forest GPO application fails if ICMP is not enabled

Symptoms

Cross-forest GPOs are not applied if ICMP is not enabled. Group Policy processing stops if large fragmented ICMP packets are not allowed on the network because of slow link detection. When this occurs, Microsoft Windows XP does not detect a fast link or a slow link. Instead Windows XP fails out of Group Policy processing. Only a generic USERENV 1054 event is logged in the Application event log. This problem affects both computer and user policies.

In this scenario, the following information is logged in the Userenv.log file:

Cause

This issue can occur when clients authenticate and pull Group Policy settings across a wide area network (WAN) link. The process that is used to detect link speed involves sending a large ICMP ping request. For example, a ping request is sent that is larger than 2 KB. The ICMP echo request is fragmented into separate IP packets by the client's own network interface, by a WAN router, or by both the interface and the router. Because some IP attacks involve malformed ICMP packets, many routers are configured to discard fragmented ICMP packets. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Resolution

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

To disable slow link detection on the Windows XP client computer, set the following registry values:

Registry subkey: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0

Registry subkey: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0

These registry settings must be configured manually because Group Policy is not applied in this scenario. These registry settings are otherwise set by the following Group Policy settings:

Policy location: Computer Configuration\Administrative Templates\System\Group Policy
Policy name: Group Policy slow link detection
Policy setting: Enabled with a value of 0

Policy location: User Configuration\Administrative Templates\System\Group Policy
Policy name: Group Policy slow link detection
Policy setting: Enabled with a value of 0

Notes

• These registry changes can be scripted with the Reg.ini file if you must apply the changes to many computers. You can then create a GPO that applies these settings to make sure that the settings are retained after this issue is resolved.
• You may also want to modify the Default User profile so that it contains the user-side settings. Therefore, all new profiles will successfully apply Group Policy settings.

After you implement these settings, the Userenv.log file shows correct Group Policy processing. The following information is logged in the Userenv.log file:

Scenario 3: Resultant Set of Policy (RSoP) Planning mode is not supported in a cross-forest scenario

Symptoms

Administrators cannot use the RSoP Planning mode to plan for scenarios that span forests in Windows Server 2003. For example, you cannot plan for a scenario where a user logs on to a workstation in Forest 1 from Forest 2. When you try to run RSoP Planning mode in a cross-forest environment, you may receive the following Group Policy error message:

Cause

This issue occurs because RSoP Planning mode does not support cross-forest scenarios. In many scenarios, RSoP cannot validate the information that is returned from a domain controller that is located in another forest. The Authenticated Users group must have Read permissions for relevant policies to successfully read a particular policy in a cross-forest environment. For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base: