How DFS Works

9/15/2016
HowDFSWorks:RemoteFileSystems
How DFS Works

Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
In this section
DFS Terminology
DFS Client and Server Compatibility
Characteristics of Namespace Types
DFS Architecture
DFS Physical Structures and Caches
DFS Processes and Interactions
DFS Protocols
DFS Interfaces
Network Ports Used by DFS
Related Information
Distributed File System DFS allows administrators to group shared folders located on different servers by transparently
connecting them to one or more DFS namespaces. A DFS namespace is 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 those
folders appear, and determines the names that the shared folders show in the namespace. When a user views the namespace,
the folders appear to reside on a single, highcapacity hard disk. Users can navigate the namespace without needing to know the
server names or shared folders hosting the data. DFS also provides many other benefits, including fault tolerance and load
sharing capabilities, making it ideal for all types of organizations. For more information about the scenarios in which DFS is
commonly used, see What Is DFS?.
For information about DFS on later versions of Windows Server, see DFS Namespaces and DFS Replication Overview.
These sections provide an indepth view of how DFS works in an optimal environment. An optimal environment for DFS is
defined as follows:
Domain Name System DNS and Active Directory replication are working properly.
Sites and site costs in Active Directory are configured properly.
The domain controller acting as the primary domain controller PDC emulator is working properly.
The Distributed File System DFS service is running on all domain controllers and root servers.
https://technet.microsoft.com/enus/library/cc782417(d=printer,v=ws.10).aspx
1/55
9/15/2016
Client computers are running one of the following operating systems: WindowsNT4.0 with Service Pack6a,
Windows2000 with Service Pack 4 or later, WindowsXP with Service Pack 1 or later, or WindowsServer2003.
Client computers are properly joined to the domain.
No firewalls block remote procedure call RPC ports used by DFS and the DFS root server that hosts DFS. These ports are
described in Network Ports Used by DFS later in this section.
The Bridge all site links option in Active Directory must be enabled. This option is available in the Active Directory Sites
and Services snapin. Turning off Bridge all site links can affect the ability of DFS to refer client computers to target
computers that have the least expensive connection cost. An Intersite Topology Generator that is running
WindowsServer2003 relies on the Bridge all site links option being enabled to generate the intersite cost matrix that
DFS requires for its sitecosting functionality. If you turn off this option, you must create site links between the Active
Directory sites for which you want DFS to calculate accurate site costs. Any sites that are not connected by site links will
have the maximum possible cost. For more information about site link bridging, see Active Directory Replication
Topology Technical Reference.
Windows2000 domain controllers and Windows2000 DFS root servers do not have the restrictanonymous registry entry
set to 2. This registry entry is located at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa. For more
information about this registry entry, see DFS Client and Server Compatibility and How Site Discovery Works later in
this section.
DFS Terminology
Before you review the DFS components and processes, it is helpful to understand DFS terminology. The following sections
provide terms and definitions, an illustration of DFS namespaces, and a brief description of the client and server roles in DFS.
DFS Terms and Definitions

The following terms are used to describe the basic components of DFS.
DFS namespace
A virtual view of shared folders on different servers as provided by DFS. A DFS namespace consists of a root and many links and
targets. The namespace starts with a root that maps to one or more root targets. Below the root are links that map to their own
targets.
DFS link
A component in a DFS path that lies below the root and maps to one or more link targets.
DFS path
Any Universal Naming Convention UNC path that starts with a DFS root.
DFS root
The starting point of the DFS namespace. The root is often used to refer to the namespace as a whole. A root maps to one or
more root targets, each of which corresponds to a shared folder on a separate server. The DFS root must reside on an NTFS
volume. A DFS root has one of the following formats: \\ServerName\RootName or \\DomainName\RootName.
domainbased DFS namespace
A DFS namespace that has configuration information stored in Active Directory. The path to access the root or a link starts with
the host domain name. A domainbased DFS root can have multiple root targets, which offers fault tolerance and load sharing.
2/55
9/15/2016
link referral
A type of referral that contains a list of link targets for a particular link.
link target
The mapping destination of a link. A link target can be any UNC path. For example, a link target could be a shared folder or
another DFS path.
referral
A list of targets, transparent to the user, which a DFS client receives from DFS when the user is accessing a root or a link in the
DFS namespace. The referral information is cached on the DFS client for a time period specified in the DFS configuration.
root referral
A type of referral that contains a list of root targets for a particular root.
root target
A physical server that hosts a DFS namespace. A domainbased DFS root can have multiple root targets, whereas a standalone
DFS root can only have one root target. Root targets are also called root servers.
standalone DFS namespace
A DFS namespace whose configuration information is stored locally in the registry of the root server. The path to access the root
or a link starts with the root server name. A standalone DFS root has only one root target. Standalone roots are not fault
tolerant; when the root target is unavailable, the entire DFS namespace is inaccessible. You can make standalone DFS roots fault
tolerant by creating them on server clusters.
DFS Namespaces Illustrated

The following figure illustrates a physical view of file servers and shared folders in the Contoso.com domain. Without a DFS
namespace in place, users need to know the names of six different file servers, and they need to know which shared folders
reside on each file server.
Example of Physical Servers and Shared Folders in Contoso.com
When the IT group in Contoso.com implements DFS, they must first decide the type of namespace to implement.
WindowsServer2003 offers two types of namespaces: standalone and domainbased. The IT group also chooses a root name,
which is similar to the shared folder name in a Universal Naming Convention UNC path \\ServerName\SharedFolderName.
The following figure 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: standalone roots, which begin with a server name, and domainbased roots, which begin with a domain name. Valid
formats for domain names include \\NetBIOSDomainName\RootName and \\DNSDomainName\RootName.
Examples of DFS Namespaces
3/55
9/15/2016
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 domainbased root can have multiple root servers to provide redundancy and high availability, whereas a standalone root can
only have one root server. Standalone roots created on server clusters provide high availability. Root servers are transparent to
users, who see only a single folder, whereas administrators can view the physical root servers by using the Distributed File
System snapin, the Dfscmd.exe commandline tool, or the Dfsutil.exe commandline tool available as part of the Windows
Support Tools. The following figure illustrates roots and root servers.
Roots and Root Servers
Below the root, administrators can create multiple links. For example, if an administrator creates a link named Templates, users
browsing the domainbased namespace shown above would see the path \\Contoso.com\Public\Templates. If an administrator
wants to create a deeper hierarchy in the namespace, the administrator can use subfolder names in the link name, such as
Templates\Presentations or Templates\Specs. Users who browse the namespace would see \\Contoso.com\Public\Templates. If
the user opens the Templates folder, the user would see two subfolders: Presentations and Specs.
Each link can correspond to one or more link targets. A link target can be any UNC path. For example, a link target could be a
shared folder such as \\NOAMFS3\Users, a folder underneath a shared folder, or a path to another DFS namespace such as
\\Contoso.com\Public\Users. Link targets are transparent to users but are visible to administrators by using the DFS tools.
Overview of Client and Server Roles in DFS

In addition to understanding the namespace components roots, root targets, links, and link targets, it is also helpful to
understand the client and server roles involved in DFS. The following sections summarize client and server roles in DFS. These
roles are described in more detail later in this document.
DFS clients
DFS clients are the computers used to access namespaces. DFS clients are typically enduser computers; computers running
Windowsbased server operating systems can also access namespaces. DFS clients in this section are assumed to run one of the
operating systems described in DFS Client and Server Compatibility later in this section.
Domain controllers
4/55
9/15/2016
Domain controllers play numerous roles in DFS:

DFS clients access domain controllers to get a list of trusted domains and domain controllers for those domains.
When a DFS client first attempts to access a domainbased namespace, a domain controller provides a list of root servers
to the client. This list of root servers is known as a root referral.
Domain controllers store DFS metadata in Active Directory about domainbased namespaces. DFS metadata consists of
information about entire namespace, including the root, root targets, links, link targets, and settings. By default, root
servers that host domainbased namespaces periodically poll the domain controller acting as the primary domain
controller PDC emulator master to obtain an updated version of the DFS metadata and store this metadata in memory.
Whenever an administrator makes a change to a domainbased namespace, the change is made on the domain controller
acting as the PDC emulator master and is then replicated via Active Directory replication to other domain controllers in
the domain.
Domain controllers acting as the Intersite Topology Generator generate site cost information. This information describes
the relative cost of the connection between two sites. DFS uses this information to sort targets in order of lowest cost in
referrals when leastexpensive target selection is enabled.
Root servers
Root servers also called root targets are the servers on which administrators create standalone and domainbased
namespaces. A root server can be a member server or a domain controller. Root servers play the following roles in DFS:
For standalone namespaces, the DFS metadata is stored in the registry of the root server. For domainbased namespaces,
DFS metadata is stored in Active Directory. Root servers also keep the DFS metadata for each namespace in a memory
cache.
Root servers host shared folders that act as the root known as the root folder and subfolders under the root folders
that correspond to every link known as link folders in those namespaces.
When a client attempts to access a root or link in a standalone namespace, or a link in a domainbased namespace, the
root server provides a referral to the client.
Link targets
Link targets are typically shared folders or folders within shared folders. Link targets can be served by any network file system
that is accessible by a UNC path, such as Server Message Block SMB, NetWare Core Protocol NCP for NetWare, or Network
File System NFS for UNIX. The client computers must have the appropriate redirector installed to access link targets. The UNC
path can lead to shared folders in any workgroup, shared folders within the same domain as the namespace, shared folders in
trusted domains, and shared folders in trusted forests.
Shared folders that are specified as link targets have no special settings that indicate that they are part of a DFS namespace. All
existing shared folder permissions and NTFS permissions on the shared folder still apply when users access the shared folder
through the namespace.
A link target can also be a DFS path in another namespace. For example, the Software link in \\Contoso.com\Public\Software
might have a link target of \\Software\Public, which is a root within a standalone namespace. When using DFS paths as link
targets, it is important to ensure that client failover works correctly. For more information, see Linking to Different DFS
Namespaces later in this section.
DFS Client and Server Compatibility

5/55
9/15/2016
The following table describes the types of clients and servers that can act as DFS clients, root servers, and link targets.
DFS Compatibility
Platform
Act As DFS Clients?
Act As a Root Server?
Act As a Link
Target?
Microsoft
WindowsServer2003,
WebEdition
Yes
Yes
Yes
WindowsServer2003,
Standard Edition
Yes
WindowsServer2003,
Enterprise Edition, and
WindowsServer2003,
Datacenter Edition
Yes
Windows Storage
Server2003
Yes
WindowsXP
Yes
No
Yes
Windows Preinstallation
Environment WinPE
Yes
No
No
Windows2000 Server
family
Yes
Yes
Yes
Windows2000
Professional
Yes
No
Yes
Yes
Yes
Yes
Can host one standalone

namespace or one domain
based namespace per server.
Yes
Yes

namespace or one domain
based namespace per server.
Yes
Yes
Can host multiple stand

alone namespaces and
multiple domainbased
namespaces per server.
Yes
Yes
Can host multiple stand

alone namespaces and
multiple domainbased
namespaces per server.
Can access standalone namespaces but

cannot access domainbased namespaces.

namespace or domainbased
namespace per server.
6/55
9/15/2016
WindowsNT Server4.0
with Service Pack6a
Can host a single stand

alone namespace per server.
WindowsNT
Workstation4.0 with
Service Pack6a
Yes
No
Yes
Windows98
Yes
No
Yes
Client for standalone DFSincluded; install the

Active Directory client extension for
Windows95 or Windows98 to access domain
based DFS namespaces.
When evaluating client compatibility, review the following important considerations:
Client computers must be members of a local or trusted domain before they can access a domainbased namespace by
using the format \\NetbiosDomainName\RootName. If clients are members of a workgroup or an untrusted domain and
can resolve DNS names, they can access domainbased namespaces by using the format \\DNSDomainName\RootName.
For information about how clients determine the list of trusted domains, see DFS Physical Structures and Caches on DFS
Clients.
Link targets can be shared folders served by other protocols, such as NetWare Core Protocol NCP for NetWare and
Network File System NFS for UNIX, but client computers must have the appropriate redirector installed to access those
link targets.
In organizations that have a large number of domains and forest trusts, clients might have difficulty accessing link targets
in other domains or forests. For more information, see DFSRelated Processes on Clients later in this section.
If a Windows2000 Server root server has the restrictanonymous registry entry set to 2, and the root server is not a
domain controller, then DFS clients in a workgroup cannot access DFS namespaces that are hosted on the root server.
This registry entry is located at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa.
Caution
Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should
back up any valued data on the computer.

The following table provides a general overview of the differences between domainbased and standalone namespaces.
Characteristic
Domainbased
StandAlone
Path to
namespace
\\NetbiosDomainName\RootName
\\ServerName\RootName
7/55
9/15/2016
\\DNSDomainName\RootName
Where DFS
metadata is
stored
In Active Directory. Also stored in a memory cache on the

root server.
In the registry of the root server. Also stored

in a memory cache on the root server.
Group
memberships
required to
create or delete
namespaces
DFS administrators must be members of the Domain

Admins group to create or delete domainbased
namespaces or have delegated permissions to the DFS
Container object in Active Directory.
DFS administrators must be members of the

