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.

Note

During the normal course of operations, there is no requirement for manual creation of the replication topology. Incorrect use of this tool may adversely impact the replication topology.

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.

Subcommand	Purpose
add	The add command will create a RepsFrom attribute on the destination domain controller for the specified naming context and initiate a replication request. During a normal replication cycle, the destination domain controller will request updates from the source domain controller.
mod	The mod command will modify the RepsFrom attribute on the destination domain controller for the specified naming context and initiate a replication request. During a normal replication cycle, the destination domain controller will request updates from the source domain controller.
delete	The delete command will remove a RepsFrom attribute on the destination domain controller for the specified naming context.

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

Parameter	Description
<Naming Context>	Specifies the distinguished name of the directory partition.
<Dest DC>	Domain controller to which the link is created.
<Source DC>	Domain controller from which to source the partition.
asyncrep	Queue the replication event, but do not wait for the replication to complete before you return control to the user.
syncdisable	Add the RepsFrom attribute but do not participate in the replication cycle. To perform replication between the destination and source domain controllers, repadmin /sync /force must be used.
/dsadn:<<Source DC DN>
transportdn	The distinguished name of the Inter Site Message transport, only used for mail-based replication.
mail	specify that the replication is mail-based, therefore requires the /transportdn option.
async	Queue the add/delete operation without interrupting the current replication cycle and return control to the user.
readonly	Specify that the partition is read-only.
/srcdsaaddr:<dns address>
nbrflagoption
localonly	Do not delete the corresponding RepsTo attribute on the source Directory System Agent (DSA).
nosource	When you remove a read-only naming context such as the global catalog, the associated data stored in the directory is removed in blocks of 500 objects. This allows the /delete command to be re-executed without having to specify the Source DSA to remove the remaining objects.

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.

Subcommand	Purpose
addrepsto	This will create a Reps-To attribute on the domain controller for the specified naming context. Ordinarily there is no requirement to perform this command as the KCC will automatically create the Reps-To attributes on destination DSAs based on other DSAs Reps-From entries.
updrepsto	This will update the Reps-To attribute on the domain controller for the specified naming context. More specifically it updates the network address used by the source DSA to contact the destination DSA.
delrepsto	Delrepsto deletes the Reps-To attribute on the domain controller for the specified naming context.

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

Parameter	Description
<Naming Context>	Specifies the distinguished name of the directory partition.
<DC>	The domain controller on which the Reps-To attribute is modified.
<Reps-To DC>	Outbound replication partner.
<Reps-To DC GUID>	DSA globally unique identifier (GUID) of outbound replication partner.

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.

Global catalog removal process

In Windows 2000 versions earlier than Service Pack 4 (SP4), when the IS_GC bit is turned off, the KCC deletes the read-only objects at a rate of only 500 for each time the KCC runs, which allows a maximum of 2000 object removals for each hour. This presents some challenges in large environments. In order to make the global catalog removal faster, you could potentially remove one partition at a time by using the unhost subcommand.

Lingering Objects

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. When lingering object exists only in one or more read-only naming contexts (global catalog), it makes it all the more difficult to delete the object. Clearing the IS_GC bit may not always be appropriate, because it removes all read-only naming contexts from the global catalog server. Unhosting and rehosting a read-only naming context is therefore sometimes considered to be a good solution, especially because you could specify the source to be a good replica that does not contain lingering objects.

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.

Subcommand	Purpose
rehost	Add a specific read-only partition to a global catalog server.
unhost	Remove a specific read-only partition from a global catalog server.
removesources	Removes all replication links for a given naming context. This does not delete the connection objects, so the KCC will build new links on it regular cycle as required.

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

Parameter	Description
<DC_LIST>	Specifies the host name of a domain controller or a list of domain controllers separated by a space that the object will be replicated to. For details about <DC_LIST>, see repadmin /listhelp.
<Naming Context>	Specifies the distinguished name of the directory partition.
<Good Source DC Address>	Specify the source domain controller.
/application	Application directory partition

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.

Action	Explanation
Unintended	Use repadmin to delete the lingering object on a domain controller that is running Windows Server 2003.
Intended	Change the replication consistency on the inbound domain controller (DC). The object will be re-animated on this DC. See strict and loose replication consistency below

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.

Replication consistency	Explanation
Loose	When replication consistency is set to loose, the receiving domain controller detects that it does not have the object for the attribute that is being replicated. The inbound partner requests the entire object from the outbound partner, and reanimates the object on its copy of the directory. The same process repeats on all domain controllers that do not have a copy of the object. This mechanism can be used to cause lingering objects to “reanimate” across the entire forest. If a lingering object is discovered and its presence is intended, then perform any update to the object. As long as replication consistency is set to loose on all domain controllers, the object will be reanimated as it replicates around the forest. “Loose replication consistency” is the default for Windows 2000 domain controllers, with the exception of domain controllers that have the MS01-044 security rollup package installed. For more information about the MS01-044 security rollup package, see article 297860 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=122508).
Strict	The default behavior for domain controllers that run Windows Server 2003 (and domain controllers that are upgraded from Windows NT 4.0) is to block inbound replication for each naming context when a domain controller receives an update to an object that it does not have. Replication is halted in the naming context for the object until the lingering object is removed or the replication mode is set to “loose.”

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)

Note

