Distributed File System

Distributed file system ( DFS ) is a technology that provides easier access and availability for file shares. The two types of DFS are server-based and domain-based. Server-based DFS resides on a single server. Administrators designate a DFS root, which is just a pointer to a file share, and underneath the DFS root administrators can create DFS links that point to other file shares. These file shares can be on the same or different servers. This enables administrators to provide a logical shared folder hierarchy regardless of the actual underlying folder structure.

Domain-based DFS has the same structure of DFS roots and links, but you can create multiple roots. Domain-based DFS also gives you the ability to provide redundant shares called replicas .

Replicas are copies of the DFS root and link on another server. By having replicas on multiple servers, clients can always access the DFS shares. For example, consider a domain called braincore.net with a DFS root ( Software ) that points to a file share on a server ( Netserver ). An additional replica is created on the server Netserver2 , which provides fault tolerance for the Software share. Clients access the share via \\braincore.net\Software . The DFS client queries Active Directory and determines the replica server closest to the client. If one of the servers is down, the client is still capable of accessing the other server. The multiple DFS replicas not only provide fault tolerance for the Software share, but also potentially bring the share closer to the user . Site-aware DFS clients (Windows 2000 or better) are directed to the DFS link in their own sites.

Using DFS for Software Deployment

DFS is particularly useful for software deployment shares. We once had to deploy Internet Explorer (IE) to an entire organization. There was no infrastructure for software deployment, so the only choice was to automate through logon scripts. To ensure local installation and minimize traffic across WAN links, we created the software distribution share for IE on servers in every location. We then had to create special scripting to detect where the client was located and direct it to the appropriate server for downloading IE. Pretty complex! DFS handles all this automatically. With DFS, we could simply create a DFS root called Software and then create DFS links for the software application share. We could create replicas of the root and links on multiple servers across the organization. The File Replication Service (FRS) would automatically replicate the content of the application share to all the replicas, providing a consistent copy of the share across all the participating servers. The software installations could be performed by simply connecting to \\domain\software\application . DFS would direct the client to a participating server in the client's own site, so the installation would be performed without crossing WAN links and without complex scripting to detect the client's location.

New DFS Features

At first glance, DFS in Windows Server 2003 appears to be the same as in previous versions. However, some subtle enhancements dramatically increase its functionality. First, you can now create multiple DFS roots on a single server. Previously, although you could create multiple DFS roots in domain-based DFS, each server could host only one root. This meant that to have multiple DFS roots in a domain, you had to use different servers for each of the roots, thus increasing the number of servers required for DFS. Additionally, DFS roots can now be published in Active Directory, to make them easier for users to find. DFS links can also be made available for offline access by Windows XP clients.

You can now designate the DFS replication topology in domain-based DFS (full ring or hub and spoke). In Windows 2000, DFS replication is either automatic or manual. Manual is just that ”the administrator must manually keep the replicas in sync (such as by using robocopy or xcopy ). With automatic replication, one server (by default the first one) is designated as the master and all other replicas synchronize with the master. With Windows Server 2003, the administrator can designate the DFS replication topology. Four choices are available:

• Ring ” One replica replicates with another and so on in a chain until the last one replicates back with the first.

• Hub and Spoke ” Similar to Windows 2000 in that there is a central server with which everyone replicates.

• Full Mesh ” Everyone replicates with everyone else.

• Custom ” The administrator can choose who replicates with whom. This provides much more flexibility in the traffic between replicas.

For additional flexibility, you can designate a replication schedule and designate certain files that should not be replicated (called a replication exclusion list ).

When multiple replicas exist for a DFS root or link, a client has to choose one of the replicas with which to connect. The way it determines which replica to use is by looking up site information in Active Directory. In Windows 2000, if no DFS replica exists in the same site as the client, the client could choose to connect to a replica in any site. Therefore, a client could potentially attempt to connect to a replica on the other side of the world when there might be a closer replica. Windows Server 2003 includes the capability to specify costs for DFS links. This provides an alternative mechanism for determining which link to use.