Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

Designing DFS Namespaces

Users might have difficulty finding information in shared folders that are located on numerous file servers. Because shared folders are usually associated with physical servers, the user must first determine which physical server is hosting the shared folder. For example, a user might need to access product information on a server named \\Building 4\Marketing2\Prod_Info and on a server named \\Corporate\Floor 4\Sales\Prod_Info.

You can use DFS to address this challenge by consolidating a large set of physical shared folders into one or more virtual namespaces. You do not need to modify the shared folders to add them to the namespace, and users can navigate the namespace without having to know the physical server names or shared folders hosting the data.

Sdcfsv_1.xls) on the Microsoft Windows Server 2003 Deployment Kit companion CD (or see "DFS Configuration Worksheet" on the Web at http://www.microsoft.com/reskit).

Figure 2.3: Designing DFS Namespaces

For more information about DFS security, see "Planning DFS and FRS Security" later in this chapter. For in-depth technical and troubleshooting information about DFS, see the Distributed Services Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).

Deciding Whether to Implement DFS

Organizations of any size, with any number of file servers, can benefit from implementing DFS. DFS is especially beneficial for organizations in which any of the following conditions exist:

The organization plans to deploy additional file servers or consolidate existing file servers.

The organization has data that is stored in multiple file servers.

The organization wants to replace physical servers or shared folders without affecting how users access the data.

The organization has data located on servers in multiple sites and wants clients to connect to the closest servers.

Most users require access to multiple file servers.

Users experience delays when accessing file servers during peak usage periods.

Users require uninterrupted access to file servers.

Even if you are busy planning your organization's migration to Windows Server 2003, you can make plans to implement DFS without immediately designing your entire namespace. You do not need to deploy DFS all at one time; you can choose to add as much or as little of your organization's physical storage as you need to the DFS namespace, at a pace that works with your overall migration schedule.

When deciding whether to implement DFS, do the following:

Review DFS terminology.





Review the benefits of using DFS.





Evaluate clients and servers for compatibility.

The following sections describe each of these steps.

Reviewing DFS Terminology

If you are not familiar with DFS, review the following terms and definitions to understand the important elements of a DFS configuration. For visual examples of these concepts, see Figure 2.4 through Figure 2.7 later in this section.

DFS namespace A virtual view of shared folders on different servers as provided by DFS. A DFS namespace consists of a root and many links and targets. The namespace starts with a root that maps to one or more root targets. Below the root are links that map to their own targets.

DFS root The starting point of the DFS namespace. The root is often used to refer to the namespace as a whole. A root maps to one or more root targets, each of which corresponds to a shared folder on a separate server. The DFS root must reside on an NTFS volume. A DFS root has one of the following formats: \\servername\rootname or \\domainname\rootname.

Root target A physical server that hosts a DFS namespace. A domain-based DFS root can have multiple root targets, whereas a stand-alone DFS root can only have one root target.

Stand-alone DFS namespace A DFS namespace whose configuration information is stored locally in the registry of the host server. The path to access the root or a link starts with the host server name. A stand-alone DFS root has only one root target. Stand-alone roots are not fault tolerant; when the root target is unavailable, the entire DFS namespace is inaccessible. You can make stand-alone DFS roots fault tolerant by creating them on clustered file servers.

Domain-based DFS namespace A DFS namespace that has configuration information stored in Active Directory. The path to access the root or a link starts with the host domain name. A domain-based DFS root can have multiple root targets, which offers fault tolerance and load sharing at the root level.

DFS path Any Universal Naming Convention (UNC) path that starts with a DFS root.

Link A component in a DFS path that lies below the root and maps to one or more link targets.

Link target The mapping destination of a link. A link target can be any UNC path. For example, a link target could be a shared folder or another DFS path.

Figure 2.4 illustrates the elements of a stand-alone DFS namespace in the Distributed File System snap-in. These elements include a stand-alone DFS root, a single root target, and multiple links.

Figure 2.4: Elements of a Stand-Alone DFS Namespace

Figure 2.5 illustrates the elements of a domain-based DFS namespace in the Distributed File System snap-in. Notice that the \\Reskit.com\Public root has two root targets on different servers.

Figure 2.5: Elements of a Domain-based DFS Namespace

