ACTIVE DIRECTORY REPLICATION: HOW IT WORKS

Transcription

1 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.

2 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 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 minutes depend on the network connectivity between sites.

3 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 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 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

4 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 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 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 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:

5 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:

6 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.

7 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.

8 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.

9 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:

10 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 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 Again with this in mind we can update the telephone number to 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 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.

11 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 for telephone number attribute. As we discussed in the beginning of this article that local USN number may be

12 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 e 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

13 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.

14