Standalone versus domain-based namespaces in Windows DFS
When setting up namespaces in Windows DFS, be aware that the popular choice may not be the best fit for your environment.
When setting up a Distributed File System (DFS) in Windows, you can create either a standalone namespace or a domain-based namespace. While in general domain-based namespaces are the more popular choice, in certain situations a standalone namespace may be a better option -- even in an Active Directory environment.
The basic difference between the two DFS namespaces is how they store the DFS configuration data. Standalone namespaces keep this information in the host server's registry, while domain-based namespaces store it in the Active Directory (AD) database. The location of this data affects the configuration of DFS. For example, the root for standalone namespaces can only have a single root target, while domain-based namespaces can have multiple root targets.
Fault tolerance and load balancing
A root target is a shared folder bound to a DFS root. Having multiple root targets allows a domain-based namespace to be connected to multiple folders, which can each be hosted on a separate file server. To ensure the root targets remain synchronized with one another, use the DFS Replication engine.
 |
||||
|
|
|||
|
||||
Having multiple replicas of a root target available provides a degree of fault tolerance. It also allows DFS to balance the workload by evenly distributing requests among the available root targets.
Still, multiple root targets aren't needed to achieve fault tolerance. Standalone namespaces can be made fault tolerant by being placed on clustered file servers. (In fact, this is the only way to achieve fault tolerance through failover clustering.) If you use this method, remember that failover clusters do not offer load balancing capabilities. If load balancing is important to you, then a domain-based namespace is the only option.
All the above information assumes the data on your file servers is dynamic. If you only need to load balance static (read-only) data, you can do so with a standalone namespace by creating identical standalone namespaces (and identical targets) on separate DFS servers, and then using DNS round robin to distribute the workload between servers. But remember that DNS-based load balancing does not take the DFS server's availability into account. DNS queries will be resolved to each DFS server in a round robin fashion, regardless if an individual DFS server is actually available.
Scalability
One of the primary reasons organizations deploy Windows DFS is to improve file server scalability. Although DFS does generally provide better scalability than a standalone file server, there are some limits depending on the namespace used.
In Windows Server 2003, organizations in need of a large DFS tree almost always had to use standalone namespaces. This is because an Active Directory limitation prevented a domain-based namespace configuration to exceed 5 MB of information. In other words, only about 5,000 folders with targets could be created with a domain-based namespace. If more than 5,000 folders were needed, a standalone namespace was necessary.
Microsoft did away with this limitation in Windows Server 2008, but there is a major caveat: to exceed the 5,000 folder limit, Active Directory must be operating in Windows Server 2008 mode. Otherwise, the limit still applies.
Overall, organizations that want to deploy DFS, but do not have Active Directory in place, are limited to creating a standalone namespace. Those with Active Directory can create either type of namespace -- as long as they carefully consider which DFS namespace will best meet their needs.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.
