Distributed File System: Frequently Asked Questions

Distributed File System (DFS) allows administrators to group shared folders located on different servers and present them to users as a virtual tree of folders known as a namespace. A namespace provides numerous benefits, including increased availability of data, load sharing, and simplified data migration.

Changes to DFS in Windows Server 2003 SP1 are described in the document titled "Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1". New features include DFS consolidation roots, target failback, target priority, and the ability to move and rename links. Improvements include better delegation and a change that allows the Time to Live value to expire without being refreshed in some clients. (See the question "How has the Time to Live (TTL) value for referrals changed in DFS clients running Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with Service Pack 1 (SP1)?," below, for more details.)

The information provided in this article is covered in more detail in Chapter 2, "Designing and Deploying File Servers," of the Windows Server 2003 Deployment Kit. To download this book, see Windows Server 2003 Deployment Kit: Planning Server Deployments in the Microsoft Download Center.

For technical information about DFS, see the DFS Technical Reference at the Microsoft Web site.

Site discovery, also called site awareness, is the process that DFS uses to determine which site a root target, link target, or client belongs to. A site is one or more TCP/IP subnets as defined in Active Directory. DFS uses this site information to determine the order in which to order the targets in a referral.

Detailed information about the site discovery process is described in the section "How Site Discovery Works" in the DFS Technical Reference.

In Windows Server 2003, DFS offers three methods of target selection: default target selection, restricted same-site target selection, and least expensive target selection (also called site-costing).

Default Target Selection

By default, DFS lists referrals in the following order:

Essentially, the client connects to a target in its site if a target is available. If no targets are available in the client's site, the client connects to a random target outside its site regardless of the bandwidth cost, connection speed, or the target server's processing load.

Restricted Same-site Target Selection

By using Dfsutil.exe with the /InSite parameter, you can limit client access to only those targets that are in the same site as the client. You enable this feature on a DFS root or on individual links in the namespace. If you enable this feature on the root, referrals for any link in the namespace return only targets that are in the same site as the client. If this functionality is disabled on the root, the individual settings on each link are used.

When using this feature, plan to have at least one target (or at least two targets, for fault tolerance) in every site, and plan to monitor servers to make sure they are online and accessible. If no same-site targets exist, clients in that site are denied access to the data in the namespace.

The /InSite parameter takes effect after you stop and restart the DFS service on each root server or when the service reads the DFS metadata, which happens every hour by default. Also, note that the /InSite parameter does not work for links that point to a domain-based DFS namespace (this type of link is known as an interlink). As a result, clients can access a target outside of the client's site if the interlink points to a domain-based DFS namespace.

Least Expensive Target Selection (Site-costing)

If you create a stand-alone or domain-based DFS root on a server running Windows Server 2003, and the domain controller acting as the Intersite Topology Generator (ISTG) is also running Windows Server 2003, you can use the /SiteCosting parameter in Dfsutil.exe to enable DFS to choose an alternate target based on connection cost if no same-site targets are available.

Windows Server 2003 uses the site and costing information in Active Directory to determine whether sites are linked by inexpensive, high-speed links or by expensive wide area network (WAN) links.

When site-costing is not available, the default target selection method is used instead as in the following situations:

If you plan to enable site-costing, review the following factors:

For more information, see the question, "Can I use multiple servers running Windows 2000 Server and Windows Server 2003 to host a domain-based DFS root?"

Target selection in Windows 2000 Server is limited to default target selection and restricted same-site target selection, whereas Windows Server 2003 additionally supports least expensive target selection (site-costing).

Site discovery in Windows 2000 Server differs from site discovery in Windows Server 2003 in a number of ways:

You use the command-line tool Dfsutil.exe that is included in the Windows Server 2003 Support Tools. Use the following syntax:

Dfsutil /Root:‹DfsName› /SiteCosting /Enable

You can run this command from any computer running Windows XP or Windows Server 2003 where the Windows Server 2003 Support Tools are installed. For example, to enable least expensive target selection on the \\Contoso.com\Public namespace, at the command prompt type:

