Distributed File System: Namespace Server Questions
Published: August 3, 2011
Updated: August 3, 2011
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2
This FAQ answers questions about namespace servers in Distributed File System (DFS) namespaces. For other questions, see DFS Namespaces: Frequently Asked Questions.
Stand-alone and domain-based DFS namespace servers store DFS-related information in the registry. All namespace servers also store a copy of the namespace structure on a local volume on the server in DFS root folders and link folders as follows.
When you create a DFS root, you specify a shared folder to use as the root folder. The root folder is accessible on the local server, although we recommend that you keep the root folder as uncluttered as possible. For example, you might place in the root folder a single file such as a readme file, which describes the contents and purpose of the namespace.
When you add DFS folders to the namespace, DFS creates special folders under each root folder. These folders, called link folders, are actually reparse points, and they display the following error message if you try to access them on the local server:
E:\RootName\LinkName is not accessible. The network location cannot be reached.
Users who access the link folders from across the network are redirected to the appropriate folder (link) target.
If you include subfolders in your DFS folder names, such as Groups\Marketing, DFS creates the required subfolders that contain the link folder.
When evaluating the hardware specifications of namespace servers, note that clients access the namespace server to get referrals, and then the clients cache the referrals locally. Therefore, namespace servers do not typically experience high CPU usage. However, as the size of the namespace grows, the DFS service uses more memory, so consider using more than the minimum recommended RAM for servers that host large DFS namespaces and for servers that host multiple DFS namespaces.
When deciding whether to host a DFS namespace on a domain controller, consider the following factors:
Only members of the Domain Admins group can manage a DFS namespace hosted on a domain controller.
If you plan to use a domain controller to host a DFS namespace, the server hardware must be sized to handle the additional load. As described in the previous question, root servers that host large or multiple namespaces require additional memory.
No. DFS takes care of creating the necessary folder structures on each root target. In fact, we recommend against enabling replication on the root, although this step is sometimes done so that data stored in multiple root folders stays synchronized. Instead, it is better to store data in link targets and enable replication on links for the following reasons.
When you enable replication on the root, morphed folders can occur under the DFS root folder. Morphed folders occur when two or more identically named folders on different servers are added to the replica tree. FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of "_NTFRS_xxxxxxxx" where "xxxxxxxx" represents eight random hexadecimal digits.
Morphed folders occur in replicated roots for the following reason: When you create a link in the namespace, DFS creates a link folder under each root folder on every root server. For example, if you add 1,000 links to a namespace, DFS creates a link folder under the DFS root folder for each of those 1,000 links on every root server. When you enable FRS replication on the root, FRS attempts to replicate its local copy of the folder structure to every root server. Because each root server has a local copy of the same folder structure as the incoming changes, FRS identifies the duplicate folder names and renames the folders that were most recently created. FRS then replicates all morphed folders to all root targets in the replica set.
When adding a new root target to an FRS replicated root, you cannot replicate the contents of individual folders in the root based on business priority. Instead, the entire contents of the root are replicated to the new root target. However, if you enable replication only on individual links, you are creating multiple replica sets, which allows you to enable replication on the most important links first, and then enable replication on the links in the namespace as desired.
You cannot take individual root targets offline. For example, if you are adding a new root target, users who are referred to the new member might see incomplete data until replication is complete. However, if you enable replication on individual links, you can take a new link target offline while the initial replication takes place or whenever you want to restrict access to a particular link target.
Use the following procedure to decommission a root server.
Remove the root server from the DFS namespace by using one of the following methods:
In the Distributed File System snap-in, right-click the root target you want to remove, and then click Remove Target.
Using the version of Dfsutil.exe included in the Windows Server 2003 Support Tools, run the following command, where RootTargetServer refers to the root server to be decommissioned:
Dfsutil /UnmapFtRoot /Root:<DFSRoot/Server:<RootTargetServer>/Share:<Share>
- In the Distributed File System snap-in, right-click the root target you want to remove, and then click Remove Target.
On the decommissioned root target, remove DFS information from the registry by using the following Dfsutil.exe command:
Dfsutil /Clean /Server: <RootTargetServer> Share: <RootName>
On the decommissioned root target, at the command prompt, type net stop dfs & net start dfs.
After you remove a root target, DFS stops giving referrals to the decommissioned server within 15 minutes of the update to the DFS Active Directory object on the local domain controller from the PDC emulator master. (This update can take time depending on Active Directory replication schedules.)
To create multiple domain-based namespaces on a server running Windows Server 2003 Standard Edition, install Windows Server 2003 Service Pack 2 (SP2).