Figure 2.6 illustrates multiple link targets for the Software link. Notice that the link targets exist on three different servers and that the administrator has disabled referrals to the link target on \\dfs-03. DFS will not refer clients to the link target on \\dfs-03 until the administrator enables referrals.

Figure 2.6: Multiple Link Targets

The roots and links displayed in the Distributed File System snap-in also appear on each root server's local storage as follows:

When you create a DFS root, you specify a shared folder to use as the root folder. If you add multiple root targets to a domain-based DFS root, you specify a shared folder on each of those root targets. (The shared folder names should always match the root name.)

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:\Public\GroupData 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.

Figure 2.7 illustrates volume E:\ on the local storage of one of the root targets. The volume contains root and link folders for the \\Reskit.com\Public namespace.

Figure 2.7: Root and Link Folders

Reviewing the Benefits of Using DFS

When you evaluate DFS for your organization, it is helpful to understand the benefits that your organization can gain after designing and implementing a DFS namespace. The following list describes the benefits of using DFS:

Unified namespace A DFS namespace links together shared folders on different servers to create a hierarchical structure that behaves like a single high-capacity hard disk. Users can navigate the logical namespace without having to know the physical server names or shared folders hosting the data.

Location transparency DFS simplifies migrating data from one file server to another. Because users do not need to know the name of each physical server or shared folder that contains the data, you can physically move data to another server without having to reconfigure applications and shortcuts, and without having to re-educate users about where they can find their data.

Storage scalability You can deploy additional or higher-performance file servers and present the storage on the new servers as new folders within an existing namespace.

Namespace scalability Servers running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition can host multiple domain-based DFS roots and stand-alone DFS roots. This feature improves the scalability of DFS, enabling you to build many large namespaces without having to add file servers to host the roots.

Increased availability of file server data When multiple servers running Windows Server 2003 host a domain-based DFS root, clients are redirected to the next available root server if any of these servers fail, providing fault-tolerant data access. To ensure the availability of stand-alone DFS namespaces, you can create the root on a clustered file server.

Alternate site selection based on cost By default, if a target in the same site as the users fails, or if no same-site target exists, DFS refers clients to a random target. If you configure the optional site costing feature, DFS can use the site information in Active Directory to locate an alternate target that has the lowest-cost network connection as defined by the administrator in the Active Directory Sites and Services snap-in. After site costing is enabled, clients can access data on DFS targets over the optimum network connection.

Load sharing DFS provides a degree of load sharing by mapping a given logical name to shared folders on multiple file servers. For example, suppose that \\Company\StockInfo is a heavily used shared folder. By using DFS, you can associate this location with multiple shared folders on different servers, even if the servers are located in different sites.

Intelligent client caching When a user requests access to a target that is a part of a DFS namespace, a referral containing the target's information is cached on the client. The next time the client requires access to that portion of the namespace, the client uses the cached referral instead of obtaining a new referral, and connects directly to one of the target computers. For more information about client caching in DFS, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at Planning DFS and FRS Security" later in this chapter.

Evaluating Client and Server Compatibility

Before you implement a DFS namespace, review the types of clients and servers in your organization to make certain that the servers can host targets and that the clients can access targets in the DFS namespace. For example, if you have UNIX clients, they cannot access the DFS namespace and must instead access the files by using the UNC path to the various file servers. Table 2.1 summarizes DFS interoperability.

When evaluating client compatibility, review the following important considerations:

Clients must be members of a domain before they can access a domain-based DFS namespace.

Link targets can use other protocols, such as NetWare Core Protocol (NCP) for NetWare and Network Filesystem (NFS) for UNIX, but clients must have the appropriate redirector installed to access those link targets.

In organizations that have a large number of domains, clients might have difficulty accessing link targets in other domains or forests. In addition, clients running Windows 98 might not be able to access any domain-based DFS namespace and might also have difficulty accessing links that point to other DFS namespaces. For more information about clients running Windows 98, see "Designing a DFS Namespace" later in this chapter.

Choosing the DFS Namespace Type

When creating a DFS namespace, you create either a stand-alone DFS root or a domain-based DFS root. Table 2.2 describes the differences between domain-based DFS namespaces and standalone DFS namespaces.

Use the following guidelines to choose a DFS namespace type.

Choose stand-alone DFS namespaces if:

Your organization does not use Active Directory.

You need to create a DFS namespace and are not part of the Domain Admins group, or company policy prevents you from delegating authority to manage a domain-based DFS namespace.

You need to create a single namespace with more than 5,000 links. (If you can divide your links among two or more namespaces, domain-based DFS is an option.)

You want to ensure the availability of the namespace by using a clustered file server.

Choose domain-based DFS namespaces if:

You plan to use FRS to replicate data and you want to use the Distributed File System snap-in to configure and administer replication.

You want to ensure the availability of the namespace by using multiple root targets.

As described in Table 2.2, you can increase the availability of roots and links in both types of DFS namespaces. For more information and specific guidelines about increasing the availability of roots and links, see "Increasing the Availability of DFS Namespaces" later in this chapter.

Reviewing DFS Size Recommendations

As you design your DFS namespace, use the guidelines in Table 2.3 to avoid potential performance problems that can arise when size recommendations are exceeded.

If your organization plans to create large namespaces, there are a number of strategies you can implement to work within the size recommendations shown in Table 2.3.

Keep comments to a minimum

When you add a root target or link target in the Distributed File Systems snap-in, you can enter comments that describe the target. If you plan to create a large namespace, use minimal comments, if any, because they can increase the overall size of the namespace.

Create multiple namespaces

If you need to create more than 5,000 links in a domain-based DFS namespace, you can create multiple DFS namespaces that meet the recommended sizes and then link them together. For more information about creating multiple namespaces, see "Designing a DFS Namespace" later in this chapter.

Enable root scalability mode

You enable root scalability mode by using the /RootScalability parameter in Dfsutil.exe, which you can install from the \Support\Tools folder on the Windows Server 2003 operating system CD. When root scalability mode is enabled, DFS root servers get updates from the closest domain controller instead of the server acting as the 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. (When you make changes to the namespace, the changes are still made on the PDC emulator master, but the root servers no longer poll the PDC emulator master hourly for those changes; instead, they poll the closest domain controller.) 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. For more information about the 5-MB limit, see the entry describing the size of the DFS Active Directory object in Table 2.3 earlier in this chapter.

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

Your namespace changes frequently, and users cannot tolerate having inconsistent views of the namespace.

Domain controller replication is slow. This increases the amount of time it takes for the PDC emulator master to replicate DFS changes to other domain controllers, which, in turn, replicate changes to the root servers. Until this replication completes, the namespace will be inconsistent on all root servers.

For information about installing Windows Support Tools, see "Install Windows Support Tools" in Help and Support Center for Windows Server 2003.

Migrate root servers running Windows 2000 Server to Windows Server 2003

Root servers running Windows Server 2003 do not add site information to the DFS Active Directory object. As a result, if all root servers run Windows Server 2003, DFS can store more root and link information to the DFS Active Directory object before reaching the recommended 5-MB limit. For more information about using a mix of root servers running Windows 2000 Server and Windows Server 2003, see "Designing a DFS Namespace" later in this chapter.

Planning the Number of DFS Namespaces

Your next step is to plan the number of namespaces you want in your domain. For an Excel spreadsheet to assist you in documenting your 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 http://www.microsoft.com/reskit).

Medium organizations might require only a single namespace, while large organizations might need multiple DFS namespaces. You can determine the number of namespaces you require by reviewing the following factors.

Scope of your domain

If your domain has a broad scope — geographically, organizationally, or functionally — you should plan for multiple DFS namespaces so that administrators in the geographical, organizational, or functional departments can define their own namespaces. On the other hand, if the domain has a narrow scope geographically, organizationally, or functionally, you might want to define a single DFS namespace.

Size of your DFS namespace

If your DFS namespace exceeds the recommended number of links per namespace, as discussed earlier in "Reviewing DFS Size Recommendations" create multiple DFS namespaces, each of which does not exceed the recommended size. In this way, you can provide a single namespace to users by creating a single DFS namespace with links that point to other DFS namespaces. For more information about linking from one namespace to another, see "Designing a DFS Namespace" later in this chapter.

Administrative boundaries

How DFS namespaces are administered can also affect the number of DFS namespaces your organization requires. For example, your organization might have the following administrative boundaries:

