DFS share works fine over site-to-site link but not VPN

rockadoodooagain

Thanks for that - very comprehensive!  I'll figure out how to act on your advice over the next day or so.

Going a bit slow on this - jammed with a zillion competing demands.

Haven't forgotten and will check it in the coming days.

Cheers.

So far have confirmed that NetBIOS is being forwarded.
What's weird is that nslookup on the namespace root of DFS gives the right IP addresses but pinging fails.
ie. nslookup \\dfs.local returns the IP addresses of all servers included in our DFS scheme.
I can ping the remote machines themselves but ping \\dfs.local fails

I tried adding an entry to the "hosts" file on the client machine, hard-coding dfs.local to a particular server but even here I can't ping the UNC name.

Still a bit of a newbie at all this and our third-party sysadmin remains as confused as we are.  Still thinking about this so sorry for slow pace of replies.

Netbios broadcasts are not routeable, you need wins to support netbios over a VPN tunnel.

This includes Netbios over SMB and netbios over TCP. That's both methods used to send Browser list and DFS shares.

Another option is to allow Site to Site replication of your DFS shares. Replication services, (FRS or DFSR) will replicate using DNS. DNS is a routeable protocol and will propogate over a VPN connection. This is why you can ping computers via host name but not computer name.

Hi ChiefIT

Thanks for the response.  It's going to take me a while to understand it!

Well, let's get you fixed, then I will answer any questions you have on DFS from site to site:

To fix you, I need to ask a few questions so I am not assuming things:

1) Do you have a Domain Controller at each site, or are you trying to get DFS shares directly from your main site? If you have DCs at each site, are both global catalog servers and are you showing signs of replication problems?

2) Do you have WINS set up?

3) How many computers at your remote site?

4) Is this for group Sysvol/Netlogon shares or some other network share?

Excellent.  Much appreciated.

1. Domain Controller is at head office.  I'm trying to connect from a branch office that does not currently have a Domain Controller.  In due course there will be a Domain Controller at the branch office too, but that's only once this simpler set up is working.

2. I don't really understand what WINS is yet so don't know/not sure.  I'll check into this.  To be honest I hve not yet grasped the difference between DNS, WINS, NetBIOS, UNC.  They all seem to do the different versions of the same thing!

3. Remote site has just one PC behind a Netgear firewall.  Nothing complicated.  I connect to head office using the IPSec VPN built into Windows Server 2003 E2.

4. The share in question is a folder of company-wide documents.  So for end-users not sysadmins or technies.

Sorry just realised I didn't answer 4 properly, so....

4. it does happen to be the same DFS namespace \\mybiz.local as for Netlogon.  We are adding shares to the same namespace for other purposes.

One computer, huh?

This is a pretty easy fix. But, you are going to have to remember we did this. It will interfere with WINS in the future.

First, let's straighten out a little confusion:

UNC path stands for Universal Naming Convention path. It can use multiple protocols to do the same thing.

example:
\\servername\share (uses the netbios name to map to a share)

\\servername.domain.name\share (uses the fully qualified domain name, (also refered to as the host name), of the share)

\\xxx.xxx.xxx.xxx\share (uses the IP to map the share, also known as ARP (address resolution protocol))

It's called Universal because of its compatibility to use either netbios, DNS or IP to map to a share.
___________________________________________________________________

DNS is simply like a phone book that uses the fully qualified domain name, (also commonly referred to as a host name). This phone book changes the host name to an IP and visa versa. Also included in this phone book are SRV records and a bunch of other records that specifically point the way to your domain controllers, mail servers, ect... So, it is like the yellow pages and government pages in your phone book.

For more information on about DNS, I wrote an article about it with links to different types of DNS records and how a DNS query is propogated over the network. Read this at your leisure. For now it is not important to fixing your problem.
http://www.experts-exchange.com/articles/Networking/Protocols/DNS/DNS-Troubleshooting-made-easy.html

___________________________________________________________________

