DFS

How DFS Works: Remote File Systems http://technet.microsoft.com/en-us/library/cc7824...
©2011 Microsoft Corporation. All rights reserved.
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,
high-capacity 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? [ http://technet.microsoft.com/en-us/library/cc779627(WS.10).aspx ] ”.
These sections provide an in-depth 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.
Client computers are running one of the following operating systems: Windows NT 4.0 with Service
Pack 6a, Windows 2000 with Service Pack 4 or later, Windows XP with Service Pack 1 or later, or
1 of 56 Tuesday 01 February 2011 12:47 PM

Windows Server 2003.
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 snap-in.) 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 Windows Server 2003 relies on the Bridge all site
links option being enabled to generate the intersite cost matrix that DFS requires for its site-costing
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 [ http://technet.microsoft.com/en-us/library
/cc755326(WS.10).aspx ] .”
Windows 2000 domain controllers and Windows 2000 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.
domain-based 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 domain-based DFS root can have multiple root targets, which offers fault
tolerance and load sharing.
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 domain-based DFS root can have multiple root targets, whereas
a stand-alone DFS root can only have one root target. Root targets are also called root servers.
stand-alone 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 stand-alone DFS root has only one root target.
Stand-alone roots are not fault tolerant; when the root target is unavailable, the entire DFS namespace is
inaccessible. You can make stand-alone 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.
Windows Server 2003 offers two types of namespaces: stand-alone and domain-based. 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: stand-alone roots, which begin with a server name, and domain-based

