If you would like to read Mitch Tulloch’s other DFS articles please go to:
In my previous article titled Implementing DFS Namespaces on WindowsNetworking.com, we saw how to create a namespace (a virtual folder tree) using the enhanced DFS Management console of Windows Server 2003 R2. This article expands on the previous one by looking at how to configure namespaces in enterprise environments where there are multiple sites. Since a site, in Active Directory terminology, basically refers to a collection of computers that are connected together as a LAN, a multi-site environment usually means multiple LANs, each located at a different geographical site. For example, a company that has its headquarters in Vancouver (Canada) might have a secondary site or branch office located a few hours south in Seattle (USA). Even though both locations may belong to the same domain, they may be separate sites to better manage replication traffic over a slow WAN link connecting them. DFS Namespaces includes new features that makes DFS work more efficiently for scenarios like this than the older DFS component of Windows 2000 worked in such scenarios. We’ll look at several ways you can improve the operation of your namespace in an enterprise environment like this.
Adding Namespace Servers
When deploying domain-based namespaces, you can add additional namespace servers to host a namespace. This has several advantages:
- If one namespace server hosting the namespace goes down, the namespace will still be available to users who need to access shared resources on your network. Adding another namespace thus increases the availability of your namespace.
- If you have a namespace that must be available to users all across your organization but your Active Directory network has more than one site, then each site should have a namespace server hosting your namespace. That way, when users in a site need to contact a namespace server for referrals, they can do so locally instead of sending traffic requests to other sites. This improves performance and reduces unnecessary WAN traffic.
Note that adding additional namespace servers is only supported for domain-based namespaces, not standalone namespaces.
Before showing how to add a namespace server to a namespace, let’s quickly review the scenario from my previous article:
- Our domain is R2.local and our domain controller is BOX161.
- We created a domain-based namespace named Accounting.
- This namespace is hosted on server BOX162.
- The namespace contains targets on servers BOX162 and BOX163.
- All servers are located in Default-First-Site, which is company headquarters in Vancouver.
- All servers are running Windows Server 2003 R2.
To make our scenario more enterprise-level, we’ll now add the following:
- We’ll create a second site named Seattle-Site, which is a branch office located in Seattle.
- Seattle-Site is in the same domain R2.local.
- Domain controller BOX171 is located in Seattle.
Let’s now add BOX171 as a new namespace server for our Accounting namespace. Open the DFS Management console, select the \\r2.local\Accounting namespace in the console tree, and click the Namespace Servers tab in the Details pane (Figure 1):
Figure 1: Details of the Namespace Servers tab for the selected namespace
Note that the Accounting namespace only has one namespace server at present (BOX162). Now let’s add BOX171 as an additional namespace server for this namespace. Click the Add Namespace Server link in the Action pane, or right-click on the namespace and select Add Namespace Server. Then browse to specify BOX171 as the additional namespace server for the Accounting namespace (Figure 2):
Figure 2: Adding BOX171 as an additional namespace server for Accounting
Note that a folder named Accounting will now automatically be created on BOX171 and shared with the appropriate permissions (Read permission for Everyone). You can override this default behavior if you like by clicking Edit Settings.
Now you have two namespace servers defined for the Accounting namespace. One of these servers is BOX162 in Vancouver and the other is BOX171 in Seattle. The question is, when a user in Seattle tries to access the namespace, which namespace server will it use? This brings us to our next topic—referrals.
Configuring Referrals
To understand the importance of configuring referrals in an enterprise environment, you first need to understand how DFS Namespaces works. Going back to our scenario above, let’s say a user named Bob Smith located in Vancouver (Default-First-Site) wants to access resources in the Accounts namespace, which is spread over (targeted to) servers located in both Vancouver and Seattle (Seattle-Site). Here’s what typically happens:
- Bob tries to access the root folder of the namespace \\R2.local\Accounting by contacting BOX162, one of two namespace servers for this namespace (the other namespace server being BOX171 located in Seattle).
- BOX162 returns a referral to Bob. This referral contains a list of servers that host the particular folder (Accounting, the root of the namespace) Bob is trying to access. In this particular scenario, a root referral is returned; if Bob tried accessing a folder higher up in the namespace, a folder referral would be returned instead.
- Bob’s Windows XP desktop computer caches the referral returned to it by BOX162 and proceeds to contact the first server in the referral list, which it turns out is BOX162 itself.
- From there Bob starts browsing the namespace, and BOX162 continues to return referrals to folder targets for each folder browsed.
So what happens then when a user in one site tries to access a shared resource in a different site using DFS? By default, the list of targets returned by a referral for a particular shared resource are ordered thusly:
- Targets in the user’s site are listed first.
- If the user’s site has multiple targets, these are listed in random order.
- Targets outside the user’s site are listed next, and if there are multiple targets in other sites, the targets are listed according to their connection costs with lowest cost first (targets with the same cost are listed in random order).
This approach means that by default, DFS tries to connect a client with a target in the client’s own site first whenever possible to prevent the client from having to use a WAN link to access the resource. Furthermore, DFS also tries to randomly load-balance such access when there are multiple targets available in the client’s site.
There are several ways this process can be configured however. For example, instead of using lowest cost for accessing targets outside the client’s site, you could specify that DFS never use targets outside the client’s site at all. This might be useful, for example, if all the shared resources needed by that site are found locally at that site (or replicated to that site—I’ll cover DFS Replication in a future article). To configure this, right-click on the namespace and select Properties, then switch to the Referrals tab and select the Exclude Targets option as shown in Figure 3:
Figure 3: Preventing clients from accessing targets outside the site of the client
Alternatively, you could leave the namespace configured so referrals outside the client’s site are done using least cost (the default setting) and then override this setting for individual folder targets. For example, right-click on the Accounts Payable folder target, select the Referrals tab, and select the first checkbox as shown in Figure 4 below:
Figure 4: Excluding targets outside the client’s site for a particular target folder
Another way of fine-tuning referrals is to change the priority of the folder targets for a particular folder. Since a folder can have more than one folder target (this is usually used in conjunction with DFS Replication) there is a default ordering to how these targets are returned in a referral. You can override this default ordering by selecting the folder in the console tree, right-clicking one of the targets listed in the Details pane for this folder, selecting Properties, selecting the Advanced tab, and configuring the override settings as desired (Figure 5):
Figure 5: Overriding the folder target order for a folder
For example, you could specify that a particular target is listed first in the referral, as shown in the figure above. Or you could specify it as last if the target is your “server of last resort” i.e. a standby server just in case everything else goes down.
Finally, if your WAN links are unreliable, you might find your clients frequently accessing different targets for the same folder. This can be a problem, for by default, DFS caches referrals for a period of time (300 seconds or 5 minutes) so if a target server suddenly goes down the client will keep trying to connect to the target and give an error instead of making the resource available to the client from a different target. Eventually (by default after 300 seconds or 5 minutes) the referral will expire in the client’s cache and a new referral will be obtained to a target that is online and the client will be able to access the desired resource, but in the meantime the user may grow frustrated since (a) the user has to wait for the referral to expire and (b) after the referral expires and a new one is obtained, the referral may direct the client to access a remote target over the WAN link which is not an optimal situation. To prevent this from happening (especially non-optimal targets), you can configure client failback on the namespace (or on specific folders in your namespace) so that when the failed target comes back online the client will fail back to that target as its preferred target. This setting is also configured on the Referral tab as shown in Figure 4 previously.
Conclusion
In this article and the previous one we’ve looked at how to implement and configure DFS Namespaces, a new feature of Windows Server 2003 R2 that replaces part of the previous DFS component of Windows 2000 and Windows Server 2003. In future articles we’ll examine how to implement the other half of DFS in R2, namely the new DFS Replication component.
If you would like to read Mitch Tulloch’s other DFS articles please go to:
