Distributed File System
Distributed File System |
|
When you roll out Dfs, you have the opportunity to start anew with a consistent namespace design. It is important to develop standards for the enterprise-wide namespace, or at least for a domainwide namespace. Developing naming standards first — and making sure you adhere to the naming standards during implementation — makes using and managing the Dfs namespace easier both from a user perspective and an administrative perspective. Both of these contribute toward lower administrative costs. Even if you do not expect to deploy Dfs until a later phase of a Windows 2000 deployment, it is important to begin thinking about the namespace design early in the deployment planning process.
The ability to define Dfs namespaces at the domain level (with domain-based Dfs roots) makes it easy to publish and manage the shared folders that exist only at the server level. Even if the shared folders themselves do not follow any naming standard, they can still be abstracted into the logical Dfs namespace in a cohesive fashion. It does not matter what names the underlying shared folders have been assigned. They can still be placed into the logical Dfs namespace at an appropriate level as Dfs links and assigned names that are consistent with Dfs namespace standards. This provides the best of both worlds. It allows access to the shared folders through their legacy physical names, and it also allows access to them through their logical names in the Dfs namespace.
It is recommended that you develop Dfs namespace standards that comply with other enterprise naming standards for domains, servers, and so on. Some of the objects that can be included or referenced by the Dfs namespace standards are described in the following sections.
Windows 2000 domains can be referenced by their FQDN name, such as division1.Reskit.com. They can also be referenced by a NetBIOS name, such as Division1. When you define your domain namespace, you might want to keep in mind that users view and use these names in UNCs when they gain access to a domain-based Dfs root.
When you develop an overall namespace design for Windows 2000, it is recommended that you also define naming standards for servers. Windows 2000–based servers can be referenced by a DNS name, such as salesfiles.division1.Reskit.com, or a NetBIOS name, such as SalesFiles.
When attempting to gain access to a stand-alone Dfs root, the user must specify the server name (for example, \\salesfiles.division1.Reskit.com or \\salesfiles). When gaining access to a domain-based Dfs root, the user can specify the server name. Remember that for a domain-based Dfs root, you must always gain access to the physical server name when you set up the Dfs namespace. It is, therefore, important to develop a consistent naming scheme for the file servers in your enterprise. For example, you probably would not want one server named \\SalesFiles and another named \\MktgFandPSrv.
The Dfs root name is significant primarily to users. It is the point beyond the server or domain name that is at the top of the hierarchy of their 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 this is where users begin their journey into that namespace. The contents of the Dfs namespace must be as clear as possible to the users so that they do not follow the wrong path and have to backtrack.
A stand-alone Dfs root name is exactly the same as the name of the underlying physical share and, therefore, must be unique to the server. With a domain-based Dfs root, the name of the root can be different from the name of the underlying physical share and must be unique to the domain.
Remember that a Dfs link is essentially a logical folder within the Dfs namespace that points to a physical shared folder. In all cases, the Dfs link names are exposed to users. As with Dfs roots, it is, therefore, important to develop standardized, meaningful names for the Dfs links.
It is recommended that you keep the user perspective in mind when you develop standards for Dfs links. An important design goal is to develop a Dfs namespace that minimizes erroneous navigation within the hierarchy that is represented in the namespace. It is important to make the namespace as clear as possible at all levels in the namespace. Keep in mind that comments entered in the Dfs administrative console are not visible to users.
This is probably even more important for a Dfs namespace than for a physical namespace. This is because it might be possible for the user to jump to a shared folder on a different computer when he or she selects a Dfs link in the namespace. This might mean that 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.
It is recommended that you also try to keep folders at the same level in the Dfs namespace consistent in context. For example, you probably would not want to have Dfs links of New York, Seattle, and Milan mixed with other links named Sales, Marketing, and Consulting.
Active Directory supports the concept of a shared folder that is essentially an object published in the directory that corresponds to a physical or logical share. A shared folder cannot be accessed by a UNC directly, but it can be searched for and queried by using any of the tools that are included with Active Directory.
Some organizations might find it useful to publish some common Dfs roots into Active Directory as shared folders. Folders that reside deeper in a Dfs namespace can also be published as shared folders, for example \\Company\Sales\Internal\CurrentYear. Because the shared folders are published with a freeform description, it is useful to establish naming conventions to ensure some level of consistency.