local Administrators group on the local
server to create or delete standalone
namespaces.
Group
memberships
required to
administer
namespaces
DFS administrators must be members of the local

Administrators group on each of the root servers to add
or delete links, link targets, roots, and root targets.*
DFS administrators must be members of the

local Administrators group on the local
server to add or delete links, link targets,
roots, and root targets.
DFS namespace
size restrictions
We recommend that you keep the size of the DFS object

in Active Directory below 5megabytes MB by using
fewer than 5,000 links in domainbased namespaces.
The largest recommended namespace size

for a standalone namespace is 50,000 links.
Supported
methods to
ensure DFS root
availability
Create multiple root targets in the same domain.
Create a standalone root on a server

cluster.
Supported
methods to
ensure link
target
availability
Create multiple link targets and replicate files by using

one of the following methods:
Create multiple link targets and replicate

files by using one of the following methods:
Enabling FRS
Copying files manually or by using scripts
Using another replication tool
Copying files manually or by using

scripts
Using another replication tool
*To ensure that the administrator can reliably administer the namespace, we recommend that the administrator be a member of
the local Administrators group on each root server. If a DFS administration tool sends a request to a root server on which the
administrator is not a member of the local Administrators group, the request will fail. If the administrator is a member of the
local Administrators group on some but not all root servers, the administrators ability to administer the namespace will be
inconsistent.
DFS Architecture
The DFS service Dfssvc.exe is the core component of the DFS architecture and runs on root servers and domain controllers. The
primary functions of the DFS service include handling referrals, managing namespaces, and communicating with the DFS driver
Dfs.sys.
The components of the DFS architecture on DFS clients and root servers are illustrated in the following figure. In this figure, the
DFS architecture of the domain controller is simplified to show only the DFS object.
8/55
9/15/2016
DFS Client and Root Server Architecture
The following figure illustrates the DFS architecture of a domain controller and a simplified view of the DFS client and root server
architecture. Note that domain controllers use DFS architecture similar to root servers; this is because domain controllers play a
role in referring client computers to domainbased roots. It is also possible for domain controllers to host namespaces and play
the role of root server. In this case, the domain controller also hosts the DFS metadata cache regardless of namespace type and
the standalone DFS metadata in its registry for standalone namespaces.
DFSRelated Architecture on Domain Controllers
9/55
9/15/2016
The following tables describe the components of the DFS architecture.

Components of DFS Tools Described in the Figure Titled DFS Client and Root Server Architecture
Component
Description
Dfsshlex.dll
Displays the DFS tab when you use a DFS client to view the properties of a folder in a DFS namespace using
Windows Explorer.
Distributed
File System
snapin
Dfsgui.msc
and Dfsui.dll
The graphical user interface tool used for administering DFS namespaces. By default, the Distributed File
System snapin Dfsgui.msc is installed on servers running WindowsServer2003. You can administer
namespaces remotely from a computer running WindowsXP with Service Pack1 by installing the
WindowsServer2003 Administration Tools Pack, which the includes Distributed File System snapin.
Distributed
File System
command
line utility
Dfscmd.exe
The DFS commandline tool used to perform basic DFS tasks, such as configuring DFS roots, links, and
targets. Also supports scripting. Dfscmd.exe is available on all servers running a member of the
WindowsServer2003 family.
Distributed
File System
The DFS commandline tool used to perform basic and advanced DFS tasks, such as enabling root scalability
mode, least expensive target selection, and samesite target selection. When installed on DFS clients,
10/55
9/15/2016
utility
Dfsutil.exe
Dfsutil.exe can be used to view and clear the referral cache PKT cache, domain cache SPC cache, and MUP
cache. Also supports scripting. Dfsutil.exe is included with the Windows Support Tools and is available on the
Microsoft Download Center Web site.
Netapi32.dll
Contains the NetDFSxxx APIs that are used to administer remote root servers. Also contains the APIs that are
used to view and clear the referral cache PKT cache, domain cache SPC cache, and MUP cache on clients.
Components of DFS Client Architecture Described in the Figure Titled DFS Client and Root Server Architecture
Component
Description
Domain
cache
Contains the domain name referrals and domain controller referrals that are stored in memory on each client
computer. The domain cache stores NetBIOS and DNS domain names for the local domain, all trusted
domains in the forest, domains in trusted forests, and the mappings of the domain names to the domain
controllers. The domain cache also called SPC cache is maintained in Mup.sys.
I/O Manager
Plays a role in handling the file I/O in redirecting the UNC paths to Mup.sys. I/O Manager is part of the core
kernel Ntoskrnl.exe of the operating system.
Mrxsmb.sys
Handles communications to the root servers, domain controllers, and Windowsbased file servers that use
the CIFS protocol.
Mup.sys
Implements DFS client support and redirector selection. "Mup" stands for multiple UNC provider.
Mup.sys is a networking component that handles input/output I/O requests for a file or device that has a
UNC name that is, a name that begins with \\. If the UNC name is a DFS path, Mup.sys resolves it to the
physical UNC path. After the path is resolved, or if the path was not a DFS path, Mup.sys determines the local
redirector that handles the UNC path.
Ntlanman.dll
Handles the establishment of drive letter and unnamed connections for DFS and SMB paths.
Nwrdr.sys
and
Mrxdav.sys
The redirectors for Netware and Web Distributed Authoring and Versioning WebDAV, respectively.
Referral
cache
Stores the root referrals and link referrals received by the client when it accesses a namespace. The referral
cache also known as the PKT cache is maintained in Mup.sys.
Workstation
service
Wkssvc.dll
Sends domain controller information and domain names to Mup.sys. Mup.sys uses this information to
generate the referrals in the clients domain cache. This service is also a component of the Server Message
Block SMB client. Also manages the loading and unloading of the Mrxsmb.sys.
Components of the DFS Root Server and Domain Controller Architecture Described in the Figure DFSRelated
Architecture on Domain Controllers
11/55
9/15/2016
Component
Description
Dfs.sys
The DFS driver. Dfs.sys runs only on Windowsbased server operating systems and reflects referral
requests from DFS clients to the DFS service running in user mode. Dfs.sys also handles the processing of
links when they are encountered during file system access.
DFS metadata
cache
The inmemory copy of DFS metadata maintained in Dfssvc.exe on root servers. DFS metadata consists of
information about entire namespace, including the root, root targets, links, link targets, and settings.
Dfssvc.exe
The DFS service. Provides serverside support for NetDFSxxx APIs that configures and maintains DFS
namespaces. The DFS service is also responsible for maintaining an uptodate version of the DFS
metadata and for giving referrals to clients who attempt to access the namespace.
Domainbased
root referral
cache and site
caches
The inmemory copies of domainbased root referrals and site information that enable Dfssvc.exe to
perform fast lookups. These caches are described in the next section.
Registry
Where the DFS metadata is stored for standalone DFS namespaces.
Srv.sys
The SMB Service server driver. Plays a role in DFS by passing on referral requests from DFS clients to
Dfs.sys.
Active Directory
Where the DFS object is stored. The DFS object stores the DFS metadata for a domainbased namespace.

The following figure illustrates the physical structures and caches on domain controllers, root servers, and DFS clients. These
physical structures and caches are described in the sections that follow.
12/55
9/15/2016
DFS Physical Structures and Caches on Domain Controllers

Domain controllers play an important role for domainbased namespaces. They store the DFS metadata for domainbased
namespaces, and they provide referrals to DFS clients to help them access domainbased namespaces. There are a number of
physical structures and caches that support these processes; these structures and caches are illustrated in the following figure.
Physical Structures and Caches on Domain Controllers
13/55
9/15/2016
The following sections describe each of the physical structures and caches on domain controllers. Domain controllers can also
host roots; in this case, the domain controller also contains the physical structures and caches described in DFS Physical
Structures and Caches on Root Servers later in this section.
DFS Object in Active Directory

The DFS object stores the DFS metadata for a domainbased namespace. The DFS object is created in Active Directory when you
create a domainbased root, and Active Directory replicates the entire DFS object to all domain controllers in a domain. When a
client requests a referral for a domainbased namespace, the domain controller first checks its domainbased root referral cache
described later in this section for an existing referral. If none exists, the domain controller locates the DFS object for that
namespace and uses the metadata in the object to create the referral.
The following figure illustrates the location of the DFS objects in Active Directory. Each DFS object class fTDfs corresponds to a
domainbased namespace.
Hierarchy of DFS Objects in Active Directory
Each DFS object has the following four important attributes:

pKT. A binary representation of the DFS metadata for this root.
pKTGuid. The globally unique identifier GUID of the DFS metadata.
14/55
9/15/2016
remoteServerName. Lists the root targets for the root.

Security descriptor. Controls who can modify the DFS object. The security descriptor on the DFSConfiguration object
controls who can create or delete a DFS object.
It is important to be aware of the size of the DFS object. An entry in the metadata uses approximately 400bytes per DFS link.
This figure does not include any comments that you add to describe the namespace. A midsized DFS namespace with 100 links
requires approximately 40kilobytes KB. Any change to the namespace causes the entire DFS object to be replicated to all
domain controllers in the domain. We recommend that the DFS object for a domainbased namespace be less than 5megabytes
MB which is equivalent to approximately 5,000 links to reduce the impact of network traffic originating from changes to the
namespace.
For more information about how domainbased root servers discover changes to the DFS object in Active Directory, see How
DFS Discovers Changes to the Namespace later in this section.
DFS Registry Entries

DFS supports several registry entries for configuring DFS behavior on domain controllers. DFS registry entries are located in the
registry under the following subkeys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
For a list of DFS registry entries, see DFS Tools and Settings.
Domain Name Referral Cache

A domain name referral contains the NetBIOS and DNS names of the local domain, all trusted domains in the forest, and
domains in trusted forests. A DFS client requests a domain name referral from a domain controller to determine the domains in
which the clients can access domainbased namespaces.
By default, domain controllers store domain name referrals in a memory cache for 12hours; this period is defined by the
DomainNameIntervalinSeconds registry entry on the domain controller. Restarting the DFS service on the domain controller
will cause this cache to be cleared. If a domain name changes, or if domains are added or removed from the forest or trusted
forests, these changes are reflected in domain name referrals after 12hours or after this cache is cleared.
Domain Controller Referral Cache

A domain controller referral contains the NetBIOS and DNS names of the domain controllers for the list of domains it has
cached. A DFS client requests a domain controller referral from a domain controller in the clients domain to determine which
domain controllers can provide a referral for a domainbased namespace.
Domain controllers store these domain controller referrals in a memory cache for 10minutes; you cannot change this setting.
Restarting the DFS service on the domain controller will cause this cache to be cleared. If a domain controller name changes, or if
domain controllers are promoted or demoted from the domain, these changes are reflected in domain controller referrals after
10minutes or after this cache is cleared.
Domainbased Root Referral Cache

A domainbased root referral contains a list of root targets that host a given domainbased namespace. Domain controllers
provide domainbased root referrals to clients that attempt to access a domainbased namespace.
By default, domain controllers store domainbased root referrals in a memory cache for 15minutes; this period is defined by the
RootReferralTimeoutInSeconds registry entry on the domain controller. Restarting the DFS service on the domain controller
will cause this cache to be cleared. If root targets are added or removed, or if settings are changed on the root, these changes
are reflected in domainbased root referrals after 15minutes or after this cache is cleared.
15/55
9/15/2016
Note
The domainbased root referrals in this memory cache do not store targets in any particular order. The targets are sorted
according to the target selection method only when requested from the client. Also, these referrals are based on DFS
metadata stored on the local domain controller, not the PDC emulator master.
Client Site Cache

When a client requests a referral from a domain controller, the DFS service on the domain controller uses the site information
defined in Active Directory through the DSAddressToSiteNames API to determine the site of the client, based on the clients IP
address. DFS stores this information in the client site cache, which contains mappings of client IP addresses to site names. DFS
uses this cache to quickly determine the site that a client belongs to.
By default, domain controllers keep entries in the client site cache for up to 24hours. This period is defined by the
SiteSupportIntervalInSeconds registry entry 12hours on the domain controller, multiplied by two. If a site name changes, or
if a client moves from one site to another and uses the same IP address, the site information in this cache will be outofdate for
a maximum of twice the value of the SiteSupportIntervalInSeconds registry entry 24hours or until the DFS service is restarted
on the domain controller.
When a cleanup process begins after the configured time interval, entries are handled as follows:
If a site name that corresponds to a client was accessed since the last cleanup process, the entry is refreshed.
If a site name that corresponds to a client has not been accessed since the last cleanup process, the entry is purged.
By default, DFS can store 200,000 entries in the client site cache. This limit is determined by the MaxClientsToCache registry
entry.
Target Site Cache

The DFS service on domain controllers uses the site information defined in Active Directory through the DSAddressToSiteNames
API to determine the site for domainbased root targets and domain controllers based on their current IP addresses. DFS stores
this information in its target site cache, which contains mappings of root server names and domain controller names to site
names. DFS uses this information to quickly determine the site that a root server or domain controller belongs to.
By default, domain controllers keep entries in the target site cache for up to 24hours. This interval is defined by the
SiteSupportIntervalInSeconds registry entry value 12hours on the domain controller, multiplied by two. After the configured
time interval, DFS refreshes the site information in this cache. If a site name changes or a root target moves from one site to
another, the site information in this cache will be outofdate for a maximum of twice the value of the
SiteSupportIntervalInSeconds registry entry 24hours or until the DFS service is restarted on the domain controller.
Site Cost Cache

