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

Enable Inbound, Disable Outbound

Enable Outbound, Disable Inbound

Disable Inbound and Outbound

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
Current DC Options: IS_GC 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
New DC Options: IS_GC DISABLE_INBOUND_REPL

Disable replication, inbound and outbound:

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

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 hpqboxDC01.hpqbox.adapps.hp.com
Current DC Options: IS_GC
repadmin running command /options against server HPQBOXDC03.hpqbox.adapps.hp.com
Current DC Options: IS_GC DISABLE_INBOUND_REPL
repadmin running command /options against server HPQBOXDC04.hpqbox.adapps.hp.com
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.
ABOUT THE AUTHOR
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.