We've been having some weird issues while migrating domains from one forest to another. We tried turning off the domain controllers for the old domain, and all of a sudden, a share which we used to have access to, on yet another domain, on it's own forest disappeared.
I'm having problems understanding how Windows clients resolve shares. i.e. when I type in \XXXXXX\yyy\zzzz, what exactly does Windows do in order to figure out what server to connect to? Note that we used to have a DFS share on the old domain as well so that plays a part.
Are there any tools that help you track down what Windows is doing? i.e. something that log something like this if I gave it the path \XXXXXX\yyy\zzzz Checking for name in local NETBIOS. Did not find name in netbios. Checking DFS cache... Found in DFS cache, using \computer.domain.com\share for \XXXXX\yyy\zzzz
Here is the whole story. We are migrating from one domain D1.xxxx.com to D2.yyyy.com in a different forest. We have a cross domain trust in place and everything has been moved except DFS. We've decided to stop using DFS in domain 2 because of all the headaches we've had. Instead we'll have a host in D2 called D1 which will serve the whole DFS. We've set it up and copied all the files. We then turn off all domain controllers for D1 and remove the trust. Now, I would expect machines on the D2 domain to go to the share called root on D1.yyyy.com when I type \D1\root\things. For some reason that doesn't seem to happen, and I can't figure out why. I tries using dfsutil /pkflush on a client machine and still no deal.
What I would like to do now is see exactly what my client machine is doing when attempting to connect to \D1\root\things. Seeing what happens on the network doesn't help. I know (or am fairly sure) it's still trying to go to the old DFS share.
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 serverto 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
I believe in this particular situation, something like Wireshark may come in handy. It actually shows DNS queries as well.