How DFS Works

 

Applies To: Windows Server 2003 with SP2, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1

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?”.

For information about DFS on later versions of Windows Server, see DFS Namespaces and DFS Replication Overview.

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 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.”

• 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

Platform	Act As DFS Clients?	Act As a Root Server?	Act As a Link Target?
Microsoft Windows Server 2003, Web Edition	Yes	Yes Can host one stand-alone namespace or one domain-based namespace per server.	Yes
Windows Server 2003, Standard Edition	Yes	Yes Can host one stand-alone namespace or one domain-based namespace per server.	Yes
Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition	Yes	Yes Can host multiple stand-alone namespaces and multiple domain-based namespaces per server.	Yes
Windows Storage Server 2003	Yes	Yes Can host multiple stand-alone namespaces and multiple domain-based namespaces per server.	Yes
Windows XP	Yes	No	Yes
Windows Preinstallation Environment (WinPE)	Yes Can access stand-alone namespaces but cannot access domain-based namespaces.	No	No
Windows 2000 Server family	Yes	Yes Can host one stand-alone namespace or domain-based namespace per server.	Yes
Windows 2000 Professional	Yes	No	Yes
Windows NT Server 4.0 with Service Pack 6a	Yes	Yes Can host a single stand-alone namespace per server.	Yes
Windows NT Workstation 4.0 with Service Pack 6a	Yes	No	Yes
Windows 98	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.	No	Yes

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.

Characteristics of Namespace Types

The following table provides a general overview of the differences between domain-based and stand-alone namespaces.

Characteristics of Namespace Types

Characteristic	Domain-based	Stand-Alone
Path to namespace	\\NetbiosDomainName\RootName \\DNSDomainName\RootName	\\ServerName\RootName
Where DFS metadata is stored	In Active Directory. Also stored in a memory cache on the root server.	In the registry of the root server. Also stored in a memory cache on the root server.
Group memberships required to create or delete namespaces	DFS administrators must be members of the Domain Admins group to create or delete domain-based namespaces or have delegated permissions to the DFS-Container object in Active Directory.	DFS administrators must be members of the local Administrators group on the local server to create or delete stand-alone namespaces.
Group memberships required to administer namespaces	DFS administrators must be members of the local Administrators group on each of the root servers to add or delete links, link targets, roots, and root targets.*	DFS administrators must be members of the local Administrators group on the local server to add or delete links, link targets, roots, and root targets.
DFS namespace size restrictions	We recommend that you keep the size of the DFS object in Active Directory below 5 megabytes (MB) by using fewer than 5,000 links in domain-based namespaces.	The largest recommended namespace size for a stand-alone namespace is 50,000 links.
Supported methods to ensure DFS root availability	Create multiple root targets in the same domain.	Create a stand-alone root on a server cluster.
Supported methods to ensure link target availability	Create multiple link targets and replicate files by using one of the following methods: - Enabling FRS - Copying files manually or by using scripts - Using another replication tool	Create multiple link targets and replicate files by using one of the following methods: - Copying files manually or by using scripts - Using another replication tool

*To ensure that the administrator can reliably administer the namespace, we recommend that the administrator be a member of the local Administrators group on each root server. If a DFS administration tool sends a request to a root server on which the administrator is not a member of the local Administrators group, the request will fail. If the administrator is a member of the local Administrators group on some but not all root servers, the 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 System snap-in (Dfsgui.msc and Dfsui.dll)	The graphical user interface tool used for administering DFS namespaces. By default, the Distributed File System snap-in (Dfsgui.msc) is installed on servers running Windows Server 2003. You can administer namespaces remotely from a 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 System command-line utility (Dfscmd.exe)	The DFS command-line tool used to perform basic DFS tasks, such as configuring DFS roots, links, and targets. Also supports scripting. Dfscmd.exe is available on all servers running a member of the Windows Server 2003 family.
Distributed File System utility (Dfsutil.exe)	The DFS command-line tool used to perform basic and advanced DFS tasks, such as enabling root scalability mode, least expensive target selection, and same-site 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”

