Distributed File System (DFS) in Windows Server 2003 Service Pack 1

Applies To: Windows Server 2003 with SP1

What does DFS do?

Distributed File System (DFS) allows administrators to group shared folders located on different servers by transparently connecting them to one or more DFS namespaces. A DFS namespace is a virtual view of shared folders in an organization. Using the DFS tools, an administrator selects which shared folders to present in the namespace, designs the hierarchy in which those folders appear, and determines the names that the shared folders show in the namespace. When a user views the namespace, the folders appear to reside on a single, high-capacity hard disk. Users can navigate the folders in the namespace without needing to know the server names or shared folders hosting the data. DFS also provides many other benefits, including fault tolerance and load-sharing capabilities, making it ideal for all types of organizations

Who does this feature apply to?

Storage administrators managing a DFS namespace, or administrators considering deploying DFS, should be aware of the changes incorporated in SP1.

What new functionality is added to this feature in Windows Server 2003 Service Pack 1?

DFS Consolidation Roots

Detailed description

New functionality in Distributed File System (DFS) maintains the original Universal Naming Convention (UNC) path of files after they are moved to a new server. This reduces the impact of file server consolidation and migration, saves end users time spent searching for files, and ensures that line-of-business applications keep running.

Why is this change important?

There are many scenarios where you will want Universal Naming Convention (UNC) paths to remain unchanged when the underlying files are moved to other servers or to other paths. For example, you may want to preserve the UNC paths that users are accustomed to if you migrate or consolidate your existing file servers to new computers running Microsoft Windows Server 2003. The paths may be embedded in links, in line-of-business applications, and in other places where the names are difficult to change

What works differently?

The consolidation root functionality is most easily configured using the File Server Migration Toolkit, available on the Microsoft Web site at https://go.microsoft.com/fwlink/LinkId=37029.

This functionality can also be configured manually by modifying keys in the Windows Registry, as described in the article about using the Distributed File System update to support consolidation roots at the Microsoft Web site at https://go.microsoft.com/fwlink/LindId=43006.

Move and Rename Support for DFS Namespaces

Detailed description

Administrators can modify the DFS namespace to correct mistakes or to adjust the hierarchy as business needs change or as new folders are added to the namespace.

Why is this change important?

Prior to Windows Server 2003 Service Pack 1, there was no way for administrators to rename elements of their namespace. Renaming or moving an element near the top of the namespace was particularly difficult as it required manually deleting and recreating every element below it.

What works differently?

DFS administrators may now use the command-line utility dfscmd to move or rename links. The syntax for this new command is as follows:

**dfscmd /move \\DFSName\DFSShareName\**Path **\\ServerName\ShareName\**Path

The following examples illustrate the different ways that this command can be used:

• To create a new folder, move the contents of an existing folder into it, and adjust any links under the folder as appropriate:

  dfscmd /move \\domain\root\old_folder \\domain\root\new_folder

• To make an existing folder a subfolder of a new top-level folder and adjust any links under the folder as appropriate:

  dfscmd /move \\domain\root\old_folder \\domain\root\new_top_folder\old_folder

• To move the contents of one folder to another existing folder

  dfscmd /move \\domain\root\folder \\domain\root\other-folder\

Client Failback

Detailed description

Client failover in DFS namespaces is the process in which clients attempt to access another server in a referral after one of the servers fails or is removed from the namespace. DFS administrators can specify that clients "failback" to a preferred, local server when it is restored. The target failback policy may be set for the entire root, or for individual links.

Why is this change important? What threats does it mitigate?

Prior to Windows Server 2003 Service Pack 1, there was no way for administrators to configure clients to fail back to their local servers; this behavior can be problematic in branch office environments when clients continue to access the hub server even after the branch server is restored.

What works differently?

The failback settings for roots and links can be set using the /TargetFailback option of dfsutil. In addition, the DFS Client Failback hotfix for Windows XP and Windows Server 2003 must be installed to enable the client to perform the failback.

Setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters\SysvolNetlogonTargetFailback registry key and restarting the DFS service on the domain controller enables target failback for SYSVOL/NETLOGON referral requests handled by that controller.

Target Priority

Detailed description

Target priority enables DFS administrators to explicitly assign the priority of a DFS link or root target.

Why is this change important? What threats does it mitigate?

Prior to Windows Server 2003 Service Pack 1, administrators had no way of designating preference between servers that host the same data in a namespace. To work around this, administrators created special subnets for such servers and artificial sites in Active Directory with high link cost. This workaround is time consuming, complex, and leads to increased support costs.

DFS management APIs have been added to configure whether a server appears first or last in a referral, which is the list of servers returned to the client for a given folder (link) in the namespace. Assigning target priority is useful in many scenarios, such as “hot-standby” scenarios where one server is considered the server of last resort. In this scenario, the administrator specifies that the standby server always appears last in referrals, and clients will fail over to this server only if all the other servers fail or become unavailable due to network outages.

What works differently?

Targets in a DFS referral response are grouped into sets based on the cost of accessing targets from a client. Within each set, targets are shuffled randomly and these sets are ordered by increasing cost from the DFS client. Prior to Windows Server 2003 SP1, the number of sets in the referral response depended on whether or not Windows Server 2003 site costing was enabled. With site costing disabled there are exactly two sets, one set containing targets in the same site as the DFS client and the other set containing the remaining targets. With site costing enabled sets are grouped on the basis of actual site cost of the target from the DFS client, and hence there could be many more of these sets. Note that there is no information in the current DFS V1, V2, or V3 referral responses that allows a DFS client to identify these sets.

