| Author |
Topic  |
|
|
craigroyston
Here To Stay
 
USA
124 Posts
Status: offline |
Posted - 06/09/2010 : 2:30:22 PM
|
I have two brand new 2008 R2 file servers (Filesvr1 and Filesvr2)that I am trying to deploy, and was planning on using DFS for all of our shared folders on the network.
I have setup and configured 2 DFS namespaces in Domain Windows 2000 Server Mode.
\\mydomain.com\users \\mydomain.com\files
Filesvr1 and Filesvr2 are the namespace servers for both namespaces, and they also will host almost all of the shares\targets for the DFS.
Internally it all works fine, I can browse either namespace with no problems using both \\mydomain\namespace or \\mydomain.com\namespace, drive mappings to the dfs shares are working, and all seems well.
I brought home a company laptop (XP) to test accessing the DFS over a VPN connection and it does not work. Error Message says :
Network Path Not Found
I am able to access shares using \\filesvr1 or \\filesvr2 and all of our other servers but I cannot when using \\mydomain.com\namespace. I cannot access sysvol share either. If I input my internal DNS server into the TCP/IP settings for DNS it does work, but this will not work as a solution. This does prove it's a name resolution issue right?
Did we shoot ourselves in the foot using .com for our internal dns domain name? Or can this be fixed? I'd really like to get DFS working but I'm running out of time and will need to scrap it if I cant get it working perfectly for our traveling and home users.
Any ideas??? Thanks!
|
|
|
craigroyston
Here To Stay
 
USA
124 Posts
Status: offline |
Posted - 06/09/2010 : 2:43:07 PM
|
| I failed to mention we use a Microsoft RRAS PPTP VPN running on a Windows 2003 domain controller. |
 |
|
|
wkasdo
Administrator
    
Netherlands
7403 Posts
Status: offline |
Posted - 06/09/2010 : 3:30:27 PM
|
> If I input my internal DNS server into the TCP/IP settings for DNS it does work, but this will not work as a solution. This does prove it's a name resolution issue right?
Correct, naming resolution problem. You need to make sure that the client uses an internal DNS once the VPN is online. That internal DNS should resolve external addresses as well, if you want the remote client to use the internet. |
Make it as simple as you can, but not simpler -- Albert Einstein |
 |
|
|
craigroyston
Here To Stay
 
USA
124 Posts
Status: offline |
Posted - 06/09/2010 : 4:00:22 PM
|
Thanks for the reply, Is there a way to automatically have the clients use the internal DNS servers once the VPN is online? Having these people input it manually into the TCP\IP properties won't go over well. |
 |
|
|
wkasdo
Administrator
    
Netherlands
7403 Posts
Status: offline |
Posted - 06/09/2010 : 4:03:12 PM
|
| I'd have to start up a lab to answer this exactly, but I'd be looking for DHCP settings for RAS. They need to hand out a reference to the internal DNS. Sorry that I cannot be more precise. |
Make it as simple as you can, but not simpler -- Albert Einstein |
 |
|
|
craigroyston
Here To Stay
 
USA
124 Posts
Status: offline |
Posted - 06/09/2010 : 4:25:07 PM
|
No problem, I appreciate the replies. I do get my internal DNS servers from DHCP for the PPTP connection, ipconfig /all shows this, but it seems that it still uses the DNS server for the NIC first by default. An nslookup always returns the DNS server assigned to my NIC. Ill do some testing and research to see if I can make it work the way I want.
Does anyone else use a similar setup for DFS?
|
 |
|
|
craigroyston
Here To Stay
 
USA
124 Posts
Status: offline |
Posted - 06/09/2010 : 4:46:19 PM
|
Found this:
http://support.microsoft.com/kb/311218
And changing the binding order did work! Now I just need to figure out an easier way to make this work or make this change on everyone's PC without having to go into everyone's registry, that would be a pain. |
 |
|
|
craigroyston
Here To Stay
 
USA
124 Posts
Status: offline |
|
|
wkasdo
Administrator
    
Netherlands
7403 Posts
Status: offline |
Posted - 06/11/2010 : 02:55:40 AM
|
| Good one, Craig! |
Make it as simple as you can, but not simpler -- Albert Einstein |
 |