Geographic. Geographically diverse sites can each have an administrator who creates and manages the DFS namespace located in that site.

Departmental or group ownership. Individual departments or groups can create and manage a DFS namespace that is used by members of that department or group.

Political. Individual departments or groups can create and manage a DFS namespace that is used by members of that department or group.

If groups in your organization will create and manage their own DFS namespaces, you can build an extensive DFS namespace out of smaller, more focused DFS namespaces. One benefit of this method is that you can present specific DFS roots to some users as the true top of the hierarchy and also present a set of those DFS roots to other users as the only DFS links in a larger hierarchy. By using a hierarchy of DFS roots, you can scale the namespace as your organization grows and tailor the namespace for distributed management.

For more information about linking from one namespace to another, see "Designing a DFS Namespace" later in this chapter.

DFS namespace depth

Limit the depth of DFS namespaces to 260 characters. The 260-character limit includes the fully qualified domain name (FQDN) of the domain hosting the DFS root as well as the DFS root name. If you exceed this limit, applications will fail when trying to access the namespace. To work around this issue, users must map part of the namespace to a drive letter and then access the longer namespace through the mapped drive letter.

Developing Root and Link Naming Standards

When you roll out DFS, you have the opportunity to implement consistent namespace designs. Developing naming standards first — and ensuring that you adhere to the naming standards during implementation — makes it easier to use and manage any DFS namespace, both from a user perspective and an administrative perspective. Even if you do not expect to implement DFS until a later phase of your Windows Server 2003 deployment, it is important to begin thinking about namespace design early in the planning process. For an Excel spreadsheet to assist you in documenting your DFS namespace design 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 http://www.microsoft.com/reskit).

Creating DFS Root Names

A DFS root name, significant primarily to users, is the point beyond the server name or domain name that is at the top of the hierarchy of the logical namespace. Standardized and meaningful names at this level are very important, especially if you have more than one DFS namespace in a domain, because the DFS root name is where users enter the namespace. The contents of a DFS namespace must be as clear as possible to the users so that they do not follow the wrong path, possibly across expensive WAN connections, and have to backtrack.

When creating the DFS root names for servers that will contain multiple roots, review the following restrictions:

Each root requires its own shared folder.

When you create a domain-based DFS root, the share name in the UNC path \\servername\sharename must be the same name as the DFS root name in \\domainname\rootname. For example, if you want to create a domain-based DFS root \\Reskit.com\Public on Server1, the UNC path to the shared folder must be \\Server1\Public.

A root cannot be nested within another root. For example, if C:\Root is a shared folder that uses the share name Public, and you use this shared folder as a stand-alone DFS root (\\servername\Public) or domain-based DFS root (\\domainname\Public), you cannot create another root in the folder C:\Root\Software. Similarly, if you create a root by using the root folder C:\, you cannot create another root at C:\Root.

On server clusters, do not create clustered DFS roots that have the same name as nonclustered DFS roots or shared folders.

Shared folders on domain controllers must not have the same name as any domain-based DFS roots in the domain. If they do, clients who try to access the shared folder on the domain controller are redirected to the domain-based DFS root. For example, if Reskit.com has a domain controller named DC1 that contains a shared folder named Tools (\\DC1\Tools), do not create a domain-based DFS namespace using a root named Tools (\\Reskit.com\Tools). Otherwise, when users attempt to access \\DC1\Tools, they are redirected to \\Reskit.com\Tools.

Creating DFS Link Names

A DFS link is a component in a DFS namespace that lies below the root and maps to one or more link targets. Because DFS link names are exposed to users, it is important to develop standardized, meaningful names for DFS links. Another important design goal is to develop a DFS namespace that provides intuitive navigation within the hierarchy that the namespace represents. Keep in mind that comments entered in the Distributed File System snap-in are not visible to users. For this reason, the namespace must be as clear as possible at all levels.

Designing a clear naming scheme is even more important for a DFS namespace than for a physical namespace, because a user might jump to a shared folder on a different file server when he or she selects a link in the DFS namespace. As a result, a session has to be set up with that physical server (if one does not already exist), which might delay access. Therefore, you want to minimize the number of times that users traverse a wrong path. Clear and meaningful naming standards can help.

