Developing Root and Link Naming Standards

  • Article

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

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

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).

Note

  • If you want to encourage users to access the DFS namespace instead of going to individual servers, you can use a dollar sign ($) at the end of the shared folder name to hide it from casual browsers. The shared folder will still appear in the DFS namespace with the link name you specify. Doing so prevents users from accessing the shared folders by specifying individual server names. Instead, users must access the shared folders by using the namespace, which enables DFS to load share requests across multiple link targets and allows clients to be directed to another link target if the previously used target is unavailable.