Dfsutil /Root:\\Contoso.com\Public /SiteCosting /Enable

For more information about using Dfsutil.exe, see the Windows Support Tools Help for Dfsutil.exe.

Root servers that run Windows 2000 Server or Windows Server 2003 and that are not domain controllers cannot determine a DFS client computer's site when the restrictanonymous registry entry is set to 2 on domain controllers running Windows 2000 Server. (This registry entry is located at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa.) As a result, these DFS root servers sort targets in link referrals and root referrals randomly, regardless of the namespace type (stand-alone or domain-based), target selection method, or client operating system.

Windows shell displays this message when you try to run an executable file from any path that includes a fully qualified domain name, regardless of whether the path is hosted by DFS. To prevent this message from occurring, add the domain to the list of trusted intranet zones on the client.

Even when least expensive or same-site target selection is enabled, clients might still access high-cost or out-of-site targets. Also, when default target selection is enabled, a client computer might access a target server outside of its own site, even though a same-site target exists. These problems are typically caused by one of the following situations:

Clients running the following operating systems can access stand-alone and domain-based DFS namespaces:

The following operating systems have additional requirements for accessing DFS namespaces:

Client "stickiness" refers to the behavior that occurs after a client receives a refreshed referral after the current referral expires. DFS looks to see if the current active target is also in the new referral. If it is, the target is marked active in the new referral, and the client "sticks" to this target, even if more desirable (e.g., lower cost) targets appear in the new referral.

Client stickiness was designed into DFS for a purpose: to give end users a consistent experience as they read and write files on a target in the namespace. If the client computer were to connect to a different target each time the referral expired, the end user might see different files on the new target depending on whether replication has completed with respect to the previous target. In addition, any open handles to the previous target would be maintained (assuming Offline Files is not used), so clients could potentially access both targets while reading and writing different files.

In some situations, though, client stickiness is not desirable. For example, if a client fails over from a local server to a remove server (such as when the local server fails), the client will continue to access the remote server, even after the local server is restored. The new client failback functionality in Windows Server 2003 SP1 was designed to give administrators more control over failback, allowing them to configure clients to fail back to a local target after the client’s referral expires. Handles to the remote server will still be maintained if Offline Files is not used, however, so this feature should only be used when the need for clients to access a local server outweighs the issues described earlier.

Note: Client failback and its interaction with Offline Files are described in more detail in the Filing Cabinet blog at https://blogs.technet.com/filecab/archive/2006/03/27/423269.aspx.

Stickiness is also an important consideration for laptop computers that are taken from one site to another and are frequently hibernated. When the laptop comes out of hibernation, it will prefer the active target from the previous site unless the laptop is rebooted or has its cache cleared using the dfsutil pktflush command.

For DFS clients that are not running Windows XP with SP2 or Windows Server 2003 with SP1, the Time to Live (TTL) value for referrals determines the earliest time that a client will request a new referral if the existing cached referral expires before it is accessed again. Clients that use a cached referral will renew the TTL value of the referral and, thus, use the referral indefinitely until the client's referral cache is cleared or the client is restarted.

This behavior has changed for clients running Windows XP with SP2 or Windows Server 2003 with SP1. Specifically, the TTL value is not renewed each time a client accesses a target using a cached referral. Instead, the referral expires after the TTL value lapses. One benefit of this change is that DFS clients running Windows XP with SP2 or Windows Server 2003 with SP1 will more quickly discover changes to links and roots. For example, if the link targets of a link named Current are changed daily, DFS clients without Windows XP with SP2 or Windows Server 2003 with SP1 would refresh the TTL value each time they access the Current link, causing them to continue to reference stale link targets well beyond the TTL value associated with the initial referral request.

This change has several effects:

The following table describes the DFS size limits and recommendations for Windows Server 2003.

DFS Size Limits and Recommendations

