Wednesday, July 16, 2008

New Child Domain: Stupid Error

Here is one of those smack-the-forehead-Im-so-stupid errors.

Youre setting up a new child domain in your Active Directory (AD) infrastructure and while running the DCPromo wizard, you cant complete the promotion because you get Access Denied (5) when it tries to replicate the schema partition.

On the system youre trying to promote, you open the event log for the Directory Service, and you see three errors:

Event ID: 1168

Source:     NTDS General

Category:  Internal Processing

Event ID: 1125

Source:     NTDS General

Category:  Setup

Description:

     The Active Directory Installation Wizard (DCPromo) was unable to establish connection with the following domain controller.

     Domain controller:

             Mynewdc.subdom.dom

 

     Additional Data

     Error value:

     5 Access is denied.

Event ID: 1168

Source:     NTDS General

Category:  Internal Processing

In the dcpromo log (%windir%\debug\dcpromoui.log)  you also see access is denied when it tried to replicate the schema partition.

If you check the domain controller (DC) holding the domain role (the FSMO role: domain role owner) in the root domain  you will find corresponding Kerberos errorsdue to time synchronization.

DUH.

If youre like us, you did not join the server to any domain before running DCPromo becausewhat would be the point?  The new child domain doesnt exist yet.

But if its not a member of a domain yet, it cant pull time from the PDC-emulator role holder in its domain.  And you probably havent bothered to configure the time source on it because that will change as soon as it IS a DC and youll go to NT5DS to grab your time from your domain structure.

In our case, we set the time zone (correctly) and the time *looked* correct, until I realized it was set for AM instead of PM.  Not to mention, the day/date was WRONG.  DUH-Ditto.

Simple problem, simple fix.  So simple that I found it was completely NOT documented anywhere accessible to google searches.  And the real trick was remembering to check the event log on the domain role holder in the root domain.  Who would have thought that the defining event explaining all the answers would be on that system?

Well, really, I should have guess that to begin with and saved myself a lot of head-scratching.

So there you are.  A blindingly simple answer to a weird problem.

No comments: