locked
DFS site connectivity has bad performance RRS feed

  • Question

  • Hello,
    I have a Windows Server 2008 AD configured and I also have DFS setup between our main office and a branch office. The two sites have a point-to-point VPN tunnel connecting them and all seems fine with DFS as far as replication. However, all branch users connect to a VPN concentrator at the main office when they are off-site. My AD has subnets configured between the two repective sites in AD Sites & Services. When folks connect to the concentrator I expect them to use the DFS member servers at the main office when browsing the DFS namespace. Unfortunately it seems like when they use the namespace it traverses the WAN link back to the branch office. Is there a way to verify what DFS member server they are attaching to, and is there some way to make sure they go to the nearest one?

    Thanks!
    Thursday, October 1, 2009 4:14 PM

Answers

  • Hello UWideUser,

     

    According to my research, if we want to know which DFS member server a specific user actually connect to, we can detect it by 2 methods.

     

    Method1.

     

    On DFS client computer, the user access your DFS namespace via \\domain\DFSrootname\DestinationDir  , when the Windows Explorer open the shared folder, you can right-click on any one of the folders under this DFS share, and you can check its properties, Select DFS tab, you may the Active status under Referral list. The Active indicates the users actual connect to server.

     

    Method2.

     

    If the client computer is Windows XP, we can install Windows Server 2003 Support tool on it, there is a DFSutil.exe within the support tools. We can use this utility to dump the DFS client cache to determine the connected share.

     

    first, please access the DFS namespace \\domain\DFSrootname\DestinationDir , then run the command

     

    dfsutil /pktinfo

     

    We can find the ACTIVE TARGETSET in the output to determine the result.

     

    For this issue, there are several situations in which DFS Clients Access Unexpected Targets, this may due to the AD sites configuration, and also related to the actual IP address the DFS client got. If the DFS client's IP address belongs to a subnet that is bind to remote site object in AD Site and Services, the DFS will consider to response the DFS client with the DFS referrals to the DFS member server that the client actually belongs to.

     

    Please take a look at the following reference:

     

    Reference: How DFS works (part: How Site Discovery Works and How Target Selection Works)

    http://technet.microsoft.com/en-us/library/cc782417.aspx

     

    To make DFS clients to the neareast on in its own site, we can use syntax Insite to make sure clients access only those replicas that are in the same site as the DFS client.

     

    dfsutil property insite <DfsPath>

     

    <DfsPath>: UNC path of a DFS namespace or DFS link.

     

    EXAMPLES:

    dfsutil property Insite \\contoso.com\DomainNamespace1  

    dfsutil property Insite \\srv1\StandaloneNamespace1

     

    Reference:

    Using the Windows Server 2008 DFSUTIL.EXE command line to manage DFS-Namespaces

    http://blogs.technet.com/josebda/archive/2009/05/01/using-the-windows-server-2008-dfsutil-exe-command-line-to-manage-dfs-namespaces.aspx

     

    Hope this can be helpful.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Tuesday, October 6, 2009 4:00 AM
    Friday, October 2, 2009 6:46 AM
  • Hi UWideUser,

    Thanks for the reply.

    To investigate why they are both pointing to the same place, please find 2 DFS clients (one in main office and the other in the remoter office) and capture outgoing network trace when the DFS clients access your DFS namespace.\

    Steps: Microsoft Network Monitor 3.3 to capture network trace

    Download: Microsoft Network Monitor 3.3
    http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en 

    a. Enable the Capture Filter "IPv4.Address == <ip of the client>" and start capture. 

    b. Restart one of clients to reproduce the issue. 

    c. Stop capture and save to *.cap file. 

    How to use Network Monitor to capture network traffic
    http://support.microsoft.com/kb/812953

    please take a screenshot at the properties tab of one of the share folders, and then  send the .cap file to me via tfwst@microsoft.com

    Note: Please specify the IP addresses of the DFS clients, Domain controller, and the DFS namespace server in your environment so that we can analyze the 2 network captured file to isoloate the cause.

    I appreciate your time and effort. Thanks.

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Tuesday, October 20, 2009 2:34 AM
    Saturday, October 17, 2009 2:45 AM