Component	Description
Domain cache	Contains the domain name referrals and domain controller referrals that are stored in memory on each client computer. The domain cache stores NetBIOS and DNS domain names for the local domain, all trusted domains in the forest, domains in trusted forests, and the mappings of the domain names to the domain controllers. The domain cache (also called SPC cache) is maintained in Mup.sys.
I/O Manager	Plays a role in handling the file I/O in redirecting the UNC paths to Mup.sys. I/O Manager is part of the core kernel (Ntoskrnl.exe) of the operating system.
Mrxsmb.sys	Handles communications to the root servers, domain controllers, and 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 Mrxdav.sys	The redirectors for Netware and Web Distributed Authoring and Versioning (WebDAV), respectively.
Referral cache	Stores the root referrals and link referrals received by the client when it accesses a namespace. The referral cache (also known as the PKT cache) is maintained in Mup.sys.
Workstation service (Wkssvc.dll)	Sends domain controller information and domain names to Mup.sys. Mup.sys uses this information to generate the referrals in the client’s domain cache. This service is also a component of the Server Message Block (SMB) client. Also manages the loading and unloading of the Mrxsmb.sys.

Components of the DFS Root Server and Domain Controller Architecture Described in the Figure “DFS-Related Architecture on Domain Controllers”

Component	Description
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 referral cache and site caches	The in-memory copies of domain-based root referrals and site information that enable Dfssvc.exe to perform fast lookups. These caches are described in the next section.
Registry	Where the DFS metadata is stored for 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.

DFS Physical Structures and Caches

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

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.”

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 Registry Entries

DFS supports several registry entries for configuring DFS behavior on root servers. The DFS service registry entries are located in the registry under the following subkeys:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters

For a list of these DFS registry entries, see “DFS Tools and Settings.”

DFS Metadata Cache

