Advanced Group Policy Management Client takes a long time to start or refresh


Consider the following scenario:

You are running a Windows Server 2003 Domain with a Windows Server 2008 R2 or Windows 7 member. You are doing this because you want to run the Group Policy Management tools in the most recent version. In addition to the tools you also install Advanced Group Policy Management (AGPM) version 4.0 so you also have the administrative roles and the change management process the component offers.

The domain has many domain controllers, where quite a number of them are only accessible across slow links or traffic is blocked on the firewall.

When you start the AGPM client in this configuration, you may encounter excessive startup times and slow refresh. When you take a network monitor trace during startup, you see that the administrative stations contacts each Domain Controller in the domain and tries to send a UDP/389 LDAP request to it. On startup, it tries to contact each domain controller at least once.

When you look at the internal error code you see:


When you enable netlogon logging according to Microsoft KB article 109626, you will see many entries similar to:

03/03 13:07:04 [MISC] DsGetDcName function called: Dom:<domain> Acct:(null) Flags: IP KDC Longhorn_DC

03/03 13:07:04 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1

03/03 13:07:04 [MAILSLOT] NetpDcPingListIp: CORP.INGOS.RU: Sent UDP ping to <IP address>

03/03 13:07:04 [CRITICAL] NetpDcMatchResponse: <DC name>: <domain>: response not from a longhorn dc. 0x1fc

"Longhorn_DC" implies the caller is specifically asking for a Windows Server 2008 or Windows Server 2008 R2 Domain Controller.


The issue in this article is an effect of the following issue:

939820 Events 1925, 1006, 1645, 1055, 40961 on a Windows Server 2008-based domain controller or error message: "No authority could be contacted for authentication" when you use Remote Desktop Connection;EN-US;939820

The AGPM client tries to find the effective permissions using AuthZ APIs on each account present in the delegation list of the current policy. To perform this task, AuthZ does a Kerberos S4U2Self request. When the Kerberos client tries to find a Key Distribution Center (KDC) for this request, it will search for Windows Server 2008 or newer domain controller. This is the result of the issue described in Microsoft KB article 939820.

When the Kerberos client fails finding a Domain Controller, the AuthZ API reverts to a reverse LDAP query method to find the group membership of the user in question. This is slower than the Kerberos S4U2Self method.


To resolve the problem, deploy the hotfix from Microsoft KB article 939820 to all Windows Server 2003 Domain Controllers of your domain. Start with the Domain Controllers in the site of your Administrative stations.

There are multiple approaches to avoid this problem:

1. Use DnsAvoidRegisterRecords to reduce the number of Domain Controllers the member walks during the failing search. For details see Microsoft KB:

306602 How to optimize the location of a domain controller or global catalog that resides outside of a client's site;EN-US;306602

2. Use AGPM 2.5 to manage group policies in Windows Server 2003 domains. Due to the newer Group Policy settings available with newer versions of the policy editor this may not be an attractive option.

3. Reduce the number of users having direct permissions on the policy. This reduces the number of attempts finding uplevel domain controllers.

4. You can skip the attempt to use Kerberos S4U2Self by telling AuthZ to immediately use the LDAP query method. Please use UseGroupRecursion=1 as described in article:

933071  The "Effective Permissions" tab may report incorrect permissions in Windows Server 2003;EN-US;933071