Distributed File System: Namespace Management Questions
Updated: February 1, 2012
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2
This FAQ answers questions about managing Distributed File System (DFS) namespaces. For other questions, see DFS Namespaces: Frequently Asked Questions.
For a list of recent changes to this topic, see the Change History section of this topic.
Namespace Management Questions
Can I create a DFS folder (link) for a printer?
No. This is not supported.
Can I disable the Distributed File System service on domain controllers?
No, this service is required to provide domain-based namespace referrals and SYSVOL referrals.
Can I enable access-based enumeration on an existing namespace?
You can enable access-based enumeration on existing namespaces in the following conditions:
Standalone namespaces on servers running Windows Server 2008 R2 or Windows Server 2008.
Domain-based namespaces that use the Windows Server 2008 mode (which can be hosted by servers running Windows Server 2008 R2 or Windows Server 2008).
To enable access-based enumeration on a domain-based namespace that uses the Windows 2000 Server mode, you must first migrate the namespace to Windows Server 2008 mode. To do so, see Migrate a Domain-based Namespace to Windows Server 2008 Mode. For information about namespace modes, see Choose a Namespace Type.
Can I host a domain-based DFS namespace in multiple domains?
No. All namespace servers (also known as root targets) for a given domain-based DFS namespace must be in the same domain.
Can I use DFS to selectively hide folders from users who are not authorized to access the folders?
No, DFS Namespaces can’t selectively hide folders. However, you can prevent unauthorized users from viewing folders to which they don’t have permission to access by enabling access-based enumeration on a namespace server. For more information, see Enable Access-Based Enumeration on a Namespace
How can I remove overlapping or duplicate DFS folders (links)?
If a script attempts to create the same DFS folder in a domain-based namespace (Windows Server 2008 mode) at approximately the same time on different namespace servers, the DFS Namespace service could create two identically named folders. These duplicate folders may not have the same list of folder targets, resulting in an inconsistent administrative and user experience where the same DFS folder can point to different folder targets.
This can also occur if a script attempts to create overlapping DFS folders with targets under the same conditions; for example, \\contoso.com\namespace1\products and \\contoso.com\namespace1\products\internal. You can create overlapping folders, but only if the parent folder (in this example \\contoso.com\namespace1\products) doesn’t contain any folder targets.
To determine if you have any duplicate or overlapping folders in a namespace, on a server running Windows Server 2008 and the Distributed File System role service or Remote Server Administration Tools (RSAT), use the Dfsdiag /testdfsintegrity command.
To remove a duplicate or overlapping DFS folder (link), use the following procedure.
To remove overlapping or duplicate DFS folders
Click Start, point to Administrative Tools, and then click ADSI Edit.
On the Action menu, click Connect to, and then specify the naming context where the namespace information resides (usually the Default naming context).
In the console tree, click the Distinguished Name, for example DC=contoso, DC=com.
Click CN=System, and then click CN=Dfs-Configuration.
Click the CN of the namespace that contains the duplicate or overlapping folder, and then click the second level CN of the namespace.
In the Details pane, double-click the name of the duplicate or overlapping folder that you want to delete.
Click the attribute msDFS-LinkPathv2, verify that the value of the logical folder path is a duplicate of another DFS folder or is overlapping another DFS folder, and then click Cancel.
After verifying that the DFS folder is a duplicate or overlapping folder, right-click the relative distinguished name entry and then click Delete to remove the folder from DFS.
If the namespace server is running Windows Server 2008, restart the DFS Namespace service (you don’t need to restart the service if the namespace server is running Windows Server 2008 R2).
To do so, open the Services snap-in, right-click the DFS Namespace service, and then click Restart.
Note
You can also remove duplicate or overlapping folders by using the Dsrm command. To do so, for the ObjectDN, specify the Distinguished Name of the DFS folder. For more information about Dsrm, see Dsrm.
What tools do I use to manage DFS namespaces?
To manage DFS namespaces, you can use the following tools:
| Tool | Description |
|---|---|
A snap-in that manages namespaces hosted by namespace servers running Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2 or Windows Server 2003. |
|
A snap-in available in Windows Server 2003 that manages namespaces hosted by Windows Server 2003. |
|
A command that manages DFS namespaces, server and client computers. |
|
A command that configures DFS folders and folder targets in a DFS namespace. |
|
A command that performs diagnostics tests of DFS Namespaces. |
Namespace Management in a Windows Server 2003 Environment Questions
What are best practices for setting permissions in namespaces?
Follow these guidelines:
Use NTFS permissions to secure DFS targets. If you are using File Replication Service (FRS) to replicate DFS link targets, any NTFS permission changes you make on one member of the replica set replicate to other members. If you are not using FRS for automatic replication, you must set the NTFS permissions on targets and manually propagate any changes that occur. It is also important to set shared folder permissions identically on each target of a particular root or link. Otherwise, user access might be inconsistent depending on which target the client is referred to. Note that FRS does not replicate shared folder permissions, so you must apply or update them manually to each target.
Set NTFS and shared folder permissions for root targets identically on all root servers. This is especially important to remember to do when you add new root targets to an existing namespace.
When setting NTFS permissions, always use the path of the physical folder instead of navigating through the DFS namespace to set permissions. This is especially important when you have multiple link targets for a given link. Setting permissions on a folder by using its DFS path can cause the folder to inherit permissions from its parent folder in the namespace. In addition, if there are multiple link targets, only one of them gets its permissions updated when you use the DFS path.
How do I back up and restore a DFS namespace or move a DFS namespace from one server to another?
You can use Dfsutil.exe to export the namespace from the source server, and then optionally restore the namespace to a destination server.
In the following example, an administrator wants to migrate the following namespaces on different servers to a single server running Windows Server 2003 Enterprise Edition:
\\NT4SVR\Marketing (a stand-alone DFS root on a server running Windows NT Server 4.0)
\\W2KSVR\Public (a stand-alone DFS root on a server running Windows 2000 Server)
First, the administrator creates the following stand-alone DFS roots on the server running Windows Server 2003 Enterprise Edition:
\\2003SVR\Marketing
\\2003SVR\Public
Next, the administrator installs Windows Support Tools from the Windows Server 2003 operating system CD, and then uses the Dfsutil.exe tool to run the following commands:
Dfsutil /Root:\\NT4SVR\Marketing /export:Nt4.txt
Dfsutil /Root:\\W2KSVR\Public /export:w2k.txt
Finally, the administrator runs the following commands to import the namespaces onto the server running Windows Server 2003 Enterprise Edition:
Dfsutil /Root:\\2003SVR\Marketing /import:Nt4.txt /set
Dfsutil /Root:\\2003SVR\Public /import:w2k.txt /set
How do I delete a link folder?
If you used a DFS tool to delete a link, yet the link folder still remains, you cannot delete it using traditional methods (such as by using Windows Explorer) because a reparse point is set on the folder. Morphed link folders that are created when File Replication service (FRS) is enabled on the root also have reparse points. To delete the reparse point from a particular link folder, use the following command to view all link folders on a volume:
dfsutil /viewdfsdirs:<driveletter> /verbose
Identify the link folder whose reparse point you want to remove and then use the following command:
fsutil reparsepoint delete*<linkfolderpath>*
After you delete the reparse point, you can delete the link folder.
Can I use DFS with Offline Files and redirected My Documents folders?
Using DFS, roaming profiles, Offline Files, redirected My Documents, and FRS is supported in the following scenarios (explanatory notes follow the table):
Microsoft Supported DFS, Offline Files, and FRS Deployments
| Scenario | Client Operating System | DFS Only | DFS and Offline Files | DFS and FRS | DFS, Offline Folders, and FRS |
|---|---|---|---|---|---|
Roaming Profiles |
Windows Server 2003 |
Yes(1) |
No(4) |
No(2) |
No(2,4) |
Roaming Profiles |
Windows XP |
Yes(1) |
No(4) |
No(2) |
No(2,4) |
Redirected My Documents |
Windows Server 2003 |
Yes |
Yes(5) |
Not recommended(3) |
Not recommended(3,5) |
Redirected My Documents |
Windows XP |
Yes |
Yes(5) |
Not recommended(3) |
Not recommended(3,5) |
Collaboration Shared Folder |
Windows Server 2003 |
Yes |
Yes(5) |
Depends(6) |
Yes(5,6) |
Collaboration Shared Folder |
Windows XP |
Yes |
Yes(5) |
Depends(6) |
Yes(5,6) |
Publishing Shared Folder |
Windows Server 2003 |
Yes |
Yes(5) |
Yes |
Yes(5) |
Publishing Shared Folder |
Windows XP |
Yes |
Yes(5) |
Yes |
Yes(5) |
If the DFS root is a stand-alone root in a remote site, or a domain-based root with no local targets, the profile might fail to load. To work around this issue, disable slow link detection or install a redundant root target at each client site. For more information, see article 830856 in the Microsoft Knowledge Base.
Roaming profiles that are replicated via FRS to multiple link targets might lead to data loss (due to FRS conflict resolution) if a user logs in to multiple workstations, makes changes to the same file on different targets, and then logs off both workstations.
If there is replication latency between link targets, the users' data might be out-of-date on the other link target, causing users to be confused if they ever fail over to another link target.
Enabling Offline Files on DFS link targets is only supported on client computers running Windows XP and Windows Server 2003. For more information, see article 262845 in the Microsoft Knowledge Base .
Administrators must not enable Offline Files on a path that shares the same first level name as a path used for roaming profiles. For example, if roaming profiles are stored in a domain-based namespace named \\Domain\Roam, Offline Files should not be enabled for a domain-based namespace named \\Domain\Project. Similarly, if roaming profiles are stored on a stand-alone namespace or regular shared folder, such as \\Server\Roam, Offline Files should not be enabled for a path such as \\Server\Other.
Offline Files treats the first level of the path nas if it were a server and caches everything under that "server." In the \\Domain\Roam and \\Domain\Project example above, enabling Offline Files for \\Domain\Project would result in the roaming profiles being cached by Offline Files as well.
FRS does not provide distributed file locking. Depending on the update patterns of users, the lack of distributed locking might cause one user's update to override another user's update. If the collaboration is such that end users are not writing to the same files simultaneously, this most likely would not be an issue.
What tools should I use to manage DFS when I have root servers that run Windows 2000 Server and Windows Server 2003?
Use the Distributed File System snap-in available in Windows Server 2003. This version of the Distributed File System snap-in is also part of the Windows Server 2003 Administration Tools Pack; you can install this pack on computers running Windows XP with Service Pack 1 (SP1) or later..
Use the version of Dfsutil.exe that shipped in Windows Server 2003 Support Tools for command-line administration of Windows Server 2003 DFS. Use the version of Dfsutil.exe that shipped in the Windows 2000 Resource Kit for command-line administration of Windows 2000 DFS.
What are the issues to consider when I use multiple servers running Windows 2000 Server and Windows Server 2003 to host a domain-based DFS root?
DFS handles site information in each of these operating systems differently. Windows Server 2003 family operating systems do not store site information in the DFS Active Directory object; instead, root servers running Windows Server 2003 obtain site information directly from Active Directory.
By contrast, if you have root servers running Windows 2000 Server, those servers try to obtain site information from the DFS Active Directory object. Unless you use the version of Dfsutil.exe included in the Windows Server 2003 Support Tools to manually update the site information in the DFS Active Directory object, the root servers running Windows 2000 Server might provide referrals (based on old site information) that lead to a target outside of the client's site.
The following table describes how DFS root servers handle site information.
How Root Servers Handle Site Information
| Site Aspect | Windows 2000 Server | Windows Server 2003 |
|---|---|---|
Where DFS stores and retrieves site information for root and link targets |
DFS stores a copy of site information for root and link targets in the DFS object in Active Directory. |
DFS uses IP addresses of root and link targets to obtain site information directly from Active Directory. By default, DFS does not store site information in the Active Directory object. |
Characteristic of site information |
Static |
Dynamic |
Method for updating site information after moving a link target to a different site |
Remove the link target from the namespace, and then add it back. |
By default, site information is updated automatically every 25 hours. |
How root servers use site information for referrals |
Root servers running Windows 2000 Server use the link target's site information only if the link target was created by using a DFS tool in Windows 2000 Server. If the link target was created by using a DFS tool in Windows Server 2003, no site information is stored. As a result, a referral from a Windows 2000 root server could lead to a target outside of the client's site. |
Root servers running Windows Server 2003 ignore any site information in the Active Directory object. Instead, they use site information directly from Active Directory. |
We recommend running Windows Server 2003 on every root server for a number of reasons:
Site information is always up-to-date, because DFS obtains site information directly from Active Directory instead of storing a copy of site information in the DFS Active Directory object.
The DFS Active Directory object can hold additional root and link targets, because it does not contain site information.
If you want referrals from root servers running Windows 2000 Server to be ordered according to site information, you can use the /UpdateWin2kStaticSiteTable parameter in the Windows Server 2003 version of Dfsutil.exe to update the static site information for all root and link targets in the DFS Active Directory object. If you plan to use this parameter, review the following information:
Using this parameter increases the size of the DFS Active Directory object, possibly making it exceed the 5-MB recommended size limit.
You need to run this parameter each time one or more of the following tasks is performed:
A new root target, new link, or a new link target for an existing link is added to the namespace.
A link target server is moved from one site to another.
Site information of root targets or link targets is changed in Active Directory.
When all root servers are running Windows Server 2003, you can use the /PurgeWin2kStaticSiteTable parameter in Dfsutil.exe to remove site information from the DFS Active Directory object, providing you with additional space for creating root and link targets.
Is it a best practice to configure one-way File Replication Service (FRS) replication between DFS link targets?
Yes, FRS does support one–way replication between link targets. However, you must be aware of the following caveats for using one–way replication:
To keep the content on all link targets consistent, you must ensure that no changes occur on any servers without outbound FRS connections, because those changes will not be replicated to other servers. In addition, FRS will not update the modified files with changes made on other servers. For example, if Server1 has no outbound connections, and someone changes File1.doc on Server1, the updated version of File1.doc is never replicated to another server. If someone later makes a change to File1.doc on Server2, those changes will not be applied to File1.doc on Server1. To prevent this occurrence, we recommend that you set up share permissions to prevent users from making changes and advise administrators who log on locally to the server to avoid making changes to the files.
Servers without outbound connections will still create change orders in their outbound logs for changes they receive. These change orders and their associated staging files will be kept for seven days by default. You can adjust this duration by modifying the Outlog Change History In Minutes registry entry. To do this, see article 221111 in the Microsoft Knowledge Base.
When setting up one-way replication, use the following best practices:
Make sure you select the desired initial master in the Configure Replication wizard. The initial master's files will be replicated to the other members.
Create a two-way replication topology first, and then remove connections as needed to set up one-way replication between two members.
Make inbound-only replica link targets read-only and warn administrators about modifying content in inbound-only link targets. Do not provide links to read/write shares to clients.
Configure outlog retention on inbound-only servers.
Can DFS and FRS be used in collaboration scenarios where multiple users might change files at the same time?
This is not advised because FRS does not provide distributed file locking. Depending on the update patterns of users, the lack of distributed locking might cause one user's update to override another user's update. If the collaboration is such that end users are not writing to the same files simultaneously, this most likely would not be an issue.
Change History
| Date | Description | Reason |
|---|---|---|
February 1, 2012 |
Edited the Can I enable access-based enumeration on an existing namespace? entry to clarify on which operating systems you can host namespaces that use the Windows Server 2008 mode. |
Customer feedback. |