Windows DFS Brain Damage

So we just started using Windows’ Distributed File System (or DFS for short). More specifically, we have been using the DFS Namespaces portion of DFS, which basically allows you to have one virtual share point to one or more underlying physical shares on any arbitrary physical server.

In theory, this level of indirection makes maintenance easier because on the client side you can map a drive letter to the virtual share, allowing you to change the physical share behind the scenes without any configuration changes on the client. For example, you could have a virtual share called \\myADDomain\corp\files that is configured to point to the physical share \\myFileServer\files. On the client, you can map a drive letter (e.g. Z:) to \\myADDomain\corp\files. Behind the scenes, that gets translated to \\myFileServer\files when the client uses the drive letter.

Today a user got the following error when logging into his Windows XP Pro machine: “An error occurred while reconnecting Z: to \\myADDomain\corp\files. Microsoft Windows Network: The system cannot find the file specified. The connection has not been restored.”

My first instinct was to reboot the client, as suggested in many DFS troubleshooting tips. So, I tried rebooting but upon logging in, the user got the new error: “Z:\ refers to a location that is unavailable.”

Sigh…

In DFS jargon, \\myADDomain\corp is called a DFS root and the files portion of \\myADDomain\corp\files is called a link. To make things more complicated, the DFS root points to these things called Root Targets, for example, \\myDC1\corp and \\myDC2\corp. Essentially, there are two levels of indirection here. \\myADDomain\corp points \\myDC1\corp (and \\myDC2\corp) and \\myDC1\corp\files (and \\myDC2\corp\files) points to \\myFileServer\files. I told you it was complicated.

The temporary workaround in this case was to map Z: drive directly to \\myFileServer\files. Of course, this renders DFS useless so I had to find a permanent fix. Below are the steps I followed:

1. Opened the DFS (Distributed File System) admininstrative tool on myDC1.
2. Noticed that \\corp.myADDomain.com\CORP (alias \\myADDomain\corp) DFS root was pointing to 2 root targets: \\myDC1\corp and \\myDC2\corp.
3. Right-clicked on each root target and clicked Check Status. Each one got a green check mark after the status check. This is good.
4. Noticed that the DFS root had the following DFS link: files.
5. Right-clicked on the link and clicked Check Status. It got a red X after the status check. This is BAD.
6. I then ran the DFS admin tool on myDC2. When I checked the status of root targets and link on this computer, ALL got green checkmarks. This is good.
7. On both myDC1 and myDC2, I ran Windows Explorer and opened the folder that maps to the CORP share. For example, the root target \\myDC1\CORP maps to C:\dfsroot on myDC1. Similarly, the root target \\myDC2\CORP maps to C:\dfsroot on myDC2.
8. In the C:\dfsroot folder on myDC1, the only child folder I saw was a hidden one called DO_NOT_REMOVE_NtFrs_PreInstall_Directory. However, on myDC2, the folder had the files child folder in addition to the funky hidden one.
9. AFAIK, you cannot manually recreate the missing child folder on myDC1 with Explorer because they it does not seem to be a real folder (right click to see the properties and you will see what I mean). In other words, it is a “magical” pseudo-folder.
10. Instead, in the DFS admin tool on myDC1, I right clicked on the \\myDC1\corp root target and clicked Remove Target.
11. Then I recreated the \\myDC1\corp root target by right clicking the DFS root (\\corp.myADDomain.com\CORP) and clicking New Root Target. For the server name I entered myDC1.
12. Then, magically, the files child folder in C:\dfsroot on myDC1 reappeared!
13. After that, the user logged out, logged in and Z: drive got mapped correctly. Woot!

How did myDC1 get into the bad state in the first place? I don’t know. Go ask Microsoft…

FOLLOW UP (November 14, 2008): This has happened two more times since writing this article. It seems to happen whenever we reboot one of the domain controllers that is hosting a Root Target. I’m not sure how to prevent the problem but at least the workaround described above always fixes it. Sigh…

If this tip helped you, please leave me a comment or send me an email!