Replication is one of the most important and perhaps complex
components of Active Directory. The infrastructure behind Active Directory
replication, including the site topology, connection objects, and the KCC, was covered in
Chapter 11. This chapter focuses strictly on some of
the tasks and processes associated with replicating data and checking
replication health. For an in-depth overview of how replication works in
Active Directory, we suggest reading Active
Directory, Fifth Edition by Brian Desmond et al.
(O’Reilly).
You want to determine whether two domain controllers are in sync and you do not have objects to replicate to each other.
To determine whether two or more DCs are in sync from a replication standpoint, you need to compare their up-to-dateness vectors. Each domain controller stores what it thinks is the highest update sequence number (USN) for every DC that replicates a naming context. This is called the up-to-dateness vector. If you want to compare DC1 and DC2, you’d first want to get the up-to-dateness vector for DC1 and compare DC1’s highest USN against what DC2 thinks DC1’s highest USN is. If they are different, then you can deduce that DC2 has not yet replicated all the changes from DC1. Next, compare the reverse to see whether DC1 is in sync with DC2.
The following command will show the replication status of all the domain controllers in the forest, as shown in the output that follows:
> repadmin /replsum Replication Summary Start Time: 2012-11-29 20:09:22 Beginning data collection for replication summary, this may take awhile: ..... Source DC largest delta fails/total %% error DC1 15m:22s 0 / 3 0 DC2 :12s 0 / 3 0 Destination DC largest delta fails/total %% error DC1 :05s 0 / 3 0 DC2 15m:22s 0 / 3 0
You can also use * as a
wildcard character to view the status of a subset of domain
controllers. The following command will display the replication status
of the servers that begin with the name dc-rtp:
> repadmin /replsum dc-rtp*
The /replsum option in
repadmin is a great way to quickly determine
whether there are any replication issues. This command should be your
starting point if you suspect any replication problems. If you are
running /replsum against a lot of
domain controllers, you can use the /sort option to sort the returned table output
by any of the table columns. You can also use the /errorsonly option to display only the
replication partners who are encountering errors.
The solution shows how to display the current unreplicated changes
between two domain controllers. This can be useful in troubleshooting
replication on your network, particularly if you are finding
inconsistent information between one or more domain controllers. The
repadmin /showchanges command has
several additional options you can use to display the changes, including
saving the output to a file for later comparison. Also, with the
/statistics option, you can view a
summary of the changes.
The following command will perform a replication sync from
<DC2Name> to
<DC1Name> of the naming context
specified by
<NamingContextDN>:
> repadmin /replicate <DC1Name> <DC2Name> <NamingContextDN>$strDCname =<DomainDNSName>$context = New-Object↵ System.DirectoryServices.ActiveDirectory.DirectoryContext('DirectoryServer',↵ $strDCname) $dc =↵ [System.DirectoryServices.ActiveDirectory.DomainController]↵ ::getDomainController($context) $strPartDN = "<Partition DN>" $dc.TriggerSyncReplicaFromNeighbors($strPartDN)
Each solution shows how to replicate all unreplicated changes from a source domain controller to a destination domain controller. This sync is a one-way operation. If you want to ensure that both domain controllers are in sync, you’ll need to follow the same procedure in the opposite direction, replicating both from DC1 to DC2 and from DC2 to DC1. It’s important to remember that all replication takes place as a pull operation. For example, DC2 notifies DC1 that it has changes available, after which DC1 pulls the changes it needs from DC2. For replication to occur in the opposite direction, DC1 will notify DC2 that it has changes available, and DC2 will pull those changes from DC1.
Note
With repadmin, you can replicate a single
object instead of all unreplicated objects in a naming context by
using the /replsingleobj
option.
Viewing Unreplicated Changes Between Two Domain Controllers for viewing unreplicated changes between two domain controllers
To disable outbound replication on a domain controller, use the following syntax:
> repadmin /options <DC Name> +DISABLE_OUTBOUND_REPLTo reenable outbound replication, enter the following:
> repamin /options <DC Name> -DISABLE_OUTBOUND_REPLTo disable inbound replication, use the following syntax:
> repadmin /options <DC Name> +DISABLE_INBOUND_REPLTo reenable inbound replication, use the following:
> repadmin /options <DC Name> -DISABLE_INBOUND_REPLWhen you are making major changes to Active Directory, particularly in cases where you are extending the schema, it is recommended that you disable outbound replication on the DC that you’re modifying. This will allow you to test any changes that you’ve made on a single DC without propagating those changes to the remainder of your directory. If you make a mistake or find that the changes you’ve made are otherwise unacceptable, you can restore a single DC rather than being faced with the prospect of performing a disaster recovery operation on your entire domain.
It’s important to note that disabling outbound replication on a domain controller will not have any effect on inbound replication; the DC in question will still receive updates from its other replication partners unless you disable inbound replication on them as well.
You can also disable replication for an entire forest by issuing the following command:
> repadmin /options * +DISABLE_INBOUND_REPL
You want to change the number of seconds that a domain controller in a site waits before sending replication partner notification within the site.
If an entry for the Configuration naming context you want to browse is not already displayed, do the following:
Right-click on ADSI Edit in the right pane and click “Connect to”.
Fill in the information for the Configuration NC. Click on the Advanced button if you need to enter alternate credentials.
In the left pane, browse to
cn=Configuration,<ForestRootDN>→cn=Partitions. Right-click on the domain partition designated by the short name of the domain (cn=ADATUMfor adatum.com) and select Properties.Double-click on the following attributes and modify their values as appropriate:
msDS-Replication-Notify-First-DSA-DelaymsDS-Replication-Notify-Subsequent-DSA-Delay
Create a file called modify_replication_interval.ldf with the following contents:
dn:<DomainPartitionCrossRefDN>changetype: modify replace: msDS-Replication-Notify-First-DSA-Delay msDS-Replication-Notify-First-DSA-Delay:<FirstDelayInSeconds>- replace: msDS-Replication-Notify-Subsequent-DSA-Delay msDS-Replication-Notify-Subsequent-DSA-Delay:<NextDelayInSeconds>
Then import the changes into Active Directory using the following syntax:
ldifde -i -v modify_replication_interval.ldf
You can also make the changes using AdMod, as follows:
admod -b cn=<DomainPartition>,cn=Partitions,cn=Configuration,<ForestRootDN>msDS-Replication-Notification-First-DSA-Delay::<FirstDelayInSeconds>msDS-Replication-Notify-Subsequent-DSA-Delay::<NextDelayInSeconds>
The following commands are examples that modify the intra-site replication parameters to 10 seconds, in the adatum.com domain:
Set-ADObject "cn=Adatum,cn=Partitions,cn=Configuration,dc=adatum,dc=com" -Replace @{"msDS-Replication-Notify-First-DSA-Delay"="10"}
Set-ADObject "cn=Adatum,cn=Partitions,cn=Configuration,dc=adatum,dc=com" -Replace @{"msDS-Replication-Notify-Subsequent-DSA-Delay"="10"}Because Active Directory assumes that DCs within a site are connected by high-speed links, intra-site replication occurs as changes are made rather than adhering to a specific schedule. The intra-site replication initial delay interval is 15 seconds, after which a DC will notify its replication partners in three-second intervals. This greatly reduces the convergence time within a site—that is, the amount of time it takes for domain controllers within a site to synchronize with one another.
Note
Some updates are deemed to be sufficiently important that the initial 15-second delay does not apply. This is known as urgent replication, and it applies to critical directory updates such as locking out an account, changing the account lockout or password policy of a domain, and changing the password of a domain-controller computer account.
To change the replication interval, create an LDIF file named set_link_rep_interval.ldf with the following contents:
dn: cn=<LinkName>,cn=ip,cn=Inter-Site Transports,cn=sites, cn=configuration,<ForestRootDN>changetype: modify replace: replInterval replInterval:<NewInterval>-
Then run the following command:
> ldifde -v -i -f set_link_rep_interval.ldf
You can also make this change using AdMod, as follows:
> admod -b cn=<LinkName>,cn=ip,cn=Inter-SiteTransports,cn=sites,cn=configuration,<ForestRootDN>replInterval::<NewInterval>
To configure the inter-site replication interval between two
sites, you need to set the replInterval attribute on the site-link object
that connects the two sites. The value of the attribute should be the
replication interval in minutes. The default value is 180 minutes (three
hours), and the minimum is 15 minutes. To view all site links, issue the
following cmdlet:
Get-ADReplicationSiteLink -Filter *
These solutions assume the use of IP transport, but SMTP transport can be used as well. However, keep in mind that you cannot use an SMTP link to replicate the Domain naming context, only the Schema and Configuration NCs as well as global catalog information.
You need to modify the options
attribute of the site-link object that connects the sites you want to
disable compression for. Site-link objects are stored in the following
location:
cn=IP,cn=Inter-site Transports,cn=Sites,cn=Configuration,<ForestRootDN>The options attribute is a bit
flag. In order to disable compression, you must set bit 2, or 0100 in
binary. If the attribute is currently unset, you can simply set it to
4.
By default, data replicated inter-site is usually compressed. By contrast, intra-site replication traffic is not compressed. It is useful to compress inter-site traffic if the traffic is going over a WAN on the assumption that the less traffic the better. The trade-off to reducing WAN traffic is increased CPU utilization on the bridgehead servers replicating the data. If CPU utilization is an issue on your bridgehead servers and you aren’t as concerned about the amount of traffic being replicated, you should consider disabling inter-site compression.
Modifying a Bit-Flag Attribute for setting bit-flag attributes
The Directory Service event log is an invaluable source of information on replication and KCC problems.
Viewing the Replication Status of Several Domain Controllers for viewing the replication status of several domain controllers
See Enabling Diagnostics Logging for more information.
Expand HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters.
If the
Strict Replication Consistencyvalue does not exist, right-click on Parameters and select New→DWORD Value. For the name, enterStrict Replication Consistency.In the right pane, double-click on the value and enter
1to enable strict consistency or0to enable loose consistency.Click OK.
To enable strict consistency, run the following command:
> reg add HKLMSystemCurrentControlSetServicesNTDSParameters /v "Strict↵ Replication Consistency" /t REG_DWORD /d 1
To enable loose consistency, run the following command:
> reg add HKLMSystemCurrentControlSetServicesNTDSParameters /v "Strict↵ Replication Consistency" /t REG_DWORD /d 0
You can also enable and disable strict replication using
repadmin. You can either specify an
individual domain controller in the <DC
Name> field or use a * to enable or disable strict replication on
every DC in the forest, as follows:
repadmin /regkey<DCName>+strict repadmin /regkey<DCName>-strict
Using strict replication consistency, a domain controller will stop replicating with a destination domain controller when it determines that the source is attempting to replicate a lingering object. Event ID 1084 will get logged in the Directory Service event log, indicating that the domain controller couldn’t replicate the lingering object. Although strict replication can halt replication, it is the preferable method, and a good way to check that lingering objects do not infiltrate your forest. For this reason, you must monitor your domain controllers to ensure they are replicating on a regular basis and they do not have any 1084 events.
Using loose replication consistency,
lingering objects could get reinjected into Active Directory and
replicate among all the domain controllers. A lingering
object is one that was previously deleted but got
reintroduced because a domain controller did not successfully replicate
for the duration of the time defined by the tombStoneLifetime attribute, or because the object was
restored using a backup older than the tombStoneLifetime. Domain controllers will
replicate the lingering object throughout the naming context. Loose
consistency thus has the potential to cause some security risks since an
object you thought was deleted is now back in the forest
again.
From the menu, select Connection→Connect.
Click OK to connect to the closest domain controller over port 389.
From the menu, select Connection→Bind.
Click OK to bind as the currently logged on user or select the option to bind with credentials, enter the credentials, and then click OK.
From the menu, select Browse→Search.
For Base DN, type the base DN from where you want to start the search.
For Scope, select the appropriate scope.
For Filter, enter
(name=* ACNF:*).Click Run.
Any distributed multimaster system has to deal with replication
collisions, and Active Directory is no different. A collision can occur
if an object is created on one domain controller and before that object
has time to replicate out, an object with at least the same name is
created on a different domain controller. So which object wins? With
Active Directory, the following steps are used to determine which object
is retained as is and which one is considered a conflict object:
AD will compare the version number of the objects. In Active Directory, version numbers are incremented every time you make a change to an object. The higher the version number, the more changes have been made to the object.
If the version numbers are the same, AD then compares the timestamps of when each object was created. The object that was created more recently will be retained and the older one will be renamed.
If the statistically improbable happens and two objects or attributes possess identical timestamps and version numbers, AD will take one final step to resolve the conflict by maintaining the object that originated from the DC with the higher GUID, and renaming the object that originated from the DC with the lower GUID.
When the losing object is renamed, the format of the renamed object is:
<ObjectName>ACNF:<ObjectGUID>
where <ObjectName> is the
original name of the object, followed by a null termination character,
followed by CNF:, followed by the
object’s GUID.
It is good to periodically scan your Active Directory tree to
ensure you do not have a lot of conflict objects hanging around and to remove
any that exist. It is a bit problematic to find conflict objects in a single query because the
filter to find them is not optimized. In all three solutions, you have
to perform a leading- and trailing-match pattern search (with *), and this can easily time out if you have a
lot of objects. You may want to restrict your initial search to a few
containers so that the search is quicker.
Because of the distributed nature of Active Directory, there
exists the possibility that an administrator working on one DC can
attempt to create or move a user into a container object such as an OU
at the same time that another administrator deletes
that OU from another DC. When this occurs, the leaf object becomes
orphaned and is moved into the LostAndFound container within the Domain NC.
You can view the lastKnownParent
attribute of an object in this container to determine the OU or
container that was deleted, and then delete the object or move it to a
different container as appropriate.
From a procedural standpoint, objects being moved to the LostAndFound container should be a rare event.
If it is happening frequently or if there are a large number of objects
in the container, you should review the change-control procedures that
are in place on your network to ensure that object moves and deletions
are more tightly coordinated.
You can query for replication connections using either the built-in DSQuery utility or AdFind. DSQuery takes the following syntax:
> dsquery * "cn=NTDS Settings,cn=<DCName>,cn=Servers,cn=<SiteName>,cn=Sites,cn=Configuration,<ForestRootDN>-filter (objectcategory=NTDSConnection) -attr *
To use AdFind, enter the following:
> adfind -config -rb "cn=NTDSSettings,cn=<DCName>,cn=Servers,cn=<SiteName>,cn=Sites" -f (objectcategory=NTDSConnection)
By default, Active Directory’s replication topology is created by
the KCC, which runs on every DC to dynamically create and maintain
connection objects. (The KCC will run
every 15 minutes by default to determine whether there have been any
changes to the site topology that require modifications to the connection objects the KCC has created.) Each
connection object corresponds to an
inbound replication connection—that is, a remote DC that will contact
the local DC whenever it has changes available. Any connection object that is listed as <automatically generated> in Active
Directory Sites and Services was created by the KCC. You can create
additional connection objects
manually, but these objects will not be kept up-to-date by the KCC in
the event that a remote DC is relocated or taken offline.
You want to view metadata for an object. The object’s replPropertyMetaData attribute stores metadata
information about the most recent updates to every attribute that has
been set on the object.
Click OK to connect to the closest domain controller over port 389.
From the menu, select Connection→Bind.
Click OK to bind as the currently logged on user or select the option to bind with credentials, enter the credentials, and then click OK.
From the menu, select Browse→Replication→View Metadata.
For Object DN, type the distinguished name of the object you want to view.
Click OK to view the metadata.
In the following command, replace
<ObjectDN> with the distinguished
name of the object for which you want to view metadata:
> repadmin /showobjmeta <DomainControllerName> <ObjectDN>You can also obtain object metadata for a single object using AdFind, as follows:
> adfind -sc objmeta:<ObjectDN>To obtain the object metadata for all objects within a container, use the following syntax:
> adfind -sc objsmeta:<ContainerDN>Object metadata can be an invaluable source of information when you need to troubleshoot replication problems or find out the last time an attribute was set for a particular object. In fact, a quick way to determine whether two domain controllers have the same copy of an object is to look at the metadata for the object on both servers. If they both have the same metadata, then they have the same version of the object. The following data is stored for each attribute that has been set on the object:
- Attribute ID
Attribute that was updated.
- Attribute version
Number of originating writes to the property.
- Local USN
USN of the property on the local DC. This will be the same value as the originating DC if the originating DC and local DC are the same.
- Originating USN
USN stored with the property when the update was made on the originating DC.
- Originating DC
DC that the originating write was made on.
- Time/Date
Time and date that the property was changed in UTC.
You also have access to the msDS-ReplAttributeMetaData and the
msDS-ReplValueMetaData
attributes, which provide much object metadata in XML-formatted output,
as shown through this AdFind query (query output truncated):
> adfind -default -rb cn=administrator,cn=users msds-replattributemetadata AdFind V01.46.00cpp Joe Richards ([email protected]) March 2012 Using server: dc1.adatum.com:389 Directory: Windows Server 8 Base DN: cn=administrator,cn=users,dc=adatum,dc=com dn:cn=Administrator,cn=Users,dc= adatum,dc=com >msDS-ReplAttributeMetaData: <DS_REPL_ATTR_META_DATA> <pszAttributeName>lastLogonTimestamp</pszAttributeName> <dwVersion>6</dwVersion> <ftimeLastOriginatingChange>2012-11-29T20:18:49Z</ftimeLastOriginating↵ Change> <uuidLastOriginatingDsaInvocationID>aae693c5-d0d9-497f-a1c4-f298aaec8a8b </uuidLastOriginatingDsaInvocationID> <usnOriginatingChange>1056930</usnOriginatingChange> <usnLocalChange>1056930</usnLocalChange> <pszLastOriginatingDsaDN>cn=NTDS Settings,cn=dc1,cn=Servers,cn=Def ault-First-Site-Name,cn=Sites,cn=Configuration,dc=adatum,dc=com</pszLastO riginatingDsaDN> </DS_REPL_ATTR_META_DATA> >msDS-ReplAttributeMetaData: <DS_REPL_ATTR_META_DATA> <pszAttributeName>isCriticalSystemObject</pszAttributeName> <dwVersion>1</dwVersion> <ftimeLastOriginatingChange>2012-09-27T18:16:45Z</ftimeLastOriginating↵ Change> <uuidLastOriginatingDsaInvocationID>c0e0fe92-685b-4e0e-863b-7067745d31f7 </uuidLastOriginatingDsaInvocationID> <usnOriginatingChange>8196</usnOriginatingChange> <usnLocalChange>8196</usnLocalChange> <pszLastOriginatingDsaDN></pszLastOriginatingDsaDN> </DS_REPL_ATTR_META_DATA> >msDS-ReplAttributeMetaData: <DS_REPL_ATTR_META_DATA> <pszAttributeName>objectCategory</pszAttributeName> <dwVersion>1</dwVersion> <ftimeLastOriginatingChange>2012-09-27T18:16:45Z</ftimeLastOriginating↵ Change> <uuidLastOriginatingDsaInvocationID>c0e0fe92-685b-4e0e-863b-7067745d31f7 </uuidLastOriginatingDsaInvocationID> <usnOriginatingChange>8196</usnOriginatingChange> <usnLocalChange>8196</usnLocalChange> <pszLastOriginatingDsaDN></pszLastOriginatingDsaDN> </DS_REPL_ATTR_META_DATA> 1 Objects returned