I had a couple of helpdesk folks ask me recently why a DFS path stopped working.When attempting to access a share in that DFS root the user would get Network Path not Found. Some users had this problem, while others did not. I have not been with this company that long and have no idea how reliable this type of path was in the past, so this may be a sort of isolated incident. A new production system was coded to use a DFS path but was using the unqualified, netbios name of the domain rather than the qualified name. We have no WINs services running here at all. So the path was \\DOMAIN\DFSROOOT\N-drive for example. When it really should be \\DOMAIN.com\DFSROOT\N-drive. They seemed to think that this should work properly regardless of whether the netbios domain name or the qualified name was used.
I can think of cases where this would be true such as the ip stack appending the proper domain suffix, or possibly a broadcast resolution of the netbios domain name. However, this is hit and miss and I would not want to rely on those methods.
So I started to wonder about creating a cname with the alias of the domain netbios name and the target being the qualifed domain name. I tried this in my test AD lab at home and it worked fine, but that's a fairly small, not overly complex environment...no replication, etc.
All I am hoping to do with this is provide a way for the netbios name of the domain to resolve to the fully qualified name of the domain. Currently it does not and when people use the netbios name of the domain in the dfs share path, it does not work most of the time.
So for example:
\\ABC.int\ROOT\N-drive works fine as does directly mapping to the resource, i.e. \\sever\share
however..
\\ABC\ROOT\N-drive does not work sometimes in some situations for some users. I have checked effected machines and the ip stack is configured to append abc.int in the dns settings.
So if I create a cname of ABC with a target of ABC.int this will allow me to resolve ABC unqualified at a command line. I know that pinging or nslookup for a netbios domain name is not a valid test, but the cname does seem to help the issue whether or not the domain name is pingable or resolvable to nslookup
I have also added a ABC x.x.x.x #PRE in the lmhosts file and this works, but I don't want to use that as a solution either... I have tested this in my AD lab and it works. When I add the cname entry for the netbios name of the domain, I can then use either the fully qualified or the netbios name of the domain in a dfs root path.
Can anyone think of any issues that I might be creating if I created the cname record I described?
Edit: I was following one of the KB articles and discovered that the domain controllers have no netbios names registered in the local cache. nbtstat -n shows no local names. The DC should have a 1C and a 1E I believe. I looked at the ip settings and netbios over ip is disabled. Would this need to be enabled for the netbios name of the domain to be resolvable?
Edit2: Getting more stumped. I installed dfs role in a pristine domain with no previous dfs, etc. Netbios disabled on the DC. Everything works fine. I can access using qualified or netbios domain name. Something in our environment interferes with this, and I can't figure out what. Also, this always happens on a vpn connection. Have only ever seen it happen outside of a vpn connection once--to my knowledge at least. So I'm wondering if it's an authentication order thing or something. Trying to use a dfs path with a netbios domain name PRIOR to having authenticated to a DC could cause this...?