The site cost cache on domain controllers contains a mapping of sites to their associated cost information as defined in Active
Directory. Costs are configured by administrators and are based on the expense of transferring data over the connection. DFS
populates this cache only when least expensive target selection is enabled. DFS uses the site cost cache to quickly determine the
connection cost associated with domain controllers and domainbased root targets so that DFS can sort targets in order of
lowest cost in referrals.
The DFS service obtains site cost information for domain controllers and domainbased root targets as needed to fulfill client
referral requests. By default, entries in the site cost cache are maintained for up to 12hours. This period is defined by the
SiteSupportIntervalInSeconds registry entry value 12hours on the local domain controller. If the connection cost between
two sites is changed in Active Directory, the site cost information in this cache will be outofdate for a maximum of the
SiteSupportIntervalInSeconds registry entry 12hours or until the DFS service is restarted.
16/55
9/15/2016
The QuerySiteCostTimeoutinSeconds registry entry on domain controllers is also used for this cache to specify a timeout
period for site cost queries. After the timeout period, the DsQuerySitesByCost API calls for site cost information in Active
Directory will fail. By default, the timeout period is 30 seconds. If DFS cannot determine a site cost within 30 seconds, DFS
assumes the maximum possible cost for that site.
DFS Physical Structures and Caches on Root Servers

The physical structures and caches on a root server vary according to the type of namespace the root server hosts domain
based or standalone. Servers running Windows2003 Server, Enterprise Edition, and WindowsServer2003, Datacenter Edition,
can host multiple standalone and domainbased roots.
The following figure illustrates the physical structures and caches on root servers.
Physical Structures and Caches on Root Servers
The following sections describe each of the physical structures and caches on root servers.
StandAlone DFS Metadata in the Registry

The standalone DFS metadata contains information about the root, root target, links, link targets, and settings defined for each
standalone namespace. This metadata is maintained in the registry of the root server at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone.
Note
Domainbased root servers have a registry entry for each root under
KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain, but these entries do not contain the domainbased DFS
metadata. When the DFS service starts on a root server, the service checks this path for registry entries that correspond to
domainbased roots. If these entries exist, the root server polls the PDC emulator master to obtain the DFS metadata for
each domainbased namespace and stores the metadata in memory.
Root and Link Folders

Each root and link in a namespace has a physical representation on an NTFS volume on each root server that hosts the
namespace. The DFS root corresponds to a shared folder, known as the root folder, on the root server. When you use the DFS
tools to add links to the root, DFS creates special folders under each root folder. These folders, called link folders, are actually
reparse points, and they display an error message similar to the following message if you try to access them on the local server:
E:\Public\GroupData is not accessible. The network location cannot be reached.
DFS clients that access the link folders from across the network are redirected to the appropriate link target by using the process
described in The Referral Process later in this section.
17/55
9/15/2016
The following figure illustrates volume E:\ on the local storage of a root server. The volume contains root folder and link folders
for the \\Contoso.com\Public namespace.
Link Folders on a Root Server
For more information about how these folders are created, see Root and Link Creation Process later in this section.

DFS supports several registry entries for configuring DFS behavior on root servers. The DFS service registry entries are located in
the registry under the following subkeys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
For a list of these DFS registry entries, see DFS Tools and Settings.
DFS Metadata Cache

The DFS metadata cache on root servers contains information about the root, root targets, links, link targets, and settings
defined in a namespace. For domainbased namespaces, this metadata is also stored in the DFS object in Active Directory. For
standalone namespaces, this metadata is also stored in the root servers registry.
This cache is updated each time the root server polls the DFS object in Active Directory for domainbased namespaces and the
registry for standalone namespaces. For more information, see How DFS Discovers Changes to the Namespace later in this
section.
Domainbased Root Referral Cache

When a client computer contacts a domainbased DFS root server directly by using the syntax \\ServerName\RootName, the root
server provides a domainbased root referral to the client computer. One scenario in which this occurs is when a client attempts
to access a link target that points to a path within another domainbased namespace. For more information, see Linking to
Different DFS Namespaces later in this section.
By default, root servers store these domainbased root referrals in a memory cache for 15minutes; this period is defined by the
RootReferralTimeoutInSeconds registry entry on the root server. Restarting the DFS service on the root server will cause this
cache to be cleared. If root targets are added or removed, or if settings are changed on the root, these changes are reflected in
domainbased root referrals provided by root servers after 15minutes or after the cache is cleared.
Note
The domainbased root referral cache does not store targets in any particular order. The targets are sorted according to
the target selection method only when requested from the client. Also, these referrals are based on DFS metadata stored
on the local domain controller, not the PDC emulator master.
Client Site Cache

When a client requests a referral from a root server, the DFS service on the root server uses the site information defined in Active
Directory via the DSAddressToSiteNames API to determine the site of the client, based on the clients IP address. DFS stores this
18/55
9/15/2016
information in the root servers client site cache, which contains mappings of client IP addresses to site names. DFS uses this
cache to quickly determine the site that a client belongs to.
By default, root servers keep entries in the client site cache for up to 24hours. This period is defined by the
SiteSupportIntervalInSeconds registry entry 12hours on the root server, multiplied by two. If a site name changes, or if a
client moves from one site to another and uses the same IP address, the site information in this cache will be outofdate for a
maximum of twice the value of the SiteSupportIntervalInSeconds registry entry 24hours or until the DFS service is restarted
on the root server.
When a cleanup process begins after the configured time interval, entries are handled as follows:
If a site name that corresponds to a client was accessed since the last cleanup process, the entry is refreshed.
If a site name that corresponds to a client has not been accessed since the last cleanup process, the entry is purged.
By default, DFS can store 200,000 entries in the client site cache. This limit is determined by the MaxClientsToCache registry
entry.
Target Site Cache

When the DFS service starts on a root server, it uses the site information defined in Active Directory through the
DSAddressToSiteNames API to determine the site for all link targets, based on the current IP address of each link target. The DFS
service also obtains site information when new link targets are added. DFS caches this information in the root servers target site
cache. The target site cache contains mappings of link target server names to site names. DFS uses this information to quickly
determine the site that a link target belongs to.
By default, root servers keep entries in the target site cache for up to 24hours. This interval is defined by the
SiteSupportIntervalInSeconds registry entry value 12hours on the root server, multiplied by two. After the configured time
interval, DFS refreshes the site information in this cache. If a site name changes or a link target server moves from one site to
another, the site information in this cache will be outofdate for a maximum of twice the value of the
Site Cost Cache

The site cost cache on root servers contains a mapping of sites to their associated cost information, as defined in Active
Directory. Costs are based on the expense of transferring data over the connection. DFS populates this cache only when least
expensive target selection is enabled. DFS uses the site cost cache to quickly determine the connection cost associated with link
targets, so that DFS can sort link targets in referrals in order of lowest cost.
The DFS service obtains site cost information for link targets through the DsQuerySitesByCost API as needed to fulfill client
referral requests. By default, root servers keep entries in the site cost cache for up to 12hours. This period is defined by the
SiteSupportIntervalInSeconds registry entry value 12hours on the root server. If the connection cost between two sites is
changed in Active Directory, the site cost information in this cache will be outofdate for a maximum of the
The QuerySiteCostTimeoutinSeconds registry entry on root servers is also used for this cache to specify a timeout period for
site cost queries. After the timeout period, the DsQuerySitesByCost API calls for site cost information in Active Directory will fail.
By default, the timeout period is 30 seconds. If DFS cannot determine a targets site cost within 30 seconds, DFS assumes the
maximum possible cost for the target server.
DFS Physical Structures and Caches on DFS Clients

DFS clients running WindowsXP and Windows2000 store referrals from domain controllers and root servers to improve
performance. A client can use the referrals in its cache when reaccessing a target in the namespace, rather than recontacting
domain controllers and root servers for referrals. DFS clients also have registry entries used for customizing DFS behavior on the
client.
19/55
9/15/2016
The following figure illustrates the physical structures and caches on DFS clients.
Caches on DFS Clients
These physical structures and caches are described in the sections that follow. For information about how clients update their
caches, see DFSRelated Processes on Clients later in this section.

DFS registry entries are located in the DFS clients registry under the following subkeys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\System\DFSClient\.
For a list of DFS registry entries, see DFS Tools and Settings.
Domain Cache on Clients

The domain cache on clients contains two types of referrals:
Domain name referrals, which are the NetBIOS and DNS domain names for the clients local domain, trusted domains in
the forest, and domains in trusted forests.
Domain controller referrals, which are the mappings of the domain names to the domain controllers that host those
domains.
You can view the domain cache on a client computer by using the Dfsutil.exe commandline tool with the /spcinfo parameter.
The following text illustrates the output displayed when you use this command.
[*][dc01.contoso.com]
[*][CONTOSO]
[*][contoso.com]
[+][contoso.com]
[dc02.contoso.com]
[+dc01.contoso.com]
[dc04.contoso.com]
[dc03.contoso.com]
[][AFRICA]
[][EUROPE]
[+][CONTOSO]
[DC02]
[+DC01]
20/55
9/15/2016
[DC03]
[DC04]
[][europe.contoso.com]
[][africa.contoso.com]
The preceding sample output can be interpreted as follows:

Entries preceded by [*] are provided by the Workstation service.
The [+] next to the domain controller named DC01 under [contoso.com] and [CONTOSO] indicates that it is the active
domain controller for that domain. The client will contact this domain controller as needed to obtain domain name
referrals, domain controller referrals, and domainbased root referrals.
The client has already contacted DC01 to receive domain name referrals for Contoso.com, Europe.Contoso.com, and
Africa.Contoso.com.
The client has already contacted DC01 to receive domain controller referrals for the Contoso.com domain.
For information about how clients update their domain caches, see DFSRelated Processes on Clients later in this section.
MUP Cache
The multiple UNC provider MUP cache stores information about which redirector, such as DFS, SMB, or WebDAV, is required for
each UNC path that a client computer attempts to access. Entries in the MUP cache are held for 15minutes. You can use
Dfsutil.exes /PurgeMupCache parameter to clear the MUP cache. This might be necessary when a folder is changed from an
SMB shared folder to a WebDAV or DFS root folder or vice versa.
For information about how clients update their MUP caches, see DFSRelated Processes on Clients later in this section.
Referral Cache on Clients

DFS clients store root referrals and link referrals in the referral cache also called the PKT cache. These referrals allow clients to
access the root and links within a namespace. You can view the contents of the referral cache by using Dfsutil.exe with the
/pktinfo parameter on a DFS client. The following figure illustrates the output displayed when you use this command on a
WindowsXP client computer.
Sample Referral Cache Output
21/55
9/15/2016
The previous figure shows four types of referrals: 1NETLOGON and SYSVOL referrals, 2domainbased root referrals, 3stand
alone root referrals, and 4link referrals. Each of these referrals contains the following information:
Entry and ShortEntry

Entry specifies the full name of the path. ShortEntry specifies the short name eight characters followed by a period and a three
more characters of the path. Root servers and domain controllers running WindowsServer2003 use the full name when
populating Entry and ShortEntry.
Expires in seconds
Specifies the Time to Live of the referral. Zero 0 seconds indicates that the referral has expired and that the client will obtain a
new referral the next time the client tries to access the target server.
UseCount and Type

UseCount is the number of open connections and files for this path. If a client has a mapped drive to a DFS path, its use count
goes up by 1. On clients running Windows2000, WindowsXP, and WindowsServer2003, you cannot clear a referral until its use
count is 0.
Type indicates the type of referral. Some common types include:
Type 0x81 REFERRAL_SVC DFS . Indicates a root referral.
Type 0x1 DFS . Indicates a link referral that has physical shared folders as link targets.
22/55
9/15/2016
Type 0x10 OUTSIDE_MY_DOM. Indicates a link referral whose link target is a path in a domainbased namespace.
Target list
The target list contains the root targets or link targets that correspond to the path specified in Entry. Targets are listed in order,
according to the target selection method configured for the root or link. A target marked Active indicates that the client either
has used this target or will use this target the next time the user tries to access this portion of the namespace.
DFS Processes and Interactions

DFS is a complex service that involves many processes and interactions between clients, root servers, and domain controllers. The
major categories of the processes and interactions, along with the names of the relevant sections, are described as follows.
Processes Related to Referrals

