Planning for a DFS implementation requires an
administrator to understand the different types of Distributed File
System namespaces and the features and limitations of each type,
including which operating system versions and domain functional levels
are required to enable certain functionality. Also, the administrator
must understand which tasks can be automated using DFS and which must be
configured manually. For instance, DFS can create the file share for
namespace roots, folders, or folder targets, including setting share
permissions, but the NTFS permissions and additional share features
cannot be configured during this process. As a best practice, DFS
administrators should create and define shares, share permissions, and
NTFS permissions on the shared folder prior to defining these shares as
DFS folder targets.
When an organization
wants automated file replication, domain-based DFS and standalone DFS
namespaces deployed in an Active Directory domain can utilize Windows
Server 2008 DFS Replication using the Remote Differential Compression to
replicate shared folders if all of the participating DFS servers are
running Windows Server 2008 or later.
Configuring File Share and NTFS Permissions for DFS Root and Folder Targets
The DFS Management console
is not currently capable of configuring advanced share features or
setting or synchronizing NTFS permissions for namespace root shares or
folder targets. This means that for administrators to ensure proper
folder access, administrators should first configure the advanced share
features and NTFS permissions on folders that will host namespace roots
and folder targets before configuring DFS. If multiple namespace root
servers or folder target servers will be utilized, permissions between
the servers will need to be manually synchronized to match; otherwise,
undesired access or lack or access might result.
Choosing a DFS Type
As mentioned previously, DFS
namespaces can be based on the server name (standalone) or the domain
name hosting the namespace. Both provide a single namespace, but only
domain namespaces can provide redundancy at the namespace root level.
Standalone DFS Namespace
A
standalone DFS namespace provides the characteristic DFS single
namespace. The namespace is defined by the name of the server that hosts
the root target and the share. Standalone roots can support only a
single root target, but an administrator can configure multiple folder
targets. Data stored within multiple folder targets must be kept in sync
manually unless the standalone namespace server and all of the folder
target servers are members of a single Active Directory domain and will
utilize DFS Replication. Standalone roots are normally deployed in
environments that do not contain Active Directory domains and can be
used to enable access-based enumeration of DFS folders as well as
enabling the ability to host more than 5,000 folders within the
namespace.
Domain-Based DFS Namespace
For an administrator to
create a domain DFS root, the initial namespace root server must be a
member of an Active Directory domain. A domain-based DFS namespace
provides a single namespace that is based on the DNS and NetBIOS domain
name plus a root name, when the namespace is created. Domain-based DFS
namespaces can utilize DFS Replication to replicate data between
multiple folder targets.
Windows 2008 Mode for Domain-based DFS Namespace
Windows 2008 mode for
domain-based namespaces enables the namespace to contain more than 5,000
folders and access-based enumeration can also be enabled. To enable
this functionality, the forest must be set to Windows Server 2003 or
greater forest functional level and the domain that contains the
namespace servers must be in Windows Server 2008 domain functional
level.
Planning for DFS Replication
When an organization wants to
replicate data stored on Windows Server 2008 R2 systems published in DFS
namespaces, administrators must create the namespaces on servers that
are members of an Active Directory domain. Replication can be configured
between multiple targets on a DFS folder or on Windows Server 2008 or
Windows Server 2008 R2 systems that do not participate in a DFS
namespace. When multiple targets are defined for a folder, DFS can
utilize the FRS or the DFSR service to create replication connection
objects and automatically synchronize data between each target.
Initial Master
When replication is
first configured using the DFS console and the New Replication Group
Wizard, the administrator can choose which target server will be the
initial master. The data contained on the initial master is replicated
to the remaining targets. For targets on servers other than the initial
master, existing data is moved to a hidden directory, and the current
folder is filled with the data contained only in the initial master
folder. After initial replication is complete, the administrator can
restore data moved to the hidden folder back to the working directory,
where it can trigger replication outbound to all the other replicas in
the replica set, if replication is two-way and neither target is set to
read-only. As a best practice, when adding additional targets to a
replica set, try to start with empty folders.
The Staging Folder
The
staging folder is the location where a DFS Replication member stores
the data that will be replicated to other replication members within a
replication group. In a fully synchronized replication group, the
staging folder on all servers will be empty. Because replication data
will travel through this folder, the drive hosting the staging folder
must have sufficient free space to accommodate the maximum size of the
staging folder and should be able to handle the additional disk load. By
default, the staging folder is limited to 4GB. The default location for
the staging folder will be located in the target share folder in a
hidden directory named c:\Apps\DfsrPrivate\Staging, if the target is
located in c:\Apps as an example. The staging folder and its 4GB limit
is unique to each target on each server.
Determining the Replication Topology
Windows Server 2008 R2
DFS provides a number of built-in replication topologies to choose from
when an administrator is configuring replication between DFS folder
targets or replication group members; they’re described next. As a
general guideline, it might be prudent to configure DFS Replication
connections and a schedule to follow current Active Directory site
replication topology connections or the existing network topology when
the organization wants true multimaster replication.
Hub and Spoke
A hub-and-spoke topology
is somewhat self-descriptive. A single target is designated as the
replication hub server, and every other target (spoke target) replicates
exclusively with it. The hub target has two replication connections
with each spoke target: sending and receiving. A hub-and-spoke topology
requires three or more servers, and when the hub target is unavailable,
replication updates stop between all replication members. Windows Server
2008 R2 introduces the ability to specify more than one hub when
creating a hub-and-spoke replication topology. In previous releases,
this required creating a custom topology.
Full Mesh
Using a full mesh
topology, each target has a connection to every other target in the
replication group. This enables replication to continue among available
replication members when any member becomes unavailable. Because each
member has a connection to every other member, replication can continue
with as few as two replication members. Using this topology with
read/write replication sets can lead to data conflicts if data is being
changed in multiple sites so this topology should be used with caution.
No Topology and Custom Topology
During the creation of a
replication group, one of the topology options is the No Topology
option. Selecting this option enables an administrator to create a
custom replication topology after the replication group is created. A
custom topology allows an administrator to define specific replication
connections for each target. This option can be useful if an
organization wants to define one-way replication for centralized backup
or to optimize read-only replicated folders. Also, this can be most
useful when creating a topology for a network that is connected using
different speed WAN links or each connection needs to have a specific
schedule and bandwidth setting.
Replication Schedule and Bandwidth Throttling
Windows
Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 DFS
Replication support scheduling replication, as well as restricting the
amount of bandwidth a replication connection can utilize. In the
original version of DFS that came with Windows 2000 and the initial
release of Windows 2003, administrators were limited in their
replication scheduling options and forced to limit replication to after
hours for large data sets as opposed to trickling data replication all
day long using only a portion of the wide area network (WAN) link
between sites. For large data sets that will initially replicate across
the WAN, the initial replication connections can be configured to run
limited bandwidth during business hours and full bandwidth after hours
until replication has completed and restrictions can be removed if
desired.
