Premkumar Yogeswaran's Blog

Active Directory | PowerShell | DNS | DHCP | Exchange Server | VM Ware

Posts Tagged ‘DC Locator’

DC Locator Process in W2K, W2K3(R2) and W2K8

Posted by Premkumar Yogeswaran on April 1, 2012


By default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:

  • _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD>

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DCs are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in, it will ask for a DC in that same domain by querying DNS with:

  • _ldap._tcp.dc._msdcs. <DOMAIN>.<TLD>

By default all writable DCs in AD domain <DOMAIN> will register that DNS SRV record. The writable DCs in the domain list are in a random order and provided by the DNS round robin mechanism. Read-Only DCs (RODCs) in Windows Server 2008 will not register domain-wide SRV records. RODCs only register SRV records for the AD site they are in.

To determine the AD site of a client:

  • NLTEST /DSGETSITE

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate/service the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient! In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SPOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that moment the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How long that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:

  • NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN><DC> /OU:<distinguished name of OU> /USERD:<DOMAIN><USER> /PASSWORDD:<PASSWORD>
  • REMARK: I specify %COMPUTERNAME% instead of the computername because this command needs to be executed locally on the client/server that needs to be joined to a domain

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records. W2K DCs do not have a GPO setting to do the configuration, so you need to configure the registry locally. To prevent that you can still create your own ADM file. W2K3 DCs do have a special GPO setting to make the configuration.

To Configure Domain Controllers or global catalogs to Not Register Generic (domain wide) Records

  • For W2K DCs
  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  • Registry value name: DnsAvoidRegisterRecords
  • Registry value type: REG_MULTI_SZ
  • Registry value data: <list of ENTER-delimited mnemonics>

For W2K3(R2)/W2K8 DCs and later:

  • GPO setting path: "Computer ConfigurationAdministrative TemplatesSystemNet LogonDC Locator DNS Records"
  • GPO setting: "DC Locator DNS records not registered by the DCs"
  • GPO setting mode: Enabled
  • GPO setting value: <list of SPACE-delimited mnemonics>

List of "mnemonics" that should not be registered by branch office DCs:

  • Dc
  • DcByGuid
  • Gc
  • GcIpAddress
  • GenericGc
  • Kdc
  • Ldap
  • LdapIpAddress
  • Rfc1510Kdc
  • Rfc1510Kpwd
  • Rfc1510UdpKdc
  • Rfc1510UdpKpwd

UPDATE:

If you have configured your branch office DCs to not register domain-wide specific records, the clients will use those DCs and fail over to the datacenter if the local DC becomes unavailable. However if the local DC comes back online the client keeps using the datacenter DC until the client is restarted or the datacenter DCs become unavailable for some reason. Apparently it does not rediscover its local DC is available again. MS-KBQ939252 provides a hotfix and registry configuration for Windows XP (SP1 & SP2) and Windows Server 2003 (SP1 & SP2). The registry configuration is the ability to configure a discovery interval for the locator process.

Make sure you also see MS-KBQ247811, as there it mentions: "After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client."

Looking at this all, the DC locator process as explained above still applies to Windows Vista and to Windows Server 2008 and later. Are there any differences or additions? Yes, there are!

Basically the client either queries for a DC in the AD site it is in or it queries for a DC in the AD domain it is in. I have always asked myself why the DC locator process did not support following the site topology based on the site cost to find the next closest DC for authentication. The answer to that is unknown to me, but both Windows Vista and Windows Server 2008 provide an additional possibility that exists between "a DC in the AD site" (the closest end) and "a DC in the AD domain" (the far end). The new possibility is "a DC in the next closest site". πŸ˜‰

Both Windows Vista and Windows Server 2008 still use the default behavior W2K, WXP, W2K3(R2) have. For both Windows Vista and Windows Server 2008 to locate a DC in the next closest site, it needs to be enabled explicitly. That can be done by using the following:

  • For WVT/W2K8 and later:
  • GPO setting path: "Computer ConfigurationAdministrative TemplatesSystemNet LogonDC Locator DNS Records"
  • GPO setting: "Try next closest site"
  • GPO setting mode: Enabled

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

