Problem Mapping network drives from Windows 7 to Windows Server 2008 R2


  • This is a long running thread with many readers and I am hoping someone here can offer a solution to what seems to be a simple problem.

    But I have posted this on many forums and no one has found a solution.  So I will try to cut to the chase and give only the facts.

    We have an office that runs Server 2008R2 in order to support a SQL database program which is accessed by the Users either when they are inside on the same network or outside using a VPN.  Before I explain the problem let me say that we ran Server 2003 and Server 2008 R1 for years with the same program and never had a problem

    The outside users can connect the VPN and they can run the SQL database program with no problem but some of them cannot map a drive letter to the network resource (folder) that contains the data needed by the database program.  This failure does not ALWAYS occur.  It seems to be related to the ISP providing internet access in some way.  The same user can drive a few blocks away to a HOTSPOT and connect and map the drive fine. In other cases they can tether their cell-phone and use it to map just fine.  But in the locations that won’t work, they will NOT work.  Not ever.

    I believe this to be related in some way to certain ports being filtered or blocked handled by the ISP but the ISP's say it isn’t them (whether it is or not)  so I get no help there.  The OLD versions of Server never had the problem so whatever it is, it only became a problem in Server 2008 R2  .  R1 worked with no issues.  Something changed in the way a drive is mapped from Server 2008 R1 to Server 2008 R2 and whatever it is, it is an essential factor.  When it will not connect, there is NO setting that I have found that will make it connect on either the User’s system or the Server System.

    I was wondering if anyone had ever experienced this and more importantly if they had any solution short of my re-installing the OLD 2008 R1 Server just to hold the data files.  I am not even sure I can do that, the SQL database may require the files to be located physically on the same system it is running on.

    I hate to "downgrade" in order to solve a problem like this but the people who need access are not willing to go out and buy cellular modems just to be able to connect to this database.  And the issue is NOT in the connection, the issue is in the DRIVE mapping.  It can’t be a permissions thing because the same person CAN map a drive if they use a different ISP to connect to the Internet

    One ISP that several of our people use for Internet access does state on their website that they block or filter ports 445 and ports 135-139. I think i heard somewhere that port 445 was just added in Server R2 as a part of the security for drive mapping and I wondered if it was just this one port that is causing all the problems?

    ANY and ALL help appreciated but please read all of what I have written.  This is NOT a connection issue.  the VPN connects fine, the SQL program will run fine and I can ping the IP and I have tried mapping both using the IP and the FQDN for the server.  This is a Network Drive Mapping Issue and it has nothing to do with "permissions".   We do not have a "Domain";  this is just a simple Workgroup.   So if someone knows the "trick" to make this work, I would be very grateful to have it

    But these are the usual answers I get and they are all wrong as I have taken the time to prove each to not be the solution.  Someone here mentioned using the XP Emulation ability of Windows 7 to map the drive under XP?  Maybe?  I have not tried that but if it works, it will be because XP used different ports for allowing a drive to be mapped and accessed.

    Obviously SQL uses some port that it can get through even when the port needed to map the SQL drive is not allowed as the database runs even if the mapped drive wont connect.  It just can’t show you the data because it looks for it on the ”mapped network drive” that isn’t there.


    Wednesday, January 16, 2013 1:15 AM


All replies

  • That sounds like a nasty problem.  The only thing I know may have
    changed is the authentication level for file shares, and possibly the
    VPN server itself.
    What kind of VPN server are you using, and do you have it set to
    encrypt all traffic, or not.  An ISP should not be able to block
    anything inside a VPN, but I suppose their packet shapers might be
    able to get to that level and probably where it doesn't work is where
    they have a certain type of packet shaper.
    You should be able to set R2 to use the same authentication as R1
    using a group policy, an that might help.  Also using a different VPN
    server might make a difference.
    Are there any events in the event viewer on the client or server?  You
    might try setting both the server and client to audit logon event
    failures to see where the problem might be.
    I doubt if XP Mode will make any difference for you, but it might be
    worth a try just so you can localize where the problem might be.

    Bob Comer - Microsoft MVP Virtual Machine
    Wednesday, January 16, 2013 2:41 PM
  • Hi,

    The proper forum to solve your issue should be Windows Server Networking Support forum. I would like suggest you redirect the issue to that forum for further help.


    Thanks for your understanding.

    TechNet Community Support

    Thursday, January 17, 2013 3:49 AM
  • Not sure if this will help..just throwing out there, as I have a different but related issue. 

    I have mapped drives that are pushed through GPO and they connect at first through VPN but for reasons unknown they disappear on some and some users had issues where it wouldn't even map to it or find the host. 

    The temp solution for us was to add the internal IP and server address to the Host file (C:\windows\systems32\drivers\etc\hosts) so that it resolves the internal system when on a VPN connection. And I must admit sometimes that isn't enough which is why I am looking for a better solution. Just thought I would mention it as the solution has worked for some but you always get that odd ball PC that doesn't want to play nice.


    • Edited by Incubeus Tuesday, January 29, 2013 2:14 PM spelling and added some
    Tuesday, January 29, 2013 2:12 PM