Clients picking up the wrong DFSN target, dfsutil shows AccessStatus 0xc000003a

We use DFS at work and I noticed one of our laptops was always connecting to a target in a far away site. My own desktop was connecting to the wrong target but after a reboot it connected to the correct one. There weren’t any user complaints about slowness, so could be that other machines were ok and/ or they weren’t noticing the slowness.

DFS seemed to be set up correctly, and the laptop was picking up an IP in the correct site etc so it wasn’t any obvious misconfiguration.

To investigate further I used the dfsutil tool. I got the idea for this from an old KB article. The dfsutil tool is a part of the DFS Management tools and is present in %WINDIR%\System32. It can be used to administer DFS-N and is more powerful than the GUI. Since the laptop didn’t have this tool I copied it from my desktop (which had the DFS Management tools installed) to the laptop.

First I checked if the laptop is able to reach the correct DC or DFSN server. I do this by examining the domain cache on the client.

In the past the command used to be dfsutil /SpcInfo but now it’s the more intuitive dfsutil cache domain. The older switch still works though. (The domain cache is also called SPC cache, hence the switch is SpcInfo).

In the output the entries with a * are those which were obtained through the Workstation service. Like the domain name, the NETBIOS domain name, and the DC which the laptop is connected to.

All other entries (both – and +) are obtained through referrals by the DFSN client. Of these, entries with a + are currently used by the client. So in the case above, the laptop had got a referral to the rakhesh.local domain and was correctly latching on to the WIN-DC01 server which is the DC and DFSN server for its site.

Next I examined the referral cache of the client to see if there are any errors that point out to why it is not using the correct referral link.

DFSN stores information on the root name, the root servers, links, and target servers in a Partition Knowledge Table (PKT). This is stored in AD (in case of a domain based DFS) or the Registry (in case of a standalone DFS). Clients refer to this and cache it with then (so they don’t have to look it up always) and this is what we need to examine. Previously the command for this used to be dfsutil /PktInfo but now it’s replaced by the more intuitive dfsutil cache referral (notice how everything comes under the dfsutil cache sub-command).

And therein lies the problem! The laptop is correctly connecting to the WIN-DC01 DFSN server, this server is correctly returning the namespace (“pub”) and link (“downloads”) and referrals to the two targets for this link (on win-data01 and win-data02). But whereas we want the laptop to use win-data01, that is not set to active and has an error status returned. Instead win-data02 is set as the active target.

There doesn’t seem to be a definite cause behind the “0xc000003a” error code. What helped me finally was this forum post. I didn’t try the solution that helped the OP (though our office environment has a similar setup) as one of the suggested solutions did the trick for me.

It appears that if the link targets have different offline caching settings, it considers the targets with offline caching enabled first and only if that fails does it consider the preferred target. So I checked my targets to see if they have different caching settings and sure enough the preferred target didn’t have caching. Turned on caching for it, rebooted the laptop, and now it picks up the correct target!

An easy way to check whether all your targets have similar ACLs and offline caching settings is to us the dfsdiag command on the DC/ DFSN server. I ran the command thus:

More about the dfsdiag command in this TechNet post.

Hopefully this helps someone.