Adroitly Sidestepping Initial Synchronization Requirements

[Alex Simons (AZURE)]

First published on CloudBlogs on Apr, 29 2007

One of my pet peeves is when I don’t recall every detail of a troubleshooting step or technique and can’t immediately find a document that explains it.   It’s like when I misplace a book I’ve been reading-I wander around the house in circles looking for it until I find it.  It’s maddening.

Case in point:  Active Directory Initial Synchronization Requirements.

AD Init Sync is normally a great feature.  Basically, it places a requirement on a domain controller which holds Flexible Single Master Operations (FSMO) roles, as it comes back up from being rebooted, to have successful AD replication (inbound and outbound) with its known replica partners before it advertises itself as domain controller and starts providing services to clients.  Those clients can be users, computers or other domain controllers.

A great deal more about this feature is here: http://support.microsoft.com/kb/305476

This is a good thing since you want a domain controller that holds one or more FSMO roles to know that it may not hold that role any longer.  It would be notified via AD replication (if the change happens while this DC is offline or otherwise not in contact) of FSMO holder changes.  So the initial sync requirement before advertising is very, very helpful.  If you have ever had a Windows 2000 domain controller which believes it hold FMSO roles turned back on following a FSMO seizure to another domain controller then you may have a more poignant understanding of how helpful the init sync is.

But when you test you may not want to run into the init sync.  For example, as a support person I am constantly (it feels) creating and tearing down test environments.  I typically use Virtual Server or Virtual PCs, but it’s still time intensive and I don’t always recall what the last horrible thing I did to a particular test environment was.  Makes life exciting, in a way.

The other day, though, I was resurrecting a test DC only to find that, though it held the FSMO roles, I had not taken the time to remove references to some other test domain controllers from the remaining DCs directory.  So the remaining DC thought it needed to sync with the removed DCs before it could advertise the roles and services it offered out to the world.

How would I know such a thing?  Well, it was a reasonable assumption based on the DCDIAG.EXE result and KnowsofRoleHolders tests (taken as a DCDIAG /V).  Here’s what they looked like with the problem:

Domain Controller Diagnosis

Performing initial setup:

* Verifying that the local machine tspringdc1, is a DC.

* Connecting to directory service on server tspringdc1.

The directory service on tspringdc1 has not finished initializing.

In order for the directory service to consider itself synchronized, it must attempt an initial synchronization with at least one replica of this server's writeable domain.  It must also obtain Rid information from the Rid FSMO holder.

The directory service has not signalled the event which lets other services know that it is ready to accept requests. Services such as the Key  Distribution Center, Intersite Messaging Service, and NetLogon will not  consider this system as an eligible domain controller.

* Collecting site info.

* Identifying all servers.

The directory service on tspringdc1 has not finished initializing.  In order for the directory service to consider itself synchronized, it must attempt an initial synchronization with at least one replica of this server's writeable domain.  It must also obtain Rid information from the Rid FSMO holder.

The directory service has not signalled the event which lets other services know that it is ready to accept requests. Services such as the Key Distribution Center, Intersite Messaging Service, and NetLogon will not consider this system as an eligible domain controller.

* Identifying all NC cross-refs.

* Found 14 DC(s). Testing 1 of them.

Done gathering initial info.

Starting test: FsmoCheck

Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355

A Global Catalog Server could not be located - All GC's are down.

Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355

A Primary Domain Controller could not be located.

The server holding the PDC role is down.

Warning: DcGetDcName(TIME_SERVER) call failed, error 1355

A Time Server could not be located.

The server holding the PDC role is down.

Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1355

A Good Time Server could not be located.

Warning: DcGetDcName(KDC_REQUIRED) call failed, error 1355

A KDC could not be located - All the KDCs are down.

......................... tspringtest.com failed test FsmoCheck

…and here’s what a good one looks like:

<no initial error regarding init sync>

Starting test: FsmoCheck

GC Name: \TSPRINGDC1.tspringtest.com

Locator Flags: 0xe00003fd

PDC Name: \TSPRINGDC1.tspringtest.com

Locator Flags: 0xe00003fd

Time Server Name: \TSPRINGDC1.tspringtest.com

Locator Flags: 0xe00003fd

Preferred Time Server Name: \TSPRINGDC1.tspringtest.com

Locator Flags: 0xe00003fd

KDC Name: \TSPRINGDC1.tspringtest.com

Locator Flags: 0xe00003fd

......................... tspringtest.com passed test FsmoCheck

So, do you live with it as is? Are you forced to right whatever is wrong?  In my test environment case that would have meant that I would need to remove all references to removed DCs from DNS and AD.  That’s documented well in the trusty mainstay article:

How to remove data in Active Directory after an unsuccessful domain controller demotion

http://support.microsoft.com/default.aspx/kb/216498

What do you do if you are in a situation like mine- a test environment – and you need the DC online quickly and don’t want to go through the tedium of cleaning up the environment when you may tear it all down soon anyway?  Or, in a unique situation where you have lost the WAN link a FSMO role holders replica partners but you need that DC to do its job without waiting for the initial synchronization with those partners?

Well I’m glad you asked.

Add the registry value below and reboot the DC in question.  When it comes back up, it will not require the init sync before successfully advertising itself and doing its job.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters]

"Repl Perform Initial Synchronizations"=dword:00000000

For the above entry, 1 means “do it” while 0 means “do not do it”.

Written from lovely Quebec City, Canada.    Until next time folks, take care out there in the wild forest of DCs you wander through.