WINS is another form of phone book. It converts the netbios name, also referred to as the computername or LMHOST name (lan manager host name)) to an IP address and visa versa.
WINS was suppose to be replaced by DNS, However the netbios broadcasts were pretty usefull.

When logging onto a computer with netbios enabled, it will send out a broadcast message that basically says "I am here" and "this is my OS". All nodes on the LAN will pick this up and use this information to determine the site's master browser. If this master browser is a Domain controller, it will be elected a Domain master browser, by default.

However, without WINS, the local broadcasts only stay within the local SITE. WINS is another phone book that will share, between sites, its phone list.

By default, WINS is not enabled. You have to manually install it and configure it, much like you have to install DNS and enable it on a domain computer.

File and printer sharing as well as the browselist, (that populates the list of computers in "My Network Places" is used by netbios broadcasts. It does this by two simultaneous ways:

1) Netbios over TCP/IP
and
2) Netbios over SMB



AND HERE IS YOUR PROBLEM:

Since you don't have a WINS server configured, your netbios broadcasts are not reaching remote site computer. It would be equal but not related to not having a DNS server phone book that provides the IP to your host name. In other words, you don't have the phone book that provides an IP to your computer name.

HERE IS YOUR FIX for this ONE computer:
With only one computer at the remote site, you can create an LMHOST record between your Domain server and your remote comptuer and enable LMHOST lookup on both the DC and the remote computer on the NIC configuration>>TCP/IP properties>>WINS tab.

That LMhost record can be found on both machines at:
C:\Windows\system32\drivers\ect\LMHost
You can edit that file using NOTEPAD or WORDPAD.

Add both your domain server and your remote computer on both machines.

HERE IS YOUR FIX WHEN YOU GET A REMOTE DC:
Make the DC a global catalog server and use DNS to REPLICATE your DFS shares from one site to the other. Replication doesn't need netbios or use WINS, it uses DNS.

DNS and IP mapping of DFS shares are routeable, while netbios mapping is not.

Wow!  Thanks for that!  Let me digest it and get back to you.

Hi ChiefIT

I tried adding the following to the LMHosts.sam file on both machines

192.168.1.199    <<our domain>>.local
192.168.1.199    <<primary domain controller>>
192.168.40.4     <<machine in branch office>>

Is that correct?

If so when I try to ping \\<<our domain>>.local I get
"Ping request could not find host \\<<our domain>>.local. Please check the name and try again."

The ping request did however work without the leading double back-slash i.e. ping <<our domain>>.local

And obviously I have substituted the real machine and domain names instead of the dummies here in the angle-brackets.

Should I restart the VPN connection once I've edited the files maybe?

Unlike HOST files, you will want to use the computer name, (also recognized as the LMHOST name).

Don't use the Fully qualified domain name.

This should guide you through the LMHOST file edits:
http://technet.microsoft.com/en-us/library/cc977235.aspx

Furthermore:
File and print sharing needs to be enabled on both server and remote computer

Then, make sure Netbios over TCP/IP is enabled on the NIC, (NOT netbios over DHCP).

and make sure LMHOST lookup is enabled on the WINS tab of both server and remote computer's nics.

Once done, go to the command of the client and type:
NBTSTAT -RR

This is pushing my understanding, so I'll let you know I get on.

Thanks a million so far anyway.

Hi all
Thanks so much for your responses.  I've been swamped with other issues and have not forgotten this.  Having trouble coordinating with our third-party support people - no criticism of them, just too much to do.
I will definitely get around to this - also this topic is rather beyond my powers so I'm struggling a bit.
Cheers for your patience.  I'll be giving points to all who helped.

Further update on this.  We're actively considering implementing a new site-to-site link instead of a VPN.  That would make this query go away.  To that extent, I'm unable to close this query until the decision is made.  Sorry for that.

Hi all,
OK, we've gone for the new site-to-site link which will dispense with this issue as we already use it elsewhere in our WAN setup.
Does anyone have any suggestions as to how I should award points?
I want to thank all who contributed.
Matt