The referral process is the process by which domain controllers and root servers refer clients to different targets in the
namespace. Numerous processes take place so that DFS can provide an optimal list of targets in the referral. These processes are
described in the following sections:
See How Site Discovery Works for information about how DFS determines the sites to which clients and targets belong.
See How Target Selection Works for information about the logic that DFS uses to sort targets in a referral. There are
three target selection methods: default target selection, samesite target selection, and least expensive target selection.
See How DFS Works in Environments Without WINS for information about how DFS can use either NetBIOS names or
DNS names of targets in referrals.
See The Referral Process for the actual steps involved in the referral process.
See How DFS Is Used During the Logon Process for information about the two special types of referrals, SYSVOL and
NETLOGON referrals, which are used when a client first logs on to the domain.
See Linking to Different DFS Namespaces for information about how link targets can point to other namespaces instead
of physical shared folders and the referral process involved when a client navigates from one DFS namespace to another.
See What Happens During Failover for information about how clients react when a target in a referral is not available
and how clients react when they have a session enabled with a target and the target server fails.
Creating and Changing Namespaces

These following sections describe what happens when you create or change a namespace.
See Root Folder and Link Folder Creation Process for information about how DFSrelated folders are created on root
servers.
See How DFS Discovers Changes to the Namespace for information about what happens when a namespace changes.
This section also provides information about where DFS data is stored so that you can determine how long it takes before
clients can see an updated view of the namespace.
See How Root Scalability Mode Works for information about a special mode in which domainbased root servers
discover namespace changes by contacting the closest domain controller.
What Happens During DFS Operations

See the section What Happens When You Check Target Status for information about how DFS works when you check target
status by using the Distributed File System snapin.
23/55
9/15/2016
DFS Interoperability
See the sections How DFS Works on Server Clusters and How DFS Works with Offline Files for information about how DFS
operates on server clusters and the Offline Files feature.
Client Processes
See the section DFSRelated Processes on Clients for information about the processes that DFS clients perform to update their
domain caches, MUP caches, and referral caches. Entries in these caches are used during the referral process.
How Site Discovery Works

Site discovery, also called site awareness, is the process that DFS uses to determine which site a root target, link target, or client
belongs to. A site is one or more TCP/IP subnets as defined in Active Directory. DFS uses this site information to determine the
order in which to sort the targets in a referral.
DFS determines the site of targets and clients as follows:
When the DFS service starts, DFS determines the site of each target by converting the targets name to an IP address
using the GetHostbyName API and then querying Active Directory using the DSAddressToSiteNames API to convert the
IP address to a site name based on the subnettosite mappings as defined in Active Directory.
When a client attempts to access the DFS namespace, DFS determines the site of a client by querying Active Directory
using the DSAddressToSiteNames API to convert the clients IP address to a site name based on the subnettosite
mappings as defined in Active Directory.
Site discovery in WindowsServer2003 works regardless of the operating system that the target server is running. For example, if
a link target is running WindowsNT4.0 or a nonWindows operating system, DFS can determine the targets site using its IP
address. For server clusters and multihomed clients and targets, site discovery works as follows:
If a target is part of a virtual server in a server cluster, DFS uses the virtual servers IP address to determine the targets
site.
When a target server is multihomed that is, the server has multiple IP addresses, the root server or domain controller
determines the targets site by using the GetHostbyName API, and the first IP address returned is what is used to
determine the site.
When a multihomed client requests a referral, the root server or domain controller uses the source IP address from the
clients network request, which could be arbitrary based on the clients network configuration. Or, if a client request goes
through a NAT gateway, the root server or domain controller uses the source IP address of the request as rewritten by the
NAT gateway.
After root servers and domain controllers obtain site information about client computers and target servers, they store the
information in the following memory caches:
Target site cache. The target site cache contains mappings of target server names to site names.
Client site cache. The client site cache contains mappings of client IP addresses to site names.
Site information remains in the client site cache and the target site cache for up to two times the duration specified in the
SiteSupportIntervalInSeconds registry entry set to 12hours, by default. Because site information is cached and not
immediately updated after it changes, it is important to understand how outofdate cached site information affects site
discovery for target servers and client computers.
24/55
9/15/2016
Target site information can become outofdate when a target server is moved from one site to another and the targets
IP address changes so that the target belongs to a subnet that is mapped to a different site in Active Directory. Changing
site names can also cause target site information to become outofdate. Eventually DFS discovers the new site
information when the old site information is updated in the target site cache, which occurs within 24hours, by default.
Until site information is refreshed in the cache, DFS might sort affected targets in referrals based on their old site
information, possibly causing clients to connect to target servers outside of their own site or to targets that are not
closest to the client computer.
Client site information can become outofdate when a client computer moves to another site but keeps the same IP
address, when the clients subnet is moved to a different site, or when the site names change. In these scenarios, DFS
discovers new site information for the client within 24hours, by default. Until site information is refreshed in the cache,
DFS might sort targets in referrals based on the clients old site information, possibly causing the client to contact target
servers outside of its own site or to targets that are not closest to the client.
When reviewing how site discovery works in WindowsServer2003, it is also important to understand how site discovery is
affected when your organization uses a combination of root servers and domain controllers running WindowsServer2003 and
Windows2000 Server. These issues are described in the sections that follow.
Differences in where site information is stored

In Windows2000 Server, DFS stores a copy of site information for root and link targets in the DFS metadata stored in the DFS
object in Active Directory for domainbased namespaces and in the registry for standalone namespaces. In environments that
have domainbased DFS namespaces hosted on multiple root servers running Windows2000 Server and WindowsServer2003,
the following conditions can arise:
Root servers and domain controllers running WindowsServer2003 ignore any site information in the DFS metadata. They
obtain site information dynamically from Active Directory.
Root servers and domain controllers running Windows2000 Server retrieve the targets site information from the DFS
metadata if the target was created by using Windows2000 Server. However, if the target was created by using
WindowsServer2003, no site information is stored for that target in the DFS metadata. As a result, Windows2000 Server
cannot determine the site of such a target. If this occurs, a referral from a Windows2000 Server could lead the client
computer to a random target, possibly outside of the clients site.
To enable root servers and domain controllers running Windows2000 to sort targets based on site, you can use the
/UpdateWin2kStaticSiteTableparameter in Dfsutil.exe to update the static site information for all root and link targets in the
DFS object in Active Directory. This tool must be run each time a target servers site information is changed, such as after the
target is moved to another site or after the targets site name changes.
When all root servers and domain controllers are running WindowsServer2003, you can use the
/PurgeWin2kStaticSiteTableparameter in Dfsutil.exe to remove site information from the DFS object in Active Directory. We
recommend using this method to decrease the size of the DFS object in Active Directory.
How the restrictanonymous registry entry affects site discovery

Root servers running Windows2000 Server or WindowsServer2003 and that are not domain controllers cannot determine a DFS
client computers site when the restrictanonymous registry entry is set to 2 on domain controllers running Windows2000
Server. This registry entry is located at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa. As a result, these DFS
root servers sort targets in link referrals and root referrals randomly, regardless of the namespace type standalone or domain
based, target selection method, or client operating system.
How Target Selection Works

When a client computer attempts to access a root or link in the namespace, a domain controller or root server provides a referral
to the client. The referral contains a list of target servers, and this list is sorted according to the currently configured target
25/55
9/15/2016
selection method. These methods are described using the following figure as an example.
Example of Client and Target Sites
Note
Outofdate or misconfigured site information can cause DFS to sort referrals incorrectly. For more information about how
DFS caches site information and when this information is refreshed, see How Site Discovery Works earlier in this section.
Default Target Selection

By default, DFS places target servers in the referral in the following order:
1. Targets in the same site as the client are listed in random order at the top of the referral.
2. Targets outside of the clients site are listed in random order.
Using the previous figure as an example, when default target selection is enabled, DFS places the target servers in the referral in
the following order:
Default Referral Order
If no samesite target servers are available, the client computer is referred to a random target server no matter how expensive
the connection is or how distant the target is. This is the default DFS behavior in Windows2000 Server and
WindowsServer2003.
SameSite Target Selection

26/55
9/15/2016
In this method, also called insite target selection, the referral contains the targets that are in the same site as the client. These
samesite targets are listed in random order. If no samesite targets exist, clients in that site do not receive a referral and cannot
access that portion of the namespace.
Using the figure Example of Client and Target Sites as an example, when samesite target selection is enabled, DFS places the
target servers in the referral in the following order:
SameSite Target Selection Referral Order
You enable this setting on a DFS root or on individual links in the namespace by using Dfsutil.exe with the /InSite parameter. If
you enable this setting on the root, root referrals and link referrals return only targets that are in the same site as the client. If no
root or link targets exist in the clients site, then no referral is returned and the client cannot access that portion of the
namespace. If this setting is enabled on a link, and no link targets exist in the clients site, then no referral is returned and the
client cannot access the link.
Samesite target selection works differently in Windows2000 Server and WindowsServer2003. In Windows2000 Server, if this
setting is enabled on a root, the setting applies to all links but not the root itself. If a client attempts to access a namespace but
no root targets exist in the clients site, the outofsite root targets are returned in the root referral. Like WindowsServer2003,
DFS in Windows2000 Server does not return link referrals if no link targets exist in the client computers site.
Least Expensive Target Selection

In this method, also called closest site selection or site costing, DFS uses the DsQuerySitesByCost API to retrieve minimum
communication cost between two sites from Active Directory. The following figure illustrates sites and their associated site link
costs.
Example of Sites and Site Link Costs
27/55
9/15/2016
When least expensive target selection is enabled, DFS places targets in the referral in the following order:
1. Targets in the same site as the client are listed in random order at the top of the referral.
2. Targets outside of the clients site are listed in order of lowest cost to highest cost. Referrals with the same cost are
grouped together and within each group the targets are listed in random order.
Using the previous figure as an example, when least expensive target selection is enabled, DFS places the targets in the referral in
the following order:
Least Expensive Target Selection Referral Order
28/55
9/15/2016
If the DsQuerySitesByCost API call fails, no cost information is returned to the root server. In this case, DFS assumes the
maximum possible cost for that target.
Least expensive target selection works in both standalone and domainbased namespaces, as long as all root servers and all
domain controllers are running WindowsServer2003. These requirements ensure that:
All domain controllers can provide root referrals based on site cost.
All root servers can provide root and link referrals based on site cost.
The domain controllers acting as Intersite Topology Generators can calculate site cost information. One domain controller
in each site is selected as the Intersite Topology Generator, and the role is automatically given to a domain controller
running WindowsServer2003, if one is available for the site.
Least expensive target selection is not available in the following situations:
When a standalone namespace is hosted on a root server that is not part of any domain.
When a root server or domain controller is running Windows2000 Server.
The Bridge all site links option in Active Directory is disabled. This option is available in the Active Directory Sites and
Services snapin. Turning off Bridge all site links can affect the ability of DFS to sort targets in referrals in order of lowest
cost. An Intersite Topology Generator that is running WindowsServer2003 relies on the Bridge all site links option being
enabled to generate the intersite cost matrix that DFS requires for its sitecosting functionality. If you turn off this option,
you must create site links between any Active Directory sites for which you want DFS to calculate accurate site costs. Any
sites that are not connected by site links will have the maximum possible cost. For more information about site link
bridging, see Active Directory Replication Topology Technical Reference.
In these situations, DFS uses the default target selection method. For more information about site costs, see DNS Support for
Active Directory Technical Reference.
Situations in Which Clients Access Unexpected Targets

Even when least expensive or samesite target selection is enabled, clients might still access highcost or outofsite targets. Also,
when default target selection is enabled, a client computer might access a target server outside of its own site, even though a
samesite target exists. These problems are typically caused by one of the following situations:
The samesite target is temporarily unavailable due to server or network issues, and the client fails over to the next
target, which could be outside of the clients site.
The outofsite or highcost target has incorrect site information that makes DFS interpret the target as being in the
clients site. This problem can occur when subnets are not configured correctly. If no samesite targets exist and a client
unexpectedly chooses a highcost target, it might be caused by an incorrect site cost setting.
The client's IP address is not in a subnet that is defined in Active Directory and so DFS cannot obtain site information
about the client.
The targets IP address is not in a subnet that is defined in Active Directory and so DFS cannot obtain site information
about the target.
The client is using a cached referral that contains outdated information about the site of the target server.
Site information has changed, but the old site information is still cached on the root server or domain controller in the
target site cache, client site cache, or site cost cache.
29/55
9/15/2016
The DFS object is not uptodate when the root server polls a domain controller. This can be caused by Active Directory
replication latency or failure.
The Bridge all site links option is disabled, as described earlier.
Site awareness is not working correctly because the restrictanonymous registry entry located at
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa is set to 2 on Windows2000 domain controllers. If this
registry entry is set to 2, DFS root servers that are not domain controllers and are running either Windows2000 Server or
WindowsServer2003 randomly sort the targets in a referral, regardless of the namespace type standalone or domain
based, target selection method, or client operating system.
How DFS Works in Environments Without WINS

The default behavior of DFS is to use NetBIOS names for all target servers in the namespace. This allows clients that support
NetBIOSonly name resolution to locate and connect to targets in a DFS namespace. Administrators can use NetBIOS names
when specifying target names and those exact paths are added to the DFS metadata. For example, an administrator can specify a
target \\FS1\Users, where FS1 is the NetBIOS name of a server whose DNS or FQDN name is FS1.contoso.com.
Organizations that do not use NetBIOS and WINS can still use DFS, but before setting up namespaces the administrators must
create the DFSDnsConfig registry entry on all root servers and then restart the DFS service on all root servers. Administrators
must then use the DNS names for when adding all targets to the namespace. When these steps are complete, the referrals will
contain the DNS names of targets accessed by clients. If a namespace already exists, the administrator must perform the
following steps:
1. Export the namespace to a data file by using Dfsutil.exe.
2. Delete the namespace.
3. In the exported data file, change the NetBIOS names to DNS names for all targets.
4. Recreate all root targets by using DNS names.
5. Import the updated data file.
For more information about the DFSDnsConfig registry entry and Dfsutil.exe, see DFS Tools and Settings.
The Referral Process

