How do you figure out how a windows machine is resolving a share name?

Solution 1:

The question you should be asking is how windows resolves computer or DFS names.

Ok an example

Servername = server

domain name = dom.local

FQDN of server = server.dom.local

DNS suffix of YOUR pc = dom.local

there are two parts to the share path. The server or hostname "\servername" and the share itself "share1" First lets look at what happens when windows resolves the name to IP using ping as an example.

you run ping server to get the IP. At this point your PC looks at its TCP/IP config and gets the IP of the DNS server. It then queries this DNS server to resolve the name...or it may use WINS (explained below).

a lot people now think "oh yeah that's easy it will query the DNS server, i knew that it was obvious". Not so! It doesn't always query the DNS server and this is where people get confused. here is what really happens:

your pc will ALWAYS try to resolve this name to a DNS name first. failing this it will try to query a WINS server (if local PC has been configured with one),if this then fails it will do a NetBIOS broadcast. it is ALWAYS in this order.

Now pay attention to the DNS suffix i mentioned above. if that was anything else other than dom.local this ping would fail. This is because when i pinged it, i didn't type the FQDN of server.dom.local but instead used part of it just 'server'. What Windows does in the background is APPEND it with the DNS suffix (this is what it is for). So when you type ping server you will actually see that windows then says "pinging server.dom.local", note it is the FQDN. Hopefully you can see where I am going here with DNS queries. As you have two separate domains the DNS suffixes may be different. If for example my dns suffix was dom2.local when I pinged server it would append it with that suffix and TRY to ping server.dom2.local. Again the confusion comes though from the fact it doesn't actually say it on the screen (because it fails) so people THINK it is querying server.dom.local when in fact it isn't. Once this fails via DNS it moves onto WINS then NetBIOS. What is actually displayed is "pinging server" once it is resolved through other means. Note the subtle difference between the two? When a query works with DNS it will say "pinging server.dom.local", when it fails and resolves using WINS or NetBIOS instead it will say "pinging server". This is something you should test to see whether it is resolving the name through DNS correctly. most people ping the name and get a reply and think DNS is working because it resolves the name. They never pay attention to the fact it didn't resolve the FQDN though which meant DNS actually failed. WITH TWO DOMAINS IN PLAY THIS IS VERY IMPORTANT and can easily cause havoc from a name resolution perspective if you aren't vigilant. Most people are blissfully unaware of this because they only have one domain. They never need to know what the DNS suffix is for.

At this point now you should know what IP your share is on. Exactly the same applies with the DFS tree. Ping the DFS name and the IP that comes back tells you where the DFS root is. Forget about DFS for the moment. going back to PC's...if your DNS query resolves a machine name then that is where your share is, plain and simple.

If the query is for a DFS name space locate the server and load up the DFS management console. lets say it was \dom.local\share1. In this example you pinged dom.local and found it resolved to 192.168.5.4. You RDP to this and load up DFS manager and now localte "share1". The DFS manager will tell you whether it is on the local server or redirects to another server. From there you just follow the breadcrumbs till you get to the actual server then subsequent share.

Make sense now?

Ok, in answer to your mroe addtional details...I don't think you read my post properly and suspect what is happening..here goes.

Remember I said about DNS domain suffixes above and why they are so important when transferring domains??? Let's say this PC you trying to connect to the shares on still has the dns suffix of the old domain which is xxxx.com. When you type or ping D1 it appends this DNS suffix at the end. so what it is really connecting to is d1.xxxx.com...this no longer exists when you drop your xxxx.com domain. Try connecting to \d1.yyyy.com\root\things and not just \d1\root\things. Let me know if this works then we can continue