Adroitly Sidestepping Initial Synchronization Requirements

Adroitly Sidestepping Initial Synchronization Requirements

  • Comments 2
  • Likes

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_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]

"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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Does this work on W2k AD?  I tried (on W2k AD) and it didn't do anything.  I still had to use REPADMIN /DELETE the inbound repl connections for the local domain of the DC before the RID master would initialize.  Thx.

  • Le rédémarrage d'un contrôleur de domaine Windows peut nécessiter une très longue durée. Cela peut prendre