Designing a DFS Namespace

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

As you design one or more DFS namespaces for your organization, you need to make a number of decisions about the structure and capacity of the namespaces. For an Excel spreadsheet to assist you in documenting your DFS namespace decisions, see "DFS Configuration Worksheet" (Sdcfsv_1.xls) on the Windows Server 2003 Deployment Kit companion CD (or see "DFS Configuration Worksheet" on the Web at https://www.microsoft.com/reskit).

Determining Who Can Manage the Namespace

You can delegate administrative authority to individual users so that they can manage a DFS namespace. Table 2.4 describes the permissions and group memberships that you must delegate before users can manage a namespace on a member server. Administering DFS namespaces on a domain controller or configuring FRS replication requires membership in the Domain Admins group.

Table 2.4   Permissions or Group Memberships Required to Administer DFS Namespaces

Task Permissions or Group Membership Required

Creating or removing a domain-based DFS root on a member server.

One of the following:

  • Membership in the Domain Admins group.

  • Full Control permission on the DFS-Configuration container in Active Directory and membership in the local Administrators group on the root server.

Adding or removing a root target from an existing domain-based DFS root on a member server.

One of the following:

  • Membership in the Domain Admins group.

  • Full Control permission on the DFS-Configuration container in Active Directory and membership in the local Administrators group on the root server.

Creating or deleting a stand-alone DFS root on a member server.

Membership in the local Administrators group on the root server.

Adding a link to a domain-based DFS namespace or adding a target to an existing link on a member server.

Membership in the local Administrators group on each of the root target servers.

Removing a link from a domain-based DFS namespace or removing a target from an existing link on a member server.

Membership in the local Administrators group on each of the root target servers.

Changing root-related or link-related information, such as comments, referral status, and cache limits on a member server.

Membership in the local Administrators group on each of the root target servers.

Performing any of the tasks in this table on a domain controller.

Membership in the Domain Admins group.

Enabling replication on links in a domain-based DFS namespace.

  • Membership in the Domain Admins group.

You can also limit delegated authority to just one domain-based DFS namespace on a member server by granting a user or group Full Control permission on the DFS root object contained in the DFS-Configuration container. Doing so allows the administrator to add or remove root targets from a specific namespace. For more information about how to delegate permission to manage a DFS namespace, see "Deploying DFS" later in this chapter.

Selecting Servers to Host Roots

Table 2.5 describes the guidelines for servers hosting stand-alone DFS roots and domain-based DFS roots.

Table 2.5   Guidelines for Servers That Host DFS Roots

Server Hosting Stand-Alone DFS Roots Server Hosting Domain-based DFS Roots
  • Must contain an NTFS volume to host the root.

  • Can be a member server or domain controller.

  • Can be a general-purpose server or Windows Powered Network Attached Storage.

  • Can be a clustered file server.

  • Must contain an NTFS volume to host the root.

  • Must be a member server or domain controller in the domain in which the DFS namespace is configured. (This requirement applies to every root target for a given domain-based DFS namespace.)

  • Can be a general-purpose server or Windows Powered Network Attached Storage.

  • Cannot be a clustered file server unless you host the domain-based DFS root on the local storage of a node in the server cluster.

The following sections provide other factors to consider when selecting root servers.

Restrictions for servers running Windows Server 2003, Standard Edition

If you are using servers running Windows Server 2003, Standard Edition, you can create only one DFS root per server, which means that you need one server for each root you plan to host.

Root servers that have the RestrictAnonymous registry value

Before you create a DFS root on a server, verify that the RestrictAnonymous registry value is not set on the server. This registry value restricts anonymous access and causes DFS referral failures. For more information about this registry value, see "Planning DFS and FRS Security" later in this chapter.

Root server performance

When evaluating the hardware specifications of the servers that host 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. For more information about choosing RAM and CPU speed for file servers, see "Determining RAM and CPU Specifications" later in this chapter.

Important

  • Servers running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition can host multiple roots of any type (stand-alone or domain-based). However, as you increase the number of roots (namespaces) on a server, you also increase the number of namespaces that will be unavailable if the server fails. Therefore, devise a plan that allows you to increase the availability of the namespaces. For more information, see "Increasing the Availability of DFS Namespaces" later in this chapter.

Hosting roots on domain controllers

When deciding whether to host a DFS root 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 root, the server hardware must be sized to handle the additional load. As described earlier, root servers that host large or multiple namespaces require additional memory. For information about capacity planning for domain controllers, see "Planning Domain Controller Capacity" in Designing and Deploying Directory and Security Services of this kit.

Using root servers running Windows 2000 Server and Windows Server 2003

If you plan to host a domain-based DFS root on servers running a mix of Windows 2000 and Windows Server 2003, you need to understand how DFS handles site information in each of these operating systems. These differences are important because Windows Server 2003 does not store site information in the DFS Active Directory object; instead, root servers running Windows Server 2003 obtain site information directly from Active Directory. If you have root servers running Windows 2000 Server, those servers try to obtain site information from the DFS Active Directory object, and unless you use Dfsutil.exe to manually update the site info in the DFS Active Directory object, the root servers running Windows 2000 Server might provide referrals that lead to a target outside of the client’s site.

Table 2.6 describes how DFS root servers handle site information.

Table 2.6   How Root Servers Handle Site Information

Site Difference 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 automatically updates 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 Windows 2000 Server. If the link target was created by using Windows Server 2003, no site information is stored, which means that the referral 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.

Running Windows Server 2003 on every root server is recommended 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 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 issues:

  • 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 you want to update site information.

  • Root servers running Windows Server 2003 continue to get site information directly from Active Directory, and they ignore all site information in the DFS Active Directory object.

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 additional space for creating root and link targets.

Important

  • If you are using a mix of root servers running Windows 2000 Server and Windows Server 2003, use the version of the Distributed File System snap-in available in either Windows Server 2003 or the Windows Server 2003 Administration Tools Pack to manage the namespace. Do not use the version of the Distributed File System snap-in available in Windows 2000 Server.

You can use the Distributed File System snap-in to specify the length of time that clients cache referrals to DFS root targets and link targets by adjusting the Time to Live value for each DFS root or link. When a client receives a referral to a target, the client will continue to access that target (either a particular root target or link target) until one of the following occurs: the client computer is restarted, the user clears the cache, or the Time to Live value for the root or link expires. The client will then obtain a new referral the next time it attempts to access the target. However, if the client continues to access the root or link within the Time To Live value, the Time to Live value is renewed each time and the client never requests a new referral. Clients that resume from hibernation do not request new referrals either.

Windows Server 2003 uses a default Time to Live value of 300 seconds (5 minutes) for DFS roots and 1800 seconds (30 minutes) for DFS links. The default Time to Live values work well in organizations where the namespace changes frequently and it is important that clients have up-to-date referrals. When using these values, make sure that your network has adequate bandwidth and your root servers have adequate resources to handle the traffic generated when clients contact the root servers for referrals.

Consider increasing the Time to Live value in the following situations:

  • An established root or link has a single link target. In this case, you do not need to load balance requests among multiple servers, so it is appropriate to have a longer Time to Live value for that root or link.

  • Your organization has clients in multiple Active Directory sites, but you do not have root servers in all sites. In this situation, you can increase the Time to Live value for the root to ensure that the client does not have to go out of its site for a root referral if more than 5 minutes have passed since the client last accessed the namespace. If your root information is static, you can set this value to be several hours.

For more information about Time to Live values, see the Windows Security Collection of the Windows Server 2003 Technical Reference (or see the Windows Security Collection on the Web at https://www.microsoft.com/reskit).

Determining the Contents of the Root Folder

The root folder of a DFS namespace is a launch point into the namespace — that is, a placeholder for the namespace. Keep the root folder as uncluttered as possible. For example, you might place a single file in the root folder (a readme file) that describes the contents and purpose of the namespace. When users access the namespace, they will see the readme file and the links that point to one or more link targets. For more information about the root folder, see "Reviewing DFS Terminology" earlier in this chapter.

Choosing Shared Folders to Add to the Namespace

Add shared folders to your namespace only if they are well established and unlikely to be retired in the near future. If you have targets whose underlying physical name is dynamic, include them in the DFS namespace only if you can tolerate the added administrative overhead or develop automated scripts to update the DFS links.

To secure files and folders, use NTFS as the underlying file system for shared folders that you add to a DFS namespace. You can add shared folders residing on file allocation table (FAT) volumes in Windows-based servers and shared folders residing on servers running other operating systems, such as UNIX or Novell NetWare servers; however, you cannot use NTFS security features to secure these folders. In addition, if you plan to use FRS to replicate the contents of shared folders, you must use NTFS as the file system.

To help users find data in DFS namespaces more easily, you can publish the UNC path for DFS links as shared folders in Active Directory. For example, if an administrator of the Reskit.com domain wants to publish the DFS link where users can install applications, the administrator can specify \\Reskit.com\Public\Apps as the path to the published folder. The administrator can also specify key words for that shared folder, such as "applications" or "Office." Domain users in a forest can locate the applications by using the Active Directory search tool in My Network Places to query for the application folder by name or key words.

For information about publishing shared folders in Active Directory, see "Publish a shared folder" in Help and Support Center for Windows Server 2003.

When designing the namespace, review the following rules regarding link creation.

You cannot create a new link under an existing link. To create a hierarchy of links, specify additional folder names within the link name. For example, instead of creating a link called Groups, create links called Groups\Development, Groups\Management, Groups\Administrative, and so forth.

If a client can access a link target in another trusted domain or trusted forest by using the target’s UNC path, the client can also access the link target by using its DFS path, but only if the list of domains fits into the client’s cache, which is 4 KB by default (roughly 2000 characters). If the list of domains is too large to fit into the 4-KB cache, the following actions occur:

  • Clients running Windows 98 cannot access any domain-based DFS namespaces. To notify you of this issue, DFS writes an entry with the ID 14537 in the system log in Event Viewer on the domain controller that enumerates the domains.

  • Computers running Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003 automatically increase their cache 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 cache as it can until the cache reaches 56 KB. DFS then writes an entry with the ID 14536 in the system event log in Event Viewer to notify you of this issue. 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 article Q244380, "How to Configure Dfs to Use Fully Qualified Domain Names in Referrals." To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

A mounted drive is a local volume attached to an empty folder on an NTFS volume. If C:\Root is a DFS root folder on Server1 (\\Server1\Root), and you create a folder C:\Root\Link1, where Link1 is a mounted drive (for example, Link1 points to drive D), you cannot create a link named Link1 in that DFS namespace.

Windows Server 2003 supports creating links that point to other DFS namespaces. Linking to other namespaces is common in organizations that want to combine the availability benefits of domain-based DFS namespaces with the scalability of stand-alone DFS namespaces. For example, if an organization needs to create 10,000 links but does not want to divide these between two domain-based DFS namespaces, the organization can take the following steps:

  1. Create a stand-alone DFS namespace with 10,000 links.

  2. Create a domain-based DFS root.

  3. Under the domain-based DFS root, create a link that points to the stand-alone DFS namespace.

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

  • If you plan to specify a domain-based DFS namespace as a link target (either the root or a link within that namespace), you cannot specify alternate link targets. (Windows Server 2003 enforces this restriction.)

  • If you plan to specify a stand-alone DFS namespace as a link target (either the root or a link within that namespace), you can specify alternate link targets that are either stand-alone DFS roots or links within the stand-alone DFS namespace. Do not specify domain-based DFS roots or shared folders as alternate targets.

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:

  • A DFS path can consist of no more than eight hops through other DFS namespaces.

  • Clients running Windows 98 might not correctly access links pointing to other DFS namespaces. Windows 98–based clients can only access the following types of links to other namespaces:

    • A link in a stand-alone DFS namespace that points to a stand-alone DFS root or link.

    • A link in a domain-based DFS namespace that points to a stand-alone DFS root. (This works only if the client has the latest Active Directory client installed, as described in article Q323466, "Directory Services Client Update for Windows 95 and Windows 98." To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

For additional rules for specifying multiple link targets, see "Choosing an Availability Method for Data in Link Targets" later in this chapter.