Drive Map to DFS Folder Getting Lost

We had a problem yesterday morning with every user (about a dozen) in one of our small branch offices being unable to access a certain network share.

Their T: drive, which is the one they had a problem with, is mapped to this:


which is a DFS folder that simply points to:


That is a Server 2012 R2 server.

This share is only a few weeks old, and has been working fine for them until today. We have other offices that have their own shares on the same server, and mapped to a DFS folder the same way, and those have been working OK (as far as I know).

The PCs are all running Windows 7.

Their S: drive is mapped to


which is a MS Server 2003 server. They had no problems with accessing this, ever.

Going to Computer > Map network drive, I could see the label for \OfficeShare1 was still attached to T:, but the path was empty. The T: drive appeared in the Computer window, but was showing as disconnected, and double-clicking it would throw an error about the path being unavailable.

Typing \\\namespace\OfficeShare1 in the address bar would cause the Computer window to hang before erroring-out. Thus, re-creating the drive map would not work.

After trying that, a user could go to \\\namespace and that would work fine. From there, they could go to the \OfficeShare1 folder without any errors.

If they then went back into Computer, their T: drive would again be working, without having to re-create the mapping.

Also, even though users couldn't browse directly to \\\namespace\OfficeShare1, without first browsing \\\namespace, they could browse directly to \\2012FileServer\OfficeShare1.

I've seen a few other users outside the aforementioned office who had the issue, but this is the first opportunity I've had to get more information on it before the client PC was rebooted. Some of those users who have had this issue, also have an X: drive, which is mapped to:


But this is a CIFS share. And like the share on the 2003 server, no user has experienced the issue with this share.

It has only happened with the shares on the Server 2012 system. And it has been kinda rare (currently less than 75 users who could potentially experience it).

All drives are mapped via Group Policy. Users do have a script they can run to re-create drive maps.

It's probably some connectivity issue that causes the drive to get disconnected (wifi signal drops, VPN gets disconnected, etc). But I'm not sure why the problem persists after connectivity is restored, why the path disappears from the mapping, and why only with this one drive. The servers hosting those shares are all in the same subnet, same data center.

I'm about to migrate about a share accessed by 500 users to this 2012 system, and I can't until I get this figured out. My hunch is that something in the Windows 7 client PC is getting... lost. It's only happening to drives that map to DFS folders in that namespace that point to shares on that 2012 server (no one has a drive that maps directly to the shares on that server). The share itself doesn't appear  to actually go offline or anything like that. And this morning is the first time I've seen it happen to multiple people at once.


Any help is appreciated.

Who is Participating?

Improve company productivity with a Business Account.Sign Up

ctp_mackdaddiesConnect With a Mentor Author Commented:
Disabling latency optimization on the onsite Riverbed accelerator resolved the issue. This is a known bug. In fact, we had a similar (though not identical) issue last year in a different office, caused by the same thing.

Not sure if there's a real fix for you but when that happened to my client restarting the "DFS Namespace" service fixed it.
ctp_mackdaddiesAuthor Commented:
It's weird because it usually only affects one user at a time, and the issue is resolved on the client-side. So one person accessing the share, probably after having their network connection disrupted, will not be able to reconnect to it. Others accessing the share won't have an issue. And it doesn't happen every time.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Picking at straws here... Maybe reboot the switch everyone is connected on?
ctp_mackdaddiesAuthor Commented:
It has occurred with people in different offices, different switches.

Since DFS replication is not being used, I might have the users map directly to the server share path, rather than the DFS redirection folder. That would be a temporary troubleshooting step, though.
Do you have other dfs shares on the suspect server? If so, do they also show the issue? If not, maybe try making a temp dfs share on the same server to see if it happens with that share. That might help isolate the server.
ctp_mackdaddiesAuthor Commented:
There are several other shares on the server, all being pointed to with DFS (although again, there is no replication). It has been experienced with a couple of the shares, but not all. And when it does happen, not everyone who accesses the share has the problem. I don't think there's something happening to the share itself. Though I don't know the source of the issue, the problem is definitely being triggered on the client PC. One person can experience the issue, while dozens of others do not. And access to the share is restored by making changes on the client PC.

Have you checked client Power settings so the NIC isn't powering down to save power?
ctp_mackdaddiesAuthor Commented:
The NIC does not power down to save power.
Not sure how that would affect one share but not the others, though.

ctp_mackdaddiesAuthor Commented:
Comments by other experts did not name or effectively narrow-down the cause.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.