With server target priority, these sets will still be based on the cost of accessing targets. Server target priority simply extends the cost sorting criteria for targets, so the sets are now those targets having the same site cost and server target priority. In addition, the new V4 protocol will indicate where the set boundaries are in the target list.

Server target priority is broken out into two values: a priority class and a priority rank. Priority classes are defined at two levels: locally, within sets of targets of equal site cost, and globally. Within each of these, there is a coarse ordering of high, normal and low priority targets. This gives us five priority classes in the following order:

• Global high

• Site-cost high

• Site-cost normal

• Site-cost low

• Global low

Note that there is no separate “global normal”. If global high or global low is not specified then the referral is placed in the "global normal" set. Priority rank is evaluated by a simple integer ranking – 0, 1, 2, and so forth.

In ordering a referral, the complete process now works as follows:

• The sets of global high and global low targets are identified, along with the remaining “global normal” targets.

• These three sets are placed in order – global high, normal and low.

• If set, INSITE is applied to the “normal” set and targets outside the client’s site are removed. It is not applied to global high and global low.

• Within each of these three sets, the targets are ordered by the site cost mechanism (either local site or by full site costing), producing sets of targets of equal site cost

• Within the sets of “global normal” targets of equal site cost, targets are ordered by priority class – site cost high, normal and low.

• Within the sets of targets of equal site cost and priority class, targets are now ordered by priority rank (0 being the highest).

• Within the sets of targets of equal site cost, priority class, and priority rank, targets are randomly shuffled for load balancing.

The /targetpriority option of dfsutil can be used to set the priority options listed above.

What existing functionality is changing in Windows Server 2003 Service Pack 1?

Better Delegation

Detailed description

As of Windows Server 2003 Service Pack 1, administrators may delegate the ability to manage domain DFS roots by setting rights to the DFS object in Active Directory. Administrators may also delegate the ability to manage stand alone DFS roots by setting rights to the DFS object in the registry. This is in addition to the existing delegation model of adding DFS administrators to the local Administrators group on every server that hosts the namespace.

Why is this change important?

In the previous versions of Windows Server 2003, administrators who want to delegate the ability to manage a namespace must make the user a member of the local Administrators group on every server that hosts the namespace. This requirement can lead to an inconsistent management experience if the group memberships are not assigned correctly, and it also allows the user full access to the local file system of each namespace server.

What works differently?

The following procedures have been updated as a result of this change in functionality:

To grant a user permission to administer only a domain DFS namespace:

1. In the Active Directory Users and Computers MMC snap-in, on the View menu, click Advanced Features.

2. In the console tree, double-click the System folder to expand it.

3. Click the DFS-Configuration folder.

   Any existing root objects appear in the details pane.

4. Right-click the root object that you want to allow the user to administer, and then click Properties.

5. On the Security tab, click Add.

6. Type the name of the user, and then click OK.

7. Verify that the user is granted the Full Control permission, and then click OK.

To grant a user permission to administer a standalone DFS namespace

1. Using regedit, locate the following key:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Standalone

2. Right-click the root object you want to allow the user to administer, and then click Permissions…

3. On the Security tab, click Add.

4. Type the name of the user, and then click OK.

5. Verify that the user is granted the Full Control permission, and then click OK.

Referral Time to Live Values Are Not Renewed for DFS Clients

Detailed description:

For DFS clients that are not running Windows XP with SP2 or Windows Server 2003 with SP1, the Time to Live for a referral determines the earliest time that a client will request a new referral, but only if the existing referral expires before it is accessed again. Clients that use a cached referral will renew the Time to Live 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 and Windows Server 2003 with SP1. Specifically, the Time to Live value is not renewed each time a client accesses a target using a cached referral. Instead, the referral expires after the Time to Live value lapses.

Why is this change important?

This change allows DFS clients running Windows XP with SP2 or Windows Server 2003 with SP1 to honor the actual Time to Live value of a referral. One benefit of this change is that DFS clients running these service packs will more quickly react to changes to links and roots. For example, if the link targets of a link named Current are changed daily, DFS clients without these service packs would refresh the Time to Live value each time they access the Current link, causing them to continue to reference stale link targets well beyond the Time to Live value associated with the initial referral request.

What works differently?

This change has several effects:

• Clients running Windows XP with SP2 or Windows Server 2003 with SP1 will request referrals more frequently than other DFS clients, which can cause moderately increased load on the domain-based DFS root servers, stand-alone root servers, and domain controllers.

• Because they request new referrals more frequently, clients running Windows XP with SP2 or Windows Server 2003 with SP1 will discover namespace updates more quickly than other DFS clients.

• In terms of DFS failover, this new behavior can cause the DFS client to fail over to a new target if the previously active target is not in the new referral, such as when the namespace is changed to remove the target that the client had accessed.

Service Disabled By Default

Detailed description

The DFS service is disabled by default in Windows Server 2003 Service Pack 1.

Why is this change important?

Unnecessary services are disabled by default in Windows Server 2003 SP1 to reduce the attack surface of the server.

What works differently?

Computers that are new installations of Windows Server 2003 with Service Pack 1 will have the DFS service disabled by default.

Upgrading a computer that is running Windows Server 2003 by installing Service Pack 1 will result in the DFS service being disabled unless the server is either a domain controller or is already hosting an existing DFS root.

When a server running Windows Server 2003 Service Pack 1 is promoted to domain controller status, the DFS service is enabled.

What settings are added or changed in Windows Server 2003 Service Pack 1?