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:
\\domain.com\namespace\Off
which is a DFS folder that simply points to:
\\2012FileServer\OfficeSha
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
\\2003FileServer\CompanySh
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 \\domain.com\namespace\Off
After trying that, a user could go to \\domain.com\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 \\domain.com\namespace\Off
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:
\\domain.com\namespace\Dep
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.
Weird.
Any help is appreciated.
Thanks!
Their T: drive, which is the one they had a problem with, is mapped to this:
\\domain.com\namespace\Off
which is a DFS folder that simply points to:
\\2012FileServer\OfficeSha
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
\\2003FileServer\CompanySh
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 \\domain.com\namespace\Off
After trying that, a user could go to \\domain.com\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 \\domain.com\namespace\Off
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:
\\domain.com\namespace\Dep
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.
Weird.
Any help is appreciated.
Thanks!
NVIT
Not sure if there's a real fix for you but when that happened to my client restarting the "DFS Namespace" service fixed it.
ASKER
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.
Picking at straws here... Maybe reboot the switch everyone is connected on?
ASKER
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.
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.
ASKER
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.
Thanks
Thanks
Have you checked client Power settings so the NIC isn't powering down to save power?
ASKER
The NIC does not power down to save power.
Not sure how that would affect one share but not the others, though.
Thanks,
Not sure how that would affect one share but not the others, though.
Thanks,
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Comments by other experts did not name or effectively narrow-down the cause.