Consider a large enterprise network with several servers and numerous shared data spread across those servers. The more servers there are and the more shares each has makes it more tedious and frustrating for users to readily and easily locate the resources they need. Users may be required to remember the names of numerous shares and exactly which server a share is on.
In this situation, users may have difficulty keeping track of what shared data is where (even with the help of mapped drives).
What if the task of keeping track of what shares were where was simplified for the user. This would ease user access to shares? In addition, what if some redundancy was built into the shared folders so that we have multiple copies of Share1 spread across several servers, and similarly multiple copies of Share2 and so forth? Then, if one server fails or one share gets corrupted we have a backup copy, and if any copy share could be accessed automatically upon a failure, we have seamless support for the share structure. Add to this a Round Robin type access to the duplicated shares, and we also have a distributed load.
Users can now access a single hierarchy created by DFS, which can also provide share duplication and load distribution. Above, Share1, Share2, and Share3 are distributed. Share4 – Share9 are not yet distributed.
DFS offers the following benefits:
Shared folders on a network appear in one hierarchy of folders created by a DFS Root with links. This simplifies user access.
Fault tolerance is an option by replicating shared folders. Uses the Microsoft File Replication Service (FRS).
Load balancing can be performed by distributing folder access across several servers.
There are two DFS models as follows:
Standalone
No Active Directory implementation
Can implement load balancing, but replication of shares is manual
DFS Root cannot be replicated
DFS accessed by \\Server_Name.Domain_Name\DFS_Root_Name
Domain-based
Available only to members of a domain
Can implement fault tolerance by Root and Link replication and load balancing, and replication of links and root is automatic
DFS accessed by \\Domain_Name\DFS_Root_Name
DFS Topology:
The DFS root (a table of contents)
Main container that holds links to shared folders
Folders from all domain computers appear as if they reside in one main folder
DFS links (pointers to shares)
Designated access path between the DFS root and shared folders
Replica sets (targets (duplicated shares))
Set of shared folders that is replicated to one or more servers in a domain
Creating Bare DFS Root Structure:
To start the process of creating a DFS hierarchical structure you first need to install DFS and create a DFS Namespace with a Root. This needs to be undertaken on each server that is to participate in the DFS structure i.e. each server that will host shared folders that will be replicated via DFS.
In Windows 2012 Server DFS is installed via the File and iSCSI Services role.
Select the DFS Namespaces and DFS Replication File Services to install and click next.
DFS Namespaces and DFS Replication File Services are now installed.
Creating a New DFS Namespace:
Now, let's start to steadily build and configure a DFS Structure by first creating a new DFS namespace (a DFS Root) on the member server where the DFS role has just been installed (a member server called DFS1 in this scenario). First, launch DFS Management via the Server Manager dashboard.
Create a new DFS namespace (create a root).
Confirm the name of the member server unit that will host the DFS root namespace being created.
Next, give the DFS namespace a root name. Then click the "Edit Settings" button.
Clicking the "Edit Settings" button allows you to confirm\change where this DFS Root will be placed on this member server, and set permissions for the shared folder.
Choose a Domain-based DFS namespace or a Workgroup-based DFS namespace.
The next screen shows a summary of configuration for the new DFS namespace being created.
After completing the installtion, the new namespace will appear in DFS Management as shown below.
You can also now browse to the new DFS root folder as shown below.
Creating Links:
With a bare base DFS structure in place, now head back to DFS Management to add in some pre-created shared folders to it. This will provide a single point of reference to these shares (called Links) for users on the LAN. In the DFS console, right click on the DFS namespace root and select "New Folder" from the drop down menu to create a Link to a pre-created share.
Next, enter the link details: Name the Link and enter a path to the pre-created shared folder this link will point to.
Add further links to the DFS structure to reference other pre-created shared folders.
With a basic DFS structure in place and links added, shared folders can be referenced from a users client system. Users can now access the shares via the DFS structures’ links. The shares are offered up to the user independently of which server the shares are actually on. The user just needs to know the network domain name and the DFS namespace root name.
Access in a Domain based DFS is via: \\Domain_Name\DFS_Root_Name. The image below shows access via a run command from within a Windows 8 client domain member.
Links that provide access to shares show no dependence to any actual server the shares are stored on.
Note: The Level of access is still determined by share and NTFS permissions.
Creating Replica Shares:
With links in place for each shared folder, we would now create duplicates of these shares as a source of backup, should any become corrupted, or the server they are on fails, or goes offline for maintenance. By also pointing each link to an alternative duplicated\replica share, that link can reference the share on more than one location (which is transparent to the user) and thus provides fault tolerance should any one share set fail.
Further, if the duplicated\replicated shares can be accessed in a round robin manner, whereby User1 accesses Share1 on Server1 and then the next user User2 who also wants to access Share1 at the same time, is automatically redirected to the replica of this share on Server4, then there is also load balancing added to fault tolerance.
For shares belonging to the same DFS link to stay synchronized, the servers where each share set resides must have the DFS Replication File Service installed (via Server Manager) and set running.
First, copy the current DFS shares in place to another server. Remember what happens to share and NTFS permissions when you copy folders to a new NTFS volume? Here, 4 shares copied from Server1 to Server2.
With 2 sets of the same share in place and one set already added in to DFS, add the second set as a new target for each appropriate DFS link. Do this by right clicking on the link and select "Add Folder Target" as shown below.
Browse to the where the replica share for the DFS link is located (Server2 in our scenario).
Next, you will be asked if you wish to allow a replication group to be created between the 2 sets of identical shares. Select "Yes".
On the next screen, you can edit the replication group name and folder name.
The wizard will then evaluate your folder targets to see if they are elgible to participate. If so, you will receive a confirmation as shown in the image below.
Next, select the primary member server. This is the server that contains the content that is to be replicated to the folder targets.
Next, select the replication topology. The replication topology consists of the logical connections that DFS Replication uses to replicate files among servers. When you set up a replication group, you can choose from three topologies:
Hub and spoke: This topology requires three or more members; otherwise this option is unavailable. For each spoke member, you can choose a required hub member and an optional second hub member for redundancy. This optional hub ensures that a spoke member can still replicate if one of the hub members is unavailable. If you specify two hub members, the hub members will have a full-mesh topology between them.
Full mesh: In this topology, every member replicates with all other members of the replication group. This topology works well when there are ten or fewer members in the replication group. It is recommended that you not select full mesh topology if you have more than ten members in the replication group.
No topology: Choose this option if you want to create connections yourself after you finish the New Replication Group Wizard or the Replicate Folder Wizard. No replication will take place until you create the connections.
When choosing a topology, keep in mind that two one-way connections are created between the members you choose. These two connections allow data to flow in both directions. For example, in a hub and spoke topology, data will flow from the hub members to the spoke members and from the spoke members to the hub members. The topology can be changed later in DFS Administration, if necessary.
Next, you can choose the amount of bandwidth you wish to allocate to replication traffic. If you do not want replication to occur during peak times, for example, the other option allows you to set specific days and time for replication to occur.
The next window allows you to confirm the settings you have entered into the wizard before creating the replication group. If all is well, click the "Create" button.
The replication group has been created. In DFS Management, you will now see a link with 2 replica share sets.
If you need to set up a replication schedule, right-click the replication group and choose "Properties" and then the "General tab". This contains a button to set the replication schedule and bandwidth used.
Access to DFS shares can be set to random to distribute the load when a client system accesses a target DFS share.
Testing Share Replication:
With replica shares for each link, now set in place for fault tolerance and load balancing, you can test replication by modifying the file\folder structure within one of the shares to see if the replica structure updates accordingly. After adding new files/folders and modifying existing files/folders, you can bring up both target shares (Server1 and Server2 in this case) and compare them.
If share data is modified, but no replication occurs between the shares, check the event logs on the servers where the share resides to look for File Replication Service errors. One possible reason is a lack of space on the drive where the FRS database is stored (%systemroot%\ntfrs\jet). Try freeing up space.
With the base DFS structure in place with share folder links and now duplicate replicated share targets for each Link, a server failure can be tested (simulated by simply turning off a server here, Server2 in this case). Users should still be able to access the DFS structure and Links as before despite the single server failure. If users are still able to access the shares, then it is working correctly.
If the server where the DFS root is located is offline, DFS access is not available. When the DFS server itself is offline, any server may well still have the physical shares available online, but only when accessed directly as you would without DFS in place, for example, using a traditional UNC of \\Server_Name (\\Server1 or \\Server2 in this case), not via the DFS structure format of: \\Domain_Name\DFS_Root_Name.
Creating a Replica DFS Root:
Once the Linked Shares have Replicas, the remaining point of failure is the DFS Root itself (DFS1 in this scenario). If the DFS Root Server (DFS1) fails the DFS structure fails. Thus in addition to creating duplicate shares for each DFS Folder Link, you should also create a duplicate of the DFS Root itself (only possible if the DFS model is domain based).
To accomplish this, we simply installed the DFS Service onto another member server (called DFS2), and in fact a Windows 2008 R2 Server. We have not undertaken any configuration of the DFS service on DFS2. We will use DFS2 as another DFS Server that will provide a backup Namespace\Root. Using the DFS Console within DFS1, add another replica DFS Namespace\ Root Server (DFS2) for DFS root server redundancy as shown below.
On the next screen, enter the namespace server, or click the "Browse" button to locate it. You can also change the path to the shared folder.
The new namespace server should now show in DFS Management.
Now if the original DFS Namespace\Root Server (DFS1) fails, the DFS structure is still available to any client system, via the root Replica (DFS2). You can test this by shutting down Server1. Similarly, if the DFS Namespace\Root Server (DFS2) fails, the DFS structure is still available to any client system, via DFS1.
Additional Notes:
A server with a replica of a DFS root and links cannot have any other roots.
The default replication interval is 15 minutes.
The DFS cache timeout can be set - the default is 1800 seconds.
