Logo
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

Windows Server 2008 R2 : File System Management and Fault Tolerance - The Distributed File System

4/9/2011 4:16:48 PM
To improve the reliability and availability of file shares in an enterprise network, Microsoft has developed the Distributed File System (DFS). DFS improves file share availability by providing a single, unified namespace to access shared folders hosted across one or more servers. A user needs to only remember a single server or domain name and share name to connect to a DFS shared folder.

DFS has many benefits and features that can simplify data access and management from both the administrator and end-user perspective. DFS provides three main functions, as follows:

  • Data redundancy— DFS can provide access to a single share that is hosted on multiple servers. This allows clients to get referred to or fail over to a different server if the primary server cannot be contacted.

  • Automated data replication— DFS can be configured to utilize the Distributed File System Replication (DFSR) service, and can be configured to automatically synchronize folders between DFS servers to provide data redundancy or centralized storage of branch office data.

  • Distributed data consolidation— DFS can be used to provide a single namespace that can contain several distinct or unique data sets, which can be hosted on separate servers. This enables administrators to provide access to existing file shares hosted on many different file servers, from the single namespace, without adding replication or redundant data sets.

DFS Namespaces

DFS can be used in a few different ways, but it will usually require the creation of a DFS namespace. A DFS namespace can be the name of a single server and share folder or the DNS and NetBIOS name of an Active Directory domain and share folder. The DFS namespace is also referred to as the namespace root. The namespace allows connections to automatically be redirected to different servers without user knowledge. Using Figure 1 as an example, when a client connects to the domain DFS namespace named \\Companyabc.com\Apps, the client will be redirected to \\Server10\Apps, and the client will be unaware of this redirection.

Figure 1. Domain DFS namespace.

For DFS to function properly with regard to client redirection and just basic connectivity, a compatible DFS client is required. In a network that supports different versions of Windows, Apple Mac, and UNIX clients, DFS should be tested on all clients before it is released to production. DFS-compatible clients are currently available for the following Microsoft Windows operating systems:

  • Windows 2000 Professional and Server.

  • Windows XP Professional.

  • Windows Server 2003 and Windows Server 2003 R2.

  • Windows Vista Business, Ultimate, and Enterprise.

  • Windows 7 Professional, Ultimate, and Enterprise.

  • Windows Server 2008 and Windows Server 2008 R2.

  • Windows NT Server and Workstation 4.0 with Service Pack 6a and the Active Directory Client Extension found on the Windows 2000 Server CD.

  • Windows 98 can support DFS domain namespaces with the installation of the Active Directory Client Extension found on the Windows 2000 Server CD.

Because DFS clients do not connect to the actual server by name, administrators can move shared folders to new servers and user logon scripts and mapped drive designations never need to be changed. In fact, DFS data presented in a single namespace can be hosted on multiple servers to provide redundancy and distribution of large amounts of data.

Standalone DFS Namespace

A standalone DFS namespace utilizes the name of the server hosting the DFS namespace. Standalone DFS namespaces should be used when file system access needs to be simplified and the amount of data exceeds the capacity of a single server. Also, if no Active Directory domain exists, a standalone DFS namespace is still supported. When a standalone DFS namespace is created on a Windows Server 2008 R2 server that is a member of an Active Directory domain, DFS replication can be configured.

Domain-Based DFS Namespace

A domain-based DFS namespace utilizes the name of the Active Directory domain the DFS namespace server is a member of. A domain-based DFS namespace is created upon deployment of an Active Directory domain at the location of \\domain\SYSVOL to replicate the domain group policies and logon script folders. Domain-based DFS namespaces support replication using either the File Replication Service or the new Distributed File System Replication service.

Domain-Based DFS Namespace Windows 2008 Mode

When a new domain-based DFS namespace is created on a Windows Server 2008 R2 system, an option to enable Windows Server 2008 mode is presented. This option is available on Windows Server 2008 and Windows Server 2008 R2 systems when the namespace is hosted on either operating system, and the domain the system is a member of must be running in Windows Server 2008 domain functional level and at least Window Server 2003 forest functional level. This means that the domain must have only Windows Server 2008 domain controllers and the entire forest must have only Windows 2003 and/or Windows 2008 domain controllers.

Windows Server 2008 mode enables the namespace to contain more than 5,000 DFS folders and it also enables access-based enumeration within the DFS namespace. Historically, many organizations ran into issues when deploying DFS because over time, the number of folders beneath a namespace grew too large and they had to create multiple namespaces and segregate the data, which in some cases defeated the purpose for deploying DFS. Windows Server 2008 namespace mode surpasses this previous limitation and with the added bonus of access-based enumeration, it allows for users to locate the data that is relevant to them much easier.

