DFS Share is much slower than direct file server path

Shakuras-P used Ask the Experts™
We have a Windows Server 2008 R2 DFS setup with 3 fileservers (which are all DCs) between our three remote offices.  We’re having an issue where opening up\saving  a document is taking much longer using the namespace name path compared to a direct server file share path.  For example, opening up a 230KB excel file will take 10 seconds on a path \\ourdomain\namespacename\dfs_share, whereas opening the same file through \\servername\share takes a second.  This is just a small file example.  Larger file delays are longer.

Some troubleshooting I have done:
-      Ping “ourdomain” to make sure that the IP address is same as “servername”
-      Right click on a folder to make sure that the DFS path is going to the server on site not remote.
-      Instead of using “ourdomain” DFS path, use the closest “IP address” as an alternate DFS path (\\IPaddress\namesapcename\dfs_share is also slow)

I am somewhat new to DFS, and any explanation of why this is happening would be greatly appreciated.  Thank you.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Afraid this is a problem with DFS.  We find the same thing here.  Much quicker to access local server than to go to a remote server and then back to local server.
We are having the same issue. We purchased a new NetAPP and wanted to continue to use DFS for a global namespace. When transferring a file 1.5GB via DFS it transfers at 11MB per second and direct to the NetApp transfers at 70MB per sec.  Is this normal?

So it doesn't seem there is a solution?
Love the accepted solution 'Afraid this is a problem with DFS.' NOT.

Perhaps this article is more useful DFS Namespace Slow UNC Fast

It states Carbon Black might be the issue.

We found the problem.  After weeks of scratching our heads we finally figured out that the issue was in fact an Application White Listing agent that was recently installed onto all workstations a few months back.

The application is called Carbon Black and used to be called Bit9.  We don't know why that agent would cause slow access to files when using DFS Namespaces to access and not cause the same issue when accessing the same files using the servername\sharename path.  It also only happened with Windows 7 boxes not 10.  Even stranger is that the agent is not actually blocking anything at this point.  We only have it in monitor mode to gather information on what applications are used by everyone in the company.  Very odd but we did confirm 100% that it was the agent causing the issue.  I am sure there is some policy update we can implement to keep that from happening but we have not figured that out yet.

So lesson learned.  When they tell you to remove AV or other apps that can scan the drives or memory you should probably do that right of the bat.  I didn't even realize the agent is was on their until we started digging through every service and found it.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial