Microsoft DFS can provide a simple and fast automatic failover. The failover of any user or application to any replica that you specify will occur if the primary source becomes unavailable.
Jump to Configuring DFS or read more about how DFS works, below.
Distributed File System (DFS) allows you to group shared folders located on different Vaults and allow access to users as a virtual tree of folders known as a namespace. Users and IT do not have to "hunt" the network because the files all appear to be in one location. DFS does this by redirecting users to the share where the data is located when you access a given unified path. All file server access first goes through the Active Directory-integrated DFS root.
DFS’s unified namespace for all shares and folders can be used to redirect all users’ access to files to an alternative location, if the primary local server becomes unavailable. DFS does so by redirecting all the client/user file requests to a secondary backup server (running another Agent) where the data is also located, when this client accesses that same given DFS path. DFS initially will go to the local server, but if it does not respond, it will redirect the request to the backup server. Remember, all file server access goes through the Active Directory integrated DFS root. So as long as any Active Directory is available, access to the files continues. DFS is designed to provide:
A unified namespace that makes it easy for users to find files which are actually distributed across multiple physical locations.
Abstraction layer. Many file paths are hard coded in user configurations (such as mapped drives), which makes it difficult to have users redirect to other servers easily. With DFS, you can keep the namespace constant, while the data is actually on another server.
Failover. Gives networked applications and shares high availability since DFS in Windows 2000 and 2003 supports automatic failover of DFS root folders to a second mirror.
All file server access is made through a hierarchy exposed directory string such as \\Company\project. If you want to access the networked file system, open Windows Explorer and type the path in the Address field. The figure below illustrates two namespaces as users would see them. Notice how the address format differs: one begins with a server name, Software, and the other begins with a domain name, Contoso.com. These differences illustrate the two types of roots: stand-alone roots, which begin with a server name, and domain-based roots, which begin with a domain name. Valid formats for domain names include \\NetBIOSDomainName\RootName and \\DNSDomainName\RootName. Use Domain name.
A root can have one or more root targets. A root target, also known as a root server, is a physical server that hosts a namespace. A domain-based root can have multiple root servers to provide redundancy and high availability, whereas a stand-alone root can only have one root server. Root servers are transparent to users, who see only a single folder, whereas administrators can view the physical root servers by using the DFS snap-in, the DFScmd.exe command-line tool, or the DFSutil.exe command-line tool (part of the Windows Support Tools). The following figure illustrates roots and root servers.
What you will see are DFS links. These are references to real file server shares where the data is actually stored. These in turn are ordinary file shares. You can find out where your files are currently located by selecting an object and open its property page. If it is accessed through DFS, you will have a DFS tab that shows you alternative access paths.
Active Directory resiliency: \\Company\project would be an Active Directory integrated DFS root share, which makes it possible to keep the links themselves replicated (by Active Directory) for availability. If one of the servers providing the DFS root share goes down, the clients automatically use another copy of the DFS root on some other Active Directory server and keeps on using DFS and data on other servers.
Understanding the Protocol: The underlying DFS mechanism is simple. The Windows client (user) and Windows server each have special agents installed on them that allow the server to signal, and the client to understand, instructions to redirect a network connection to a different server. A DFS share is essentially a standard network share with additional functionality. This functionality does not come into play until the client accesses a subdirectory that is actually a mapped shared folder; until then it looks and acts just like any other share. However, specifics of the DFS protocol begin to appear the moment a client requests a directory that is actually a mapped shared folder.
To configure Failover Setup of DFS
Set up the system, i.e., install Agents, create Jobs, select and mirror data among your sites.
Create a DFS root. (Do not link Jobs to the root.) DFS roots must be created by you, domain based, on partitions generated with Windows. You will have multiple targets in the root target referral list.
Add DFS links. (These link folders can be linked to your Jobs.) You can add DFS links under the DFS roots to reference (referral) any root or link in the DFS tree.
Specify replicas or link targets for a DFS root or link. Multiple DFS Targets.
Your setup resulted in mirror copies on two or more Windows servers, which update as the files change. These mirrors at your Agents are accessible by Active Directory and can therefore be link targets. All copies are referred to as replicas, including the local version on your primary. DFS-aware clients will automatically select the nearest replica based on the site topology information. They only redirect to the alternate replica if the original is unavailable.
 |
DFS can sometimes see a directory as "not exactly" NTFS. The error message may refer to "parse point." If so, type in the root directory, a layer above the actual folder. In other words, have the replica name in the root be one level above the folder that is actually being replicated. For instance, if the replicating folder is C:/USA/Texas/Dallas, then put C:/USA/Texas as the replica. Or add a new level C:/USA/Texas/DfsReplica/Dallas and make DFSReplica the replica in the root. At the other sites (the backup site), add this same level (DFSReplica), but share out the correct folder (Dallas), and just ignore this new level. Some systems require a different set of steps: After you create the DFS root, you might then need to configure DFS Replication in a full mesh environment. Setup the rights to allow write to the share. Then create a new folder, and after that folder has been created in the other computers too, stop replication in DFS. Then setup the Agents to replicate anything in this folder. |
Refer to Microsoft Technet to help configure your DFS shares http://technet.microsoft.com/en-us/library/bb727150.aspx
|
If there are no available root targets in the client's site, the client will randomly connect to another DFS root target in any site. With Windows 2003, if a root target is not available in the client's site, it will randomly look for a target in the next closest site, and so on. This feature, called Closest Site Selection automatically connects the client to the closest possible DFS target. For Closest Site Selection to work on link targets, Intersite Topology Generator (ISTG) must be running on Windows 2003. All domain controllers in a domain must be running Windows 2003 for Closest Site Selection to work on domain root targets. |
In DFS failover, clients attempt to access another target in a referral after one of the targets fails to respond or is no longer part of the namespace. Clients must access a domain-based namespace by using the format \\DomainName\RootName. If a client accesses a domain-based namespace directly on the root server (\\RootServer\RootName), root target failover does not occur. DFS failover is only performed when a client opens a file or folder. If a client has files or folders open and attempts to read or write to them when the target server is unavailable, the application will receive a failure on that operation.
Referrals are cached locally to maintain performance, and if replicas are available, all replicas are provided to the DFS client. The client chooses which referral to use as a failover and preference is still given to replicas within the same site as the client. After a referral is selected, a session setup is performed (credentials are passed to the new server if a prior connection does not exist). If the selected referral fails, a failover process begins. The speed and implications of the failover depend on what the client was doing at the time of the failure, how the failure occurred, and how tolerant of delays an application is.
To configure user connections to the local DFS image
At each client workstation, map a network drive to the data folder you set up via DFS.
Right-click this new network drive, then click Properties.
On the DFS tab, specify the server you want to go to and set it to Active.
The DFS topology is stored in the server–based Partition Knowledge Table (PKT). When DFS roots and links are accessed by users, the computer caches that portion of the PKT and connects to one of the servers in the referral list. The PKT maps the logical DFS namespace into physical referrals, as shown below. (Replicas appear as a list for a single DFS link.)
DFS path |
Link [server and share] |
Time-To-Live |
DFS name #1 |
UNC name #1 |
5 minutes (default) |
|
UNC name #2 |
5 minutes |
|
UNC name #3 |
5 minutes |
DFS name #2 |
UNC name #4 |
5 minutes |
|
UNC name #5 |
5 minutes |
The PKT also stores site information, which is used to connect users to DFS roots and links in the same site. The PKT is a sorted lookup table. One PKT resides in Active Directory for each DFS root in a domain-based DFS. The PKT for a stand-alone DFS resides locally in the registry. This table determines the failover.
Multiple remote shares will correspond to a single mapped shared folder. The client requests information about a mapped shared folder and the DFS server provides it with a listing of the servers. This is shown in the SMB portion of the packet description provided by Network Monitor:
SMB: R transact2 NT Get DFS Referral (response to frame 55)
SMB: Transaction data
SMB: DFS Path Consumed = 36 (0x24)
SMB: DFS Number of Referrals = 4 (0x4)
SMB: DFS Server Function = 2147450878 (0x7FFF7FFE)
SMB: DFS Version 2 Referral
SMB: DFS Version Number = 2 (0x2)
SMB: DFS Server Type = Unknown Server Type
SMB: DFS Proximity = 0 (0x0)
SMB: DFS TimeToLive = 604800 (0x93A80)
SMB: DFS Filename = \TONY\DFS\Test\DFS
SMB: DFS 8.3 Filename = \TONY\DFS\TEST\DFS
SMB: DFS Sharename = \TONY\DFS4
SMB: DFS Version 2 Referral
SMB: DFS Version Number = 2 (0x2)
SMB: DFS Server Type = Unknown Server Type
SMB: DFS Proximity = 0 (0x0)
SMB: DFS TimeToLive = 604800 (0x93A80)
SMB: DFS Filename = \TONY\DFS\Test\DFS
SMB: DFS 8.3 Filename = \TONY\DFS\TEST\DFS
SMB: DFS Sharename = \TONY\DFS2
SMB: DFS Version 2 Referral
SMB: DFS Version Number = 2 (0x2)
SMB: DFS Server Type = Unknown Server Type
SMB: DFS Proximity = 0 (0x0)
SMB: DFS TimeToLive = 604800 (0x93A80)
SMB: DFS Filename = \TONY\DFS\Test\DFS
SMB: DFS 8.3 Filename = \TONY\DFS\TEST\DFS
SMB: DFS Sharename = \TONY\DFS1
SMB: DFS Version 2 Referral
SMB: DFS Version Number = 2 (0x2)
SMB: DFS Server Type = Unknown Server Type
SMB: DFS Proximity = 0 (0x0)
SMB: DFS TimeToLive = 604800 (0x93A80)
SMB: DFS Filename = \TONY\DFS\Test\DFS
SMB: DFS 8.3 Filename = \TONY\DFS\TEST\DFS
SMB: DFS Sharename = \TONY\DFS3
As you can see, the client determines which network share it will attempt to access. It always goes to the local one, unless there is a problem. For example, a user connects to a DFS branch that mapped to four shares and creates a new file. The server fails and the client redirects. The client might issue the next commands through an SMB session connected to a different share. Therefore, only with a real-time mirror can alternate shares ever work with read/write files, if they were redirected to a different server site. This is because the file updates always take place across sites.
Scenario 1
A client is browsing through a replicated folder. The computer hosting the replica loses power or drops off the network for some reason. In order to fail over, the client computer must first detect that the hosting computer is no longer present. How long this takes depends on which protocol the client computer is using. Many protocols, such as TCP/IP, account for slow and loosely connected WAN links before the protocol itself times out. After that occurs, DFS immediately selects a new replica. If no protocols are available from the local cache, the DFS client consults with the DFS root to see whether the administrator has modified any PKT entries and initiates a fresh replica selection and session setup.
Scenario 2
A client is browsing through the folder. The computer hosting the replica loses the hard disk containing the replica, or the replica itself is deactivated. In this scenario, because the server hosting the replica is still responding to the client request, the failover to a fresh replica occurs at near-LAN speed.
Scenario 3
A client has open files. The computer hosting the replica loses power or drops off the network for some reason. In this scenario, you have the same protocol failover process described in Scenario 1. New attempts to open files trigger the same failover process that is described in Scenario 1. Operations on already open files fail with appropriate errors.
Scenario 4
A client has open files. The computer hosting the replica loses the hard disk containing the replica, or the replica itself is deactivated. In this scenario, you have the same rapid failover process that is described in Scenario 2. In addition, the failover depends on the application that previously had file handles from the previous replica to detect the change and establish new handles.
It then establishes an SMB connection to the server and share referenced and does whatever it needs to do in normal SMB fashion. Once the referred computer is connected to, traffic is no longer DFS specific. If the client already has a connection to a given share, a new connection is not established. Connections are reused whether or not the original connection was established through DFS. You should reference the fewest number of network shares possible.
Prior to Windows Server 2003 Service Pack 1, there was no way for administrators to configure clients to fail back to their local servers; this behavior can be problematic in branch office environments when clients continue to access the hub server even after the branch server is restored.
The failback settings for roots and links can be set using the /TargetFailback option of DFSutil. In addition, the DFS Client Failback QFE for Windows XP and Windows Server 2003 must be installed to enable the client to perform the failback. Setting the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters\SysvolNetlogonTargetFailback registry key and restarting the DFS service on the domain controller enables target failback for SYSVOL/NETLOGON referral requests handled by that controller.
Key Terms Associated With DFS
DFS topology. Overall logical hierarchy of a distributed file system, including elements such as roots, links, shared folders, and replica sets, as depicted in the DFS administrative console. This is not to be confused with DFS namespace, which is the logical view of shared resources seen by users.
DFS root. The share at the top of the DFS topology that is the starting point for the links and shared files that make up the DFS namespace. A DFS root can be defined at the domain level for domain-based operation or at the server level for stand-alone operation. Domain-based DFS can have multiple roots in the domain but only one root on each server.
Root replica. The server that duplicates a DFS root to provide greater availability. The server that is hosting the DFS root is responsible for handing out referrals to clients for shared folders. If that server becomes unavailable and a root replica has not been created, the DFS namespace becomes inoperative. Replicas can also be created for existing DFS links.
DFS link. Part of the DFS topology that lies below the DFS root and forms a connection to one or more shared folders or another DFS root. It does this by mapping a DNS name to the standard UNC of the target shared folder.
DFS shared folder. Files or folders in the DFS namespace that are shared by users with proper permissions. Shared folders can exist at the root level (domain-based DFS only) or be referred to by DFS links.
Partition knowledge table (PKT). A table that maps root and replica nodes in the DFS namespace to Active Directory sites and physical servers. For a domain-based DFS root, the PKT is stored in Active Directory and made available to each domain controller in a domain. For a stand-alone DFS root, the PKT is stored in the individual server's registry. When a DFS client gains access to a shared folder in the DFS namespace, it caches that portion of the PKT for the length of time specified in the TTL.
Referral. The referral is the physical server and share residing in the PKT that clients connect to.
Time-To-Live (TTL). The length of time that a DFS client stores the referral information from the PKT when it accesses a shared folder. DFS clients request a new portion of the PKT when the TTL expires or when the client is restarted. The TTL resets if the shared folder is visited before expiration. It is configurable on a per-link basis.
Revision level. Refers to DFS client compatibility. There are three revisions of DFS clients that can be viewed in Network Monitor traces. Clients that are running Windows NT version 4.0, Windows 98, and Windows 95 support DFS revision level 2; clients that are running Windows 2000–based support revision level 3. Version 1 clients do not exist. DFS clients and servers negotiate the highest common protocol revision supported.
The instructions below use the following information. (Substitute your information when performing the procedure.)
Active Directory name is koenigshouse.com
Win2003 server name is Storage
DFS Root name is Documents
DFS Link name is Public
The folder that is replicating on the server is shared as NetworkData
Creating the DFS Root
Open DFS. (Start > Run> type dfsgui.msc > ENTER.)
Click Action, then click New Root. The New Root Wizard appears.
Click Next.
Ensure Domain Root is selected, then click Next.
In the Domain name, ensure that your domain is listed (\\koenigshouse.com in this example), then click Next.
In the Server name box, type the server name that will hold the DFS Root (in this example, storage.koenigshouse.com), then click Next.
Type the name of the DFS Root (in this example, Documents) and any comments, then click Next to continue.
Type the location of an empty folder on the server that will be used as the DFS placeholder, then click Next to continue. (If necessary, create one.)
Click Finish.
Creating the first DFS Link
Open DFS. (Start > Run> type dfsgui.msc > ENTER.)
Click Action, then click Show Root.
In the Show Root dialog box, click your DFS Root that you created in the previous procedure.
Right click your DFS Root, then click New Link. Type the DFS Link name (Public in this example), the location of the Shared Folder on the server (\\Storage\NetworkData in this example), and any comments. You now have a DFS Link called Public that points to a share called NetworkDat on the \\Storage server.
Open Explorer and type \\koenigshouse.com. You will see the DFS Root called Documents that you set up in the previous procedure.
Open Documents, and you will see the DFS Link called Public.
Adding Additional DFS Targets to a DFS
Open DFS. (Start > Run> type dfsgui.msc > ENTER.)
Click Action, then click Show Root.
In the Show Root dialog box, click your DFS Root.
Click the DFS Link and you will see the DFS Target on the right.
Right-click the DFS Link, then click New Target.
Type or browse for the path to the shared folder. (Be sure to clear the replication set check box.)
Now you should have two servers available to which clients can connect. You can add all server shares that are being replicated.