The referral process describes the steps that client computers, root servers, and domain controllers perform when a client
attempts to access a target server in a namespace. The following sections provide general and indepth descriptions of the
referral process for domainbased and standalone namespaces. These processes assume that all targets are available. For more
information about how clients respond when a target is unavailable, see What Happens During Failover later in this section.
Overview of the Referral Process

The general steps that occur when a client accesses a domainbased or standalone namespace are described below. These
processes assume the following:
The clients domain cache contains the necessary domain name referrals and domain controller referrals.
The clients referral cache does not contain existing referrals for the targets that the client is attempting to access.
The first root target and link target in each referral are available.
30/55
9/15/2016
The link target is a shared folder on a physical server, not a DFS path in another namespace. The referral process that
occurs when a link points to a DFS path is described in Linking to Different DFS Namespaces later in this section.
Simplified Referral Process for Domainbased Namespaces

1. A user attempts to access a link in a domainbased namespace, such as by typing \\Contoso.com\Public\Software in the
Run dialog box.
2. The client computer sends a query to the active domain controller to discover a list of root targets for the domainbased
namespace.
3. The domain controller returns a list of root targets defined for the requested namespace.
4. The client selects the first root target in the referral and sends a query to the root server for the requested link.
5. The root server constructs a list of link targets in the referral. The order in which the link targets are sorted depends on
the target selection method. The root server sends the referral to the client.
6. The client establishes a connection to the first link target in the list.
Simplified Referral Process for Domainbased Namespaces
Simplified Referral Process for StandAlone Namespaces

1. A user attempts to access a DFS path, such as by typing \\Software\Public\Antivirus in the Run dialog box.
2. The DFS client computer sends a query to the root server that hosts the standalone namespace.
3. The root server returns a root referral to the client. The root referral contains the single root target.
4. The client sends a query to the root server for the requested link.
5. The root server constructs a list of link targets in the referral. The order in which the link targets are sorted depends on
the target selection method. The root server sends the referral to the client.
6. The client establishes a connection to the first link target in the list.
Simplified Referral Process for StandAlone Namespaces
31/55
9/15/2016
Referral Process for Domainbased Namespaces

The referral process for domainbased namespaces is as follows:
1. A user attempts to access a link in a domainbased namespace, such as by typing \\Contoso.com\Public\Software in the
Run dialog box.
2. The client checks its domain cache for an existing domain name referral for the Contoso.com domain. If this referral is in
the domain cache, the client proceeds to step 3. If no domain name referral is in the domain cache, the client connects to
the IPC$ shared folder of the active domain controller in the context of the LocalSystem account and sends a domain
name referral request with a null string. The domain controller returns the list of local and trusted domains to the client.
3. The client checks its referral cache for the longest prefix match from a previous referral. This might be a root referral
\\Contoso.com\Public or a link referral \\Contoso.com\Public\Software. If the client finds a valid entry, it goes to step 5
or 6 depending on the type of the referral. If not, the client continues to the next step.
4. The client checks its domain cache for an existing domain controller referral for the Contoso.com domain. If this referral is
in the cache, the client proceeds to step 5. If no domain controller referral is in the domain cache, the client connects to
the IPC$ shared folder of the active domain controller in the context of the LocalSystem account and sends a domain
controller referral request containing the appropriate domain name Contoso.com. The domain controller returns the list
of domain controllers in the Contoso.com domain. The domain controllers in the clients site are at the top of the list. If
leastexpensive target selection is enabled, domain controllers outside of the targets site are sorted by lowest cost. If
samesite target selection is enabled, DFS ignores this setting and lists the remaining domain controllers in random order.
5. The client checks its referral cache for an existing domainbased root referral. If this referral is in the cache, the client
proceeds to step 6. If no domainbased root referral exists in the referral cache, the client connects to the IPC$ shared
folder of the active domain controller in the context of the LocalSystem account and requests a domainbased root
referral. The domain controller determines the clients site and returns a list of root targets. By default, the root targets in
the clients site are at the top of the list, followed by the remaining root targets in random order. If leastexpensive target
selection is enabled, the remaining root targets are ordered by lowest cost. If samesite target selection is enabled, only
root servers in the clients site are listed in the referral.
6. The client chooses the first root target in the domainbased root referral. The client connects to the root server and
navigates the subfolders under the root folder. When a client encounters a link folder, the root server sends a
STATUS_PATH_NOT_COVERED status message to the client, indicating that this is a link folder that requires redirection.
7. The client checks its referral cache for an existing link referral. If this link referral is in the cache, the client computer
connects to the first link target in the list. If the link referral is not in the cache, the client connects to the IPC$ shared
folder of the root server in the context of the LocalSystem account and requests a link referral from the root server. The
root server returns a list of link targets. At the top of the target list are the link targets that are in the same site as the
client. The root server puts the remaining link targets in the target list using one of the following methods:
By default, the link targets outside of the clients site are put in random order.
If samesite target selection is enabled, the root server does not add outofsite link targets to the referral.
32/55
9/15/2016
If leastexpensive target selection is enabled, the root server checks its site cost cache to determine whether cost
information exists for the connection between the clients site and the link targets site. If the site cost data is not in
the cache, the root server contacts the domain controller acting as the Intersite Topology Generator and uses the
DsQuerySitesByCost API to retrieve site cost data. The root server then sorts the remaining link targets by lowest
cost.
Referral Process for StandAlone Namespaces

The referral process for standalone namespaces is as follows:
1. A user attempts to access a DFS path, such as by typing \\Software\Public\Antivirus in the Run dialog box.
2. The client checks its domain cache and determines that the DFS path is not a domainbased DFS path that is, Software is
not the name of a domain.
3. The client checks its referral cache to determine if an existing standalone root referral is in the cache. If the root referral is
in the cache, the client proceeds to Step 5. If the referral is not in the cache, the client connects to the IPC$ shared folder
of the root server in the context of the LocalSystem account and sends a root referral request. The root server responds
with a root referral so that all future requests are funneled through DFS.
4. The client connects to the root server and navigates the subfolders under the root folder. When a client encounters a link
folder, the root server sends a STATUS_PATH_NOT_COVERED status message to the client, indicating that this is a link
folder that requires redirection.
5. The client checks its referral cache for an existing link referral. If the link referral is in the referral cache, the client connects
to the first link target in the list. If the link referral is not in the referral cache, the client connects to the IPC$ shared folder
of the root server in the context of the LocalSystem account and requests a link referral from the root server. The root
server returns a list of link targets. At the top of the target list are the link targets that are in the same site as the client.
The root server puts the remaining link targets in the target list using one of the following methods:
By default, the link targets outside of the clients site are put in random order.
If samesite target selection is enabled, the root server does not add outofsite link targets to the referral.
If leastexpensive target selection is enabled, the server checks its site cost cache to determine whether cost
information exists for the connection between the clients site and the link targets site. If the site cost data is not in
the cache, the root server contacts the domain controller acting as the Intersite Topology Generator and uses the
DsQuerySitesByCost API to retrieve site cost data. The root server then sorts the remaining link targets by lowest
cost.
How DFS Is Used During the Logon Process

When a client logs on to a domain, the client contacts a domain controller and requests a special type of referral, known as a
SYSVOL or NETLOGON referral, to gain access to the scripts and policies stored in the SYSVOL and NETLOGON shared folders on
domain controllers. Specifically, the client requests SYSVOL and NETLOGON referrals from the active domain controller, which is
preceded by a + under the appropriate domain in the clients domain cache. These referrals map the paths
\\DomainName\Sysvol and \\DomainName\Netlogon to a list of SYSVOL and NETLOGON shared folders for all domain
controllers. Clients store these referrals in their referral cache. To see examples of these referrals, see the figure Sample Referral
Cache Output earlier in this section.
DFS objects do not exist in Active Directory for these shared folders; instead, the domain controller simply recognizes that it is
responsible for these paths and responds to queries of the form \\DomainName\Sysvol and \\DomainName\Netlogon. These
referrals are distinct in that although the targets are hosted on a domain controller, the targets are not roots themselves and do
not appear in any of the DFS tools, nor can the SYSVOL and NETLOGON shared folders host links.
33/55
9/15/2016
Domain controllers generate SYSVOL and NETLOGON referrals each time a client requests a referral. By default, the list of
domain controllers listed in a SYSVOL or NETLOGON referral are sorted as follows:
1. All domain controllers in the clients site are grouped in random order at the top of the list.
2. Domain controllers outside of the clients site are listed in random order.
It is possible to configure DFS to sort the domain controllers outside of the clients site in order of lowest cost. You can enable
this feature by adding the SiteCostedReferrals registry entry on each domain controller and then restarting the DFS service on
each domain controller. The DFS service then obtains site cost information for all domain controllers and stores this information
in its site cost cache.
Linking to Different DFS Namespaces

When you create a link and specify the link target, you can use any UNC path, including a path to another namespace. For
example, the Apps link in a standalone namespace \\Dev\Team\Apps might have a link target of
\\Contoso.com\Public\Software, which is a link within a domainbased namespace. These types of links are often called interlinks,
and DFS namespaces that point to other namespaces are often called cascaded namespaces.
Linking to different namespaces requires that certain rules be followed so that clients can fail over correctly if one of the targets
is unavailable. The rules are as follows:
DFS clients can perform a maximum of eight hops through other DFS namespaces. This means that a given link can point
to a DFS path, and that path can point to another DFS path, and so on, up to a maximum of eight times.
A link that points to a different namespace can correspond to only one of the following options:
A link target can point to one or more standalone DFS paths anywhere in the standalone DFS namespace. For
example, a link target can be \\Software\Public a DFS path with just the root or \\Software\Public\Applications a
DFS path with a root and link.
A link target can point to a single domainbased DFS path anywhere in the domainbased DFS namespace. For
example, a link target can be \\Contoso.com\Public or \\Contoso.com\Public\Users.
The referral process that occurs when a client accesses a link whose target is a DFS path is as follows:
1. A user attempts to access a link that points to another namespace.
2. If necessary, the DFS client requests domain and domain controller referrals for domainbased namespaces and root
referrals for both types of namespaces by following the steps described in The Referral Process earlier in this section.
3. The root server provides a link referral. Because the link points to another namespace, the link target in the referral shows
the DFS path, not the physical path.
4. The client attempts to access the DFS path provided in the link referral and requests the necessary referrals.
5. The client receives the referrals and accesses the intended target.
The following figure illustrates a clients referral cache after the client attempts to access the Apps link within a standalone
namespace \\Dev\Team\Apps that points to a link in a domainbased namespace \\Contoso.com\Public\Software. Note that
the link target in the link referral for Apps is listed as Contoso.com\Public\Software and that the type is shown as type 0x10,
OUTSIDE_MY_DOM. This type is used when a link points to a path in a domainbased namespace.
34/55
9/15/2016
DFS Client Referral Cache
What Happens During Failover

DFS failover is the process in which clients attempt to access another target in a referral after one of the targets fails or is no
longer part of the namespace. Failover can occur in five scenarios:
A client attempts to access the currently active target in a referral, but the target is unavailable.
A client attempts to access a domain controller to request a domain referral or a domainbased root referral, but the
currently active domain controller in the referral is unavailable.
The DFS client has a session enabled with a target, and the target server fails.
The DFS client has a session enabled with a target, and the hard disk on the server fails or the shared folder is disabled.
A referral expires for a DFS client running Microsoft WindowsXP with Service Pack 2 SP2 or Windows Server2003 with
Service Pack 1 SP1, and the previous active target is not in the new referral.
When reviewing the different types of failovers, note the following:
Clients must access a domainbased namespace by using the format \\DomainName\RootName. If a client accesses a
domainbased 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.
The following scenarios describe different types of failures and what is involved in the failover process in each case.
The active target in a referral is unavailable

35/55
9/15/2016
When a DFS client accesses a namespace, the client always chooses the first target in the target list in the referral. If the first
target is available, a session setup is performed and client credentials are passed to the server, unless a prior connection already
exists with the selected target. If the selected target cannot be accessed, the client attempts to access the next target in the list,
and so on, until all targets are exhausted. If all targets are unavailable, then the client cannot access that portion of the DFS
namespace.
Note
When DFS attempts to access a target in the target list, and the first target or subsequent targets are not available, DFS
does not attempt to access those targets again during later failovers until it has reached the bottom of the list.
A domain controller fails

When a client attempts to request a domainbased root referral or a domain name referral from a domain controller, and the
first domain controller for a given domain in the clients domain cache is unavailable, the client will fail over to the next domain
controller in the cache. If all domain controllers for the given domain are unavailable, the client cannot access the domainbased
DFS namespace for that domain.
A client is accessing the target server when it becomes unavailable