* The figures in this table are based on information gathered in a test environment. The numbers in an operational DFS configuration might exceed the numbers described here and still provide acceptable performance.

Use 16 or fewer root targets unless you enable root scalability mode by using the /RootScalability parameter in Dfsutil.exe. When root scalability mode is enabled, DFS root servers get updates from the closest domain controller instead of from the server acting as the primary domain controller (PDC) emulator master. As a result, root scalability mode reduces network traffic to the PDC emulator master at the expense of faster updates to all root servers. With this mode enabled, you can have as many root targets as you need, as long as the size of the DFS Active Directory object (for each root) is less than 5 MB.

Note that the PDC emulator master is not removed entirely from DFS operations. The PDC emulator master is still used as follows:

Do not use root scalability mode if any of the following conditions exist in your organization:

Note: The number of root targets running Windows 2000 should be limited to 16 for any one namespace. After you enable root scalability mode in a namespace with root servers running Windows 2000 and Windows Server 2003, root servers running Windows 2000 Server still obtain updates from the PDC emulator master.

You can use the command-line tool Dfsutil.exe that is included in the Windows Server 2003 Support Tools. Use the following syntax:

Dfsutil /Root:‹\\dfsname\root› /View

You can use the following methods:

Windows Server 2003 supports creating links that point to other DFS namespaces. This kind of link is often referred to as an interlink. Instead of specifying a shared folder as a link target, you can specify a DFS root or link within another namespace, allowing you to create a hierarchy of namespaces, also called a cascaded DFS. Linking to other namespaces is often done in the following scenarios:

When linking to other namespaces, you must follow these guidelines to make certain that clients can be redirected properly if a target is unavailable:

Important: The DFS tools do not prohibit you from specifying domain-based DFS roots or shared folders as alternate targets. Therefore, follow these guidelines carefully.

When linking to other namespaces, review the following restrictions:

Each element in the namespace (root name, link name, target path, and comments) takes up space in the DFS Active Directory object. The amount of space can vary depending on the number of characters used in each element. The following formula assumes that each element is 10 characters:

For example, if you create a root (300 bytes) with 3 root targets (150 bytes × 3) and then add 100 links (100 × 320 bytes) with each link having 3 link targets (100 × 120 bytes × 3), the DFS Active Directory object will be approximately 300 + (150 × 3) + (100 × 320) + (100 × 120 × 3) = 67 kilobytes (KB) in size.

No. This is not supported.

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.

Stand-alone and domain-based DFS root servers store DFS-related information in the registry. All root 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.

Root Folders

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.

Link Folders

When you add links to the root, 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 link target.

If you include subfolders in your link names, such as Groups\Marketing, DFS creates the required subfolders that contain the link folder. For example, when you browse the namespace structure under E:\RootName on the local server, you can open the subfolder E:\RootName\Groups, but you cannot open the link folder E:\RootName\Groups\Marketing.

When evaluating the hardware specifications of the servers that host DFS roots, note that clients access the root server to get referrals, and then the clients cache the referrals locally. Therefore, root 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 root on a domain controller, consider the following factors:

Use the following procedure to decommission a root server:

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 the hotfix described in article 903651 in the Microsoft Knowledge Base on the Microsoft Web site.

No, this service is required to provide domain-based namespace referrals and SYSVOL referrals.

Follow these guidelines:

The following table describes the permissions required to administer DFS namespaces.

Permissions or Group Memberships Required to Administer DFS Namespaces

^*To ensure that the administrator can reliably administer the namespace, we recommend that the administrator be a member of the local Administrators group on each root server. If a DFS administration tool sends a request to a root server on which the administrator is not a member of the local Administrators group, the request will fail. If the administrator is a member of the local Administrators group on some but not all root servers, the administrator's ability to administer the namespace will be inconsistent.

The procedures below can be used to allow members of the local Administrators group on each root server to create and manage domain-based DFS namespaces.

To grant a selected user the ability to create new DFS namespaces as well as administer existing ones, do the following:

