O’DFS Shares! Where Art Thou? – Part 1/3

Hello, this is Sabin and Shravan from the Microsoft Directory Services Support team. We are here today to discuss one of the common customer issues where they are seeing a delay in accessing a DFS Namespace. Some of these issues may manifest as affecting user’s experience on the machine where redirected folders may be slow to access or home drives don’t work. You may need to perform other troubleshooting which may bring you to the point where you are now left to troubleshoot slow DFS access. In essence, users can get to the shares but it’s slower than usual – in the order of minutes – resulting in lower productivity. Accessing “\\contoso.com\DFSroot\share” is slower as compared to directly accessing the closest DFS server using the UNC path, i.e. “\\DFSserver_netbios Name\share” or “\\DFSserver_fully qualified domain name\share”.

This is Blog 1 of the 3 part series:

- Part 1: Understanding the Referral Process for Domain-based Namespaces
- Part 2: Client experiencing slowness though DFS server accessed is in the same AD site
- Part 3: Client experiencing slowness due to DFS server accessed in a different AD site (out of site)

Part 1: Understanding the Referral Process for Domain-based Namespaces

Before we start trouble shooting slow access for DFS, it’s important to understand the following:

1. DFSN terminology
2. Referral process
3. Referral cache (viewed by dfsutil /pktinfo)
4. UseCount and Type

All these are described in details on the technet site under How DFS works? Understanding the DFS referral process is critical.

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 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.
5. 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$ (named pipe) of the root server in the context of the Current User in Vista clients (LocalSystem account in case of Pre-vista clients) and requests a link referral from the root server. The root server constructs a list of link targets in the referral depending on the target selection method and sends the referral list to the client.
6. The client establishes a connection to the first link target in the list.

NOTE: The Referrals in steps 3 and 5 above are grouped as a TARGETSET which indicates set of targets of equivalent cost. By default the servers are grouped in two TARGETSETS – in site and out of site.

All this is true if there are no referrals in the client cache. For a detailed understanding of this process (especially when client has cached the referral), please refer to Referral Process for Domain-Based Namespaces on TechNet site.

Lab Setup (Ex. 1) - Using Windows 2003 servers for DFS servers and Windows Vista as a client

The troubleshooting steps in this post are based on the following lab setup:

Distributed File System is as shown below

- Root - \\contoso.com\rootdfsn
  Root Targets –
                         - \\MS1\rootdfsn
                         - \\MS2\rootdfsn

- Link - \\contoso.com\rootdfsn\data
  Link targets –
                       - \\MS1\Data
                       - \\MS2\DataReplica

Snapshot of DFS Snap-in:

ROOT 

LINK

Tools Used:

1. DFSDiag (for Vista/2008 or later clients only) is part of the Remote Server Administration Tools (RSAT) for Windows Vista.
2. Netmon 3.3 can be downloaded from here.

Lab Setup (Ex.2) - Using Windows 2008 servers for DFS Namespace Servers and Windows Vista as a client

NOTE: While the troubleshooting steps in this whitepaper are based on the Lab setup ex. 1, the method to troubleshoot DFSN slow access in the lab setup ex. 2 configuration is very similar.

Distributed File System is as shown below:

- DFS Namespace - \\contoso.com\2008NS
  Namespace servers –
                   - \\2008-MS1\rootdfsn
                   - \\2008-MS2\rootdfsn
- Folder name - \\contoso.com\2008NS\Testfolder
  Folder targets –
                   - \\2008-MS1\2008DFSN
                   - \\2008-MS2\2008DFSN

Snapshot of DFS Management Snap-in:

NAMESPACE

FOLDER

WORKING SCENARIO ILLUSTRATION:

Following is a detailed analysis of the expected response from DFS where client is in the same site as the DFS server MS1 that is hosting the information. “DFSutil /PKTINFO” shows the following:

Entry: \contoso.com\rootdfsn
ShortEntry: \contoso.com\rootdfsn
Expires in 208 seconds
UseCount: 1 Type:0x81 ( REFERRAL_SVC DFS )
0:[\Ms1\rootdfsn] State:0x110 ( ACTIVE TARGETSET )
1:[\Ms2\rootdfsn] State:0x100
Entry: \Ms1\rootdfsn\Data
ShortEntry: \Ms1\rootdfsn\Data
Expires in 1729 seconds
UseCount: 1 Type:0x1 ( DFS )
0:[\Ms1\Data] State:0x110 ( ACTIVE TARGETSET )
1:[\Ms2\DataReplica] State:0x100

ANALYSIS:

1. User tries to access \\contoso.com\rootdfsn\Data.
2. Client sends a referral request for domain controllers in Contoso.com.
3. Client receives a list of domain controllers (DC1 and DC2) in the Contoso.com domain.

NOTE:

•  
  • The domain controllers in the client’s 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.

4. Client sends a query to the domain controller (DC2) to discover a list of root targets for the DFS Namespace

5. Domain controller DC2 returns a list of root targets (MS1 and MS2) as seen below

  0:[\Ms1\rootdfsn] State:0x110 (TARGETSET )
1:[\Ms2\rootdfsn] State:0x100

NOTE: MS1 and MS2 are listed under a single TARGETSET being servers in the same site/cost boundary.

6. Client selects the first root target (MS1) in the referral and sends a query for the requested DFS link (Data).

NOTE: PKTINFO indicates a successful connection to the referral returned by listing it as ACTIVE.

Entry: \contoso.com\rootdfsn
ShortEntry: \contoso.com\rootdfsn
Expires in 208 seconds
UseCount: 1 Type:0x81 ( REFERRAL_SVC DFS )
0:[\Ms1\rootdfsn] State:0x110 ( ACTIVE TARGETSET )
1:[\Ms2\rootdfsn] State:0x100

7. Root server MS1 constructs a list of link targets (Data and DataReplica)

0:[\Ms1\Data] State:0x110 (TARGETSET )
1:[\Ms2\DataReplica] State:0x100

8. The client establishes a connection to the first link target in the list (\MS1\Data).

NOTE: PKTINFO indicates a successful connection to the referral returned by listing it as ACTIVE.

Entry: \Ms1\rootdfsn\Data
ShortEntry: \Ms1\rootdfsn\Data
Expires in 1729 seconds
UseCount: 1 Type:0x1 ( DFS )
0:[\Ms1\Data] State:0x110 ( ACTIVE TARGETSET )
1:[\Ms2\DataReplica] State:0x100

Now that you have a better understanding of the working scenario, this will greatly help in understanding the problem cases where the expected response from DFS shares is slower. Be sure to check out the next part in the series on slow DFS access where we actually get into the troubleshooting steps in different scenarios. Ciao!

-Sabin Nair and Shravan Kumar