Problem solve Get help with specific problems with your technologies, process and projects.

Solving Active Directory replication failure

Every now and then, admins are faced with unintentional replication failure. While fixing the error is critical, knowing how to find the cause of the failure can be just as important.

Not long ago a systems administrator approached me about a situation where replication had been reported in DCDiag...

as disabled. He resolved it by using RepAdmin to enable replication again: .

Repadmin /options –DISABLE_INBOUND_REPL
Repadmin /options –DISABLE_OUTBOUND_REPL

Despite the fix, however, the admin still wanted to know how replication became disabled in the first place. He believed something -- rather than someone -- was responsible and wanted to get to the bottom of it. In this article, we'll look at ways administrators can find the cause of disabled replication.

Using RepAdmin /Options

The obvious reason for replication being disabled is that someone used the RepAdmin command to disable inbound and/or outbound replication (and that person may not want to admit to the oversight).

Replication is controlled by the Options attribute on the NTDS Settings object as shown in the following table. The Options attribute value is found in ADSIEdit by browsing to Configuration → Sites → <Site Name> → Servers - <Server Name> → NTDS Settings.

  RepAdmin Option NTDS Settings/Options attribute value
  Enable Inbound and Outbound 1
  Enable Inbound, Disable Outbound 5
  Enable Outbound, Disable Inbound 3
  Disable Inbound and Outbound 7

Here is what it looks like when you disable or enable replication via RepAdmin using the /Options switch. Note that the minus (-) character in front of the option indicates a negative disable or enable. To disable these values, use the plus (+) sign: +DISABLE_INBOUND_REPLICATION, for example.

Enable both inbound and outbound replication:

C:\>repadmin /options wtec-dc1
Current DC Options: IS_GC

Disable replication, outbound only:

C:\>repadmin /options wtec-dc1 -disable_outbound_repl
New DC Options: IS_GC

Disable replication, inbound only:

C:\>repadmin /options wtec-dc1 +disable_inbound_repl
Current DC Options: IS_GC

Disable replication, inbound and outbound:

C:\>repadmin /options wtec-dc1 +disable_outbound_repl +disable_inbound_repl
Current DC Options: IS_GC
CAUTION: These commands remain in effect until changed. That is, if you turn on the Disable inbound repl feature, it will remain on (i.e., inbound replication is disabled) until you enable it again using the –disable_inbound_repl command).

There are several reasons why you would want to do this. One reason would be if a report such as RepAdmin /replsum /bysrc /bydest /sort:delta shows that replication has not happened in the past 60 days (tombstone lifetime). Then you would want to disable outbound replication. Of course, if you have strict replication enabled you will be OK, but it's better to be safe than sorry in this instance.

The RepAdmin command is quick and easy. Note that in this case there is really no need to disable inbound replication since the danger is in replicating outbound. Still, I suggest that you play it safe and do both until you determine the existence of lingering objects.

In addition, if you suspect corruption or issues with a domain controller that you don't want replicated, this command is an easy way to prevent replication from that source. Remember, you can remotely execute RepAdmin. And the DCList option in RepAdmin can be used to specify a single DC, or an asterisk (*) can be used to specify all DCs.

Authoritative Restore and lag sites

Authoritative restoration is used to move the Active Directory back in time by taking a singe system state backup from an earlier date, stopping replication on a DC, then restoring the backup using NTDSUtil's Authoritative Restore feature.

When it boots into normal mode and replication is enabled (using RepAdmin), this copy of the Active Directory is pushed out as authoritative and all DCs get a copy. Since you typically want to at least disable inbound replication before starting this -- and then enable it again -- it's easy to forget after the restore that you need to re-enable replication.

Lag sites can be another cause for replication failure. Lag sites are scheduled to replicate only once or twice per week to provide a sort of online backup for a quick authoritative restore.

In case of a disaster recovery situation, such as deleting an OU, it's important to disable replication on the lag site DC(s). Some prefer to simply keep replication disabled on the lag DC(s) and manually re-enable it when they want replication. Again, it's easy to forget that it was purposely disabled. You can view the status of the replication options for all DCs in the forest via RepAdmin as shown below. Note that DC01 and DC04 show only the IS_GC option set. However, DC03 shows that DISABLE_INBOUND_REPL is also set.

Repadmin /Options *

repadmin running command /options against server hpqbox-

Current DC Options: IS_GC

repadmin running command /options against server HPQBOX-


repadmin running command /options against server HPQBOX-

Current DC Options: IS_GC

So, the RepAdmin /Options command will list all the options set, and among those options are whether DISABLE_INBOUND_REPL and DISABLE_OUTBOUND_REPL are enabled. If those options do not show up, then they are enabled. If you suspect that replication has been disabled, or if you see events or DCDiag reports stating it's disabled, then produce a quick report using RepAdmin /Options * to determine if any other DCs have replication purposely disabled.

In the case of the admin who claimed that replication stopped without someone specifically disabling it, an updated sequence number (USN) rollback could cause replication to be disabled on a DC if it is done improperly.

USN rollback is quite a complex issue, and in an upcoming article, I will explain exactly how a USN rollback could stop replication without your knowing it.

For more information about resolving issues with AD, visit our Active directory troubleshooting topic page.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.

Dig Deeper on Windows systems and network management