To allow a user to administer only within a single DFS namespace, do the following:

Three tools are used for managing DFS namespaces: the Distributed File System snap-in, dfscmd.exe, and dfsutil.exe.

Distributed File System Snap-in
The Distributed File System snap-in is available in Windows Server 2003 in the Administrative Tools folder. This snap-in provides a graphical user interface for configuring namespaces and is the only tool available for enabling FRS replication in DFS namespaces.

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 Service Pack 1 (SP1) or later and create FRS schedules and topologies on remote servers running Windows 2000 and Windows Server 2003. For more information, see Administering Windows Server-based Computers Using Windows XP Professional-based Clients.

Dfscmd.exe
The Dfscmd.exe command-line tool is available in Windows Server 2003. Use Dfscmd.exe for basic DFS tasks, such as creating links, adding and removing link targets, and viewing the namespace. For more information about Dfscmd.exe, in Help and Support Center for Windows Server 2003 click Tools, and then click Command-line reference A-Z.

Dfsutil.exe
The Dfsutil.exe command-line tool is a Windows Support Tool. You can install Dfsutil.exe from the \Support\Tools folder on the Windows Server 2003 operating system CD. Dfsutil.exe provides extensive features for configuring and managing DFS, including those that are not available in the Distributed File System snap-in, such as root scalability mode and least expensive target selection (site-costing).

For more information about Dfsutil.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools.

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:

First, the administrator creates the following stand-alone DFS roots on the server running Windows Server 2003 Enterprise Edition:

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:

Finally, the administrator runs the following commands to import the namespaces onto the server running Windows Server 2003 Enterprise Edition:

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.

No, DFS does not support this functionality.

Using DFS, roaming profiles, Offline Files, redirected My Documents, and FRS is supported in the following scenarios (see below for the corresponding number references):

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. For more information, see Knowledge Base article Administering Windows 2000-Based and Windows Server 2003-Based Computers Using Windows XP Professional-Based Clients.

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.

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.

We recommend running Windows Server 2003 on every root server for a number of reasons:

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:

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.

Yes, FRS does support one–way replication between link targets. However, you must be aware of the following caveats for using one–way replication:

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.

Yes, for instructions, see article 907458 in the Microsoft Knowledge Base. For more information about access-based enumeration, see Windows Server 2003 Access-based Enumeration and Windows Server 2003 Access-based Enumeration Tools.

No. All root targets for a given domain-based DFS root must be in the same domain.

DFS clients periodically discover new domains in the local forest and in trusted forests. This discovery process, which occurs every 15 minutes by default, runs against a domain controller from the domain that hosts the client's computer account. To avoid real-time queries to domain controllers in the domain, the referrals received during the discovery process are stored in a special table, called the domain cache or SPC cache. As a result of this process, clients can more quickly distinguish queries for fully qualified domain names from fully qualified computer names.

To determine the domains and forests in which a client can access domain-based namespaces, you can view the domain cache on a client computer by using the Dfsutil.exe command-line tool with the /spcinfo parameter. The following text illustrates the output displayed when you use this command.

[*][dc-01.contoso.com]
[*][CONTOSO]
[*][contoso.com]
[+][contoso.com]
     [-dc-02.contoso.com]
     [+dc-01.contoso.com]
     [-dc-04.contoso.com]
     [-dc-03.contoso.com]
[-][AFRICA]
[-][EUROPE]
[+][CONTOSO]
     [-DC-02]
     [+DC-01]
     [-DC-03]
     [-DC-04]
[-][europe.contoso.com]
[-][africa.contoso.com]

The preceding sample output can be interpreted as follows:

If an organization has a large number of trusted domains and forests, it is possible that clients will not be able to access all domain-based namespaces within the trusted domains and forests. This limitation can occur when the list of trusted domains and forests is too large to fit in the client's buffer. By default, DFS clients send a 4-KB (2,048 Unicode character) buffer to a domain controller when requesting domain name referrals. If the list of domains is too large to fit into the 4-KB buffer, DFS clients automatically increase their buffer size to accept the list of domains, up to a maximum of 56 KB.