To determine a writable DC within a set of DCs in the next closed AD site from the client’s perspective that could authenticate the client:

  • NLTEST /DSGETDC: <FQDN DOMAIN> /WRITABLE /TRY_NEXT_CLOSEST_SITE

Until now I talked about locating a DC for authentication. What I did not talk about yet is locating the SYSVOL to apply GPOs and to use the legacy NETLOGON share. Let’s see how that works.

Each AD domain contains one system domain DFS that allows access to the SYSVOL and NETLOGON share. After a computer or user has been authenticated a referral is requested at the authenticating DC for \<Domain Name><SYSVOL or NETLOGON>. The authenticating DC creates two lists being one list with random referrals IN the same AD site as the computer/user and one list with random referrals OUTside the AD site of the computer/user. As you can see the authenticating DC is not by default (it can be however) also the DC that provides access to the SYSVOL or NETLOGON shares. It can thus be another DC in the same AD site as the computer/user that will provide access to the SYSVOL or NETLOGON shares. To make sure the authenticating DC in the same AD site as the computer/user is at the top of the DFS referrals in-site list an update needs to be installed on the DCs and a registry configuration needs to be made on the same DCs. For more information see MS-KBQ831201.

In addition to installing the update on the DCs the following configuration needs to be made on the DCs to put the authenticating DC on top of the DFS referrals list:

  • Registry key: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDfsParameters
  • Registry value name: PreferLogonDC
  • Registry value type: REG_DWORD
  • Registry value data: 1

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8.

It gets even worse if a computer/user is authenticated outside its AD site because its DC is not available or because it is a DC-less AD site. In that situation it will use ANY DC to gain access to the SYSVOL or NETLOGON shares and in the worst case it will use some DC on the other side of the world with the tiniest WAN link you can imagine. That kinda sucks!

For both W2K and W2K3 a solution exist so that the referral process uses the nearest referral based upon site link costs. To achieve this the following is needed:

  • For W2K SP4 (!) DCs
  • Install update as mentioned in MS-KBQ823362
  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsDriver
  • Registry value name: DfsEnableSmartClient
  • Registry value type: REG_DWORD
  • Registry value data: 1

For W2K3(R2) DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SiteCostedReferrals
  • Registry value type: REG_DWORD
  • Registry value data: 1

To determine DFS referral information:

  • DFSUTIL /SPCINFO
  • DFSUTIL /PKTINFO

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8. If it is the most probably you need to use the W2K3 configuration

Now imagine the client used a DFS referral for the SYSVOL or NETLOGON outside of its AD site because its local DC was not available for some reason. Of course you want the client to fallback to its local DC in the AD site as soon as it becomes available to either access the SYSVOL or NETLOGON share. But will it do that? No! It will use the DFS referral outside its AD site until it is rebooted or its cached is reset. W2K3 SP1 allows a client to fallback to its local DFS referral target as soon as it becomes available again and it needs to access the SYSVOL or NETLOGON share.

On W2K3 SP1 DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SysvolNetlogonTargetFailback
  • Registry value type: REG_DWORD
  • Registry value data: 1

On WXP SP2 clients and W2K3 SP1 servers:

For additional information, make sure to have a look at:

  • SRV record

How to verify that SRV DNS records have been created for a domain controller

SRV Resource Records

How to optimize the location of a domain controller or global catalog that resides outside of a client’s site

How DFS Works

http://blogs.technet.com/b/arnaud_jumelet/archive/2010/07/11/domain-controller-locator-in-depth.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 1
http://blogs.dirteam.com/blogs/jorge/archive/2007/06/30/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-1.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 2
http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-2.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 3
http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-3.aspx

Posted in Active Directory, DNS | Tagged: , | 7 Comments »