DFS not working over VPN RRS feed

  • Question

  • Dear all,

    I am migrating a DFS from a Windows Storage Server 2003 to a Windows Server 2008 R2. Everything went fine except one thing.

    I cannot access the DFS over the VPN.

    Internally everything works.

    Over VPN I get access the netlogon and sysvol folder but I get the message \\FQDN\DFSname not found after some time

    When the DFS was located on the Windows 2003 Server I could access it over VPN.

    So Browsing \\FQDN\DFSname does not work, ping to FQDN works, \\FQDN\ gives me sysvol and netlogon shares.

    Any ideas ?

    Kind regards,


    Friday, September 23, 2011 7:56 PM


All replies

  • Hello, what happen when you type in the direct server name \\Namespaceservername.domain.com\DFSname?
    Isaac Oben MCITP:EA, MCSE,MCC View my MCP Certifications
    Monday, September 26, 2011 3:39 PM
  • Hi Kenny,

    Is it a Windows Storage Server 2003 or 2003 R2?

    DFSR will not work in systems earlier than Windows 2003 R2 (they are using FRS for replication instead of DFSR).

    So if it is not a 2003 R2 server, you will need to manually recreate DFS structure.

    For further information please see:


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.
    Friday, September 30, 2011 4:57 AM
  • I do not think this answers the question.  Your assumption is that the problem is DFS-R (replication), when I believe the problem described is DFS-N (namespace). 

    I cannot get DFS namespace to work over a VPN connection, either, and the articles I've seen so far do not seem to help.

    http://support.microsoft.com/kb/311218 is one article, but my issues are with Windows 7 connecting to DFS namespace in a 2008 domain, whether the shares are on Server 2003 or 2008/2008 R2.

    Views expressed do not represent those of my employer.
    Saturday, November 12, 2011 4:14 PM
  • Just found my answer!

    I found my answer here:  http://blogs.imeta.co.uk/JCripps/archive/2009/01/29/591.aspx !  What is the registry edit list as number 1. 

    James Cripps writes:

    "Accessing DFS Shares when you have an Active PPTP VPN in Windows Vista

    I've been investigating a problem involving a user trying to access a local DFS share while having an active VPN connection to a remote network. I looked at all the usual things including a routing problem or a DNS issue without any success. I also tested this same setup on a Virtual Machine running Windows XP and there was no problem. This therefore narrowed it down to a change in functionality between Windows Vista and Windows XP. As I couldn't nail down the reason I decided to speak to Microsoft and see whether they could shed any light on the problem. It turns out that the problem is caused by the credential manager in Vista. When connected to a VPN the credentials that you are signed onto the VPN with are cached and then used to authenticate when accessing resources on the local or remote network. When trying to access a DFS share the cached VPN credentials are submitted and access is denied. The second part of the issue is that Windows Vista will not default back to your local domain credentials following this failure. There are two ways of resolving this problem

    1.) You can set the value of the following key to 1, Hkey_Local_Machine\System\CurrentControlSet\Control\Lsa\DisableDomainCreds. This turns off the caching off credentials and forces your domain credentials to be used when accessing resources on both the local and remote network.

    2.) The second option is to run cmdkey /delete /ras from a command prompt once you have connected to the vpn. This will clear the cached vpn credentials from credential manager.  This is not really a long term fix as once you disconnect and reconnect the vpn, the credentials will be cached again and you will be back to square one. "


    Views expressed do not represent those of my employer.
    Saturday, November 12, 2011 4:32 PM
  • NO, I do not think this is the correct solution. This is a FQDN issue. DFS doesn't use FQDN by default and when using a VPN this prevents you from accessing the shares for DFS.


    This is the correct solution but has to be done at time of creation. I ran into this problem and had to recreate by DFS system and start over to fix.

    (Temp Fix)

    The other solution is to map a direct link to the FQDN share itself only for VPN users. This defeats DFS for that user and there will be no fail over but they will get access over the VPN.


    Vote for Freedom - Vote to Protect our Country
    Tuesday, December 20, 2011 4:43 PM
  • I did not have to re-create my DFS-N infrastructure and was able to fix my problem, as I was getting an authentication error.  Your mileage may vary, but the proof is in the pudding.

    Now, might there be some side effect?  Perhaps, but I haven't found one yet. 

    I don't have anything against running after the FQDN issue, but it would not solve an authentication issue if Windows is trying to authenticate with an account that doesn't even exist in a local machine or AD database. 

    Views expressed do not represent those of my employer.
    Tuesday, December 20, 2011 5:10 PM
  • For anyone battling this- I just went through this with a client of mine.  Turned out that Win7 goes stupid when it's a 'slow link' VPN connection and tries to find a 'local' copy of the shares to work with- IF Offline Files are enabled.  Disabled offline files and everything worked perfectly.  Requires a reboot after the change.
    Monday, July 7, 2014 8:12 PM
  • This resolved it for me..

    My DFS Shares had a grey x on them with a Windows 10 Machine. I disabled Offline files and DFS shares were available again over PPTP VPN via RRAS 2008R2. 

    Just writing this reply even though it is an older post in case someone else struggles like I did to find this solution.


    Friday, July 15, 2016 12:11 PM
  • Another post well after the fact, but I wanted to reiterate what the previous two posters said.  In my environment we use DFS extensively along with folder redirection, and with folder redirection on you automatically get the joys of offline files.  This causes all sorts of gremlins when it comes to accessing DFS shares over VPN, and the problems can appear/disappear within a single VPN session depending on link speed, how often the sync center is checking for a connection, and what day of the week it is.

    But then, offline files have always been a bit touchy, and I think this is another example of how the underlying functions can monkey with tertiary systems.


    Thursday, June 22, 2017 3:01 PM