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

INTRODUCTION

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.

More Information

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



USERENV(ec0.86c) 13:36:18:156 ProcessGPO: Deferring search for <LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=nils,DC=com>
USERENV(ec0.86c) 13:36:18:484 GetMachineDomainDS: ldap_bind_s failed with 82
USERENV(ec0.86c) 13:36:18:500 GetGPOInfo: Leaving with 0

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:


896683
A user in a trusted external domain cannot log on to a Windows Server 2003-based domain even though the "Allow Cross-Forest User Policy and Roaming User Profiles" Group Policy setting is enabled

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:

USERENV(22c.91c) 15:58:22:322 ProcessGPOs:
USERENV(22c.91c) 15:58:22:322 ProcessGPOs:
USERENV(22c.91c) 15:58:22:332 ProcessGPOs: Starting user Group Policy (Background) processing...
USERENV(22c.91c) 15:58:22:332 ProcessGPOs:
USERENV(22c.91c) 15:58:22:341 ProcessGPOs:
USERENV(22c.91c) 15:58:22:341 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0
USERENV(22c.91c) 15:58:22:341 EnterCriticalPolicySectionEx: User critical section has been claimed. Handle = 0x734
USERENV(22c.91c) 15:58:22:351 EnterCriticalPolicySectionEx: Leaving successfully.
USERENV(22c.91c) 15:58:22:351 ProcessGPOs: Machine role is 2.
USERENV(22c.91c) 15:58:22:370 PingComputer: Adapter speed 10000000 bps
USERENV(22c.91c) 15:58:22:446 PingComputer: First time: 76
USERENV(22c.91c) 15:58:27:247 PingComputer: Second send failed with 11010
USERENV(22c.91c) 15:58:27:314 PingComputer: First time: 73
USERENV(22c.91c) 15:58:32:496 PingComputer: Second send failed with 11010
USERENV(22c.91c) 15:58:32:563 PingComputer: First time: 73
USERENV(22c.91c) 15:58:37:745 PingComputer: Second send failed with 11010
USERENV(22c.91c) 15:58:37:745 PingComputer: No data available
USERENV(22c.91c) 15:58:37:926 PingComputer: Adapter speed 10000000 bps
USERENV(22c.91c) 15:58:38:003 PingComputer: First time: 75
USERENV(958.95c) 15:58:42:517 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe
USERENV(22c.91c) 15:58:42:994 PingComputer: Second send failed with 11010
USERENV(22c.91c) 15:58:43:070 PingComputer: First time: 77
USERENV(22c.91c) 15:58:48:243 PingComputer: Second send failed with 11010
USERENV(22c.91c) 15:58:48:396 PingComputer: First time: 159
USERENV(22c.91c) 15:58:53:492 PingComputer: Second send failed with 11010
USERENV(22c.91c) 15:58:53:492 PingComputer: No data available
USERENV(22c.91c) 15:58:53:492 ProcessGPOs: DSGetDCName failed with 59.
USERENV(22c.91c) 15:58:53:502 ProcessGPOs: No WMI logging done in this policy cycle.
USERENV(22c.91c) 15:58:53:502 ProcessGPOs: Processing failed with error 59.
USERENV(22c.91c) 15:58:53:502 LeaveCriticalPolicySection: Critical section 0x734 has been released.
USERENV(22c.91c) 15:58:53:512 ProcessGPOs: User Group Policy has been applied.

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:

227260 How a slow link is detected for processing user profiles and Group Policy

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:
322756 How to back up and restore the registry in Windows


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:


USERENV(21c.6f4) 17:09:54:872 ProcessGPOs:
USERENV(21c.6f4) 17:09:54:872 ProcessGPOs:
USERENV(21c.6f4) 17:09:54:872 ProcessGPOs: Starting computer Group Policy (Background) processing...
USERENV(21c.944) 17:09:54:872 ProcessGPOs:
USERENV(21c.944) 17:09:54:882 ProcessGPOs:
USERENV(21c.944) 17:09:54:882 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0
USERENV(21c.944) 17:09:54:882 EnterCriticalPolicySectionEx: User critical section has been claimed. Handle = 0xa4c
USERENV(21c.6f4) 17:09:54:882 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0
USERENV(21c.6f4) 17:09:54:892 EnterCriticalPolicySectionEx: Machine critical section has been claimed. Handle = 0xa44
USERENV(21c.944) 17:09:54:892 EnterCriticalPolicySectionEx: Leaving successfully.
USERENV(21c.944) 17:09:54:902 ProcessGPOs: Machine role is 2.
USERENV(21c.6f4) 17:09:54:892 EnterCriticalPolicySectionEx: Leaving successfully.
USERENV(21c.6f4) 17:09:54:912 ProcessGPOs: Machine role is 2.
USERENV(21c.944) 17:09:54:902 IsSlowLink: Slow link transfer rate is 0. Always download policy.

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:



Cross forest planning mode scenarios are not currently supported

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:
312373 Resultant Set of Policy planning mode is not supported in cross-forest scenarios in Windows Server 2003

References

896683
A user in a trusted external domain cannot log on to a Windows Server 2003-based domain even though the "Allow Cross-Forest User Policy and Roaming User Profiles" Group Policy setting is enabled
823862
User policies are not applied when you log on to a computer that is running Windows 2000 SP4
Propriedades

ID do Artigo: 910206 - Última Revisão: 20 de jun de 2014 - Revisão: 1

Comentários