Try to keep links at the same level in the DFS namespace consistent in context. For example, you probably would not want to have links named New York, Seattle, and Milan mixed with other links named Sales, Marketing, and Consulting. To help you create a consistent namespace, DFS supports adding one or more folder names to the link name so that you can create a meaningful hierarchy of link names. In the previous example, you could create links such as the following:

Branches\New York, Branches\Seattle, and Branches\Milan

Departments\Sales, Departments\Marketing, and Departments\Consulting

When users browse this namespace, they will see a folder called Branches and another called Departments, which they can use to navigate to folders for branch offices (New York, Seattle, and Milan) and departments (Sales, Marketing, and Consulting).

Designing a DFS Namespace

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 http://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.

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.

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.

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.

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.

Determine the Root and Link Referral Time to Live Values

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 Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://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.

Reviewing Rules for Creating Links

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

Creating new links under existing links

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.

Creating links to shared folders in other domains or forests

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.

Creating links to mounted drives

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.

Creating links to different namespaces

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:

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





Create a domain-based DFS root.





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.

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 http://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.

Increasing the Availability of DFS Namespaces

After you create your initial namespace design, you need to review that design to determine whether part or all of the namespace needs to be available at all times. You can ensure DFS namespace availability at both the root and link target level. This helps prevent the situation in which the target servers are up and running but users cannot access them by using the namespace.

To increase the availability of DFS namespaces, take the following steps:

Choose an availability method for DFS roots.





Choose an availability method for data in link targets.





Determine where to place multiple targets.





Choose a replication method.

The following sections describe each of these steps.

Choosing an Availability Method for DFS Roots

If you plan to create DFS namespaces that must be highly available, such as those that provide access to business-critical data, the availability method you choose depends on the root type.

Stand-alone DFS roots

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 more information about making stand-alone DFS roots highly available, see "Increasing Data Availability by Using Clustering" later in this chapter.

Domain-based DFS roots

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. (For information about choosing servers to host root targets, see "Designing a DFS Namespace" earlier in this chapter.)

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.

After you determine which roots need to be highly available, document your decisions. For an Excel spreadsheet to assist you in documenting the high-availability requirements of DFS roots, 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 http://www.microsoft.com/reskit).

Choosing an Availability Method for Data in Link Targets

As you design your namespace, you need to identify link targets whose data must be highly available. There are two ways to increase the availability of data in link targets:

Create a single link that points to a link target on a clustered file server.

Create multiple link targets and replicate content among them.

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 must replicate the files by copying them manually, using scripts, using Robocopy.exe, which is available in the 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. If you do not want to use FRS in a domain-based DFS namespace, you can replicate files by copying them manually or by using third-party replication tools.

For more information about replication, see "Choosing a Replication Method" later in this chapter.

If you plan to use multiple link targets to ensure data availability, you need to configure link targets correctly. Each link can have targets that correspond to only one of the following options:

One or more shared folders.

One or more stand-alone DFS paths anywhere in the stand-alone DFS namespace, including the root.

A single domain-based DFS path anywhere in the domain-based DFS namespace, including the root.

After you determine which link targets need to be highly available, document your decisions. For an Excel spreadsheet to assist you in documenting which links require multiple link targets, 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 http://www.microsoft.com/reskit).

Placing Multiple Targets

When you evaluate where to place multiple targets, you should plan to place at least one target in the same Active Directory site where users access the data. Doing so enables clients to use fast, inexpensive bandwidth to access the target. Use multiple same-site targets to ensure namespace availability in each site and to avoid the need to use expensive bandwidth if one of the same-site targets fails or is taken offline. Using multiple same-site targets also provides load sharing among the targets in the site.

After you determine where to place multiple targets, you also need to consider where clients will be redirected if the primary target is unavailable. DFS supports three methods of target selection, which are described in the following sections. These methods apply to both stand-alone and domain-based DFS namespaces. After you determine the method of target selection for each link or root, document your decisions. For an Excel spreadsheet to assist you in documenting the target selection methods, 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 http://www.microsoft.com/reskit).

Default target selection

If the last (or only) target in an Active Directory site fails or is taken offline, DFS directs clients to another target in the same site, if a target is available. Clients are directed to a random target if no same-site targets are available. DFS does not consider bandwidth cost, connection speed, or the target server's processing load when choosing the random target.