There was a post-SP2 hotfix (also included in the security rollup package from November 2001) that used a different registry value. A setting of 0 will not recreate the missing object (strict), and a setting of 1 will create the missing object. This value is only needed with the November version of the hotfix.

• 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]

Parameter	Description
<Dest_DC_LIST>	The domain controller that is suspected to have lingering objects.
<Source DC GUID>	Source domain controller GUID used to compare with the suspected domain controller.
<NC>	Specifies the distinguished name of the directory partition.
/ADVISORY_MODE	Read-only mode.

Note

During lingering object removal, Event ID 1937 is logged to the Directory Service log. This information includes the source domain controller, the objects that are removed, and a total count of all the objects that are removed.

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.

Parameter	Description
<DC>	Domain controller
IS_GC	DSA is a global catalog server.
DISABLE_INBOUND_REPL	Disables inbound replication.
DISABLE_OUTBOUND_REPL	Disables outbound replication.
DISAB LE_NTDSCONN_XLATE	Turns off the capability of the KCC to translate connection objects to replication links.

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

Value	Description
1	Global catalog server
2	Disable inbound replication
3	2 + 1
4	Disable outbound replication
5	4 + 1
6	4 + 2
7	4 + 2 + 1
8	Disable connection translation

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

Procedure	Purpose
Disable Outbound Replication	Use this procedure to disable Active Directory replication from a domain controller. The domain controller continues to receive inbound replication. Repadmin /options<ServerName>+disable_outbound_repl where <ServerName> is the name of the domain controller on which you want to disable outbound replication. The tool reports the current options (the options that were in effect prior to pressing ENTER) and the new options (all options that are in effect after pressing ENTER).
Disable inbound Replication	Similar to the above step you could disable inbound replication to a server as well. repadmin /options<ServerName>+disable_inbound_repl
Disable the ability of the KCC to translate connection objects.	When creating temporary replication links between replication partners, the process could fail if the KCC starts while you perform the procedure. The KCC will delete any replication links for which no corresponding connection object exists.

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]

Parameter	Description
<DC>	Domain controller
site: <Site>	Site name where the domain controller resides
IS_AUTO_TOPOLOGY_DISABLED	Disables the automatic generation of intra-site topology.
IS_TOPL_CLEANUP_DISABLED	Disables the cleanup or unneeded connection objects and replication links.
IS_TOPL_MIN_HOPS_DISABLED	Disables the KCC rule that all intrasite replication partners should be no more than three hops from any other partner.
IS_TOPL_DETECT_STALE_DISABLED	Disables the detection by the KCC of failing replication links and the behavior of the KCC to route around failing links. Use this with the KCC Branch Office mode.
IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED	Disables the automatic generation of the intersite topology. Commonly used for creating manual connections, either by hand or with MKDSX.
IS_GROUP_CACHING_ENABLED	Enables group caching for use with “no-GC logon.” This setting is also exposed in the UI of Active Directory Sites and Services.
FORCE_KCC_WHISTLER_BEHAVIOR	Forces the KCC to operate using the new spanning tree algorithm. It’s not recommended to manually change this setting. The recommended alternative is to raise the forest functional level to Windows Server 2003.
FORCE_KCC_W2K_ELECTION	Forces the Windows 2000 domain controller ISTG election logic. The default is for any Windows Server 2003 domain controller to assume the ISTG role.
IS_RAND_BH_SELECTION_DISABLED	Disables the new random bridgehead selection behavior. Reverts to Windows 2000 KCC behavior of using a single bridgehead server.
IS_SCHEDULE_HASHING_ENABLED	Creates a random schedule on each new connection object based in hashed value. Helps to balance the load on bridgehead servers.
IS_REDUNDANT_SERVER_TOPOLOGY_ENABLED	Creates two inbound connection objects from different domain controllers in a hub site. Reduces impact on FRS (vvjoin) during failover.

Miscellaneous

The following table lists nbrflagoptions.

Parameter	Definition
SYNC_ON_STARTUP	Replication of this naming context from this source is attempted when the destination server is booted. This normally only applies to intra-site neighbors.
DO_SCHEDULED_SYNCS	Perform replication on a schedule. This flag is normally set unless the schedule for this naming context and source is "never", that is, the empty schedule.
WRITEABLE	The local copy of the naming context is writable.
TWO_WAY_SYNC	If set, indicates that when inbound replication is complete, the destination server must tell the source server to synchronize in the reverse direction. This feature is used in dial-up scenarios where only one of the two servers can initiate a dial-up connection. For example, this option would be used in a corporate headquarters and branch office, where the branch office connects to the corporate headquarters over the Internet by means of a dial-up ISP connection.
NEVER_SYNCED	Synchronization has never been successfully completed from this source.
IGNORE_CHANGE_NOTIFICATIONS	This neighbor is set to disable notification-based synchronizations. Within a site, domain controllers synchronize with each other based on notifications when changes occur. This setting prevents this neighbor from performing synchronizations that are triggered by notifications. The neighbor will still do synchronizations based on its schedule, or in response to manually requested synchronizations.
DISABLE_SCHEDULED_SYNC	This neighbor is set to not perform synchronizations based on its schedule. The only way this neighbor will perform synchronizations is in response to change notifications or to manually requested synchronizations.
COMPRESS_CHANGES	Changes received from this source are to be compressed. This is normally set if, and only if, the source server is in a different site.
NO_CHANGE_NOTIFICATIONS	No change notifications should be received from this source. Normally set if, and only if, the source server is in a different site.