roots, which begin with a domain name. Valid formats for domain names include \\NetBIOSDomainName
\RootName and \\DNSDomainName\RootName.
Examples of DFS Namespaces
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 domain-based root can have multiple root servers to provide redundancy and high
availability, whereas a stand-alone root can only have one root server. (Stand-alone 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 snap-in, the Dfscmd.exe
command-line tool, or the Dfsutil.exe command-line 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 domain-based 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 end-user computers;
computers running Windows-based 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
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 domain-based 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 domain-based 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 domain-based 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 domain-based 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 least-expensive target selection is enabled.
Root servers
Root servers (also called root targets) are the servers on which administrators create stand-alone and
domain-based namespaces. A root server can be a member server or a domain controller. Root servers play the
following roles in DFS:
For stand-alone namespaces, the DFS metadata is stored in the registry of the root server. For
domain-based 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 stand-alone namespace, or a link in a

domain-based 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 stand-alone 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
The following table describes the types of clients and servers that can act as DFS clients, root servers, and link
targets.
DFS Compatibility
Act As a
Link
Platform Act As DFS Clients? Act As a Root Server? Target?
Microsoft Yes Yes Yes

Windows Server 2003,
Web Edition Can host one
stand-alone namespace
or one domain-based
namespace per server.
Windows Server 2003, Yes Yes Yes

Standard Edition
Can host one
or one domain-based
Windows Server 2003, Yes Yes Yes

Enterprise Edition, and
Windows Server 2003, Can host multiple
Datacenter Edition stand-alone namespaces
and multiple
domain-based
namespaces per server.
Windows Storage Server 2003 Yes Yes Yes
Can host multiple

stand-alone namespaces
and multiple
domain-based
namespaces per server.
Windows XP Yes No Yes
Windows Preinstallation Yes No No

Environment (WinPE)
Can access stand-alone
namespaces but cannot access
domain-based namespaces.

Windows 2000 Server family Yes Yes Yes
Can host one

or domain-based
Windows 2000 Professional Yes No Yes
Windows NT Server 4.0 with Yes Yes Yes

Service Pack 6a
Can host a single
per server.
Windows NT Workstation 4.0 Yes No Yes

with Service Pack 6a
Windows 98 Yes No Yes
Client for stand-alone

DFS included; install the Active
Directory client extension for
Windows 95 or Windows 98 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
domain-based 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
domain-based 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 “DFS-Related Processes
on Clients” later in this section.
If a Windows 2000 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 domain-based and stand-alone
namespaces.
Characteristic Domain-based Stand-Alone
Path to namespace \\NetbiosDomainName\RootName \\ServerName\RootName
\\DNSDomainName\RootName
Where DFS In Active Directory. Also stored in a In the registry of the root server.
metadata is stored memory cache on the root server. Also stored in a memory cache on
the root server.
Group DFS administrators must be members of DFS administrators must be

memberships the Domain Admins group to create or members of the local Administrators
required to create delete domain-based namespaces or have group on the local server to create
or delete delegated permissions to the or delete stand-alone namespaces.
namespaces DFS-Container object in Active Directory.
Group DFS administrators must be members of DFS administrators must be

memberships the local Administrators group on each of members of the local Administrators
required to the root servers to add or delete links, link group on the local server to add or
administer targets, roots, and root targets.* delete links, link targets, roots, and
namespaces root targets.
DFS namespace We recommend that you keep the size of The largest recommended
size restrictions the DFS object in Active Directory below namespace size for a stand-alone
5 megabytes (MB) by using fewer than namespace is 50,000 links.
5,000 links in domain-based namespaces.
Supported Create multiple root targets in the same Create a stand-alone root on a
methods to ensure domain. server cluster.
DFS root
availability
Supported Create multiple link targets and replicate Create multiple link targets and
methods to ensure files by using one of the following methods: replicate files by using one of the
link target following methods:
availability Enabling FRS
Copying files manually or
Copying files manually or by by using scripts
using scripts
Using another replication
Using another replication tool 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
administrator’s 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.
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 domain-based 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 stand-alone DFS metadata in its registry
(for stand-alone namespaces).
DFS-Related Architecture on Domain Controllers

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 The graphical user interface tool used for administering DFS namespaces. By
System snap-in default, the Distributed File System snap-in (Dfsgui.msc) is installed on servers
(Dfsgui.msc and running Windows Server 2003. You can administer namespaces remotely from a
Dfsui.dll) computer running Windows XP with Service Pack 1 by installing the
Windows Server 2003 Administration Tools Pack, which the includes Distributed File
System snap-in.
Distributed File The DFS command-line tool used to perform basic DFS tasks, such as configuring
System DFS roots, links, and targets. Also supports scripting. Dfscmd.exe is available on all
command-line utility servers running a member of the Windows Server 2003 family.
(Dfscmd.exe)
Distributed File The DFS command-line tool used to perform basic and advanced DFS tasks, such
System utility as enabling root scalability mode, least expensive target selection, and same-site
(Dfsutil.exe) target selection. When installed on DFS clients, 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”
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 Windows-based
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 The redirectors for Netware and Web Distributed Authoring and Versioning (WebDAV),
Mrxdav.sys 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 Sends domain controller information and domain names to Mup.sys. Mup.sys uses this
service information to generate the referrals in the client’s domain cache. This service is also a
(Wkssvc.dll) 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
“DFS-Related Architecture on Domain Controllers”

Dfs.sys The DFS driver. Dfs.sys runs only on Windows-based 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 in-memory 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 server-side support for NetDFSxxx APIs that
configures and maintains DFS namespaces. The DFS service is also responsible
for maintaining an up-to-date version of the DFS metadata and for giving
referrals to clients who attempt to access the namespace.
Domain-based root The in-memory copies of domain-based root referrals and site information that
referral cache and site enable Dfssvc.exe to perform fast lookups. These caches are described in the
caches next section.
Registry Where the DFS metadata is stored for stand-alone 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
domain-based 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.

DFS Physical Structures and Caches on Domain Controllers
Domain controllers play an important role for domain-based namespaces. They store the DFS metadata for
domain-based namespaces, and they provide referrals to DFS clients to help them access domain-based
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

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 domain-based namespace. The DFS object is created in Active
Directory when you create a domain-based root, and Active Directory replicates the entire DFS object to all
domain controllers in a domain. When a client requests a referral for a domain-based namespace, the domain
controller first checks its domain-based 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 domain-based 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.
remoteServerName. Lists the root targets for the root.
Security descriptor. Controls who can modify the DFS object. The security descriptor on the
DFS-Configuration 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 400 bytes
per DFS link. (This figure does not include any comments that you add to describe the namespace.) A mid-sized
DFS namespace with 100 links requires approximately 40 kilobytes (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 domain-based namespace be less than 5 megabytes (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 domain-based 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 [ http://technet.microsoft.com/en-us/library
/cc780950(WS.10).aspx ] .”
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 domain-based namespaces.
By default, domain controllers store domain name referrals in a memory cache for 12 hours; 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 12 hours
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 client’s domain)
to determine which domain controllers can provide a referral for a domain-based namespace.
Domain controllers store these domain controller referrals in a memory cache for 10 minutes; 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 10 minutes or after this cache is cleared.
Domain-based Root Referral Cache
A domain-based root referral contains a list of root targets that host a given domain-based namespace. Domain
controllers provide domain-based root referrals to clients that attempt to access a domain-based namespace.

By default, domain controllers store domain-based root referrals in a memory cache for 15 minutes; 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 domain-based root referrals after 15 minutes or
after this cache is cleared.
Note
The domain-based 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 client’s 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 24 hours. This period is defined by the
SiteSupportIntervalInSeconds registry entry (12 hours) 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 out-of-date for a maximum of twice the value of the SiteSupportIntervalInSeconds registry
entry (24 hours) 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 domain-based 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 24 hours. This interval is defined by
the SiteSupportIntervalInSeconds registry entry value (12 hours) 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 out-of-date for a maximum
of twice the value of the SiteSupportIntervalInSeconds registry entry (24 hours) 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 domain-based 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 domain-based root targets as needed to
fulfill client referral requests. By default, entries in the site cost cache are maintained for up to 12 hours. This
period is defined by the SiteSupportIntervalInSeconds registry entry value (12 hours) 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 out-of-date for a maximum of the SiteSupportIntervalInSeconds registry entry (12 hours) or
until the DFS service is restarted.
The QuerySiteCostTimeoutinSeconds registry entry on domain controllers is also used for this cache to
specify a time-out period for site cost queries. After the time-out period, the DsQuerySitesByCost API calls for site
cost information in Active Directory will fail. By default, the time-out 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 stand-alone). Servers running Windows 2003 Server, Enterprise Edition, and
Windows Server 2003, Datacenter Edition, can host multiple stand-alone and domain-based 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.
Stand-Alone DFS Metadata in the Registry
The stand-alone DFS metadata contains information about the root, root target, links, link targets, and settings
defined for each stand-alone namespace. This metadata is maintained in the registry of the root server at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone.
Note
Domain-based 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
domain-based DFS metadata. When the DFS service starts on a root server, the service checks this
path for registry entries that correspond to domain-based roots. If these entries exist, the root server
polls the PDC emulator master to obtain the DFS metadata for each domain-based 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.
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 [ http://technet.microsoft.com/en-us/library
/cc780950(WS.10).aspx ] .”
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 domain-based namespaces, this metadata is also stored in the DFS object in
Active Directory. For stand-alone namespaces, this metadata is also stored in the root server’s registry.
This cache is updated each time the root server polls the DFS object in Active Directory (for domain-based
namespaces) and the registry (for stand-alone namespaces). For more information, see “How DFS Discovers
Changes to the Namespace” later in this section.
Domain-based Root Referral Cache
When a client computer contacts a domain-based DFS root server directly by using the syntax \\ServerName
\RootName, the root server provides a domain-based 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 domain-based
namespace. For more information, see “Linking to Different DFS Namespaces” later in this section.
By default, root servers store these domain-based root referrals in a memory cache for 15 minutes; 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 domain-based root referrals (provided by root servers) after
15 minutes or after the cache is cleared.
Note
The domain-based 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
client’s IP address. DFS stores this information in the root server’s 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 24 hours. This period is defined by the
SiteSupportIntervalInSeconds registry entry (12 hours) 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 out-of-date for a maximum of twice the value of the SiteSupportIntervalInSeconds registry
entry (24 hours) 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 server’s 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 24 hours. This interval is defined by the
SiteSupportIntervalInSeconds registry entry value (12 hours) 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 out-of-date for a maximum
of twice the value of the SiteSupportIntervalInSeconds registry entry (24 hours) or until the DFS service is
restarted.
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 12 hours. This
period is defined by the SiteSupportIntervalInSeconds registry entry value (12 hours) 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
out-of-date for a maximum of the SiteSupportIntervalInSeconds registry entry (12 hours) or until the DFS
service is restarted.
The QuerySiteCostTimeoutinSeconds registry entry on root servers is also used for this cache to specify a
time-out period for site cost queries. After the time-out period, the DsQuerySitesByCost API calls for site cost
information in Active Directory will fail. By default, the time-out period is 30 seconds. If DFS cannot determine a
target’s 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 Windows XP and Windows 2000 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.
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 “DFS-Related Processes on Clients” later in this section.
DFS registry entries are located in the DFS client’s 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 [ http://technet.microsoft.com/en-us/library
/cc780950(WS.10).aspx ] .
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 client’s 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 command-line tool with the /spcinfo

parameter. The following text illustrates the output displayed when you use this command.
[*][dc-01.contoso.com]
[*][CONTOSO]
[*][contoso.com]
[+][contoso.com]
[-dc-02.contoso.com]
[+dc-01.contoso.com]
[-][AFRICA]
[-][EUROPE]
[+][CONTOSO]
[-DC-02]
[+DC-01]
[-DC-03]
[-DC-04]
[-][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 DC-01 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 domain-based root
referrals.
The client has already contacted DC-01 to receive domain name referrals for Contoso.com,
Europe.Contoso.com, and Africa.Contoso.com.
The client has already contacted DC-01 to receive domain controller referrals for the Contoso.com
domain.
For information about how clients update their domain caches, see “DFS-Related 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
15 minutes. You can use Dfsutil.exe’s /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 “DFS-Related 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 Windows XP client computer.

Sample Referral Cache Output
The previous figure shows four types of referrals: (1) NETLOGON and SYSVOL referrals, (2) domain-based root
referrals, (3) stand-alone root referrals, and (4) link 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
Windows Server 2003 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 Windows 2000, Windows XP, and Windows Server 2003, 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.
Type 0x10 ( OUTSIDE_MY_DOM). Indicates a link referral whose link target is a path in a
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, same-site 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 DFS-related 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 domain-based
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 snap-in.
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 “DFS-Related 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 target’s 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 subnet-to-site
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 client’s IP address to a site
name based on the subnet-to-site mappings as defined in Active Directory.
Site discovery in Windows Server 2003 works regardless of the operating system that the target server is running.
For example, if a link target is running Windows NT 4.0 or a non-Windows operating system, DFS can determine
the target’s 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 server’s IP address to
determine the target’s site.
When a target server is multihomed (that is, the server has multiple IP addresses), the root server or
domain controller determines the target’s 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 client’s network request, which could be arbitrary based on the client’s 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 12 hours, by default). Because site information is
cached and not immediately updated after it changes, it is important to understand how out-of-date cached site
information affects site discovery for target servers and client computers.
Target site information can become out-of-date when a target server is moved from one site to
another and the target’s 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 out-of-date. Eventually DFS discovers the new site information when the old site information
is updated in the target site cache, which occurs within 24 hours, 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 out-of-date when a client computer moves to another site but
keeps the same IP address, when the client’s 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 24 hours,
by default. Until site information is refreshed in the cache, DFS might sort targets in referrals based
on the client’s 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 Windows Server 2003, it is also important to understand how site
discovery is affected when your organization uses a combination of root servers and domain controllers running
Windows Server 2003 and Windows 2000 Server. These issues are described in the sections that follow.
Differences in where site information is stored
In Windows 2000 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 domain-based namespaces) and in the registry (for stand-alone
namespaces). In environments that have domain-based DFS namespaces hosted on multiple root servers running
Windows 2000 Server and Windows Server 2003, the following conditions can arise:
Root servers and domain controllers running Windows Server 2003 ignore any site information in the
DFS metadata. They obtain site information dynamically from Active Directory.
Root servers and domain controllers running Windows 2000 Server retrieve the target’s site
information from the DFS metadata if the target was created by using Windows 2000 Server.
However, if the target was created by using Windows Server 2003, no site information is stored for
that target in the DFS metadata. As a result, Windows 2000 Server cannot determine the site of such
a target. If this occurs, a referral from a Windows 2000 Server could lead the client computer to a
random target, possibly outside of the client’s site.
To enable root servers and domain controllers running Windows 2000 to sort targets based on site, you can use
the /UpdateWin2kStaticSiteTable parameter 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 server’s site
information is changed, such as after the target is moved to another site or after the target’s site name changes.
When all root servers and domain controllers are running Windows Server 2003, you can use the
/PurgeWin2kStaticSiteTable parameter 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 Windows 2000 Server or Windows Server 2003 and that are not domain controllers cannot
determine a DFS client computer’s site when the restrictanonymous registry entry is set to 2 on domain
controllers running Windows 2000 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 (stand-alone 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 selection method. These methods are described using the following figure as an
example.
Example of Client and Target Sites
Note
Out-of-date 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 client’s 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 same-site 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 Windows 2000
Server and Windows Server 2003.
Same-Site Target Selection
In this method, also called in-site target selection, the referral contains the targets that are in the same site as the
client. These same-site targets are listed in random order. If no same-site 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 same-site target selection is enabled,
DFS places the target servers in the referral in the following order:
Same-Site 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 client’s 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 client’s site, then no referral is returned and the client cannot access the link.
Same-site target selection works differently in Windows 2000 Server and Windows Server 2003. In Windows 2000
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 client’s site, the out-of-site root targets are returned in the
root referral. Like Windows Server 2003, DFS in Windows 2000 Server does not return link referrals if no link
targets exist in the client computer’s 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

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 client’s 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

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 stand-alone and domain-based namespaces, as long as all root
servers and all domain controllers are running Windows Server 2003. 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 Windows Server 2003, if one is available for the
site.)
Least expensive target selection is not available in the following situations:
When a stand-alone namespace is hosted on a root server that is not part of any domain.
When a root server or domain controller is running Windows 2000 Server.
The Bridge all site links option in Active Directory is disabled. (This option is available in the Active
Directory Sites and Services snap-in.) 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
Windows Server 2003 relies on the Bridge all site links option being enabled to generate the
intersite cost matrix that DFS requires for its site-costing 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 [ http://technet.microsoft.com/en-us/library/cc755326(WS.10).aspx ] .
In these situations, DFS uses the default target selection method. For more information about site costs, see “DNS
Support for Active Directory Technical Reference [ http://technet.microsoft.com/en-us/library
/cc781627(WS.10).aspx ] .”
Situations in Which Clients Access Unexpected Targets
Even when least expensive or same-site target selection is enabled, clients might still access high-cost or out-of-site
targets. Also, when default target selection is enabled, a client computer might access a target server outside of its
own site, even though a same-site target exists. These problems are typically caused by one of the following
situations:
The same-site 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 client’s site.

The out-of-site or high-cost target has incorrect site information that makes DFS interpret the target
as being in the client’s site. This problem can occur when subnets are not configured correctly. If no
same-site targets exist and a client unexpectedly chooses a high-cost 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 target’s 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.
The DFS object is not up-to-date 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 Windows 2000 domain
controllers. If this registry entry is set to 2, DFS root servers that are not domain controllers (and are
running either Windows 2000 Server or Windows Server 2003) randomly sort the targets in a
referral, regardless of the namespace type (stand-alone 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 NetBIOS-only 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 [
http://technet.microsoft.com/en-us/library/cc780950(WS.10).aspx ] .

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 in-depth
descriptions of the referral process for domain-based and stand-alone 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 domain-based or stand-alone namespace are described
below. These processes assume the following:
The client’s domain cache contains the necessary domain name referrals and domain controller
referrals.
The client’s 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.
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 Domain-based Namespaces
1. A user attempts to access a link in a domain-based 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
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 Domain-based Namespaces

Simplified Referral Process for Stand-Alone 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 stand-alone 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 Stand-Alone Namespaces
Referral Process for Domain-based Namespaces
The referral process for domain-based namespaces is as follows:
1. A user attempts to access a link in a domain-based 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 least-expensive target
selection is enabled, domain controllers outside of the targets site are sorted by lowest cost. If same-site
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 domain-based root referral. If this referral is in the
cache, the client proceeds to step 6. If no domain-based 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 domain-based 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 least-expensive target selection is enabled, the remaining
root targets are ordered by lowest cost. If same-site 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 domain-based 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 same-site target selection is enabled, the root server does not add out-of-site link targets to
the referral.
If least-expensive 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 Stand-Alone Namespaces
The referral process for stand-alone 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 domain-based DFS path (that
is, Software is not the name of a domain).
3. The client checks its referral cache to determine if an existing stand-alone 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 same-site target selection is enabled, the root server does not add out-of-site link targets to
the referral.
If least-expensive 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 client’s
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.
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 client’s site are grouped in random order at the top of the list.
2. Domain controllers outside of the client’s site are listed in random order.
It is possible to configure DFS to sort the domain controllers outside of the client’s 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 stand-alone namespace \\Dev\Team\Apps might have a link target of
\\Contoso.com\Public\Software, which is a link within a domain-based 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 stand-alone DFS paths anywhere in the
stand-alone 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 domain-based DFS path anywhere in the domain-based
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 domain-based
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 client’s referral cache after the client attempts to access the Apps link within a
stand-alone namespace (\\Dev\Team\Apps) that points to a link in a domain-based 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
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 domain-based 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 Windows XP with Service Pack 2 (SP2) or
Windows Server 2003 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 domain-based namespace by using the format \\DomainName\RootName. If a

client accesses a domain-based 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
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 domain-based root referral or a domain name referral from a domain
controller, and the first domain controller (for a given domain) in the client’s 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 domain-based 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 Server 2003 with SP1
The behavior of the Time to Live value has changed for DFS clients running Microsoft Windows XP with SP2 or
Windows Server 2003 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 server’s 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.
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 non-empty folder with the same name as the link exists, DFS renames the non-empty folder to
DFS.GUIDLinkName, creates a new link folder, and sets a reparse point on the folder. An example
folder name is DFS.cf13c05f-5c10-4879-9acb-04ced8f46c7aTemplates, where cf13c05f-
5c10-4879-9acb-04ced8f46c7a 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 domain-based 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 up-to-date 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 same-site 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 stand-alone and domain-based namespaces.
Note

These sections assume that site information is up-to-date 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 referrals correctly. Client and target site information can be
out of date for up to 24 hours, and site cost information can be out-of-date up to 12 hours. For more
information about how site information is updated, see “How Site Discovery Works” earlier in this
section.
How Changes Are Discovered in Stand-Alone Namespaces
Changes made to a stand-alone namespace are updated immediately in the DFS metadata in the root server’s
registry and in the root server’s in-memory DFS metadata cache. Therefore, stand-alone root servers typically
provide up-to-date 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 out-of-date referrals are used in
stand-alone namespaces.
When Referrals to Stand-Alone Namespaces Expire
Where Referrals Are Default Expiration

Cached Referral Type Time Where Expiration Time Is Stored
DFS clients Stand-alone root 5 minutes Time to Live of root (configured

referral 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 Server 2003 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 client’s referral cache is cleared or the client is
restarted.
This behavior has changed for clients running Windows XP with SP2 or Windows Server 2003 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 Windows XP with SP2 or Windows Server 2003 with SP1 will request referrals more
frequently than other DFS clients, which can cause moderately increased load on the stand-alone DFS
root server.
Because they request new referrals more frequently, clients running Windows XP with SP2 or
Windows Server 2003 with SP1 will discover namespace updates more quickly than other DFS clients.
How Changes Are Discovered in Domain-based Namespaces
The update process for domain-based 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

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 Windows Server 2003 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 Windows Server 2003 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 Windows Server 2003 receive the change notification message, they poll the
PDC emulator master to obtain an updated version of the DFS metadata. (Root servers running
Windows 2000 Server ignore change notification messages and poll the PDC emulator master every hour.)
If a Windows Server 2003 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
16 root 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
command-line 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 up-to-date version of the DFS object at the next polling.
When changes to domain-based 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 up-to-date, DFS root servers and domain controllers can provide
outdated domain-based root referrals until those referrals expire or are cleared from the domain-based root
referral cache. On the other hand, link referrals are up-to-date as soon as the root server receives an updated
copy of the DFS object. After the root servers and domain controllers begin providing up-to-date referrals, clients
might continue to use outdated referrals until the referrals expire or are flushed from the client’s referral cache.

You can use the following table to determine the maximum length of time that out-of-date referrals are used in
domain-based namespaces. This table assumes that the root servers and domain controllers have received the
most recent version of the DFS metadata.
When Referrals to Domain-based Namespaces Expire
Default
Where Referrals Expiration
Are Cached Referral Type Time Where Expiration Time Is Stored
Domain Domain-based root 15 minutes RootReferralTimeoutInSeconds

controller referral registry entry
Root server Domain-based root 15 minutes RootReferralTimeoutInSeconds

referral registry entry
DFS client Domain-based root 5 minutes Time to Live of root (configured using the
referral 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
domain-based 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 up-to-date 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 high-speed 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 out-of-date
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 Windows 2000 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 one-hour 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 Windows XP with SP2 or Windows Server 2003 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 client’s referral cache is cleared or the client is restarted.
This behavior has changed for clients running Windows XP with SP2 or Windows Server 2003 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 Windows XP with SP2 or Windows Server 2003 with SP1 will request referrals more
frequently than other DFS clients, which can cause moderately increased load on the domain-based
DFS root servers and domain controllers.

Because they request new referrals more frequently, clients running Windows XP with SP2 or
Windows Server 2003 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 domain-based
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 up-to-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 domain-based root has root targets running Windows 2000 Server and Windows Server 2003,
root servers running Windows 2000 Server poll the PDC emulator master every hour.
What Happens When You Check Target Status
You can use the Distributed File System snap-in to check the status of roots, links, and root and link targets. The
snap-in verifies the namespace elements as follows:
When you check the status of a root or link, the snap-in calls the GetFileAttributes API on each target
to verify that they can be accessed. If this succeeds, the snap-in 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 snap-in 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 snap-in or choose the Refresh command on the Action
menu.
DFS Status Flags for Roots and Links
Root or Link Description

Folder icon (yellow) No known status.
Folder icon with green All targets are reachable on the network and their referrals are enabled.
check mark
Folder icon with yellow Indicates one of the following conditions:

exclamation point
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 business-critical 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 stand-alone roots in an
organization. DFS is supported on server clusters as follows:
Link targets. Link targets can consist of any File Share resource on shared cluster storage and any
shared folder on a cluster node’s local (non-shared) 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
non-clustered file servers. If a link target is hosted on a cluster node’s local storage, and the node fails
or is taken offline, the link target is not available.
Stand-alone roots. Stand-alone roots are supported on shared cluster storage and on a cluster
node’s local storage. When a stand-alone 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 stand-alone root is hosted
on a cluster node’s local storage, and the node fails or is taken offline, the namespace is not available.
Domain-based roots. Domain-based roots are not supported on shared cluster storage.

Domain-based roots are supported only on a cluster node’s local storage. If a domain-based root is
hosted on a cluster node’s local storage, and the node fails or is taken offline, the namespace is not
available unless there is another root target (either on another node’s local storage or on another
server in the domain).
If you plan to create stand-alone 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 [ http://technet.microsoft.com/en-us/library/cc759014(WS.10).aspx ] .”
Resource Dependencies of Stand-Alone Roots
Using Cluster Administrator, you choose the File Share resource type to create a stand-alone DFS root on a server
cluster’s 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 Stand-Alone 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
Stand-alone 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 stand-alone
roots on cluster nodes can be put on this state. This state is not supported for normal stand-alone or
domain-based 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 stand-alone 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 stand-alone 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 root’s 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
client’s MUP cache to contain entries indicating that the resource is an SMB shared folder, and not a DFS root.
Clearing the client’s MUP cache by using Dfsutil.exe’s /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 Windows XP Professional or Windows Server 2003. The
following sections describe two important interactions between Offline Files and DFS. These sections assume that
the client computers are running either Windows XP Professional or Windows Server 2003.
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.
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 domain-based 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 user’s 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.
DFS-Related Processes on Clients
The following sections describe how DFS clients running Windows XP and Windows 2000 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 15 minutes 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 client’s
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 client’s 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 15-minute
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 domain-based 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 client’s 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
domain-based 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 domain-based 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 target’s 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 client’s buffer. By default, DFS clients send a 4-KB
(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 4-KB buffer, DFS clients automatically increase their buffer size to accept the list
of domains, up to a maximum of 56 KB.
If the list of domains exceeds 56 KB, DFS puts as many domains in the buffer as it can until the buffer reaches
56 KB. 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 Windows-based 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 4 KB if there is room for at least one target in the referral. If the paths of the
targets are so long that the 4-KB buffer cannot hold even one target, DFS makes the client request a larger
response limit (up to 56 KB).
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. Windows Server 2003 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 DC-01) 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 DC-01.
Frame 23: Client requests domain name referral
The client sends a request with an empty name to the domain controller to request a domain name referral.

SMB: Transaction parameters

SMB: DFS Max Referral Level = 3 (0x3)
SMB: DFS Request Filename =
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
client’s forest and in trusted forests. In this particular example, there is only one domain.
SMB: Transaction data

SMB: DFS Version 3 Referral
SMB: DFS Version Number = 3 (0x3)
SMB: DFS Server Type = Unknown Server Type
SMB: DFS TimeToLive = 600 (0x258)
SMB: DFS Special Name =\contoso.com
SMB: DFS Number of Expanded Names = 0 (0x0)
SMB: DFS Special Name =\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: DFS Request Filename = \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.
SMB Transaction data

SMB: DFS Special Name =\contoso.com
SMB: DFS Expanded Name =\Dc-01.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: DFS Request Filename =\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.

SMB: DFS Special Name =\
SMB: DFS Expanded Name =\Dc-01
Network Capture of a Client Accessing a Domain-based 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 DC-01), a root server (ROOT-DFS-03), and a link target server (NOAM-FS-1).
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 Domain-based Namespace

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 352-353: Client connects to IPC$
The client connects to IPC$ on DC-01.
Frame 354: Client requests a root referral
The client requests a root referral for the \\Contoso.com\Public namespace.

SMB: DFS Request Filename = \contoso.com\public
Frame 355: Domain controller provides a root referral
The domain controller provides a root referral that contains three root servers, \\Root-DFS-03\Public, \\Root-
DFS-02\Public, and \Root-DFS-01\Public.


SMB: DFS Server Type = SMB Server
SMB: DFS TimeToLive = 300 (0x12C)
SMB: DFS Filename =\contoso.com\public
SMB: DFS 8.3 Filename =\contoso.com\public
SMB: DFS Sharename =\Root-DFS-03\public
SMB: Servicesite GUID = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


Frames 365-377: Client connects to Root-DFS-03
The client establishes a connection with the first root server in the referral, Root-DFS-03.
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 563-564: 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: DFS Request Filename =\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: \\Noam-FS-1\Apps,
\\Noam-FS-3\Apps, and \\Noam-FS-2\Apps.


SMB: DFS Filename =\contoso.com\public\software
SMB: DFS 8.3 Filename =\contoso.com\public\software
SMB: DFS Sharename =\noam-fs-1\apps


Frames 577-589: Client connects to \\Noam-FS-1\Apps
The DFS client sets up a session with the first link target in the referral, \\Noam-FS-1\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 domain-based root. If the domain-based root already

exists, the function adds the specified root target to the root.
NetDfsAddStdRoot Creates a new stand-alone root.
NetDfsEnum Enumerates all links in the named root. It also lists all roots in a domain
and all roots on a server.
NetDfsGetClientInfo Returns the information about cached referrals on a client for a given DFS
root or link path.

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.
NetDfsRemoveFtRoot Removes the specified root target from a domain-based root. If the target
is the last target of the root, the function also deletes the root.
NetDfsRemoveFtRootForced Removes the specified root target from a domain-based root, even if the
server is offline. If the target is the last root target, the function also
deletes the root.
NetDfsRemoveStdRoot Deletes the stand-alone root.
NetDfsSetClientInfo 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 137 137
controllers; servers acting as link targets; client computers
acting as link targets
NetBIOS Datagram Domain controllers; root servers that are not domain 138
Service controllers; servers acting as link targets; client computers
NetBIOS Session Service Domain controllers; root servers that are not domain 139
controllers; servers acting as link targets; client computers
LDAP Server Domain controllers 389 389
Remote Procedure Call Domain controllers 135

(RPC) endpoint mapper
Server Message Block Domain controllers; root servers that are not domain 445 445
(SMB) controllers; servers acting as link targets; client computers
Related Information
The following resources contain additional information that is relevant to this section.

Active Directory Replication Topology Technical Reference [ http://technet.microsoft.com/en-us

/library/cc755326(WS.10).aspx ]
DNS Support for Active Directory Technical Reference [ http://technet.microsoft.com/en-us/library

/cc781627(WS.10).aspx ]
FRS Technical Reference [ http://technet.microsoft.com/en-us/library/cc759297(WS.10).aspx ]
Server Clusters Technical Reference [ http://technet.microsoft.com/en-us/library

/cc759014(WS.10).aspx ]
Tags:
Community Content

DFS

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

DFS

Загружено:

Авторское право:

Доступные форматы

How DFS Works: Remote File Systems http://technet.microsoft.com/en-us/library/cc7824...

©2011 Microsoft Corporation. All rights reserved.

How DFS Works

DFS Client and Server Compatibility

Characteristics of Namespace Types

DFS Physical Structures and Caches

DFS Processes and Interactions

Network Ports Used by DFS

Sites and site costs in Active Directory are configured properly.

1 of 56 Tuesday 01 February 2011 12:47 PM

Windows Server 2003.

Client computers are properly joined to the domain.

DFS Terms and Definitions

domain-based DFS namespace

2 of 56 Tuesday 01 February 2011 12:47 PM

stand-alone DFS namespace

DFS Namespaces Illustrated

Example of Physical Servers and Shared Folders in Contoso.com

3 of 56 Tuesday 01 February 2011 12:47 PM

Examples of DFS Namespaces

Roots and Root Servers

Overview of Client and Server Roles in DFS

4 of 56 Tuesday 01 February 2011 12:47 PM

Domain controllers play numerous roles in DFS:

Whenever an administrator makes a change to a domain-based namespace, the change is made on

When a client attempts to access a root or link in a stand-alone namespace, or a link in a

5 of 56 Tuesday 01 February 2011 12:47 PM

DFS Client and Server Compatibility

Microsoft Yes Yes Yes

Windows Server 2003, Yes Yes Yes

Windows Server 2003, Yes Yes Yes

Windows Storage Server 2003 Yes Yes Yes

Can host multiple

Windows XP Yes No Yes

Windows Preinstallation Yes No No

6 of 56 Tuesday 01 February 2011 12:47 PM

Windows 2000 Server family Yes Yes Yes

Can host one

Windows 2000 Professional Yes No Yes

Windows NT Server 4.0 with Yes Yes Yes

Windows NT Workstation 4.0 Yes No Yes

Windows 98 Yes No Yes

Client for stand-alone

When evaluating client compatibility, review the following important considerations:

7 of 56 Tuesday 01 February 2011 12:47 PM

Characteristics of Namespace Types

8 of 56 Tuesday 01 February 2011 12:47 PM

Characteristics of Namespace Types

Characteristic Domain-based Stand-Alone

Path to namespace \\NetbiosDomainName\RootName \\ServerName\RootName

Group DFS administrators must be members of DFS administrators must be

Group DFS administrators must be members of DFS administrators must be

9 of 56 Tuesday 01 February 2011 12:47 PM

DFS Client and Root Server Architecture

DFS-Related Architecture on Domain Controllers

10 of 56 Tuesday 01 February 2011 12:47 PM

The following tables describe the components of the DFS architecture.

11 of 56 Tuesday 01 February 2011 12:47 PM

12 of 56 Tuesday 01 February 2011 12:47 PM

DFS Physical Structures and Caches

DFS Physical Structures and Caches

13 of 56 Tuesday 01 February 2011 12:47 PM

DFS Physical Structures and Caches on Domain Controllers