Restricted same-site target selection

By using Dfsutil.exe /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 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.

Least expensive target selection

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 WAN links.

Site costing is not available in the following situations:

When a stand-alone DFS namespace is hosted on a server that is not part of any domain.

When the closest domain controller acting as the ISTG is running Windows 2000 Server.

(This situation occurs when there are only domain controllers running Windows 2000 Server in the site of the DFS root server, or when there are no domain controllers in the site of the DFS root server and the closest site with at least one domain controller has only Windows 2000 Server domain controllers in that site. The closest site is defined in Active Directory.)

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

You can enable site costing on a per-namespace basis.

When the domain controller acting as the ISTG is running Windows 2000 Server, DFS uses the default target selection, described earlier in this section. If domain controllers running Windows 2000 Server and Windows Server 2003 exist in a site, the ISTG role is automatically given to the domain controller running Windows Server 2003.

For more information about defining sites in Active Directory, see "Designing the Site Topology" in Designing and Deploying Directory and Security Services of this kit.

Choosing a Replication Method

If you plan to use multiple targets and you want to synchronize data in those targets, you need to choose a replication method. You have several methods for replicating data:

A manual replication method (such as using the command-line tool Robocopy.exe, which is available in the Windows Server 2003 Deployment Kit)

FRS

A third-party replication tool

It is not mandatory to use FRS to keep targets synchronized. In fact, by default, FRS is not enabled for DFS targets in domain-based DFS namespaces. However, in general you do want to make sure that the underlying shared folders that correspond to DFS links and targets are synchronized to present the same data to users, regardless of the folder that they want to access.

The following sections describe when to use manual replication or FRS. For an Excel spreadsheet to assist you in documenting the replication method for each target, 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 http://www.microsoft.com/reskit). For information about using third-party replication tools, consult the documentation provided by your software vendor.

When to Use Manual Replication

If the data in the shared folder is static, you can replicate the data by doing a one-time copy of the data to a target in the replica set. Even if the data in the shared folder is dynamic but changes infrequently, you might want to keep the targets synchronized by downloading the initial copies over the network and then manually updating them with changes. You must use manual replication if you plan to use a stand-alone DFS namespace or if one or more link targets for a particular link do not run Windows 2000 Server or Windows Server 2003.

When to Use FRS

FRS works by detecting changes to file and folders in a replica set and replicating those changes to other file servers in the replica set. When a change occurs, FRS replicates the entire file, not just the changed bytes. You can use FRS only if you are using a domain-based DFS namespace, and only servers running a Windows 2000 Server or Windows Server 2003 operating system can be part of a replica set. In addition, all replica sets must be created on NTFS volumes.

FRS offers a number of advantages over manually copying files, including:

Continuous replication FRS can provide continuous replication, subject to server and network loads. When a file or folder change occurs, and the file or folder is closed, FRS can begin replicating the changed file or folder to outbound partners (that is, the replica members that will receive the changed file or folder) within five seconds.

Replication scheduling You can schedule replication to occur at specified times and durations as needed by your organization. Scheduling replication to occur during evening hours, for example, can reduce the cost of transmitting data over expensive WAN links. Replicating data during off-hours also frees up network bandwidth for other uses.

Compression To save disk space, FRS compresses files in the staging directory by using NTFS compression. Files sent between replica members remain compressed when transmitted over the network.

Authenticated RPC with encryption To provide secure communications, FRS uses Kerberos authentication protocol for authenticated remote procedure call (RPC) to encrypt the data sent between members of a replica set.

Fault-tolerant replication path FRS does not rely on broadcast technology, and it can provide fault-tolerant distribution via multiple connection paths between members. If a given replica member is unavailable, the data will flow via a different route. FRS uses logic that prevents a file from being sent more than once to any given member.

Conflict resolution FRS can resolve file and folder conflicts to make data consistent among the replica members. If two identically named files on different servers are added to the replica set, FRS uses a "last writer wins" algorithm, which means that the most recent update to a file in a replica set becomes the version of the file or folder that replicates to the other members of the replica set. If two identically named folders on different servers are added to the replica tree, FRS identifies the conflict during replication and renames the folder that was most recently created. Both folders are replicated to all servers in the replica set, and administrators can later merge the contents of two folders or take some other measure to reestablish the single folder.

