Ledhed at 22:02, 11 December 2013

2013-12-11T22:02:12Z

Ledhed at 22:01, 11 December 2013

2013-12-11T22:01:12Z

Ledhed: Created page with "== 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 ..."

2013-12-11T22:00:27Z

Created page with "== 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 ..."

New page

== 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/

== Reference ==
http://msmvps.com/blogs/acefekay/archive/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records.aspx

[[Category:Windows]]

@@ Line 267: / Line 267: @@
-Sharepoint's People Picker and DC/GC Access
+== Sharepoint's People Picker and DC/GC Access ==
 This has been brought up time to time, and I thought I would provide my notes on this.
@@ Line 295: / Line 295: @@
-Related Links and Resources
+== Related Links and Resources ==
 DC Locator Process in W2K, W2K3(R2) and W2K8 - PART 1, Part 2, Part 3, and Which DCs are used when promoting a server to a DC?

Active Directory Authentication - Revision history

Ledhed at 22:02, 11 December 2013

Ledhed at 22:01, 11 December 2013

Ledhed: Created page with "== 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 ..."