It is important to note that the same functionality enabled for a Windows 2008 mode domain-based namespace exists on standalone DFS namespaces when the namespace server is hosted on a Windows Server 2008 R2 server, so this functionality can be leveraged immediately, even in organizations that are far from meeting the requirements for Windows 2008 mode domain-based namespaces.

DFS Replication

When an Active Directory domain exists, standalone and domain-based DFS namespaces support the replication of DFS data stored on multiple servers. This can be a valuable tool used to distribute company applications to each site or to provide centralized storage of remote office data for redundancy, centralized backup, and to support users who travel and work in different offices.

With the release of Windows Server 2003 R2 and further improved in Window Server 2008 R2, a service to extend the functionality and optimize DFS Replication has been created. This service is called the Distributed File System Replication (DFSR) service, which utilizes the new Remote Differential Compression (RDC) protocol. DFSR replaces the legacy File Replication Service (FRS) that was previously used to replicate DFS data. As long as all of the DFS servers defined in a DFS replication group are running Windows Server 2003 R2 or later, the DFSR service will be used to replicate the data. If any of the systems are running a previous version operating system, DFS data will be replicated using the File Replication Service. There is one exception to this rule: The Domain System Volume (SYSVOL) will be replicated between domain controllers using the File Replication Service, even if all the domain controllers are running Windows Server 2008 R2, until the domain functional level is raised to the Windows Server 2008 level and the SYSVOL is migrated from FRS to DFSR.

DFS Replication and DFS namespaces are independent of one another, but they can be used together, as they are commonly deployed in this fashion. Replication of folders can be set up between servers that do not host any DFS namespaces or namespace folders but the DFS Replication service must be installed on all systems participating in the replication. Windows Server 2008 R2 increases DFS Replication security and performance because all DFS Replication is compressed and encrypted. Note that the data stream cannot be set to run unencrypted.

DFS Terminology

To properly understand DFS, a number of technical terms are used when deploying, configuring, and referencing DFS. Although the DFS namespace and DFS Replication have already been described, the remaining terms should also be understood before reading the remainder of this article or deploying a new DFS infrastructure:

  • DFS namespace— A unified namespace that presents a centralized view of shared folder data in an organization.

  • DFS namespace server— A Windows server that hosts a DFS namespace.

  • DFS namespace root— The top level of the DFS tree that defines the namespace for DFS and the functionality available. The namespace root is also the name of the DFS namespace. A domain-based root adds fault-tolerant capabilities to DFS by allowing several servers to host the same DFS namespace root.

    Note

    Depending on which Server version, service pack, and edition of Window Server 2003 or 2008 is used will determine how many namespaces are supported on a single server. Please refer to online Microsoft documentation to determine which edition is right for your organization’s implementation of DFS.


  • DFS folder— A folder that will be presented under the root when a DFS client connects. When a root is created, folders can be created within the file system, but DFS folders allow the system to redirect clients to different systems other than the namespace server hosting the root.

  • Folder target— A shared folder hosted on a Windows server. The DFS folder name and the share name do not need to be the same but for troubleshooting purposes it is highly recommended. Multiple folder targets can be assigned to a single DFS folder to provide fault tolerance. If a single folder target is unavailable, clients will be connected to another available target. When DFS folders are created with multiple folder targets, replication can also be configured using DFS replication groups to keep the data across the targets in sync. Folder targets can be a share name or a folder beneath a share. For example, \\server1\userdata or \\server1\userdata\Finance are both valid folder targets.

  • DFS tree— The hierarchy of the namespace. For example, the DFS tree begins with the DFS root namespace and contains all the defined folders below the root.

  • Referrals— A configuration setting of a DFS namespace and/or folder that defines how DFS clients will connect to the namespace server, a folder in the namespace, or a particular folder target server. Referral properties include limiting client connections to servers in the local Active Directory site and how often to check the availability of a DFS server. Disabling a target’s referral keeps it from being used by clients. Target referral can be disabled when maintenance will be performed on a server.

DFS Replication Terminology

DFS uses either the File Replication Service or the Distributed File System Replication service to automatically replicate data contained in DFS folder targets. To understand the replication concepts, you must understand some key DFS replication terminology. Here are some important terms:

  • Replication— The process of copying data from a source server folder to a destination server folder.

  • Replication connection— The directory object that defines and manages the replication between a sending and receiving replication member server. The replication connection defines the replication schedule, which service will replicate the data, the sending and receiving members, and any bandwidth restrictions for the connection. Each replication connection has only a single sending and receiving replication member.

  • Replication member— A server that shares a common replication connection. The receiving replication server receives data from a sending member server specified in the replication connection. The sending replication partner sends data to the receiving member specified in the replication connections.

  • Read-only replication folders— Windows Server 2008 R2 introduces support for read-only replicas. This can be useful for auditing, centralized backup, or managing data sets. Only the replication members that are not defined as the primary source can host read-only replication folders. Read-Only Domain Controllers host the SYSVOL as a read-only replication folder. When read-only replication folders exist, it is a best practice to ensure that replication is only one-way to the read-only replication folder.

  • Replication group— All the servers, folders, and connections that define a replication set of data.

  • Multimaster replication— This defines two-way replication between multiple servers in a replication group. With multimaster replication, data changed on any server in the group will be replicated to every other server in the group.

