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. It’s 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 it’s 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 it’s 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.

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 doesn’t 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.

DC1

DC3

DC5 DC4

DC2

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 doesn’t 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 let’s 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 doesn’t 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 it’s 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

let’s 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, let’s 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 don’t have the UGMC enabled at site, so the site option is showing

none for us.

Now let’s 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. Let’s 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 it’s a root domain controller

and I haven’t 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 let’s 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.

Let’s 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 let’s

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 let’s 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 don’t 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 let’s 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 let’s 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.