In the following scenario, assume that a client application is accessing a target in the namespace when the server hosting the
physical shared folder loses power or drops off the network. If the referral contains more than one target, the client will attempt
a failover the next time the client attempts to open any file or folder in that portion of the DFS namespace. The amount of time it
takes to detect that the hosting computer is offline depends on the protocol that the client is using. Many protocols, such as
TCP/IP, account for slow and loosely connected WAN links, and, as such, might have retry counts of up to two minutes before the
protocol times out. After the protocol returns an error, DFS returns a failure to the application. The next time the application
attempts to open a file or folder in that portion of the namespace, DFS will fail over to the next target. If the DFS client reaches
the bottom of the list, it will start again at the top until it has attempted to connect to all targets.
A client is accessing the target server when a hard drive failure occurs or folder sharing is stopped
In the following scenario, assume that a client is accessing a target in the namespace when the server hosting the physical shared
folder loses the hard disk containing the folder, or an administrator stops sharing the folder. If the referral contains more than
one target, the client will attempt a failover as in the previous scenario. However, in this scenario, the server hosting the shared
folder is still responding to the client request; therefore, the failover to a new target is much faster than the previous scenario
because DFS does not rely on the protocol to detect a failure.
A referral expires for a DFS client running Windows XP with SP2 or Windows Server2003 with SP1
The behavior of the Time to Live value has changed for DFS clients running Microsoft WindowsXP with SP2 or Windows
Server2003 with SP1. These clients do not renew the Time to Live value each time they access a target using a cached referral. As
a result, the referral expires after the Time to Live value lapses, regardless of whether the client has accessed or is currently
accessing the target. In terms of DFS failover, this new behavior can cause the DFS client to fail over to a new target if the
previously active target is not in the new referral, such as when the namespace is changed to remove the target that the client
had accessed.
For more information about the Time to Live value, see How DFS Discovers Changes to the Namespace later in this section.
Root Folder and Link Folder Creation Process

When you first create a DFS namespace, you specify a shared folder to use as the root folder. When you add links to the
namespace, DFS creates a special folder, called a link folder, under the root folder to represent each link. The hierarchy of the
root folder and link folders on the root servers local storage matches the actual namespace. If you create a link by using the
format FolderName\FolderName\LinkName, DFS creates the hierarchy of empty folders and then creates the link folder. Root and
link folders are illustrated in the following figure.
36/55
9/15/2016
Roots, Links, Root Folders, and Link Folders
When you use a DFS tool to create a link, DFS checks whether a folder that has the same name as the link appears under the
root. DFS then takes one of the following actions:
If no folder exists, DFS creates the link folder and sets a reparse point on the folder.
If an empty folder with the same name as the link exists, DFS sets a reparse point on that folder.
If a nonempty folder with the same name as the link exists, DFS renames the nonempty folder to DFS.GUIDLinkName,
creates a new link folder, and sets a reparse point on the folder. An example folder name is DFS.cf13c05f5c104879
9acb04ced8f46c7aTemplates, where cf13c05f5c1048799acb04ced8f46c7a is the GUID and Templates is the LinkName.
The reparse points set on the link folders prevent data from being stored in the link folders and prevent administrators from
deleting link folders by using traditional methods, such as by using Windows Explorer or the command prompt. If an
administrator needs to remove a link folder, the administrator can use Dfsutil.exe to remove all DFS reparse points under a
specified root folder and then delete the link by using the DFS tools. When the DFS service is started, it checks that the link
folders are configured correctly and recreates link folders and reparse points as necessary. It also cleans up stale reparse points
that are no longer part of any namespace.
When you add a new root target to an existing domainbased namespace, you specify an existing shared folder or create a new
shared folder to use as the root. DFS creates the link folders on the new root target after the root server obtains the DFS
metadata by polling the PDC emulator master or the closest domain controller if root scalability mode is enabled. When a root
server obtains the DFS metadata after polling and detects that a link has been removed, the root server removes the reparse
point and the link folder for the deleted link.
How DFS Discovers Changes to the Namespace

To ensure that clients have an uptodate view of the namespace, DFS must maintain a consistent version of the namespace on
all root servers. A change to the namespace can include the following types of changes:
Adding, changing, or removing root targets, links, and link targets.
Changing the settings on a namespace, including the Time to Live for roots and links, target selection method for
example, changing to least expensive or samesite target selection, enabling root scalability mode, and so forth.
Enabling or disabling a referral to a link target.
The following sections describe how changes are discovered in standalone and domainbased namespaces.
Note
These sections assume that site information is uptodate in the client site cache, target site cache, and site cost cache on
root servers and domain controllers. If these caches contain outdated site information, DFS might not sort targets in
37/55
9/15/2016
referrals correctly. Client and target site information can be out of date for up to 24hours, and site cost information can
be outofdate up to 12hours. For more information about how site information is updated, see How Site Discovery
Works earlier in this section.
How Changes Are Discovered in StandAlone Namespaces

Changes made to a standalone namespace are updated immediately in the DFS metadata in the root servers registry and in the
root servers inmemory DFS metadata cache. Therefore, standalone root servers typically provide uptodate root referrals and
link referrals.
Clients do not request new root and link referrals until the referrals expire or are cleared from their cache. You can use the
following table to determine the maximum length of time that outofdate referrals are used in standalone namespaces.
When Referrals to StandAlone Namespaces Expire
Where Referrals Are

Cached
Referral Type
Default Expiration
Time
Where Expiration Time Is Stored
DFS clients
Standalone root
referral
5 minutes
Time to Live of root configured using the DFS

tools
DFS clients
Link referral
30 minutes
Time to Live of link configured using the DFS

tools
For DFS clients that are not running Windows XP with Service Pack 2 SP2 or Windows Server2003 with SP1, the Time to Live for
a referral determines the earliest time that a client will request a new referral, but only if the existing referral expires before it is
accessed again. Clients that use a cached referral will renew the Time to Live of the referral and thus use the referral indefinitely
until the clients referral cache is cleared or the client is restarted.
This behavior has changed for clients running WindowsXP with SP2 or Windows Server2003 with SP1. Specifically, the Time to
Live value is not reset each time a client accesses a target using a cached referral. Instead, the referral expires after the Time to
Live value lapses. This change has several effects:
Clients running WindowsXP with SP2 or Windows Server2003 with SP1 will request referrals more frequently than other
DFS clients, which can cause moderately increased load on the standalone DFS root server.
Because they request new referrals more frequently, clients running WindowsXP with SP2 or Windows Server2003 with
SP1 will discover namespace updates more quickly than other DFS clients.
How Changes Are Discovered in Domainbased Namespaces

The update process for domainbased namespaces is more complex because there are multiple locations of the DFS metadata
the DFS metadata is stored in the DFS object in Active Directory on each domain controller and is stored in a memory cache on
multiple root servers. To ensure that all root servers discover changes to the namespace, DFS uses two methods of keeping root
servers up to date:
Root server notification
Periodic polling of the PDC emulator master
38/55
9/15/2016
These methods are described in the sections that follow.
Root server notification

To maintain a consistent namespace across root servers, DFS depends on the domain controller acting as the primary domain
controller PDC emulator master to be the gatekeeper for all updates to the namespace. Having all root servers running
WindowsServer2003 poll the PDC emulator master after the namespace changes ensures that root servers can obtain the
updated DFS metadata relatively quickly without needing to wait for Active Directory replication to replicate the DFS object to all
domain controllers.
Root server notification in WindowsServer2003 works as follows:
1. The DFS tool that an administrator uses to make the change contacts the closest root server for that namespace.
2. The root server updates the DFS metadata in the DFS object in Active Directory on the PDC emulator master.
3. The root server sends a change notification message to all other root servers hosting the namespace.
4. When root servers running WindowsServer2003 receive the change notification message, they poll the PDC emulator
master to obtain an updated version of the DFS metadata. Root servers running Windows2000 Server ignore change
notification messages and poll the PDC emulator master every hour. If a WindowsServer2003 root server does not
receive the change notification message, for example, if the root server is temporarily offline, it will poll the PDC emulator
master at the next polling interval.
This update process can cause an increased load on the PDC emulator master in namespaces that have more than 16root
targets and in namespaces that change frequently. In these environments, we recommend enabling root scalability mode. For
more information, see How Root Scalability Mode Works later in this section.
Periodic polling of the PDC emulator master

By default, root servers poll the PDC emulator master during the following events:
When the root server starts up or the DFS service is restarted.
When any DFS API is called against the root server. For example, using the Dfscmd.exe commandline tool with the /view
\\dfsname\dfsshare /fullparameter causes the root server to poll the PDC emulator master. This command calls the
NetDfsEnum API.
At the interval specified in the SyncIntervalInSeconds registry entry on the root server, which is one hour by default.
Organizations that have stable namespaces can increase this value so that root servers contact the PDC emulator master
less frequently.
If the PDC emulator master is unavailable when a root server attempts polling, the root server will poll its closest domain
controller. If the DFS object has replicated from the PDC emulator master to the domain controller closest to the root server, the
root server receives the uptodate version of the DFS object at the next polling.
When changes to domainbased namespaces are reflected in referrals

Even if the DFS metadata stored in a memory cache on root servers and present in the DFS object in Active Directory on domain
controllers is identical and uptodate, DFS root servers and domain controllers can provide outdated domainbased root
referrals until those referrals expire or are cleared from the domainbased root referral cache. On the other hand, link referrals
are uptodate as soon as the root server receives an updated copy of the DFS object. After the root servers and domain
controllers begin providing uptodate referrals, clients might continue to use outdated referrals until the referrals expire or are
flushed from the clients referral cache.
39/55
9/15/2016
You can use the following table to determine the maximum length of time that outofdate referrals are used in domainbased
namespaces. This table assumes that the root servers and domain controllers have received the most recent version of the DFS
metadata.
When Referrals to Domainbased Namespaces Expire
Where Referrals Are

Cached
Referral Type
Default Expiration
Time
Where Expiration Time Is Stored
Domain controller
Domainbased root
referral
15 minutes
RootReferralTimeoutInSeconds registry
entry
Root server
Domainbased root
referral
15 minutes
RootReferralTimeoutInSeconds registry
entry
DFS client
Domainbased root
referral
5 minutes
Time to Live of root configured using the

DFS tools
DFS client
Link referral
30 minutes
Time to Live of link configured using the DFS

tools
Based on the default values in the previous table, domain controllers and root servers can provide updated domainbased root
referrals after 15 minutes, assuming that the domain controller or root server has received the most recent version of the DFS
object in Active Directory. Any latency in Active Directory replication could cause additional delay.
If settings on a link change, root servers can provide uptodate link referrals as soon as the root server has obtained an updated
version of the DFS metadata in the DFS object from the PDC emulator master. As described earlier, root servers contact the
PDC emulator master soon after they receive the change notification message. If root servers are connected by highspeed
network connections to each other and to the PDC emulator master, any changes to links are reflected in referrals almost
immediately. A root server will provide outofdate information in a link referral if any of the following conditions apply:
The root server does not receive a change notification message due to network problems or other issues. In this case, the
root server will contact the PDC emulator to obtain the updated DFS metadata at the polling interval described earlier.
Note that root servers running Windows2000 Server ignore change notification messages and poll the PDC emulator
master every hour.
Root scalability mode is enabled. In this case, root servers obtain the DFS metadata from the closest domain controller
every hour, so you must factor in an additional onehour delay plus the time required for Active Directory replication to
replicate the updated DFS object to each domain controller.
For DFS clients that are not running WindowsXP with SP2 or Windows Server2003 with SP1, the Time to Live for a referral
determines the earliest time that a client will request a new referral, but only if the existing referral expires before it is accessed
again. Clients that use a cached referral will renew the Time to Live of the referral and thus use the referral indefinitely until the
clients referral cache is cleared or the client is restarted.
This behavior has changed for clients running WindowsXP with SP2 or Windows Server2003 with SP1. Specifically, the Time to
Live value is not reset each time a client accesses a target using a cached referral. Instead, the referral expires after the Time to
Live value lapses. This change has several effects:
40/55
9/15/2016
Clients running WindowsXP with SP2 or Windows Server2003 with SP1 will request referrals more frequently than other
DFS clients, which can cause moderately increased load on the domainbased DFS root servers and domain controllers.
Because they request new referrals more frequently, clients running WindowsXP with SP2 or Windows Server2003 with
SP1 will discover namespace updates more quickly than other DFS clients.
How Root Scalability Mode Works

