Active Directory Site Topology, Not Just for DCs

Active Directory Site Topology, Not Just for DCs

  • Comments 3
  • Likes

Mark here again. Following a recent experience in the field (yes, Premier Field Engineers leave the office), I thought it’d be useful to discuss Active Directory Topology and how it influences DFS Namespace and DFS Folder referrals.

Let’s look at the following environment for the purposes of our discussion

image

Let’s suppose that the desired referral behaviour is for clients to use local DFS targets, then the DFS target in the hub site and finally, any other target.

Lastly, let’s assume the effective referral ordering is configured for “Lowest Cost”.

Note: DFS Namespace and Folder referrals are site-costed by default in Windows Server 2008 or later. The feature is also available in Windows Server 2003 (SP1 or later) but is disabled by default. The use of site-costed referrals is controlled by the following registry value

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters]
Value Name: SiteCostedReferrals
Data Type: REG_DWORD
Value: 0 (off) or 1 (on)

What does the referral list look like for clients in each site?

Scenario A

Clients assigned an IP Address in the subnet 192.168.1.0/24, will associate themselves with the site Spoke-A. The DFS referral process will offer them the ordered list

DFS Target A
DFS Target Hub
<random ordering of DFS Target C, DFS Target D and DFS Target E>
DFS Target B

Great! This is pretty much what we’d designed for – the local target first, the hub second and random ordering of equally costed targets after that. The exception is DFS Target B, which cannot be costed without a site-link between site Spoke-B and any other site.

Scenario B

Clients assigned an IP Address in the subnet 192.168.2.0/24 will associate themselves with the site Spoke-B. The DFS referral process will offer them the ordered list

DFS Target B
<random ordering of DFS Target A, DFS Target C, DFS Target D, DFS Target E and DFS Target Hub>

In this scenario, we correctly receive the local DFS target heading the list but the rest of the referral order is random. Without a site-link from the site Spoke-B to any other site, DFS cannot calculate the cost of targets beyond the client site.

Scenario C

Clients assigned an IP Address in the subnet 192.168.3.0/24 do not associate with any site. The pattern seen in the site diagram above suggests the client should associate with the site Spoke-C but the missing subnet definition leaves clients in limbo. In fact, nltest.exe will show you this

image

The DFS referral process will offer clients the ordered list

<random ordering of DFS Target A, DFS Target B, DFS Target C, DFS Target D, DFS Target E and DFS Target Hub>

Completely random – a long way from the design goal.

Scenario D/E

Clients assigned an IP Address in the subnet 192.168.4.0/24 will associate themselves with the site Spoke-D. The DFS referral process will offer them the ordered list

DFS Target D
<random ordering of DFS Target E and DFS Target Hub>
<random ordering of DFS Target A and DFS Target C>
DFS Target B

Here the local target is ordered first. DFS Target E and DFS Target Hub have the same cost and are ordered next in random order. This is because sites Hub, Spoke-D and Spoke-E are all linked with the same site-link and therefore have the same cost.

DFS Target A and DFS Target C are offered in random order following DFS Target E and DFS Target Hub – again because they have the same cost. Lastly, the un-costed DFS Target B is ordered.

Clients assigned an IP Address in the subnet 192.168.5.0/24 will associate themselves with the site Spoke-E and experience the same referral order as clients in site Spoke-D except the position of DFS Target D and DFS Target E in the referral order will be swapped.

This is close to the design goal but the site-link connecting three sites may cause DFS Target Hub to appear slightly out of order.

Conclusion

I’ve seen many poorly managed Active Directory topologies – most often when Domain Controllers reside in a central site. A well-defined topology is important for other reasons than DC replication/location – DFS referrals being a big one. Without properly defined site-links, subnets and site-to-subnet mappings, users may find themselves unwittingly directed to a file server in Mordor.

- Mark “AD Site Topology is Precious” Renoden.

  • Interessting Post. Only one question left: How come is it possible that a Site is not associated with at least on Site link? If I create a Site it is mandatory to specifiy a Site link... Christian

  • You can manually delete anything in there. Sometimes people do a big manual toplogy, but fail to complete a site matrix. The AD Topology Diagrammer is a useful tool to catch those mistakes, as well as visualize the whole thing.

  • excellent post