Distributed File System (DFS) in Windows Server 2003 Service Pack 1

What does DFS do?
Distributed FileSystem (DFS) allows administrators to group shared folders located on different servers by transparently
connecting them to one or more DFS namespaces. A DFS namespaceis a virtual view of shared folders in an organization.
Using the DFS tools,an administrator selects which shared folders to present in the namespace, designs the hierarchy in which
thosefolders appear,and determines the names that theshared folders show in the namespace.When a user views the
namespace, thefolders appear to reside on a single, high-capacity hard disk. Users can navigatethefolders in the namespace
without needing to know theserver names or shared folders hosting the data. DFS also provides many other benefits,
including fault toleranceand load-sharing capabilities, making it ideal for all types of organizations
Who does this feature apply to?
Storageadministrators managing a DFS namespace, or administrators considering deploying DFS, should beaware of the
changes incorporated in SP1.
What new functionality is added to this feature in Windows Server 2003 Service Pack 1?
DFS Consolidation Roots
Detailed description
New functionality in Distributed FileSystem (DFS) maintains the original Universal Naming Convention (UNC) path of files
after they are moved to a new server.This reduces theimpact of fileserver consolidation and migration, saves end users time
spent searching for files,and ensures that line-of-business applications keep running.
Why is this change important?
Thereare many scenarios whereyou will want Universal Naming Convention (UNC) paths to remain unchanged when the
underlying files are moved to other servers or to other paths.For example,you may want to preservethe UNC paths that users
areaccustomed to if you migrate or consolidateyour existing fileservers to new computers running Microsoft Windows
Server 2003.The paths may beembedded in links, in line-of-business applications,and in other places wherethe names are
difficult to change
What works differently?
Theconsolidation root functionality is mosteasily configured using theFileServer Migration Toolkit,available on the Microsoft
Web siteat http://go.microsoft.com/fwlink/LinkId=37029.
This functionality can also beconfigured manually by modifying keys in the Windows Registry,as described in thearticleabout
using the Distributed FileSystem updateto support consolidation roots at the Microsoft Web siteat
http://go.microsoft.com/fwlink/LindId=43006.
Move and Rename Support for DFS Namespaces
Detailed description
Administrators can modify the DFS namespaceto correct mistakes or to adjust the hierarchy as business needs change or as
new folders areadded to the namespace.
Why is this change important?
Prior to Windows Server 2003 Service Pack 1, there was no way for administrators to renameelements of their namespace.
Renaming or moving an element near thetop of the namespace was particularly difficultas it required manually deleting and
recreating every element below it.
What works differently?
DFS administrators may now usethecommand-line utility dfscmd to move or renamelinks.Thesyntax for this new command
is as follows:
dfscmd /move \\ DFSName \ DFSShareName \ Path \\ ServerName \ ShareName \ Path
Thefollowing examples illustratethe different ways that this command can be used:
To createa new folder, movethecontents of an existing folder into it,and adjustany links under thefolder as
appropriate:
dfscmd /move \\domain\root\old_folder \\domain\root\new_folder
To makean existing folder a subfolder of a new top-level folder and adjustany links under thefolder as appropriate:
dfscmd /move \\domain\root\old_folder \\domain\root\new_top_folder\old_folder
To movethecontents of onefolder to another existing folder
dfscmd /move \\domain\root\folder \\domain\root\other-folder\
ClientFailback
Detailed description
Client failover in DFS namespaces is the process in which clients attempt to access another server in a referral after one of the
servers fails or is removed from the namespace. DFS administrators can specify that clients “failback” to a preferred, local
server when it is restored.Thetarget failback policy may beset for theentireroot, or for individual links.
Why is this change important? What threats does it mitigate?
Prior to Windows Server 2003 Service Pack 1, there was no way for administrators to configureclients to fail back to their local
servers; this behavior can be problematic in branch officeenvironments when clients continueto access the hub server even
after the branch server is restored.
What works differently?
Thefailback settings for roots and links can beset using the/TargetFailback option of dfsutil. In addition, the DFS Client
Failback hotfix for Windows XP and Windows Server 2003 must beinstalled to enabletheclient to perform thefailback.
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.
Target Priority
Detailed description
Target priority enables DFS administrators to explicitly assign the priority of a DFS link or root target.
Why is this change important? What threats does it mitigate?
Prior to Windows Server 2003 Service Pack 1,administrators had no way of designating preference between servers that host
thesame data in a namespace.To work around this,administrators created special subnets for such servers and artificial sites
in Active Directory with high link cost.This workaround is timeconsuming,complex,and leads to increased support costs.
DFS management APIs have been added to configure whether a server appears first or last in a referral, which is thelist of
servers returned to theclient for a given folder (link) in the namespace. Assigning target priority is useful in many scenarios,
such as “hot-standby” scenarios where oneserver is considered theserver of last resort. In this scenario, theadministrator
specifies that thestandby server always appears last in referrals,and clients will fail over to this server only if all the other
servers fail or become unavailable dueto network outages.
What works differently?
Targets in a DFS referral responseare grouped into sets based on thecost of accessing targets from a client.Within each set,
targets areshuffled randomly and thesesets are ordered by increasing cost from the DFS client. Prior to Windows Server 2003
SP1, the number of sets in thereferral response depended on whether or not Windows Server 2003 sitecosting was enabled.
With sitecosting disabled thereareexactly two sets, oneset containing targets in thesamesiteas the DFS clientand the other
set containing theremaining targets.With sitecosting enabled sets are grouped on the basis of actual sitecost of thetarget
from the DFS client,and hencetherecould be many more of thesesets. Notethat thereis no information in thecurrent DFS
V1, V2, or V3 referral responses thatallows a DFS client to identify thesesets.
With server target priority, thesesets will still be based on thecost of accessing targets.Server target priority simply extends
thecost sorting criteria for targets, so thesets are now thosetargets having thesamesitecostand server target priority. In
addition, the new V4 protocol will indicate wheretheset boundaries arein thetarget list.
Server target priority is broken out into two values:a priority class and a priority rank. Priority classes are defined at two levels:
locally, within sets of targets of equal sitecost,and globally.Within each of these, thereis a coarse ordering of high, normal
and low priority targets.This gives us five priority classes in thefollowing order:
Global high
Site-cost high
Site-cost normal
Site-cost low
Global low
Notethat thereis no separate“global normal”. If global high or global low is not specified then thereferral is placed in the
“global normal” set. Priority rank is evaluated by a simpleinteger ranking – 0, 1, 2,and so forth.
In ordering a referral, thecomplete process now works as follows:
Thesets of global high and global low targets areidentified,along with theremaining “global normal” targets.
Thesethreesets are placed in order – global high, normal and low.
If set, INSITE is applied to the“normal” setand targets outsidetheclient’s siteareremoved. It is notapplied to global
high and global low.
Within each of thesethreesets, thetargets are ordered by thesitecost mechanism (either local site or by full site
costing), producing sets of targets of equal sitecost
Within thesets of “global normal” targets of equal sitecost, targets are ordered by priority class – sitecost high, normal
and low.
Within thesets of targets of equal sitecostand priority class, targets are now ordered by priority rank (0 being the
highest).
Within thesets of targets of equal sitecost, priority class,and priority rank, targets arerandomly shuffled for load
balancing.
The/targetpriority option of dfsutil can be used to set the priority options listed above.
What existing functionality is changing in Windows Server 2003 Service Pack 1?
Better Delegation
Detailed description
As of Windows Server 2003 Service Pack 1,administrators may delegatetheability to manage domain DFS roots by setting
rights to the DFS object in Active Directory. Administrators may also delegatetheability to managestand alone DFS roots by
setting rights to the DFS object in theregistry.This is in addition to theexisting delegation model of adding DFS administrators
to thelocal Administrators group on every server that hosts the namespace.
Why is this change important?
In the previous versions of Windows Server 2003,administrators who want to delegatetheability to managea namespace
must makethe user a member of thelocal Administrators group on every server that hosts the namespace.This requirement
can lead to an inconsistent managementexperienceif the group memberships are notassigned correctly,and italso allows the
user full access to thelocal filesystem of each namespaceserver.
What works differently?
Thefollowing procedures have been updated as a result of this changein functionality:
To grant a user permission to administer only a domain DFS namespace:
1. In the Active Directory Users and Computers MMC snap-in, on the View menu,click Advanced Features.
2. In theconsoletree, double-click the System folder to expand it.
3. Click the DFS-Configuration folder.
Any existing root objects appear in the details pane.
4. Right-click theroot object thatyou want to allow the user to administer,and then click Properties.
5. On the Security tab,click Add.
6. Typethe name of the user,and then click OK.
7. Verify that the user is granted theFull Control permission,and then click OK.
Note
The user’s rights as defined by theaccess control listapplied to the DFS object in Active Directory areevaluated at the
individual root targets. Because of this, rights granted to well known users and groups areignored dueto potential
differences between the membership of the well known groups in Active Directory and ateach root target.For example,
granting Power Users full control over the DFS root object in Active Directory will notenable Power Users on theindividual
root targets to managethecorresponding DFS root. Additionally, if a well known user or group is granted rights to a root
target but is denied access to the DFS root object in Active Directory, that denial will beignored by the DFS root targets.
To grant a user permission to administer a standalone DFS namespace
1. Using regedit, locatethefollowing key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Standalone
2. Right-click theroot objectyou want to allow the user to administer,and then click Permissions…
3. On the Security tab,click Add.
4. Typethe name of the user,and then click OK.
5. Verify that the user is granted theFull Control permission,and then click OK.
Referral Time to Live Values Are Not Renewed for DFS Clients
Detailed description:
For DFS clients thatare not running Windows XP with SP2 or Windows Server 2003 with SP1, theTimeto Livefor a referral
determines theearliest timethata client will requesta new referral, but only if theexisting referral expires beforeit is accessed
again. Clients that usea cached referral will renew theTimeto Live of thereferral and thus usethereferral indefinitely until the
client’s referral cacheis cleared or theclient is restarted.
This behavior has changed for clients running Windows XP with SP2 and Windows Server 2003 with SP1.Specifically, theTime
to Livevalueis not renewed each timea clientaccesses a target using a cached referral. Instead, thereferral expires after the
Timeto Livevaluelapses.
Why is this change important?
This changeallows DFS clients running Windows XP with SP2 or Windows Server 2003 with SP1 to honor theactual Timeto
Livevalue of a referral. One benefit of this changeis that DFS clients running theseservice packs will more quickly react to
changes to links and roots.For example, if thelink targets of a link named Currentarechanged daily, DFS clients without these
service packs would refresh theTimeto Livevalueeach timethey access the Current link,causing them to continueto
referencestalelink targets well beyond theTimeto Livevalueassociated with theinitial referral request.
What works differently?
This change has several effects:
Clients running Windows XP with SP2 or Windows Server 2003 with SP1 will request referrals morefrequently than
other DFS clients, which can cause moderately increased load on the domain-based DFS root servers, stand-aloneroot
servers,and domain controllers.
Becausethey request new referrals morefrequently,clients running Windows XP with SP2 or Windows Server 2003 with
SP1 will discover namespace updates more quickly than other DFS clients.
In terms of DFS failover, this new behavior can causethe DFS client to fail over to a new target if the previously active
target is not in the new referral, such as when the namespaceis changed to removethetarget that theclient had
accessed.
Service Disabled By Default
Detailed description
The DFS serviceis disabled by default in Windows Server 2003 Service Pack 1.
Why is this change important?
Unnecessary services are disabled by default in Windows Server 2003 SP1 to reducetheattack surface of theserver.
What works differently?
Computers thatare new installations of Windows Server 2003 with Service Pack 1 will havethe DFS service disabled by
default.
Upgrading a computer that is running Windows Server 2003 by installing Service Pack 1 will result in the DFS service being
disabled unless theserver is either a domain controller or is already hosting an existing DFS root.
When a server running Windows Server 2003 Service Pack 1 is promoted to domain controller status, the DFS serviceis
enabled.
What settings are added or changed in Windows Server 2003 Service Pack 1?
Setting name Location Previous
default value
Default
value
Possible
values
Server Consolidation
Retry
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet
\Services\Dfs \Parameters\Replicated
N/A 0 0,1
LogServer
Consolidation
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet
\Services\Dfs \Parameters\Replicated
N/A 0 0,1
Sysvol Netlogon
TargetFailback
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet
\Services\Dfs \Parameters
N/A 0 0,1