locked
DFS Target Issue RRS feed

  • Question

  • All,

    I have a 5 site domain, with DFS Namespace and Replication enabled for approximately four shares.
    Each site has a local file server, with the DFS shares located on each of the local file servers.
    For a long time, this was working without issue ... where users in each site would map directly to the local DFS share on their local DFS File Server.
    They were doing this based on the AD site they were in.

    Now, users in NY are mapping to DFS shares in Toronto, and users in Toronto are mapping to DFS Shares in Los Angeles.
    It seems like out of nowhere, users are mapping to the wrong DFS Targets.

    How do I troubleshoot this issue? All my Domain Controllers seem to be in good health.
    I am having a difficult time with troubleshooting this issue.

    Thanks,



    Systems Admin
    Tuesday, December 15, 2009 4:30 PM

Answers

  •    Hello Bree08,

     

    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.

     

    If the AD site/subnet/IP address is well binding, I think you can consider to enable DFS Insite option 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

     

    Please read this KB article, which may provide some helpful information on troubleshooting your issue.

     

    Users Are Accessing a DFS Root Replica in a Remote Site

    http://support.microsoft.com/default.aspx/kb/282071

     

    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

     

    According to my research, we have 2 methods know which DFS member server a specific user actually connect to.

     

    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.

     

    Hope this can be helpful.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by David Shen Wednesday, December 16, 2009 1:18 PM
    • Marked as answer by David Shen Friday, December 18, 2009 3:22 PM
    Wednesday, December 16, 2009 4:24 AM

All replies

  •    Hello Bree08,

     

    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.

     

    If the AD site/subnet/IP address is well binding, I think you can consider to enable DFS Insite option 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

     

    Please read this KB article, which may provide some helpful information on troubleshooting your issue.

     

    Users Are Accessing a DFS Root Replica in a Remote Site

    http://support.microsoft.com/default.aspx/kb/282071

     

    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

     

    According to my research, we have 2 methods know which DFS member server a specific user actually connect to.

     

    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.

     

    Hope this can be helpful.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by David Shen Wednesday, December 16, 2009 1:18 PM
    • Marked as answer by David Shen Friday, December 18, 2009 3:22 PM
    Wednesday, December 16, 2009 4:24 AM
  • Hi Bree08,

    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.

     

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, December 18, 2009 6:54 AM