Solved

Drive Map to DFS Folder Getting Lost

Posted on 2015-01-07
10
775 Views
Last Modified: 2015-01-25
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\OfficeShare1

which is a DFS folder that simply points to:

\\2012FileServer\OfficeShare1

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\CompanyShare

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\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 \\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\OfficeShare1, without first browsing \\domain.com\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:

\\domain.com\namespace\DeptShare1

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!
0
Comment
Question by:ctp_mackdaddies
  • 6
  • 4
10 Comments
 
LVL 23

Expert Comment

by:NVIT
ID: 40536458
Not sure if there's a real fix for you but when that happened to my client restarting the "DFS Namespace" service fixed it.
0
 
LVL 1

Author Comment

by:ctp_mackdaddies
ID: 40536990
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.
0
 
LVL 23

Expert Comment

by:NVIT
ID: 40537001
Picking at straws here... Maybe reboot the switch everyone is connected on?
0
 
LVL 1

Author Comment

by:ctp_mackdaddies
ID: 40538019
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.
0
 
LVL 23

Expert Comment

by:NVIT
ID: 40538348
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.
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 1

Author Comment

by:ctp_mackdaddies
ID: 40538440
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
0
 
LVL 23

Expert Comment

by:NVIT
ID: 40538469
Have you checked client Power settings so the NIC isn't powering down to save power?
0
 
LVL 1

Author Comment

by:ctp_mackdaddies
ID: 40545371
The NIC does not power down to save power.
Not sure how that would affect one share but not the others, though.

Thanks,
0
 
LVL 1

Accepted Solution

by:
ctp_mackdaddies earned 0 total points
ID: 40560607
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.

thanks
0
 
LVL 1

Author Closing Comment

by:ctp_mackdaddies
ID: 40569017
Comments by other experts did not name or effectively narrow-down the cause.
0

Featured Post

Complete Microsoft Windows PC® & Mac Backup

Backup and recovery solutions to protect all your PCs & Mac– on-premises or in remote locations. Acronis backs up entire PC or Mac with patented reliable disk imaging technology and you will be able to restore workstations to a new, dissimilar hardware in minutes.

Join & Write a Comment

Suggested Solutions

This article will review the basic installation and configuration for Windows Software Update Services (WSUS) in a Windows 2012 R2 environment.  WSUS is a Microsoft tool that allows administrators to manage and control updates to be approved and ins…
If you get continual lockouts after changing your Active Directory password, there are several possible reasons.  Two of the most common are using other devices to access your email and stored passwords in the credential manager of windows.
The viewer will learn how to successfully download and install the SARDU utility on Windows 7, without downloading adware.
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now