Sign in
 
HomeWindows Server “8” Beta20082003LibraryForums
Windows Server TechCenter > Windows Server Forums > Directory Services > Group Policy Error 1006 on new 2008 DC to a 2003 domain

Answered Group Policy Error 1006 on new 2008 DC to a 2003 domain

    •  
      Friday, March 28, 2008 10:14 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      I have just pulled a vanilla Windows Server 2008 into my Windows Server 2003 domain. The server is happy until I promote it to a Domain Controller. Then I get the following error message regarding Group Policy:

       

      "The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description."

       

      I can't find much info on technet regarding this. The Event Id is 1006, however the listed bunch of Error Code's doesn't include the one I'm getting which is 82 / Local Error.

       

      I tried to push on with DNS and DHCP and things just got worse. So I've started again and figured not to just proceed until I can iron out this one Error code. Could it be encryption, some form of authentication issue between 2008 and 2003?

       

      I'm completely lost and there's really not much info out there...

       

    Answers

    • Tuesday, April 01, 2008 7:00 AM
      Moderator
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote

       

      Hello,

       

      From your description, the Event 1006 with error code 82 is logged on your newly promoted Windows Server 2008 DC.

       

      Based on my research, ldap bind error <82> tranlates to LDAP_LOCAL_ERROR, a very generic error. It is returned from the server for a generic substitute of "unknown error" on the DC.

       

      To narrow down the issue, please answer the following questions:

       

      1. How many DCs in the Windows Server 2003 domain? If there are more than 2 DCs in the original domain, is also Event 1006 is logged on them?
      2. How often the Event 1006 is logged? They are logged in separate little ones or repeated ones with a time interval (5min).
      3. Is there any Group Policy related error events logged?

       

      This problem may occur when all the ephemeral ports 1025-5000 are in use on the DC. When the Event 1006 is newly logged in Windows Server 2008 DC, run 'netstat -ano' immediately on the Windows Server 2003 DC to check whether all ephemeral ports (TCP: 1025-5000) are occupied by other processes. If so, please perform the following steps to maximize the ephemeral ports and reduce the TcpTimedWaitDelay number:

       

      a. MaxUserPort (set to 65000)
      http://technet2.microsoft.com/WindowsServer/en/library/730fb465-d402-4853-bacc-16ba78e9fcc01033.mspx?mfr=true

      1. Start Registry Editor.
      2. Locate the following subkey in the registry, and then click Parameters:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
      3. On the Edit menu, click New, and then add the following registry entry:
      Value Name: MaxUserPort
      Value Type: DWORD
      Value data: 65000 (decimal)
      Description: This parameter controls the maximum port number that is used when a
      program requests any available user port from the system. Typically, ephemeral
      (short-lived) ports are allocated between the values of 1024 and 5000 inclusive.

      4. Quit Registry Editor.


      b) TcpTimedWaitDelay (set to 30)
      http://technet2.microsoft.com/WindowsServer/en/library/38b8bf76-b7d3-473c-84e8-e657c0c619d11033.mspx?pf=true


      Reducing this value from its default setting of 240 seconds will make ports expire sooner. This parameter determines the length of time that a connection stays in the TIME_WAIT state when it is being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be reused.

      1. Start Registry Editor
      2. Locate the following subkey in the registry, and then click Parameters: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
      3. On the Edit menu, click New, and then add the following registry entry:
      Value Name: TcpTimedWaitDelay
      Value Type: DWORD
      Value data: 30 (decimal)
      4. Quit Registry Editor.

       

       

      Hope this will helps.

       
    • Tuesday, June 24, 2008 12:16 PM
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote
      hi,

      We had the same issue but could solve the problem with help from MS-Support!
      The problem appears if you once did an authoritative restore of your AD - so the msDS-KeyVersionNumber property from the userobject "KRBTGT" was increased.
      KB939820  (http://support.microsoft.com//kb/939820) addresses the same authentication problem! (the kb article describes authentication problems with rdp.....)

      after installing the hotfix to all our windows 2003 dc´s the problem was fixed!

      Wulf
       

    All Replies

    • Monday, March 31, 2008 1:19 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Whilst I cannot offer you a solution, I can confirm that you are not alone.  I have exactly the same issue.  Along with this error, the DC will not function correctly, seems OK just after promotion, but then starts to register replication problems.

       

      Strangely, if you stop the KDC service on the W2008 DC box and try GPUPDATE, I think you will find it works, although with KDC stopped, it isn't a great deal of use as a DC>

       

      I have a case open with MS support at the moment and will try to let you know how I get on.

       

      Neil.

       

       
    • Tuesday, April 01, 2008 7:00 AM
      Moderator
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote

       

      Hello,

       

      From your description, the Event 1006 with error code 82 is logged on your newly promoted Windows Server 2008 DC.

       

      Based on my research, ldap bind error <82> tranlates to LDAP_LOCAL_ERROR, a very generic error. It is returned from the server for a generic substitute of "unknown error" on the DC.

       

      To narrow down the issue, please answer the following questions:

       

      1. How many DCs in the Windows Server 2003 domain? If there are more than 2 DCs in the original domain, is also Event 1006 is logged on them?
      2. How often the Event 1006 is logged? They are logged in separate little ones or repeated ones with a time interval (5min).
      3. Is there any Group Policy related error events logged?

       

      This problem may occur when all the ephemeral ports 1025-5000 are in use on the DC. When the Event 1006 is newly logged in Windows Server 2008 DC, run 'netstat -ano' immediately on the Windows Server 2003 DC to check whether all ephemeral ports (TCP: 1025-5000) are occupied by other processes. If so, please perform the following steps to maximize the ephemeral ports and reduce the TcpTimedWaitDelay number:

       

      a. MaxUserPort (set to 65000)
      http://technet2.microsoft.com/WindowsServer/en/library/730fb465-d402-4853-bacc-16ba78e9fcc01033.mspx?mfr=true

      1. Start Registry Editor.
      2. Locate the following subkey in the registry, and then click Parameters:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
      3. On the Edit menu, click New, and then add the following registry entry:
      Value Name: MaxUserPort
      Value Type: DWORD
      Value data: 65000 (decimal)
      Description: This parameter controls the maximum port number that is used when a
      program requests any available user port from the system. Typically, ephemeral
      (short-lived) ports are allocated between the values of 1024 and 5000 inclusive.

      4. Quit Registry Editor.


      b) TcpTimedWaitDelay (set to 30)
      http://technet2.microsoft.com/WindowsServer/en/library/38b8bf76-b7d3-473c-84e8-e657c0c619d11033.mspx?pf=true


      Reducing this value from its default setting of 240 seconds will make ports expire sooner. This parameter determines the length of time that a connection stays in the TIME_WAIT state when it is being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be reused.

      1. Start Registry Editor
      2. Locate the following subkey in the registry, and then click Parameters: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
      3. On the Edit menu, click New, and then add the following registry entry:
      Value Name: TcpTimedWaitDelay
      Value Type: DWORD
      Value data: 30 (decimal)
      4. Quit Registry Editor.

       

       

      Hope this will helps.

       
    • Tuesday, April 01, 2008 8:50 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      Hi,

      Thanks for your replies. To answer your initial questions;

      1. There are two 2003 DC's in the domain - the 1006 errors are solely on the new 2008 NC
      2. The 1006 event is logged roughly every 5 minutes. However, I can prompt the error to appear at anytime by running gpupdate. The really wierd thing is after about 9 hours (overnight) the errors stop and even a gpupdate claims everything is fine, but once rebooted everything returns to the usual pattern of errors
      3. The 1006 event is a Group Policy error. The only other info I'm getting is a warning on LsaSrv, ID 40961 although I've gone through a bunch of possible fixes for this, none of which have helped.
      So, I ran a gpupdate to prompt the server into giving the errors and ran 'netstat -ano' as you suggested. The ports weren't full but they were certainly busy. I decided to run those fixes anyway to give more ports. Do I need to reboot the server for that to take effect? I rebooted the 2008 DC but no change, however I can only bring the main 2003 DC domain down overnight so if that's the case it'll have to wait til then.

      Thanks for you help and efforts on this so far.

      regards
      David

       
    • Thursday, April 03, 2008 12:21 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      Also thanks Neil,

      I can confirm we must have pretty much the same issue. If I stop KDC and run gpupdate everything pings up fine. However a reboot obviously returns things to this frustrating status quo. I get a chance to reboot the 2003 DC's tonight to see if Miles' registry edits have done anything.

      cheers
      David
       
    • Tuesday, June 24, 2008 12:16 PM
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote
      hi,

      We had the same issue but could solve the problem with help from MS-Support!
      The problem appears if you once did an authoritative restore of your AD - so the msDS-KeyVersionNumber property from the userobject "KRBTGT" was increased.
      KB939820  (http://support.microsoft.com//kb/939820) addresses the same authentication problem! (the kb article describes authentication problems with rdp.....)

      after installing the hotfix to all our windows 2003 dc´s the problem was fixed!

      Wulf
       
    • Wednesday, June 25, 2008 1:52 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      Guys,

      I can confirm that Wulf is correct.  We also got resolution from MS Support 2-3 days ago with the same fix as described and it does work perfectly. 

      Neil.
       
    • Wednesday, March 09, 2011 9:39 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Hi,

      Just to confirm as Wolfgang suggested I have installed KB939820 on all 2003 DCs and problem is solved. I have 4 - 2003 R2  and 2 - 2008 R2, few month ago we have performed authorative restore and since then I noticed gpo processing problem on the servers and clients as well.

      After you install KB you have to restart DC.

      Regards.

       
    • Thursday, July 21, 2011 10:59 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Hey Mladen, thanks for you info, as i am having the same problems here, just to be safe: the hotfix also works for 2003 R2 ??

       

      Kind regards,

      markus