DFS (Distributed File System) is a way to unit files on different computers
into a single name space. DFS makes it easy to build a single, hierarchical view
of multiple file servers and file server shares on a network.
The advantage for the administrator is the ability to store any data on any
server. and provide it to users on the network through one single namespace. The
advantage for users is they no longer have to know where data is stored on the
network to access it as all data is presented to the user as a domain resource,
listed in a hierarchical format much like a directory. DFS offers the following
functions :
| Unified namespace for all file sharing |
| High availability of file sharing services |
| Load sharing a file shares |
| Expand capacity of volumes transparent to users |
| Create intranet/internet publishing shares consolidated into one namespace for Web server retrieval |
DFS is installed automatically when installing Windows 2000. During an upgrade of Windows NT 4.0 to Windows 2000, any DFS 4.x roots are converted automatically to Windows 2000 stand-alone DFS roots.
| DFS root. The share at the top of the DFS topology, which is the starting point for the DFS links and shared folders that make up the DFS namespace. The containers can contain files and DFS links. Each server can only have one DFS root. |
| DFS root share. Copy of the DFS root to create redundancy. |
| DFS link. Located under the DFS root, a DFS link forms a connection to one or more domain-based volumes or shared folders, or to another DFS root. (In DFS 4.x in Windows NT terminology, a DFS link is called a child node or junction point.) |
| DFS shared folders. Files or folders in the DFS namespace that can be accessed by users who have proper permissions. |
| Replica set. Two or more DFS roots or DFS shared folders that participate in replication. There is a maximum of 32 shared folders for one DFS link. |
| Replica. A folder within a replica set. |
Within Windows 2000 you can create stand-alone DFS roots and domain-based DFS roots.
These are the DFS structures as they could be created on NT 4.0. They have the following properties :
| They are non-fault-tolerant. |
| They do not use Active Directory. |
| They can only have a single level of DFS links. |
| They cannot contain root level DFS-shared folders. |
In stand-alone DFS can a DFS link have replicas. The difference with
domain-based DFS is that the replicas cannot be replicated automatically.
You can set the client cache time for the DFS root and for each DFS link. The
default cache time for the DFS root is 300 seconds, for the DFS links 1800
seconds.
For each DFS link you can check the status and take it offline.
| They are published in the Active Directory. |
| They can be fault tolerant. |
| The root must be on NTFS 5. |
| They can have multiple levels of DFS links. |
| They can contain root level DFS-shared folders. |
In domain-based DFS can a DFS link have replicas that are replicated
automatically via FRS. You can enable or disable replication for each
replica and set the master. This only works if FRS is available on the client
hosting the DFS link. File replication is not allowed between two replicas on
the same server.
You can create root replicas for the DFS root. These replicas are also stored
within DFS and will provide redundancy if another server hosting a DFS root is
not available.
You can set the client cache time for the DFS root and for each DFS link. The
default cache time for the DFS root is 300 seconds, for the DFS links 1800
seconds.
For each DFS link you can check the status and take it offline. If the link
contains replicas you can also check the replication status.
A DFS volume is accessed using a standard UNC name: \\Server_Name\Dfs_Share_Name\Path\File or with a directory service-enabled version of DFS by using the fault-tolerant name \\Fault_Tolerant_Name\Dfs_Share_Name\Path\File
DFS links can reside on any computer running Windows NT Server 3.51 or higher, Windows NT Workstation 3.51 or higher, Windows 95/98, Windows for Workgroups, LAN Manager, or Novell NetWare. To access a DFS link on a NetWare server from a Microsoft client, you must first install a NetWare redirector.
To access any DFS link from a Windows 95 client, you must first install the DFS Service for Microsoft Network Client, Windows 98 client can only access stand-alone DFS 5.0 clients. A client for domain-based DFS has to be downloaded. Windows NT 4.0 > SP3 clients can access DFS 5.0.
You can specify alternate paths for a DFS leaf volume, thereby balancing the data load over a number of servers.
When you use the Active Directory client, you attempt to connect a fault tolerant DFS root via \\domainname\share (rather than \\servername\share) when you use DFS. The Windows 95 client cannot use the DNS namespace as part of accessing Windows NT shares. Other clients can.
A server can host a single DFS root, and you can have an unlimited number of DFS roots in each domain. Up to 32 servers can host the same root. A DFS path can be up to 260 characters. A DFS root can have a maximum of 1000 DFS links.
DFS info, the root and all it links, is stored as a single entity known as a blob. When a change is made to the blob, the whole blob replicates until consistent throughout the domain. This blob is part of the Partition Knowledge Table (PKT). The replication take 5 minutes between domain controllers in the same site and at least 15 minutes if they are in different sites.
Each server that hosts a domain-based DFS root obtains the PKT from the Active Directory. The synchronization of the DFS root and Active Directory (PKT information) is triggered in three ways:
| Start-up. When a server hosting a domain-based DFS root boots, the booting server obtains the PKT from an active domain controller. |
| Changes. When changes are made to the PKT (changes are made in Active Directory itself), all participating DFS root servers are notified that changes have occurred that the servers must retrieve from the directory. |
| Set interval. Domain-based DFS root servers poll the directory service for current PKT information every 24 hours. |
When a client machine requests a referral to a DFS share, the DFS root server
uses the Partition Knowledge Table (PKT) to direct the client to the physical
share. This PKT will remain in the RAM of the client and will by default be
refreshed every 5 minutes (300 seconds). It contains all available replicas for
a share.
The PKT is stored in Active Directory for domain-based DFS and stored in the
registry for stand-alone DFS. In a network environment, the PKT maintains all
information about DFS topology, including its mappings to the underlying
physical shares. After the DFS root server refers the client to a list of
replica shares that correspond to the requested DFS link, the client then uses
Active Directory site topology to contact a replica within the same site or, if
one is not available, a replica outside the site.
In Windows 2003 this procedures can be changed by using closest site selection.
First the client will try to connect to a DFS root or link within the site. If
these are not available you can assign cost to other DFS links. Based on the
cost the DFS client will choose a DFS link. This procedure required the ISTG to
run on Windows 2003 domain controllers. It can be enabled via Dfsutil
/root:<dfsname> /Sitecosting /enable.
The default TTL for a root DFS share is 5 minutes (300 seconds) in
contradiction with the links that have a TTL of 30 minutes. If a DFS (root) share
is accessed, the TTL will be renewed, until the share has not been accessed for
the TTL, a reboot is made or Clear History is pressed on the DFS-tab of a
Windows 2000 client. If the cache is not refreshed, new available replicas will
not be known by the client.
A PKT also stores site information so Windows 2000 can contact a DFS (root)
share within their own site.
You can control access to the PKT to stores the DFS mapping information, via the
DFS snap-in.Select the DFS root to modify, right click and select properties. On
the security tab you can set the security for the DFS root object.
When implement domain based DFS, make sure that all Windows 2000 domain
controllers are running the DFS service. If not, workstations on the subnet
where the DFS-less domain controller is located may have trouble locating the
DFS resources.
For replication to be enabled, the shares for the DFS root or link must
reside on an NTFS 5.0 formatted partition on a Windows 2000 domain controller or
member server. The Primary flag marks the specified servers' files and folders
as authoritative the first time replication takes place, after which normal
multi-master replication takes place. Only Windows 2000 clients can connect to
fault tolerant DFS roots. Older clients can connect directly to an individual
DFS root to participate in the fault-tolerant environment by using the
machine-name instead of the domain-name.
A replica set is two or more copies of a DFS root or DFS shared folder that
participate in replication. Here are the two types of replica sets:
| DFS root replicas. DFS root replicas replicate DFS
"knowledge." In domain-based DFS, you can create DFS root
replicas, that is, two or more copies of the DFS root, each on a different
server. As stated above, a DFS root replica uses the PKT to provide
referrals to clients. This is why replication of DFS roots is also referred
to as replication of DFS knowledge. |
| DFS link replicas. DFS link replicas replicate DFS "content." When you create a DFS link, you can create a replica set by specifying multiple shared folders for that link. Each copy must be located on a separate computer, but all share the same logical DFS name. The fact that more than one copy (which can be read-write copies) exists is transparent to users. You can specify hundreds of shared folders in a replica set. Just as DFS root replicas support high availability for DFS roots, DFS link replicas support high availability for a portion of the DFS namespace. You can select manual and automatic replication. When using automatic replication (NTFS required) , FRS synchronizes the content by default every 15 minutes. Stand-alone DFS can only use manual replication. |
When a connection to an alternate DFS share fails, it will take same time before the protocol detects a connection failure. (time-out settings) Once that occurs, DFS selects a new alternate from the local PKT cache. If none is available it checks the DFS root to check if PKT entries have been changed. If no alternate are available, a failure occurs. On files that were open, errors will occur if the connection to the server dropped.
Most administrative functions can be performed with the Distributed File System console (dfsgui.msc) or via dfscmd.exe or via the dfsutil.exe in the support\tools folder on the W2K disk.
Last update : 3 March 2003