They both need netlogon? I was recently approached by our security team to assist on some odd issue where a 2003 Domain Controller could not process Windows Updates.
The WU scan would simply hang there.
The WU log showed:
2006-08-22 19:00:35 4896 1288 AUClnt FATAL: Error: 0x8007000e. wuauclt handler: failed to spawn COM server
The security engineer debugged it down to where COM was failing on CoCreateInstance, part of this process was calling an API which tries to get the RID for the machine account. It was calling over to netlogon – which happens to be in my area, so he called me up to look at it.
The interesting thing is, at this point I failed to look at the first thing I should have looked at. The event logs. How many times do we forget to look in the obvious places?
So, into the debugger I jumped. Foolish.
It didn’t take long to determine what was going on. Netlogon holds some global information about the DC’s role, is it a PDC,BDC, does it host NDNC’s etc..
Well if it is all messed up, it says that the role is invalid, which is what it was in this case.
How did it get that way?
When netlogon initializes it goes through the process of creating the domain. You can see this in the netlogon logs of any DC.
One of its tests, is to make a call to the SAM API’s and determine its role – is it the PDC?
Yes, it was, so it fills in the role as PDC.
Next, make sure it’s the ONLY PDC. A simple call to dsgetdcname DS_PDC_REQUIRED | DS_AVOID_SELF is used. It should return failure, but in this case it returned success so netlogon goes into a state of panic and rubs out the role value altogether setting it to invalid.
Well – the original call to the NetAPI for the RID would then fail with eax=0000054b
# for hex 0x54b / decimal 1355 :
# The specified domain either does not exist or could not be
# 1 matches found for "0000054b"
And the COM server fails, so Windows update fails.
All of which may have been determined ( possibly ) via a glance in the evt logs:
Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 3097
Time: 11:20:31 AM
This computer is configured to be the primary domain controller of its domain. However, the computer FAKEPDC is currently claiming to be the primary domain controller of the domain.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp
I guess my excuse could be - how in the world would you connect a failure to determine the PDC role to a failure in Windows update?? J That’s my excuse and I’m sticking to it.
I doubt this will really help anyone - it *might* and if it does - I'd be really interested since I thought this was a really, really obscure scenario.
BTW - the reason the \\FAKEDC machine was being found as a duplicate PDC, was because it was registering the 1b and 1c records in WINS for the same domain - it was a Mac machine ( never did find out why it was doing this )
Thank you for posting this explanation. I knew we had an OS X server acting as a PDC and that it was causing issues, but had no clue that it would be tied into windows update! I demoted the OS X server to a standard server and viola everything is working wonderfully!