Repadmin for Experts

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

The previous topics in this guide have looked at how an administrator can use repadmin to view the replication topology (sometimes referred to as Reps-From and Reps-To) as seen from the perspective of each domain controller, monitor forest-wide replication, diagnose replication problems, and perform miscellaneous tasks.

The following sections are used for advanced operations only. These commands have the potential to break your Active Directory installation, and they should be used only under the expert guidance of Microsoft Customer Support Service representative or engineer.

Add, Modify, or Delete replication links

During normal operation, the Knowledge Consistency Checker (KCC) automatically manages the replication topology for each naming context held on domain controllers.

Although in normal practice this should not be necessary, repadmin can be used to manually create the replication topology. This topology would be temporary in nature by default and would last until the next time the KCC is run. So we need to engage these steps only during troubleshooting issues related to Active Directory replication.

Syntax

Repadmin /add <Naming Context> <Dest DC> <Source DC> [/asyncrep] [/syncdisable] [/dsadn:< Source DC DN>] [/transportdn:< Transport DN>] [/mail] [/async] [/readonly]

Repadmin /mod <Naming Context> <Dest DC> <Source GUID> [/readonly] [/srcdsaaddr:< dns address>] [/transportdn:< Transport DN>] [+nbrflagoption] [-nbrflagoption]

Repadmin /delete <Naming Context> <Dest DC> [<Source DC Address>] [/localonly] [/nosource] [/async]

The following table lists the purpose for each of the subcommands.

The following table lists the parameters that can be used with the subcommands.

When you create temporary replication links between replication partners, the process could fail if the KCC starts while you are performing the procedure. The KCC will delete any replication links for which no corresponding connection object exists.

Because these commands can take a very long time to complete as they trigger the replication of the corresponding naming context, it is important to ensure that KCC do not disturb the process. This is where you would use +DISABLE_NTDSCONN_XLATE which effectively disables capability for the KCC to translate connection objects to replication links.

Add, Modify, or Delete outbound replication partners

Similar to inbound replication (Reps-From) partners, outbound replication (Reps-To) partners are instantiated from connection objects by a process called “Connection Translation.”

Both Reps-From and Reps-To attributes are for each partition and they are not replicated. Reps-To is only needed when the destination requires the source to notify him that there is a change in the partition at the source, and the destination should synchronize. Because Reps-To attributes are used for notification, if the destination has a Reps-From marked NO_NOTIFY, then the source will not have a Reps-To.

Depending on the underlying operating system, sometimes you might see outbound partners lingering. While Windows Server 2003 takes care of this, Windows 2000 would need some help cleaning out lingering outbound partners.

Syntax

Repadmin /addrepsto <Naming Context> <DC> <Reps-To DC> <Reps-To DC GUID> Repadmin /updrepsto <Naming Context> <DC> <Reps-To DC> <Reps-To DC GUID> Repadmin /delrepsto <Naming Context> <DC> <Reps-To DC> <Reps-To DC GUID>

The following table lists the purpose for each of the subcommands.

The following table lists the parameters that can be used with the subcommands.

Hosting and unhosting read-only partitions

Hosting and unhosting global catalog partitions is convenient, especially when you want to ensure a faster global catalog removal process. As noted in the following table, these subcommands will also facilitate removal of lingering objects from Active Directory.

Syntax

Repadmin /rehost <DC_LIST> <Naming Context> <Good Source DC Address> [/application] Repadmin /unhost <DC_LIST> <Naming Context> Repadmin /removesources <DC_LIST> <Naming Context>

The following table lists the purpose for each of the subcommands.

The following table lists the parameters that can be used with the subcommands.

Detecting and removing lingering objects

There are multiple methods that are available to detect or remove lingering objects from Active Directory. This depends on the operating system version that the domain controller is running. Repadmin could be used to detect or remove lingering objects from a directory partition when the source and destination domain controllers are running Windows Server 2003 and therefore the scope here is limited to the following:

• Introduction to lingering objects

• Repadmin usage in Windows Server 2003

A lingering object is an object that is present on one replica, but on another replica it has been deleted and removed from the directory by the garbage collection process.

This condition can occur for a variety of reasons including:

• Prolonged misconfigurations (such as those that cause event ID 1311 messages)