Root scalability mode allows organizations to use more than the recommended 16 root targets per domainbased root. When
root scalability mode is enabled, DFS root servers do not send change notification messages to other root servers when the
namespace changes or poll the PDC emulator master every hour. Instead, they poll their closest domain controller every hour to
discover updates to the namespace.
Root scalability mode reduces network traffic to the PDC emulator master at the expense of faster updates to all root servers.
Updates are still made to the DFS object in Active Directory on the PDC emulator master, but root servers do not discover those
changes until the updated DFS object replicates using Active Directory replication to the closest domain controller for each root
server. After root scalability mode is enabled, clients might have an inconsistent view of the namespace until the most upto
date version of the DFS object is replicated to all domain controllers and the DFS root servers poll a domain controller to
discover the changes.
Root scalability mode does not entirely eliminate traffic to the PDC emulator master. The PDC emulator master is still used as
follows:
As described earlier, changes to the namespace are still made on the PDC emulator master.
If the closest domain controller is the PDC emulator master, then the root server will poll the PDC emulator master every
hour.
When the DFS service starts on the root server when the server reboots, for example, the DFS service polls the PDC
emulator master. On the next polling interval, the root server polls the closest domain controller to get an initial copy of
the DFS metadata. This behavior occurs because the root scalability setting is stored in the DFS object in Active Directory,
so when a root server first starts up, it polls the PDC emulator master, determines that root scalability mode is enabled,
and begins polling the domain controller at regular intervals.
If a domainbased root has root targets running Windows2000 Server and WindowsServer2003, root servers running
Windows2000 Server poll the PDC emulator master every hour.
What Happens When You Check Target Status

You can use the Distributed File System snapin to check the status of roots, links, and root and link targets. The snapin verifies
the namespace elements as follows:
When you check the status of a root or link, the snapin calls the GetFileAttributes API on each target to verify that they
can be accessed. If this succeeds, the snapin calls the GetFileAttributes API on the root folder or link folder to verify that
it can be accessed.
When you check the status of a root target or link target, the snapin calls the GetFileAttributes API on the target to verify
that the target can be accessed.
The following tables list the possible status indicators for DFS roots, links, and targets. These status indicators remain on the
namespace element until you restart the snapin or choose the Refresh command on the Action menu.
DFS Status Flags for Roots and Links
41/55
9/15/2016
Root or Link
Description
Folder icon yellow
No known status.
Folder icon with green check

mark
All targets are reachable on the network and their referrals are enabled.
Folder icon with yellow

exclamation point
Indicates one of the following conditions:

All corresponding targets are reachable on the network but one or more targets
has its referral disabled.
Some corresponding targets are not reachable on the network.
Folder icon with red X
Indicates one of the following conditions

All corresponding targets are not reachable on the network.
All corresponding targets have their referrals disabled.
The root path is unreachable.
DFS Status Flags for Targets
Target
Description
Folder icon yellow
No known status.
Folder icon with green check mark
Target is reachable on the network.
Folder icon with red X
Target is not reachable on the network.
How DFS Works on Server Clusters

A server cluster is a group of individual computer systems, called nodes, working together cooperatively to provide increased
computing power and continuous availability of businesscritical applications or resources. A cluster can be configured so that
the workload is distributed among the group, and if one of the nodes fails, another node automatically assumes its duties.
Using DFS in conjunction with server clusters can result in the increased availability of standalone roots in an organization. DFS
is supported on server clusters as follows:
42/55
9/15/2016
Link targets. Link targets can consist of any File Share resource on shared cluster storage and any shared folder on a
cluster nodes local nonshared storage. The fact that a link target exists on a server cluster is transparent to DFS, so you
can select these link targets as you would link targets on nonclustered file servers. If a link target is hosted on a cluster
nodes local storage, and the node fails or is taken offline, the link target is not available.
Standalone roots. Standalone roots are supported on shared cluster storage and on a cluster nodes local storage.
When a standalone root is created on shared cluster storage, the root is available as long as one of the nodes in the
server cluster is available. If a standalone root is hosted on a cluster nodes local storage, and the node fails or is taken
offline, the namespace is not available.
Domainbased roots. Domainbased roots are not supported on shared cluster storage. Domainbased roots are
supported only on a cluster nodes local storage. If a domainbased root is hosted on a cluster nodes local storage, and
the node fails or is taken offline, the namespace is not available unless there is another root target either on another
nodes local storage or on another server in the domain.
If you plan to create standalone roots on shared cluster storage, it is important to understand the resource dependencies for
DFS roots and the processes related to the creation and failover of DFS roots. The following sections describe these issues. For
more information about how server clusters work in general, see Server Clusters Technical Reference.
Resource Dependencies of StandAlone Roots

Using Cluster Administrator, you choose the File Share resource type to create a standalone DFS root on a server clusters
shared storage. The resource group that hosts the DFS root must contain the following resources:
File Share resource select the DFS Root option
Network Name resource this is the virtual server name that is used by the clients to access this DFS root
IP Address resource for the network name
Physical Disk resource hosts the DFS root
The dependencies for these resources must be configured correctly so that DFS can fail over if the node hosting the DFS root
fails. The dependency tree is illustrated in the following figure.
File Share Resource Dependency Tree
How StandAlone Roots on Server Clusters Work

When the DFS service starts on a cluster node, the DFS service uses the Cluster APIs to determine whether the current node is
part of a cluster. This process is important for two reasons
43/55
9/15/2016
Standalone roots on cluster nodes can be put in standby mode by using the NetDfsSetInfo API. When a root is put on
this state, the DFS service does not provide referrals for it. Note that only standalone roots on cluster nodes can be put
on this state. This state is not supported for normal standalone or domainbased roots. When the root is in standby
mode, the operations of removing the root and bringing the cluster to online mode are supported.
The referrals for standalone roots on cluster nodes must contain the respective virtual server name rather than the name
of the node that is currently hosting the root.
When a standalone root is first created on shared cluster storage, the DFS service on the node that hosts the resource group
that contains the DFS root resource creates the DFS metadata for the root in a registry entry at
KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone. The Cluster service propagates this registry information to
the cluster database on the quorum resource, which is a resource that maintains the configuration data that is necessary for the
recovery of the resource group. When a link is added or removed, or when the settings on the namespace are changed, the DFS
service on the hosting node makes these changes in the DFS metadata in the registry. These changes to the registry are
propagated to the cluster database. The physical folder acting as the root folder and any link folders are maintained on the
shared cluster storage.
DFS registers a callback function with the Cluster service when a root is first created on a node and when the root is created on
another node during cluster failover. The callback function is important because it allows DFS to determine whether the root is
created on shared cluster storage. When DFS registers a callback function, the Cluster service enumerates all the File Share
resources in the cluster, and DFS determines if the root it is currently creating is a cluster resource.
If the node that hosts the DFS root fails, the following actions occur on another node for example, Node 2:
1. The Cluster service reads the roots registry settings from the quorum resource and places these settings in the registry of
Node 2.
2. The Cluster service brings the resources online in the order of dependency.
3. The Cluster service creates an SMB shared folder on the root folder in the shared cluster storage.
4. The Cluster service informs DFS about the new root information in the registry and starts the DFS service if it is not
already running.
5. DFS creates the internal data structures necessary for the DFS service to provide referrals for this root.
If a client attempts to access the root between steps 3 and 4, the client cannot access links under the root. This problem occurs
because the DFS root is not yet created, so the SMB redirector claims the UNC path, causing the clients MUP cache to contain
entries indicating that the resource is an SMB shared folder, and not a DFS root. Clearing the clients MUP cache by using
Dfsutil.exes /PurgeMupCache parameter will correct this problem.
How DFS Works with Offline Files

By using the Offline Files feature, you can make shared folders that correspond to DFS root targets and link targets available
offline to client computers running WindowsXP Professional or WindowsServer2003. The following sections describe two
important interactions between Offline Files and DFS. These sections assume that the client computers are running either
WindowsXP Professional or WindowsServer2003.
Offline Settings on Root Targets and Link Targets

The Offline Files feature provides three settings for shared folders:
Only the files and programs that users specify will be available offline.
44/55
9/15/2016
All files and programs on the share will be available offline.

No files or programs on the share will be available offline.
Offline settings for root targets and link targets are set on the individual shared folders that are specified as targets. Although
link targets appear subordinate to root targets in the namespace, link targets do not inherit or otherwise use the offline settings
set on root targets. In addition, if a root or link has multiple targets, and those targets have different offline settings, the client
will use whatever settings are applied to the target to which the client connects. Therefore, it is important for administrators to
apply offline settings consistently to all targets for a DFS root or link.
How the Offline Files Feature Interprets DFS Paths

The Offline Files feature does not distinguish DFS paths from UNC paths. This can cause the client to interpret the entire
namespace as unavailable if a target is down when a client attempts to access it. For example, if \\Contoso.com\Public is a
domainbased root with several root targets and numerous links, the Offline Files feature interprets this namespace as a single
server named \\Contoso.com. If a client is accessing or attempts to access a target in the \\Contoso.com\Public namespace, and
the target is unavailable, the client interprets the entire namespace as unavailable and will attempt to open a users locally
cached files if they exist. The client cannot access any target in the namespace until the target comes back online. The client will
check every 10 minutes to detect whether the target has come back online. Alternatively, the user can use the Synchronization
Manager to attempt to synchronize the offline files with those stored on the network. The user can also use Synchronization
Manager to go back online without synchronizing changes.
DFSRelated Processes on Clients

The following sections describe how DFS clients running WindowsXP and Windows2000 update the memory caches described
in DFS Physical Structures and Caches on DFS Clients earlier in this section.
How Clients Update the Domain Cache

DFS clients periodically discover new domains in the local forest and in trusted forests. This discovery process, which occurs every
15minutes by default, runs against a domain controller from the domain that hosts the client's computer account. To avoid real
time queries to domain controllers in the domain, the referrals received during the discovery process are stored in a special table,
called the domain cache or SPC cache. As a result of this process, clients can more quickly distinguish queries for fully qualified
domain names from fully qualified computer names.
The process by which DFS clients update the domain cache is as follows:
1. When a DFS client starts up, the Workstation service calls the DFS client driver Mup.sys with information about the
NetBIOS and DNS names of the domain to which the client is joined. The Workstation service also provides the name of
one domain controller in that domain. For this example, assume that the domain controller is called ClientDC.
2. The client saves the domain information and opens the IPC$ connection \\ClientDC\IPC$ to the domain controller and
sends a request with an empty name to request a list of trusted domains in the clients forest and in trusted forests.
If the client cannot connect to the domain controller or the domain controller fails in its response, the failure is sent to the
Workstation service. This causes the Workstation service to find another domain controller for the clients domain and to
pass that information to the DFS client. If this also fails, the Workstation service stops attempting to locate a domain
controller. Regardless of whether previous attempts have succeeded, the Workstation service performs this process every
15 minutes to ensure that DFS has a current working domain controller. The DfsDcNameDelay registry entry on the DFS
client specifies the 15minute interval.
3. If the referral request for the domain name information is successful, the client fills in its domain cache. This cache
contains the domain information returned to the client as a response to the empty referral request. This information is
updated every time the Workstation service calls the DFS client driver.
4. Any UNC request on the client comes to DFS first before any of the network redirectors. DFS checks its domain cache to
determine whether the name is a domain name. If it is meaning that the UNC path request is for a domainbased
45/55
9/15/2016
namespace, DFS checks its referral cache to detect whether it already has a referral to this namespace. If no referral exists,
and the name is a domain name, the client proceeds to the next step.
5. The client determines whether the domain name is expanded. An expanded domain name is one in which the domain
controllers are cached for the domain. If the domain name is not expanded, the client requests a domain controller
referral from ClientDC.
DFS clients request new domain name referrals and domain controller referrals every 15 minutes, by default. You can configure
this interval by using the DfsDcNameDelay registry entry on the client. Domain name referrals and domain controller referrals
remain in the clients domain cache until the client receives updated referrals at the next interval or the client computer is
restarted.
Note
Without the proper domain name referrals and domain controller referrals, clients cannot access domainbased
namespaces. This problem can occur when clients are logged on using cached credentials. DNS problems can also cause a
client to be missing referrals.
If an organization has a large number of trusted domains and forests, it is possible that clients will not be able to access all
domainbased namespaces within the trusted domains and forests. If a client can access a link target in another trusted domain
or trusted forest by using the targets UNC path, the client can also access the link target by using its DFS path, but only if the list
of domains fits into the clients buffer. By default, DFS clients send a 4KB 2,048 Unicode character buffer to a domain controller
when requesting domain name referrals. If the list of domains is too large to fit into the 4KB buffer, DFS clients automatically
increase their buffer size to accept the list of domains, up to a maximum of 56KB.
If the list of domains exceeds 56KB, DFS puts as many domains in the buffer as it can until the buffer reaches 56KB. DFS then
writes an entry with the ID 14536 in the system event log of the domain controller that provided the domain referral. When
populating the buffer, DFS gives preference to local and explicitly trusted domains by filling the buffer with their names first.
Consequently, by creating explicit trust relationships with domains that host important DFS namespaces, you can minimize the
possibility that those domain names might be dropped from the list that is returned to the client.
Note
To make sure that clients can access link targets in other trusted domains or trusted forests, use DNS names for all link
targets and configure DFS to use fully qualified domain names in referrals. For more information about using DNS names,
see How DFS Works in Environments Without WINS earlier in this section.
How Clients Update the MUP Cache

When a Windowsbased client attempts to access a UNC path, Windows sends the request to the multiple UNC provider
Mup.sys to identify which redirector should handle the request. When Mup.sys receives the request, Mup.sys determines
whether the path is in a DFS namespace. If it is, Mup.sys passes the request to DFS. If the path is a shared folder or WebDAV
folder, for example, Mup.sys checks its internal cache, known as the MUP cache, to see whether the connection had been made
previously. Mup.sys then sends the request to each redirector that handles each request synchronously and attempts to identify
a resource on the network that matches the request. After all redirectors return, Mup.sys chooses the redirector that the
application will use based on response and priority.
How Clients Update the Referral Cache