The DFS metadata cache on root servers contains information about the root, root targets, links, link targets, and settings defined in a namespace. For 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

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.

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]  
        [-dc-04.contoso.com]  
        [-dc-03.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 domain-based namespace.

Target list

The target list contains the root targets or link targets that correspond to the path specified in Entry. Targets are listed in order, according to the target selection method configured for the root or link. A target marked Active indicates that the client either has used this target or will use this target the next time the user tries to access this portion of the namespace.

DFS Processes and Interactions

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

Processes Related to Referrals

The referral process is the process by which domain controllers and root servers refer clients to different targets in the namespace. Numerous processes take place so that DFS can provide an optimal list of targets in the referral. These processes are described in the following sections:

• See “How Site Discovery Works” for information about how DFS determines the sites to which clients and targets belong.

• See “How Target Selection Works” for information about the logic that DFS uses to sort targets in a referral. There are three target selection methods: default target selection, 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.

In these situations, DFS uses the default target selection method. For more information about site costs, see “DNS Support for Active Directory Technical Reference.”

Situations in Which Clients Access Unexpected Targets

Even when least expensive or 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.

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 domain-based namespace.

3. The domain controller returns a list of root targets defined for the requested namespace.

4. The client selects the first root target in the referral and sends a query to the root server for the requested link.

5. The root server constructs a list of link targets in the referral. The order in which the link targets are sorted depends on the target selection method. The root server sends the referral to the client.

6. The client establishes a connection to the first link target in the list.

Simplified Referral Process for 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 domain-based namespace.

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.

Note In the above list, "unavailable" indicates the operating system is down or the network does not work. However, this section does not discuss the scenario in which the DFS namespace service is not started.

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 Cached	Referral Type	Default Expiration Time	Where Expiration Time Is Stored
DFS clients	Stand-alone root referral	5 minutes	Time to Live of root (configured using the DFS tools)
DFS clients	Link referral	30 minutes	Time to Live of link (configured using the DFS tools)

For DFS clients that are not running Windows XP with Service Pack 2 (SP2) or Windows 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

Where Referrals Are Cached	Referral Type	Default Expiration Time	Where Expiration Time Is Stored
Domain controller	Domain-based root referral	15 minutes	RootReferralTimeoutInSeconds registry entry
Root server	Domain-based root referral	15 minutes	RootReferralTimeoutInSeconds registry entry
DFS client	Domain-based root referral	5 minutes	Time to Live of root (configured using the DFS tools)
DFS client	Link referral	30 minutes	Time to Live of link (configured using the DFS tools)

Based on the default values in the previous table, domain controllers and root servers can provide updated 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 check mark	All targets are reachable on the network and their referrals are enabled.
Folder icon with yellow exclamation point	Indicates one of the following conditions: - All corresponding targets are reachable on the network but one or more targets has its referral disabled. - Some corresponding targets are not reachable on the network.
Folder icon with red X	Indicates one of the following conditions - All corresponding targets are not reachable on the network. - All corresponding targets have their referrals disabled. - The root path is unreachable.

DFS Status Flags for Targets

Target	Description
Folder icon (yellow)	No known status.
Folder icon with green check mark	Target is reachable on the network.
Folder icon with red X	Target is not reachable on the network.

How DFS Works on Server Clusters

A server cluster is a group of individual computer systems, called nodes, working together cooperatively to provide increased computing power and continuous availability of 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.”

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 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  
SMB: DFS Number of Expanded Names = 0 (0x0)  
  

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: Transaction parameters  
SMB: DFS Max Referral Level = 3 (0x3)  
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 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 = 3 (0x3)  
SMB: DFS Expanded Name =\Dc-01.contoso.com  
SMB: DFS Expanded Name =\Dc-03.contoso.com  
SMB: DFS Expanded Name =\Dc-02.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: Transaction parameters  
SMB: DFS Max Referral Level = 3 (0x3)  
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 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 =\  
SMB: DFS Number of Expanded Names = 3 (0x3)  
SMB: DFS Expanded Name =\Dc-01  
SMB: DFS Expanded Name =\Dc-03  
SMB: DFS Expanded Name =\Dc-02  
  

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: Transaction parameters  
SMB: DFS Max Referral Level = 3 (0x3)  
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 Transaction data  
SMB: DFS Version 3 Referral  
SMB: DFS Version Number = 3 (0x3)  
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  
  
SMB: DFS Version 3 Referral  
SMB: DFS Version Number = 3 (0x3)  
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-02\public  
SMB: Servicesite GUID = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  
SMB: DFS Version 3 Referral  
SMB: DFS Version Number = 3 (0x3)  
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-01\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: Transaction parameters  
SMB: DFS Max Referral Level = 3 (0x3)  
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 Transaction data  
SMB: DFS Version 3 Referral  
SMB: DFS Version Number = 3 (0x3)  
SMB: DFS Server Type = Unknown Server Type  
SMB: DFS TimeToLive = 1800 (0x708)  
SMB: DFS Filename =\contoso.com\public\software  
SMB: DFS 8.3 Filename =\contoso.com\public\software  
SMB: DFS Sharename =\noam-fs-1\apps  
SMB: Servicesite GUID = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  
SMB: DFS Version 3 Referral  
SMB: DFS Version Number = 3 (0x3)  
SMB: DFS Server Type = Unknown Server Type  
SMB: DFS TimeToLive = 1800 (0x708)  
SMB: DFS Filename =\contoso.com\public\software  
SMB: DFS 8.3 Filename =\contoso.com\public\software  
SMB: DFS Sharename =\noam-fs-3\apps  
SMB: Servicesite GUID = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  
SMB: DFS Version 3 Referral  
SMB: DFS Version Number = 3 (0x3)  
SMB: DFS Server Type = Unknown Server Type  
SMB: DFS TimeToLive = 1800 (0x708)  
SMB: DFS Filename =\contoso.com\public\software  
SMB: DFS 8.3 Filename =\contoso.com\public\software  
SMB: DFS Sharename =\noam-fs-2\apps  
SMB: Servicesite GUID = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  

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.

Network Ports Used by DFS

DFS uses the following network ports.

Network Ports Used by DFS

Service Name	Relevant Computers	UDP	TCP
NetBIOS Name Service	Domain controllers; root servers that are not domain controllers; servers acting as link targets; client computers acting as link targets	137	137
NetBIOS Datagram Service	Domain controllers; root servers that are not domain controllers; servers acting as link targets; client computers acting as link targets	138
NetBIOS Session Service	Domain controllers; root servers that are not domain controllers; servers acting as link targets; client computers acting as link targets		139
LDAP Server	Domain controllers	389	389
Remote Procedure Call (RPC) endpoint mapper	Domain controllers		135
Server Message Block (SMB)	Domain controllers; root servers that are not domain controllers; servers acting as link targets; client computers acting as link targets	445	445

Related Information

The following resources contain additional information that is relevant to this section.

• Active Directory Replication Topology Technical Reference

• DNS Support for Active Directory Technical Reference

• FRS Technical Reference

• Server Clusters Technical Reference