• Prolonged errors in name resolution, authentication or the replication engine that block inbound replication.

• Bringing a domain controller online after it has been offline for a period greater than the TombStone Lifetime (TSL).

• Advancing system time or reducing TSL values in an attempt to accelerate garbage collection before end-to-end replication has taken place for all naming contexts in the forest.

Symptoms that you may have lingering objects:

• Active Directory replication is prevented from occurring.

• A user account that no longer exists still appears in the Global Address list for E-mail clients.

• A universal group that no longer exists still appears in a user’s access token.

• E-mail messages cannot be delivered due to duplicate e-mail address on two different user objects.

Regardless of the reason, a deleted object can remain on a domain controller in either of the following circumstances:

• A domain controller goes offline immediately prior to the deletion of an object on another domain controller, and remains offline for a period that exceeds the tombstone lifetime.

• A domain controller goes offline immediately following the deletion of an object on another domain controller but prior to receiving replication of the tombstone, and remains offline for a period that exceeds the tombstone lifetime.

What to do with a lingering object?

Determining what to do with a lingering object depends on whether or not it was intended.

Strict and loose replication consistency

If the attributes of a lingering object never change, the object is never considered for replication. However, if an attribute changes, the attribute is considered for outbound replication. The problem with an attribute update for a lingering object is that the receiving domain controller does not hold the object for the attribute being replicated. An update cannot be performed because the entire object does not exist on the receiving domain controller. What happens next depends on the replication consistency set on the domain controller.

Storage for Consistency Setting

The setting for replication consistency is in the registry on each domain controller.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Entry name: Strict Replication Consistency

Data type: REG_DWORD

Values: 1 for enabled; 0 for disabled

Default: 1 (enabled)

• Value Name: Correct Missing Objects
  
  
• Data type: REG_DWORD
  
  
• Value data: 1
  
  

The repadmin /removelingeringobjects command does the following:

• Designates an up-to-date domain controller as the authority.

• Compares the Active Directory database objects on the authoritative server with the objects that are on the suspected domain controller that contains the lingering objects.

• With /advisory_mode, the subcommand logs the potential deletions to the Directory Service log.

• Without /advisory_mode, the subcommand removes the lingering objects.

Syntax

Repadmin /removelingeringobjects <Dest_DC_LIST> <Source DC GUID> <NC> [/ADVISORY_MODE]

Advanced domain controller options

By using the option subcommand, we could change the options attribute stored on the NTDS Settings Object. The options attribute determines the following behaviors on a domain controller:

• Global catalog installation and removal

• Enable or disable inbound or outbound replication

• Disable connection translation

Note that disabling inbound or outbound replication is specific to the domain controller where you target the operation. So this does not disable intrasite or intersite replication. It just disables Active Directory replication for that domain controller. If the domain controller happens to be the bridgehead server and the Intersite Topology Generator (ISTG) is disabled, then effectively intersite replication to and from that site is disabled.

Syntax

Repadmin /options <DC> [{+|-} IS_GC] [{+|-} DISABLE_INBOUND_REPL] [{+|- DISABLE_OUTBOUND_REPL] [{+|-} DISAB LE_NTDSCONN_XLATE]

+|- turns on or off the associated parameter.

The following table lists the possible values for the options attribute.

The following table lists the purpose for the possible procedures using the options attribute.

Advanced site options

By using the siteoptions subcommand, we could change the options attribute stored on the NTDS Site Settings Object.

Syntax

Repadmin /siteoptions <DC> /site:< Site> [{+|-}IS_AUTO_TOPOLOGY_DISABLED] [{+|-} IS_TOPL_CLEANUP_DISABLED] [{+|-} IS_TOPL_MIN_HOPS_DISABLED] [{+|-} IS_TOPL_DETECT_STALE_DISABLED] [{+|-} IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED] [{+|-} IS_GROUP_CACHING_ENABLED] [{+|-} FORCE_KCC_WHISTLER_BEHAVIOR] [{+|-} FORCE_KCC_W2K_ELECTION] [{+|-} IS_RAND_BH_SELECTION_DISABLED] [{+|-} IS_SCHEDULE_HASHING_ENABLED] [{+|-} IS_REDUNDANT_SERVER_TOPOLOGY_ENABLED]

Miscellaneous

The following table lists nbrflagoptions.