ACTIVE DIRECTORY REPLICATION: HOW IT WORKS

Active Directory is a great tool. And Now a days it hard to imagine a windows network without active
directory. In this part we will see what active directory replication is and how it works. Many windows
administrators want to know how replication works and how to verify that replication is fine between
active directory servers. Now sure we can create an object in active directory (user account, computer
account, group etc..) in one domain controller and check the object in its partner domain controller to
see whether its replicated and certainly its one way to check and ensure that replication is working fine
between domain controllers.

But let say we have 50 or 100 or even more than those domain controllers in network, then surely this
method will not suite in the scenario. Its very hard for administrators to check each and every domain
controller to ensure whether replication is fine or not. So in this article we will see various method and
tools to verify active directory replication in network. And we will also discuss what replication is and
how it works.

Firstly what is replication? Well its just a process to make sure that our entire domain controller has the
same piece of information. For eg. We created a user object in our head office at city A for user which
actually available in our branch office at city B, then active directory servers must need to replicate the
object over city B domain controller so that it authenticate its new user when he first logon to his
domain. Without proper replication city B domain controller has no knowledge about this new user and
will deny to login into the domain. Similarly if we change the properties of user account, say its office
address or location or department we need that this information also must updated to other domain
controller also. In other word that active directory servers in our network has the same update
information.

One of the services which might be useful in the replication scenario is KCC or knowledge consistency
checker. KCC jobs is their connection object between two or more domain controller and in every 15
minutes it will check the servers if anything change in the environment automatically update its
replication topology if its find domain controllers in site have been added or removed from the
network.

If a domain controller has made any changes in site it will take 15 seconds to replicate other domain
controller in same site. The second domain controller has pulled out the change thru RPC or remote
procedure call.

For eg. Below diagram we have 5 domain controllers in our network. If DC1 have an object changed it
notifies DC2 and DC3. And once DC2 and DC3 have the updated then it replicated to DC 4 and DC5.
 DC1

DC2 DC3

DC4 DC5

The only limitation of KCC is it only supports 3-hop replication. So if we have more than 3-hop
replication at our network, say that we have about 10 domain controllers in ring topology, KCC will
create a mesh topology by creating more connection objects.

We have two type of replication. Intrasite and intersite replication. In intrasite replication all its domain
controllers are available in same site while in intersite replication domain controller will replicate the
change from one site to another site and intersite topology generator (ISTG) service will play a role here.

Now we will see how active directory replicate its data from one site to another site. For example we
have two different site A and site B with 8 domain controllers in each site. Within site all domain
controller will replicate to each other with intrasite replication, but between the sites active directory
servers will use service called ISTG, intersite topology generator service to replicate the data between
sites. ISTG will generate one server in each site as bridgehead server and these servers are responsible
for replication data with each other. Then other domain controller in each site will pulled out the
changes with bridge head servers. Unlike intrasite replication, intersite replication will occur under
schedule period. And also intersite replication doesnt use remote procedure call to replicate data. It
uses IP or either SMTP.

To check the intersite replication schedule period, we need to open Active Directory Sites and services
console. Expand Sites. And we will expand Inter-site Transports. Now we select IP container and in
right hand side window we select DEFAULTIPSITELINK and right click to view its properties. And we will
see here that intersite replication by default it will take 3 hours to replicate the data between sites.

You can also change the value between 15 minutes to maximum 10080 minutes depend on the network
connectivity between sites.
Now we will discuss here about the favorite tool to check and troubleshoot active directory replication
i.e Repadmin. But before discussing about the tool let us discuss some fine and interesting points on
replication which is useful when we start the repadmin command.

When an object has made any changes in active directory how does the other domain controller know
that it doesnt have the updated object. How can it tell the version of the object it has is new or older
than the one on the other server. For this active directory uses UPDATE SEQUENCE NUMBERS or USN
that are 64-bit value maintained by each domain controller in active directory. Now when an object is
change in anyway the domain controller with changes made will increment its value by 1.

So lets say we have a user account in one side domain controller DC1 with USN number 10000 and we
made a small change like address modify or phone number modify, active directory will increment the
user object USN by 1 and now it has the USN number 10001. And seems this is the most recent change
in the domain controller and it now has the highest update USN for any attribute store at domain
controller. So DC1 will notify it partner domain controller DC2 about change. DC2 will now ask what is
the highest value USN you have. DC1 will reply with 10001and if DC2 has lower value than DC1, it knows
there are some changed needs to be replicated. If it has the same value it knows it has already been
updated. So if DC2 has a lower value say 9950, DC2 knows that it needs to replicate 51 objects from
DC1.