When users access DFS roots and links, the client sends a referral request to the DFS server either a domain controller or root
server, depending on the type of referral requested. The DFS server puts the referral response in a 4 KB buffer 2,048 Unicode
characters and returns the buffer to the client. Root servers and domain controllers send referrals up to 4KB if there is room for
at least one target in the referral. If the paths of the targets are so long that the 4KB buffer cannot hold even one target, DFS
makes the client request a larger response limit up to 56KB.
46/55
9/15/2016
After a client receives a referral, the client stores the referral in the referral cache and accesses the first available target either a
particular root target or link target in the list of targets provided in the referral. The client will continue to access that target until
one of the following occurs:
The client computer is restarted, which clears the referral cache.
The user manually clears the referral cache by using Dfsutil.exe with the /pktflush parameter.
The target server becomes unavailable.
The Time to Live value for the root or link referral expires. WindowsServer2003 uses a default Time to Live value of 300
seconds 5 minutes for root referrals and 1800 seconds 30 minutes for link referrals.
After any of these events, the client will obtain a new referral the next time it attempts to access the target. If the client continues
to access the target within the Time to Live value, the Time to Live value is renewed and the client never requests a new referral.
If the Time to Live value is not renewed, it is decremented by 4 minutes 240 seconds until it reaches zero. If the Time to Live
value is set less than 240 seconds, the referral will not expire for 240 seconds.
DFS Protocols
DFS uses the Common Internet File System CIFS for communication between DFS clients, root servers, and domain controllers.
CIFS is an extension of the Server Message Block SMB file sharing protocol. Examining network captures of CIFS
communications between a DFS client and server is helpful for understanding and troubleshooting DFS processes. The following
sections illustrate two network captures created when a client receives different types of referrals.
Network Capture of a Client Receiving Domain Name Referrals and Domain Controller Referrals
The following network capture taken using Microsoft Network Monitor shows what happens when a client first receives domain
name referrals and domain controller referrals. This network capture was taken on a domain controller named DC01 after the
client named DFSCLIENT was restarted. Only SMB frames are shown. Note that this network capture is an example of client and
domain controller communication and might differ from network captures taken in your environment.
Network Capture of a Client Receiving Domain Name Referrals and Domain Controller Referrals
The following sections provide a partial printout of the SMB data for each frame and explain the processes that occur in each
frame. These processes are explained in more detail in DFS Physical Structures and Caches on DFS Clients and The Referral
Process earlier in this section.
Frames 20 and 22: Client connects to IPC$

The client connects to IPC$ on DC01.
Frame 23: Client requests domain name referral

47/55
9/15/2016
The client sends a request with an empty name to the domain controller to request a domain name referral.
SMB:Transactionparameters
SMB:DFSMaxReferralLevel=3(0x3)
SMB:DFSRequestFilename=
Frame 24: Domain controller provides a domain name referral

The domain controller provides a domain name referral that contains the names of all trusted domains in the clients forest and
in trusted forests. In this particular example, there is only one domain.
SMB:Transactiondata
SMB:DFSVersion3Referral
SMB:DFSVersionNumber=3(0x3)
SMB:DFSServerType=UnknownServerType
SMB:DFSTimeToLive=600(0x258)
SMB:DFSSpecialName=\contoso.com
SMB:DFSNumberofExpandedNames=0(0x0)
SMB:DFSSpecialName=\CONTOSO
Frame 25: Client requests a domain controller referral

The client requests a domain controller referral for Contoso.com. Note that the client is sending the DNS name Contoso.com.
SMB:DFSRequestFilename=\contoso.com
Frame 26: Domain controller provides a domain controller referral

The domain controller provides domain controller referrals for the three domain controllers in the Contoso.com domain. The
domain controller names are returned as DNS names.
SMBTransactiondata
SMB:DFSSpecialName=\contoso.com
48/55
9/15/2016
SMB:DFSExpandedName=\Dc01.contoso.com
Frame 27: Client requests a domain controller referral

The client requests a domain controller referral for Contoso, the NetBIOS name of the domain.
SMB:DFSRequestFilename=\CONTOSO
Frame 28: Domain controller provides a domain controller referral

The domain controller provides domain controller referrals for the three domain controllers in the Contoso.com domain. The
domain controller names are returned as NetBIOS names.
SMBTransactiondata
SMB:DFSSpecialName=\
SMB:DFSExpandedName=\Dc01
Network Capture of a Client Accessing a Domainbased Namespace

The following network capture shows what happens when a client accesses a link Software in the \\Contoso.com\Public
namespace. This network capture was taken on a DFS client named DFSCLIENT and includes referrals from a domain controller
named DC01, a root server ROOTDFS03, and a link target server NOAMFS1. Only SMB frames are shown, and some
frames were removed for brevity. Note that this network capture is an example of client, root server, and link target
communication and might differ from network captures taken in your environment.
Network Capture of a Client Accessing a Domainbased Namespace
49/55
9/15/2016
The following sections provide a partial printout of the SMB data for each frame and explain the processes that occur in each
frame. These processes are explained in more detail in The Referral Process earlier in this section.
Frames 352353: Client connects to IPC$

The client connects to IPC$ on DC01.
Frame 354: Client requests a root referral

The client requests a root referral for the \\Contoso.com\Public namespace.
SMB:DFSRequestFilename=\contoso.com\public
Frame 355: Domain controller provides a root referral

The domain controller provides a root referral that contains three root servers, \\RootDFS03\Public, \\RootDFS02\Public, and
\RootDFS01\Public.
SMBTransactiondata
SMB:DFSServerType=SMBServer
SMB:DFSTimeToLive=300(0x12C)
SMB:DFSFilename=\contoso.com\public
SMB:DFS8.3Filename=\contoso.com\public
SMB:DFSSharename=\RootDFS03\public
SMB:ServicesiteGUID=00000000000000000000000000000000
50/55
9/15/2016
Frames 365377: Client connects to RootDFS03

The client establishes a connection with the first root server in the referral, RootDFS03.
Frame 561: Client navigates to Software link folder

The client navigates to the Software link folder on the root server.
Frame 562: Root server provides STATUS_PATH_NOT_COVERED message

The root server responds with the STATUS_PATH_NOT_COVERED message, which indicates that this is a link folder and that the
client must request a link referral.
Frames 563564: Client connects to IPC$ on root server

The client connects to IPC$ on the root server.
Frame 565: Client requests a link referral

The client requests a link referral to the Software link.
SMB:DFSRequestFilename=\contoso.com\public\Software\
Frame 567: Root server provides a link referral

The root server sends a link referral that contains three link targets for the Software link: \\NoamFS1\Apps, \\NoamFS3\Apps,
and \\NoamFS2\Apps.
SMBTransactiondata
51/55
9/15/2016
SMB:DFSFilename=\contoso.com\public\software
SMB:DFS8.3Filename=\contoso.com\public\software
SMB:DFSSharename=\noamfs1\apps
Frames 577589: Client connects to \\NoamFS1\Apps

The DFS client sets up a session with the first link target in the referral, \\NoamFS1\Apps.
DFS Interfaces
The following APIs are associated with DFS. For more information about these APIs, see DFS in the Microsoft Platform SDK on
MSDN.
DFS APIs
API Name
Description
NetDfsAdd
Creates a new Dfs link or adds targets to an existing link in a DFS root.
NetDfsAddFtRoot
Creates a new domainbased root. If the domainbased root already exists, the function adds the
specified root target to the root.
NetDfsAddStdRo
ot
Creates a new standalone root.
NetDfsEnum
Enumerates all links in the named root. It also lists all roots in a domain and all roots on a server.
NetDfsGetClientI
nfo
Returns the information about cached referrals on a client for a given DFS root or link path.
52/55
9/15/2016
NetDfsGetInfo
Retrieves information about a root or a link in the named root.
NetDfsRemove
Removes a link target from a link or removes a link. If the specified target is the last target of the link,
then the NetDfsRemove function also removes the link.
NetDfsRemoveFt
Root
Removes the specified root target from a domainbased root. If the target is the last target of the root,
the function also deletes the root.
NetDfsRemoveFt
RootForced
Removes the specified root target from a domainbased root, even if the server is offline. If the target is
the last root target, the function also deletes the root.
NetDfsRemoveSt
dRoot
Deletes the standalone root.
NetDfsSetClientIn
fo
Modifies information about cached referrals on a client for a given DFS root or link path.
NetDfsSetInfo
Sets or modifies the information associated with a link in the named root, or with the root itself.

DFS uses the following network ports.
Service Name
Relevant Computers
UDP
TCP
NetBIOS Name Service
Domain controllers; root servers that are not domain controllers;

servers acting as link targets; client computers acting as link
targets
137
137
NetBIOS Datagram
Service

targets
138
NetBIOS Session
Service

targets
LDAP Server
Domain controllers
389
389
Remote Procedure Call

RPC endpoint mapper
Domain controllers
135
Server Message Block

SMB

targets
445
445
139
53/55
9/15/2016
Related Information
The following resources contain additional information that is relevant to this section.
Active Directory Replication Topology Technical Reference
DNS Support for Active Directory Technical Reference
FRS Technical Reference
Server Clusters Technical Reference
Community Additions
Firewall Ports
I couldn't get it working without high ports for RPC 4915265535
Barack D
11/29/2014
DFSutil Type codes / Access codes

I would be great to find a page explaining the various type codes
As some technet blogs explain a few of the codes but nowhere I can find a list of all codes.
things like:
Type 0x81 REFERRAL_SVC DFS .

Indicates a root referral.
Type 0x1 DFS .Indicates a link referral that has physical
shared folders as link targets.
Type 0x10 OUTSIDE_MY_DOM.Indicates a link referral whose link target
is a path in a domainbased namespace.
state 0x21:inactive or not responding
State 0x31:responding and an active target
state: 0x19: ?
Type:0x8001 DFS FAILBACK_ENABLED

54/55
9/15/2016
link referral with failback enabled???

Type:0x8081 REFERRAL_SVC DFS FAILBACK_ENABLED
root referral with Failback enabled???
HandbrakeChicks
5/28/2014
Change of behavior after hotfix

<QUOTE From The "Domain Controllers" Section>
Domain controllers acting as the Intersite Topology Generator generate

site cost information. This information describes the relative cost of
the connection between two sites. DFS uses this information to sort
targets in order of lowest cost in referrals when leastexpensive target
selection is enabled
</QUOTE From The "Domain Controllers" Section>
REMARK: by default the ISTG, which can be found through an attribute on the NTDS Site Settings Object has been designated as the DC to
calculate the site cost matrix for an DFS client. In reality ANY DC can provide that information. By installing the hotfix as mentioned in the
KB article http://support.microsoft.com/kb/2285823 any DC can be used to provide this information instead of specifically targeting the DC
with the ISTG
Jorge de Almeida Pinto [MVPDS]
4/11/2013
2016 Microsoft
55/55

How DFS Works - Remote File Systems

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

How DFS Works - Remote File Systems

Hochgeladen von

Copyright:

Verfügbare Formate

9/15/2016

DFS Terms and Definitions

DFS Namespaces Illustrated

Overview of Client and Server Roles in DFS

Domain controllers play numerous roles in DFS:

DFS Client and Server Compatibility

Act As DFS Clients?

Act As a Root Server?

Can host one standalone

Can host one standalone

Can host multiple stand

Can host multiple stand

Can access standalone namespaces but

Can host one standalone

Can host a single stand

Client for standalone DFSincluded; install the

Characteristics of Namespace Types

In Active Directory. Also stored in a memory cache on the

In the registry of the root server. Also stored

DFS administrators must be members of the Domain

DFS administrators must be members of the

DFS administrators must be members of the local

DFS administrators must be members of the

We recommend that you keep the size of the DFS object

The largest recommended namespace size

Create multiple root targets in the same domain.

Create a standalone root on a server

Create multiple link targets and replicate files by using

Create multiple link targets and replicate

Copying files manually or by using

DFS Client and Root Server Architecture

The following tables describe the components of the DFS architecture.

Where the DFS metadata is stored for standalone DFS namespaces.

DFS Physical Structures and Caches

DFS Physical Structures and Caches on Domain Controllers

DFS Object in Active Directory

Each DFS object has the following four important attributes:

remoteServerName. Lists the root targets for the root.

DFS Registry Entries

Domain Name Referral Cache

Domain Controller Referral Cache

Domainbased Root Referral Cache

Client Site Cache

Target Site Cache

Site Cost Cache

DFS Physical Structures and Caches on Root Servers

StandAlone DFS Metadata in the Registry

Root and Link Folders

DFS Registry Entries

DFS Metadata Cache

Domainbased Root Referral Cache

Client Site Cache

Target Site Cache

Site Cost Cache

DFS Physical Structures and Caches on DFS Clients

DFS Registry Entries

Domain Cache on Clients

The preceding sample output can be interpreted as follows:

Referral Cache on Clients

Entry and ShortEntry

UseCount and Type

DFS Processes and Interactions