Freigeben über

Optimizing DFS Referrals: SiteCostedReferrals and PreferLogonDC

  • Artikel

In a multi-site infrastructure you would under most circumstances want to make sure that the client is accessing Sysvol and Netlogon from a local DC, typically the logon server – or failing that to use the closest DC as determined by the replication costs defined on the site links in AD Sites & Services.

Two registry keys enable this functionality – they are however off by default (on W2k3 and W2k8 DC's) which means that the list of DFS referrals will be sorted with the DC’s in the same site first (in random order) and other out-of-site DC’s in semi-random order (this is assuming site & subnet configuration for clients and DC’s is correct).

A domain controller that is passing a DFS referral (for Sysvol or Netlogon) to a client will by default not have any preference to put itself at the top of the referral list - you'll potentially get any DC in the same site at the top of the list.

Setting PreferLogonDC on the DC’s makes the DC do just that for SYSVOL and Netlogon however.

In the same manner – SiteCostedReferrals needs to be set on the DC’s to make the DC returning the DFS referral sort the list of DFS referrals based on the site cost as viewed from the client side.

For the SiteCostedReferrals key to be usable the subnets of the clients and DC’s must to have been defined and assigned to a suitable site in AD Sites & Services.

Note: the SiteCostedReferrals and PreferLogonDC registry keys only apply to SYSVOL and Netlogon DFS referrals.

The DFSUTIL command can both display the current status and configure them:clip_image002

The reason for not having either of those keys on by default is that there is some (minor) performance overhead that comes from calculating the referrals for each client using the additional criteria.
With today’s hardware however the performance impact to the DC’s should be minimal when compared to the performance benefits that the clients gain.

Tip: If at all possible - use DNS for any DFS referrals. Using NetBIOS names for DFS referrals is relying on either WINS or broadcasts for name resolution... which is less secure and can produce undesired side-effects.

As a footnote: 

  • RODC's don't register as Intersite Topology Generators (ISTG) for the site they are in, using SiteCostedReferrals on an RODC that is the only DC in the site therefore doesn't produce the desired results.
    A possible workaround is to manually register the RODC as an ISTG for the site (using ADSIEDIT.msc).

  • In a single DC site the PreferLogonDC registry key becomes meaningless and even counterproductive - if you find that you have to use it in single-DC sites then chances are that your Subnet mapping for clients is incorrect or missing or else that you may have a problem with the Site definitions in AD Sites & Services.

    Further details:

You may receive DFS referrals that contain a list of random DFS targets, random SYSVOL or NETLOGON referrals, or experience slow performance when you access a shared folder in a DFS namespace on a Windows Server 2003-based computer
http://support.microsoft.com/kb/905846

An update for Windows Server 2003 and Windows 2000 Server makes it possible to put the logon server at the top of the DFS referrals list
http://support.microsoft.com/kb/831201

How to configure DFS to use fully qualified domain names in referrals
http://support.microsoft.com/kb/244380

Determining the Inter-Site Topology Generator (ISTG) of a Site in the Active Directory
http://support.microsoft.com/kb/224599

Comments

  • Anonymous
    January 01, 2003
    True on both accounts - this is covered in http://support.microsoft.com/kb/244380 (How to configure DFS to use fully qualified domain names in referrals)

  • Anonymous
    January 10, 2010
    The comment has been removed

  • Anonymous
    April 26, 2013
    Do we need restart the DC after that?