All replies

  • Hello UWideUser,

     

    According to my research, if we want to know which DFS member server a specific user actually connect to, we can detect it by 2 methods.

     

    Method1.

     

    On DFS client computer, the user access your DFS namespace via \\domain\DFSrootname\DestinationDir  , when the Windows Explorer open the shared folder, you can right-click on any one of the folders under this DFS share, and you can check its properties, Select DFS tab, you may the Active status under Referral list. The Active indicates the users actual connect to server.

     

    Method2.

     

    If the client computer is Windows XP, we can install Windows Server 2003 Support tool on it, there is a DFSutil.exe within the support tools. We can use this utility to dump the DFS client cache to determine the connected share.

     

    first, please access the DFS namespace \\domain\DFSrootname\DestinationDir , then run the command

     

    dfsutil /pktinfo

     

    We can find the ACTIVE TARGETSET in the output to determine the result.

     

    For this issue, there are several situations in which DFS Clients Access Unexpected Targets, this may due to the AD sites configuration, and also related to the actual IP address the DFS client got. If the DFS client's IP address belongs to a subnet that is bind to remote site object in AD Site and Services, the DFS will consider to response the DFS client with the DFS referrals to the DFS member server that the client actually belongs to.

     

    Please take a look at the following reference:

     

    Reference: How DFS works (part: How Site Discovery Works and How Target Selection Works)

    http://technet.microsoft.com/en-us/library/cc782417.aspx

     

    To make DFS clients to the neareast on in its own site, we can use syntax Insite to make sure clients access only those replicas that are in the same site as the DFS client.

     

    dfsutil property insite <DfsPath>

     

    <DfsPath>: UNC path of a DFS namespace or DFS link.

     

    EXAMPLES:

    dfsutil property Insite \\contoso.com\DomainNamespace1  

    dfsutil property Insite \\srv1\StandaloneNamespace1

     

    Reference:

    Using the Windows Server 2008 DFSUTIL.EXE command line to manage DFS-Namespaces

    http://blogs.technet.com/josebda/archive/2009/05/01/using-the-windows-server-2008-dfsutil-exe-command-line-to-manage-dfs-namespaces.aspx

     

    Hope this can be helpful.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Tuesday, October 6, 2009 4:00 AM
    Friday, October 2, 2009 6:46 AM
  • Hi,

    I want to see if the information provided was helpful. Please keep us posted on your progress and let us know if you have any additional questions or concerns.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, October 5, 2009 3:48 AM
  • Thank you so much for your help. I was able to see which server was in use by looking at the properties tab of one of the share folders. It just seems that DFS namespce performance sucks (at least in our environment). It is better to just use the local server name from the remote site; much quicker response. Not sure why this is since they are both pointing to the same place, but I assume it has to do with name resolution.
    Friday, October 16, 2009 6:32 PM
  • Hi UWideUser,

    Thanks for the reply.

    To investigate why they are both pointing to the same place, please find 2 DFS clients (one in main office and the other in the remoter office) and capture outgoing network trace when the DFS clients access your DFS namespace.\

    Steps: Microsoft Network Monitor 3.3 to capture network trace

    Download: Microsoft Network Monitor 3.3
    http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en 

    a. Enable the Capture Filter "IPv4.Address == <ip of the client>" and start capture. 

    b. Restart one of clients to reproduce the issue. 

    c. Stop capture and save to *.cap file. 

    How to use Network Monitor to capture network traffic
    http://support.microsoft.com/kb/812953

    please take a screenshot at the properties tab of one of the share folders, and then  send the .cap file to me via tfwst@microsoft.com

    Note: Please specify the IP addresses of the DFS clients, Domain controller, and the DFS namespace server in your environment so that we can analyze the 2 network captured file to isoloate the cause.

    I appreciate your time and effort. Thanks.

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Tuesday, October 20, 2009 2:34 AM
    Saturday, October 17, 2009 2:45 AM