If the list of domains exceeds 56 KB, DFS puts as many domains in the buffer as it can until the buffer reaches 56 KB. DFS then writes an entry with the ID 14536 in the system event log of the domain controller that provided the domain referral. When populating the buffer, DFS gives preference to local and explicitly trusted domains by filling the buffer with their names first. Consequently, by creating explicit trust relationships with domains that host important DFS namespaces, you can minimize the possibility that those domain names might be dropped from the list that is returned to the client.

When populating the cache, DFS gives preference to local and explicitly trusted domains by filling the cache with their names first. Consequently, by creating explicit trust relationships with domains that host important DFS namespaces, you can minimize the possibility that those domain names might be dropped from the list that is returned to the client.

Important: To make sure that clients can access link targets in other trusted domains or trusted forests, you must use DNS names for all link targets and configure DFS to use fully qualified domain names in referrals. For more information, see How to Configure DFS to Use Fully Qualified Domain Names in Referrals.

Yes, if you are a member of the Enterprise Admins group, you can configure FRS replication on a DFS link whose targets are in different domains in the same forest. If you are not a member of the Enterprise Admins group, permissions must be configured as follows:

If any of these permissions are not configured correctly, you will get an Access Denied message when you try to enable replication by using the Configure Replication Wizard in the Distributed File System snap-in.

For more information, see article 296183, Overview of Active Directory Objects That Are Used by FRS.

The answer depends on type of namespace: stand-alone or domain-based.

For stand-alone DFS namespaces, you ensure the availability of a stand-alone DFS root by creating it on the cluster storage of a clustered file server by using the Cluster Administrator snap-in.

For domain-based DFS namespaces, you ensure the availability of domain-based DFS roots by creating multiple root targets on nonclustered file servers or on the local storage of the nodes of server clusters. (Domain-based DFS roots cannot be created on cluster storage.) All root targets must belong to the same domain. To create root targets, use the Distributed File System snap-in or the Dfsutil.exe command-line tool.

To ensure the availability of domain-based DFS roots, you must have at least two domain controllers and two root targets within the domain that is hosting the root. If you have only one domain controller and it becomes unavailable, the namespace is inaccessible. Similarly, if you have only a single root target, and the server hosting the root target is unavailable, the namespace is also unavailable.

There are two ways to increase the availability of data in link targets:

You can create link targets that point to clustered file servers in both types of namespaces. However, if you want to replicate content among multiple link targets, the type of namespace determines your replication options.

Using Replication in Stand-alone DFS Namespaces
In a stand-alone DFS namespace, you can replicate the files by copying them manually, using scripts, using Robocopy.exe, which is available in the Microsoft Windows Server 2003 Deployment Kit, or by using other replication tools. The Distributed File System snap-in does not provide a user interface for configuring FRS replication in stand-alone DFS namespaces. To configure replication manually, consult the documentation supplied with your replication tools.

Using Replication in Domain-based DFS Namespaces
The Distributed File System snap-in in Windows Server 2003 provides a user interface for creating the FRS topology and schedule on servers running Windows Server 2003. Using FRS in a domain-based DFS namespace is optional; you can also replicate files by copying them manually or by using non-Microsoft replication tools.

If a DFS client attempts to access a previously used target, and that target is unavailable, the DFS client works down through its referral list for the next available target. This process is often referred to as link target or root target failover. If the client reaches the end of the referral list (that is, there are no available targets), the DFS client fails the request.

Because stand-alone DFS namespaces can have only one root target, no failover occurs if the stand-alone root server is not available; in that case, clients cannot access the namespace.

For link target failover to work correctly, each link can have targets that correspond to only one of the following locations:

For root target failover to work correctly, clients must access a domain-based DFS namespace by using the format \\DomainName\RootName, not \\RootServerName\RootName.