Other -----------------
- Windows Server 2003 : Creating Role-Specific Server Configurations (part 2) - Securing Infrastructure Servers & Securing File and Print Servers
- Windows Server 2003 : Creating Role-Specific Server Configurations (part 1) - Securing Domain Controllers
- Exchange Server 2010 Management and Maintenance Practices : The Exchange Control Panel
- Exchange Server 2010 Management and Maintenance Practices : Maintenance Tools for Exchange Server 2010
- Exchange Server 2010 Management and Maintenance Practices : Proper Care and Feeding of Exchange Server 2010
- SharePoint 2010 : Designing and Managing Pages and Sites for Knowledge Workers - Reviewing Site Features and Site Collection Features
- SharePoint 2010 : Designing and Managing Pages and Sites for Knowledge Workers - Understanding and Using Site Variations
- SharePoint 2010 PerformancePoint Services : Examining Reporting Services Reports
- SharePoint 2010 PerformancePoint Services : Examining ProClarity Analytics Server Page Reports
- SharePoint 2010 PerformancePoint Services : Examining KPI Details Reports
- BizTalk 2010 Recipes : Orchestrations - Configuring a Send Port at Runtime
- BizTalk 2010 Recipes : Orchestrations - Binding Orchestrations
- BizTalk 2010 Recipes : Orchestrations - Creating Multipart Messages
- Windows Server 2008 R2 : File Server Resource Manager (part 4)
- Windows Server 2008 R2 : File Server Resource Manager (part 3)
- Windows Server 2008 R2 : File Server Resource Manager (part 2)
- Windows Server 2008 R2 : File Server Resource Manager (part 1) - Installing the File Server Resource Manager Tools & FSRM Global Options
- Windows Server 2008 R2 : Volume-Based NTFS Quota Management
- Exchange Server 2010 : Installing Edge Transport Monitoring Certificates (part 3) - Install the Agent on the Edge Transport & Configure the Agent to Use the Certificate
- Exchange Server 2010 : Installing Edge Transport Monitoring Certificates (part 2) - Request a Certificate from the Root CA Server
 
 
Most view of day
- System Center Configuration Manager 2007 : ConfigMgr Classic Reports Versus SQL Reporting Services
- Microsoft Visio 2010 : Sharing and Publishing Diagrams - Publishing Visio Drawings to SharePoint 2010 Visio Services
- Extending the Real-Time Communications Functionality of Exchange Server 2007 : Exploring Office Communications Server Tools and Concepts
- Advanced Windows 7 Programming : Working in the Background - DEVELOPING TRIGGER-START SERVICES (part 6)
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 3) - Activating the Workflow
- BizTalk Server 2009 : Editing and Resubmitting Suspended Messages (part 2) - Pseudo-Walkthrough to Perform Edits and Resubmits
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 1) - Understanding iSCSI storage
- Windows Phone 8 : Configuring Basic Device Settings - Passwords and Screen Timeouts (part 1) - Setting the Screen Timeout
- Securing the Workstation : Applying the Castle Defense System (part 6) - Working with external access - Working with the Windows Firewall with Advanced Security
- SQL server 2008 R2 : Reverting to a Database Snapshot for Recovery
Top 10
- Microsoft Project 2010 : Linking Tasks (part 8) - Auditing Task Links,Using the Task Inspector
- Microsoft Project 2010 : Linking Tasks (part 7) - Creating Links by Using the Mouse,Working with Automatic Linking Options
- Microsoft Project 2010 : Linking Tasks (part 6) - Creating Links by Using the Entry Table
- Microsoft Project 2010 : Linking Tasks (part 5) - Creating Links by Using the Task Information Dialog Box
- Microsoft Project 2010 : Linking Tasks (part 4) - Entering Leads and Lags, Creating Links by Using the Menu or Toolbar
- Microsoft Project 2010 : Linking Tasks (part 3) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- Microsoft Project 2010 : Linking Tasks (part 2) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- Microsoft Project 2010 : Linking Tasks (part 1) - Defining Dependency Links
- Microsoft Project 2010 : Defining Task Logic - Manipulating Your Schedule
- Microsoft Lync Server 2013 : Director Troubleshooting (part 3) - Synthetic Transactions,Telnet
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro