In recent years, Microsoft has made several improvements to its Distributed File System (DFS), a technology that, in part, provides a unified view of file system resources.
The UNC path that redirects requests to a file's actual location is the DFS namespace. In essence, a DFS namespace is a unified namespace that presents users with a centralized view of file server resources. There are several parts that make up a DFS namespace.
The DFS root
A DFS namespace is hierarchical in nature, with the DFS root at the top. For all practical reasons, the root and the namespace can be considered the same since the root is commonly used to refer to the namespace as a whole. The DFS root is a shared folder, which must exist on an NTFS volume.
The DFS root is linked to one or more root targets, and a root target is linked to a UNC share on a file server. The number of root targets a DFS root can link to depends on the type of namespace associated with the DFS root. There are two types of DFS namespaces -- standalone namespaces and domain-based namespace.
Standalone namespaces store their configuration information in the host server's registry. Domain-based namespace store this information in the Active Directory database. This difference affects the number of root targets that can connect to a DFS root. Standalone DFS roots can only contain a single root target, while domain-based DFS roots can contain multiple root targets spread across several servers.
Figure 1 below shows a domain-based DFS root. It is clear that this is domain-based because the root name (\\lab.com\namespace) reflects the name of the domain. The center pane displays two UNC paths, and both of these paths are connected to the DFS root as root targets.
Folders or links in a DFS namespace
The next element in the hierarchy is the folder or – as it's sometimes referred to – the link. Each folder in a DFS namespace maps to a link target – just as the DFS root maps to root targets. The link target points to a UNC share that is mapped to a physical folder.
In Figure 2, three folders --Folder1, Folder2 and Folder 3 – are defined beneath the DFS root (notice I have selected Folder1.) The console's center pane lists the link target mapped to the folder.
As you can see, the link target is nothing more than a UNC path mapped to a shared folder. Furthermore, notice that in the console's center pane there's a variety of information displayed for the link target, including type, path, and referral status.
The referral status exists because a folder can be joined with multiple link targets on separate servers. After doing so, you could create a replication group for the link target, and the replication group would keep the contents of the various folders synchronized with each other. Figure 3 shows a folder with multiple link targets.
The referral status for both link targets is Enabled. This means DFS can refer resource requests to either target. Therefore, if one of the file servers had to be taken offline for maintenance, referrals for that server could be disabled and DFS would stop sending requests to the server until referrals were re-enabled.
DFS namespace at the NTFS level
The above elements make up a DFS namespace. In Figure 4, you can see what the namespace looks like at the NTFS level.
Notice the folder named Dfsroots, and the folder below it named Namespace. DFS automatically created these folders when I created the root. The Namespace folder is actually shared, but the file system hides the share.
Finally, notice that below the namespace there are shortcuts to Folder1, Folder2 and Folder3. These are the target folders specified in the DFS management console. At the bottom of the figure is another listing for the three folders, which are the actual shared folders on the C: drive. The shortcuts that I pointed out a moment ago map to these shared folders.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.
This was first published in February 2010