Once these update have replicated DC2 now knows DC1 highest USN is 10001 and this is known as HIGH
WATERMARK. So on the next replication cycle DC2 already knows the high watermark value with DC1 is
10001, so it would ask DC1 what value it has. If the value is 10001 so it will replicate anything since DC2
has already most current information. These 2 servers though maintain their own local USN and later on
this article when we using repadmin command we will see the local USN for the same object are
different. For eg. DC1 might have the local USN 10001 and DC2 might have the local USN 9000 for the
same object. But that doesnt matter as each domain controller will also maintain a record of its
replication partner USN.
Now there may also a problem occur with the USN when an object is modified before ahead its time to
replicate and the same object is modified at different domain controller also. This is referred as a
Replication Collision. And this problem is solved thru Property Version Number (PSN). For example
lets say on DC1 password has been change for a user account and before the password has been
replicated to DC2, other admin on DC2 has change the password for same user account so which one
win ? The answer is the domain which has the latest PSN number for the object.

So now lets demonstrate the repadmin command. To demonstrate the replication I have used 2
windows server 2008 domain controller server. (AD1 and AD2)

To run the repadmin , open the command prompt window and type repadmin and if you want to see
all the special switches available for repadmin type repadmin /? . We will not cover all the switches
available for repadmin but few of the option which uses most in operation.

When you troubleshooting replication problem, the first thing you like to know which domain controller
you are replicating with. To know this we need to run repadmin /showrepl, as shown below:
When you run repadmin/showrepl command as shown in above pic, it will run against the local
domain controller that are currently connected to. And if we want to run the same command against
different domain controller, we have to mention domain controller name in command. So if we want to
run the same against our different domain controller, which is in our lab is AD2.test.abhi, we have to run
repadmin/showrepl AD2.test.abhi.

Alright, lets discuss the output result. As shown in above pic, the command has been run against
AD1.test.abhi domain controller, which is a member of default first site. We will see that it also a
global catalog server, as DSA option is IS_GC. And the site option is none. Now if the site has additional
configuration for example if the site has universal group membership caching (UGMC) enabled, option
would be different. Currently we dont have the UGMC enabled at site, so the site option is showing
none for us.

Now lets enable UGMC at our site. To enable UGMC in site, Open site and services console window thru
dssite.msc or thru Administrative tools. Expand sites and select the site in which you want to enable this
setting. At right console, right click NTDS site settings and go to properties and check the box enable
universal group membership caching. Click Apply and Ok.

So we have enabled UGMC in our only site which is default first site. Lets re- run the command again,
and now we will see that site option is changed to IS_GROUP_CACHING_ENABLED.

Also the next two lines in above output which tell the GUID of this domain controller. This GUID value of
the domain controller has never changed during his entire lifetime. However the next value which is
DSA invocationID, which is a database signature, can be change. Now in my case you will notice that
both of the value (DSA object GUID and DSA invocationID) is same, since its a root domain controller
and I havent any application directory partition hosted. However if
we run repadmin/showrepl command against our different domain controller server, which is
AD2.test.abhi, we will see the last two values are changed:
Also the DSA object GUID is registered in DNS as CNAME record. To view this record, open DNS
management console by either thru dnsmgmt.msc command or thru administrative tools. In DNS
expand the Forward lookup zones and select _msdcs.DOMAIN NAME.

Now if we double click any of the CNAME record we will see the FQDN name. And if we ping the FQDN
name, we will see that we are able to ping domain controller using GUID.

This is important, because if you have any replication problem due to DNS issue, the first thing you can
check whether you are able to resolve GUID name with your correct domain controller.
Now rest of the output of repadmin/showrepl is the naming context or directory partition which is
replicated between domain controllers.

First of the naming context is CONFIGURATION, contains information about the forest infrastructure
including trees, domains, trust, sites and services and so forth and this will be replicated to all domain
controller in forest.

Next we have SCHEMA naming context which also replicated to all domain in a forest, and it defines
the role for creating objects and modifying objects in the forest.

Next we have DomainDnsZones which is application naming context which is intended to replicate
between all domains and ForestDnsZones is also a application naming context which intended to
replicate between forest.

Also we can see the time of replication, the protocol its used for replication like in this case its RPC,
when the last time it was successfully replication, domain controller replication partner and so forth.

So we have seen that repadmin/showrepl command has given lot of handy information which will help
us to troubleshoot the replication.

Now we will see some more switch options which we can used with repadmin command. So lets begin
with repadmin /showconn. Once we run this command we will get following output. This command I
run against the second domain controller AD2.test.abhi, and it shows the connection objects that we
have for our domain controllers.
So lets see the top result of this command, here we have the KCC generated object result ,we can see
the connection name ,the server name and the service distinguished name and from above output we
can see that KCC using ring topology for naming context replication.

If you want to see overall replication summary in the active directory we can run the command
repadmin /replsummary. This will show the inbound and outbound replication status for domain
controllers.
The largest delta value in above output is the longest replication gap in all the link of replication in
domain controllers. Fails column is for how many replication links are failed during replication cycle and
this will be useful to identify how many links are failed. Total column will tell how many replication links
are available for our domain controller and one is each for naming context. If your replication has any
issue you will see in this output and you can identify about the link failure or any replication error.

Lets talk more about replication, perhaps the most interesting one. But before talk on this point, open
Active Directory Users and Computers thru either administrative tools or dsa.msc command. And create
a new user object. To demonstrate this I have created a new user account Labuser01.

Now this time we will run the repadmin command with showmeta option. The syntax of the command
is repadmin /showmeta Distinguished name of the object. So our user object is labuser01, our
command is like repadmin /showmeta CN=labuser01,OU=lab IT users,DC=test,DC=abhi. Once we
hit the command we will have following output:
Now what we can get from this output is the entire attribute of the user object labuser01. Notice that
at left side of the output is the information about update sequence number (USN) , and the right side is
the version attribute and this is what we called property version number (PSN) of the object which we
discussed in the beginning of this article. With this in mind, let's go back and change some of the
attribute value for the labuser01 account. From the above output you can notice that there is no such
attribute called telephone, it means telephone attribute entry for user object is not there, so lets
change the telephone number for user to 12345 thru active directory users and computers. Once we
change the telephone number to 12345, we re-run the command again and will see the output like
below:

Now this time you can notice that there is an attribute entry for telephone number with version number
1 in right side is added and in the left side we can see the USN number is 20691. Again with this in mind
we can update the telephone number to 123456 and re-run the command. This time we can see that
version number of telephonenumber attribute has been changed to 2 and the USN number is updated
to 20700. We can visibly able to see the changes of the USN number and property version number (PSN)
whenever any changes made to the user labuser01.
So whenever there is change is version number or USN number, the replication partner domain
controller understand that it need to replicate the object attribute from other domain controller and
whichever having the highest version number is the winning domain controller.

Also you can notice that above command we run on AD2.test.abhi domain controller. We will re-run the
command again but this time it against AD1.test.abhi.

This time you will see that local USN number is change but original USN number is 20700 for telephone
number attribute. As we discussed in the beginning of this article that local USN number may be
different for domain controllers but object USN number should be same in order to verify proper
replication. Above output show that AD1 domain controller also has the same property version number
and same USN number for object which confirms that both the domain controller has no issue with
replication.

Now how you will know that what object active directory domain controllers servers are expecting to be
replicated. So lets see how we can find this information. For this we can run the command
repadmin/showchanges which narrows what changes domain controllers need to replicate. Using this
command we can find the change difference between the domain controllers. So in this lab we have two
domain controllers and for example we have to run this command on AD2 to find the changes between
AD2 and AD1 servers, we have to run this command in following syntax:

Repadmin /showchanges remote DC GUID of the Local DC DC=Domain, DC=Com

So in this case our command will like as:

repadmin /showchanges AD1.test.abhi d3303a67-d27f-41fd-9251-27310962845e DC=test,DC=abhi

After hit the command we can see that currently servers dont have any changes to replicate between
them. With this is mind, we can go back to our active directory users and computers and change the
attribute of user account labuser01. This time lets update the user office field in active directory as
INDIA. Re-run the command again and now we will the changes which active directory need to replicate
From Above output we can see that AD1 domain controller need to update the changes which we made
at AD2 and the change is for Office name attribute INDIA for the user account labuser01 .

So to replicate the changes from AD2 to AD1 server , run repadmin /replicate AD1.test.abhi
AD2.test.abhi DC=test,DC=abhi

The command completed successfully and now lets re-run the /showchanges command again to verify
there will no change pending to replicate between servers.

So in this article we learn what active directory replication is, how it works, types of replication, what is
all about update sequence number and property version number, replication collusions and High water
mark value and what is repadmin command and how it be useful to find out who are replication partner
for domain controller ,when the last time replication took place, what objects and attributes are
replication, replication summary and what object changes active directory expected to replicate.