|
|
remko.de.koning
Seasoned But Casual Onlooker

Netherlands
58 Posts
Status: offline |
Posted - 05/31/2012 : 04:44:50 AM
|
Hi guys, it has been a while since I have been here, but I guess I need the experts on this :-)
I found this "old" topic up and it seems I have a similar but slightly different problem.
Just recently implemented a DFS folder structure in our organisation as this makes browsing for the users easy. Also from an administrator point of view it makes it easier to move stuff around without interrupting the users. This works excellent when working in the office. However, when working over a VPN connection odd things start to happen which I cannot really explain yet.
We have a (persistant) Network drive mapped for every user pointing to drive letter N:\ mapping to \\domain\dfs\data
When I connect over VPN accessing the drive letter is very erratic. Most of the times it returns an "Location is not available" error. Sometimes it connects just fine.
When I connect manually to \\domain\dfs\data it works fine. Also connecting directly to the server \\servername\data works fine.
Basically it is the drive mapping to "n:\" that is giving the problems. As long as I point the drive mapping to "\\servername\data" instead of the DFS notation it works fine but I guess that defeats the purpose of using DFS.
So what are my options here?
We are using: Win7 x32 enterprise edition. Server 2003 x32 domain Server x64 2008R2 fileserver. Cisco VPN client version 5.0.06.0160
DNS lookups work ok. The query "our domain" in nslookup returns our Domain controllers so I guess the whole binding order stuff as discussed in this topic is not the source of my problem.
Any thoughts on this are welcome.
Remko
|
 |
|
|
wkasdo
Administrator
    
Netherlands
7403 Posts
Status: offline |
Posted - 05/31/2012 : 05:07:40 AM
|
Welcome back, Remko!
In your setup you have a 3-layer DFS:
1. Domain Controllers 2. DFS root servers 3. DFS targets (fileservers)
Are there perhaps firewall limitations preventing you from getting at some DFS root servers? If so, you may need to make sure you have your site/subnet mapping correct.
> Most of the times it returns an "Location is not available" error.
I wonder if you have a VPN startup problem. If the VPN stack signals to Windows that it's ready before full connectivity is established, you would get this problem. I expect a netlogon trace on the client to give additional information in that case.
As for troubleshooting: nothing beats a wireshark/netmon trace to see the DFS referrals. |
Make it as simple as you can, but not simpler -- Albert Einstein |
 |
|
|
remko.de.koning
Seasoned But Casual Onlooker

Netherlands
58 Posts
Status: offline |
Posted - 05/31/2012 : 05:16:36 AM
|
Hey thanks wkasdo,
It's feels good to be back :-)
Good idea to use wireshark. Hopefully this reveals something as I am completely puzzled by this. VPN traffic flows through our ASA5510 but should not be firewalled. The only thing is that the connecting PC is in a different (VPN) subnet than the servers it is connecting to. Odd thing is that when I connect directly to my DFS it works just fine. I guess this rules out any firewall issues It is just the drive mapping that is causing the problems.
The DFS root servers are also my domain controllers (redundant). The DFS target are various fileservers (Win2003 and Win2008)
I will go ahead and test with Wireshark and see if this reveals anything.
Remko
|
 |
|
|
remko.de.koning
Seasoned But Casual Onlooker

Netherlands
58 Posts
Status: offline |
Posted - 05/31/2012 : 05:49:53 AM
|
It is difficult to interpret the wireshark logs but I can see connections being made to my domain controller returning the DFS paths and server names.
There is definately some communication going on. Strange thing I also noticed is that the homefolder mapped to drive "X:\" works flawlessly. Creating a file on the X:\ ,which is actually mapping to \\domain\dfs\users\homefolders\user , shows up instantly on my server.
Isn't this the same thing??? Only difference is that the X:\ drive is mapped via Active Directory and the N:\ drive is mapped via a login script.
This brings me closer to a solution though..
Mapping an other drive letter to the same DFS share works without any problems. I looks like the "old" persistant drive mapping is the source of my problems. I have no clue yet why though. :-)
Remko |
 |
|
| |
Topic  |
|