Replication integrity FRS relies on the update sequence number (USN) journal to log records of files that have changed on a replica member. Files are replicated only after they have been modified and closed. As a result, FRS does not lose track of a changed file even if a replica member shuts down abruptly. After the replica member comes back online, FRS replicates changes that originated from other replica members, as well as replicating local changes that occurred before the shutdown. This replication takes place according to the replication schedule.

When you use FRS, the link targets might not always be completely synchronized. As a result, one client's view of a link in a DFS namespace can be different from another client's view of the same link. This inconsistency can happen when clients have been referred to different link targets in the namespace. Link targets do become consistent with time, but you might experience temporary inconsistencies due to replication latency when updates are occurring. For more information about using FRS, see "Choosing an Availability Strategy for Business-Critical Data" later in this chapter.

FRS is typically used to keep link targets synchronized. It is also possible to put files and folders directly in a domain-based DFS root target and then enable replication on the root so that the files and folders are replicated to all root targets. However, avoid enabling replication on domain-based DFS roots for the following reasons:

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. On the other hand, 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. On the other hand, 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.

Example: An Organization Designs a DFS Namespace

An organization with 35,000 users in one site designs a stand-alone DFS namespace to provide unified access to 1.4 terabytes (TB) of both business-critical and nonessential software. The team responsible for designing and deploying the namespace chooses a stand-alone DFS namespace for the following reasons:

The team is not a member of the Domain Admins group, and corporate security policy prevents them from becoming members of this group.

Corporate security policy also prohibits the team from creating a domain to host a domain-based DFS namespace.

When designing the namespace, the team needs to provide access to the following types of software:

Business-critical software and operating systems

Previous (archived) versions of software and operating systems

Multimedia software that runs from the network

Training courseware

To ensure the availability of the namespace, the team creates the stand-alone DFS root, \\software\public, on a two-node clustered file server. Each node has two Pentium III 1.26-gigahertz (GHz) CPUs and 256 MB of RAM. The root server does not provide any other services.

When evaluating users' availability requirements for the different types of software, the team determines that the business-critical software and operating systems must be available at all times. In addition, because this is the most frequently accessed software, the team wants good response times. To provide the desired availability and performance, the team uses four servers as link targets. These servers each have two Pentium III 733-MHz CPUs and 256 MB of RAM.

Although the multimedia software is not business critical, the team uses two servers as link targets for this software to improve server response times, because the client portion of the multimedia software accesses files from the server. The team does not use redundant servers for the remaining software, because it is not business critical, and users can tolerate temporary downtime of those servers.

Figure 2.8 describes the DFS namespace for this example.

Figure 2.8: A Stand-Alone DFS Namespace Used for Software Installation

When updating software on the \\archsvr, \\mmsoft, and \\trainsvr servers, the team adds new files directly to the servers. To update software on the business-critical \\software servers, the team copies the new files to a staging server, \\stagesvr. The team uses Robocopy scripts on \\stagesvr to copy the data to the \\software servers. By making changes only at the staging server, the team makes sure that no accidental changes are made on the \\software servers. The team also uses the staging server as the backup source, because it contains source files for a number of servers in addition to the \\software servers. The backup team backs up the other servers individually.

To prevent the staging server from becoming overloaded, the team does not make the staging server part of the namespace, so users do not directly access the server. The team also increases the hardware specifications of this server to meet the increased disk and CPU utilization required for copying files to the \\software servers and to support backups. The hardware configuration has four Pentium III Xeon 700-MHz processors and 1 gigabyte (GB) of RAM.

While deploying the namespace in the production environment, the team learned a number of valuable lessons that can help other organizations as they test and deploy their namespaces:

When setting permissions on the clustered root server, follow the guidelines in "Planning Cluster Security" later in this chapter. Test the clustered root server to verify that permissions work correctly after a failover occurs.

Be sure to change the Cluster service password as specified by your organization's password policy. Windows Server 2003 does not send notification that the password is about to expire. If the password expires, problems can occur at failover. For more information about Cluster service passwords, see "Change the Cluster service account password" in Help and Support Center for Windows Server 2003.

Stagger new software announcements so that users do not overload the servers while trying to install new software. For example, send e-mail notification to a percentage of users each day.