Repost
The DC Locator Process, The Logon Process, Controlling Which DC Responds in an AD Site, and SRV Records
Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003 Microsoft Certified Trainer Microsoft MVP: Directory Services Active Directory, Exchange and Windows Infrastructure Engineer
Original Compilation: 4/2009 Posted/Published 1/3/2009 Updated 10/28/2011
Note: This is a compilation of data from various resources. I hope you find it helpful.
Controlling which DC responds in a Site
This section is to understand how to change the Netlogon Registry Data to control SRV weights and priorities, that are referenced in the links above. Be careful when implementing these changes. It MUST be documented so if another DC in the site were to go down, users may experience a delay or worse, an inability to logon, and if the changes made were forgotten, it will be extremely difficult to troubleshoot.
To find out which DC logged you in: echo %logonserver%
You can also test which DCs are nearest to your workstation in your site (copy nltest.exe from the DC to the workstation's system32 folder): nltest /sc_query:YourDomainName.com
To find the GC your workstation used (copy nltest.exe from the DC to the workstation's system32 folder): nltest /dgsgetdc:your_domain_name.com /GC
This is performed altering the default weight and/or priority settings that get registered in the SRV records. The changes are made in the specific DC's netlogon registry entry. I would suggest to change all your DCs in a Site for more finite control. The reason is it controlled in the netlogon registry entry, is because the netlogon service is the component that registers a DC's data into their respective SRV folders.
When changing them, keep in mind a client will attempt to contact a server with the lowest priority first. If there are more than one server with the same priority, DNS load balancing is used when selecting the target server. If the weights are changed with the same priority, then a server is chosen based a percentage by dividing the weigth by the sum of all weights of all DCs in an AD Site.
Let's say you have 3 DCs: DC01, DC02 and DC03. Weights are assigned as follows: DC01 = 10 DC02 = 20 DC03 = 30
In this example: DC01 will be contacted 1 out of every 6 times (10/(30+20+10)) DC02 will be contacted 2 out of every 6 times (10/30(20/(30+20+10))) DC03 will be contacted 3 out of every 6 times (10/20(30/(30+20+10)))
You can use nslookup to find the SRV weights: nslookup q=srv _ldap._tcp.dc01._msdcs.domain.com
Then verify the correct SRV records were created based on the registry changes you made:
How to verify that SRV DNS records have been created for a domain controller:
http://support.microsoft.com/kb/816587
The CSEs (client side extensions) is what chooses a DC in this order:
1.A DC in its own AD Site based on the client's IP address and subnet its in. 2.If more than one DC in the same Site to choose from in the same IP subnet, Round Robin prevails 3.If more than one DC in the same AD Site but one of the DCs are in the same subnet and the other is not, then Subnet Priortization prevails to choose the DC in its own subnet. 4.If more than one DC in the same AD Site but both of the DCs are in different IP subnets than the client, and the two DCs are in the same subnet, then Round Robin will prevail to choose one of the DCs in that same subnet. 5.If more than one DC in the same AD Site but both of the DCs are in different IP subnets than the client, then Subnet Priortization will prevail to choose one of the subnets that a closest match based on the network bits (see this for more info on subnet priortization and bit selection: Technet Thread - DNS issue : DHCP relay + VLANs + multiple AD Sites (Heavily discusses subnet priortization and subnet bits) http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/ea03c013-7484-4a24-96be-d95219b69b3f/