Ryfujk

Currently performing a project to migrate all users from mapped drive home folders to redirected folders (Documents).

Having a strange issue at the moment whereby users redirected folder Documents is really slow (locally) even browsing through folders can take several seconds just to populate the list of files.

I have mapped the drive to the same DFS namespace and the speed is fine this way, I've also tested by redirecting the folder redirection to the share name instead of the DFS namespace and this is also fine. So it would seem the combination of having Folder Redirection to DFS Namespace is causing the slowness.

DFS is a singular point no replication to a NAS as per Microsoft recommendations.

Anyone had something similar or any ideas what could be causing the problem?

I have also had the similar issue in my setup and seems to due to below issue

http://support.microsoft.com/kb/2610379

During low network latency, we have faced slowness, we didn't observe it clearly at first. But when we look at the logs, we have found that the problem is the latency.

Also if the slowness is observed on windows 7 machine i.e. clients, below might be of help

http://www.networksteve.com/windows/topic.php/Windows_7_Folder_Redirection_to_DFS_slow_when_browsing/?TopicId=47217&Posts=0

Applying hotfix helps us. Hope this might be of some help.

I have same issues in the past, sometimes they didn't even work.

Check the troubleshooting this way.
http://blogs.technet.com/b/josebda/archive/2009/07/15/five-ways-to-check-your-dfs-namespaces-dfs-n-configuration-with-the-dfsdiag-exe-tool.aspx

Then if this doens't work,
Just start over again all from the console and make a schema in the paper of what are you doing before implementing this is really helpful.

Create a namespace
then associate the shared folders (assuming you are making the domain name option).
the do the test from any computer in the domain if the resource is accesible using the domain.comnamespaceresource then do the replication by adding the other resource and accepting the options.

This way always works for me .

I hope this helps

I'd this issue also: \dfsresource was slow or even not working, while \targetserverresource was fine.

In my case, the problem was DFS root server was W2008 R2 and the target was located on a W2003. Apparently, they use a different version of NTFS, so when not specified, w2003 assumes user have always the Traverse folders, but w2008 R2 assumes the opposite.

So adding the Traverse folders rights in the w2003 folder to the Domain users group solved it for me. Except for those folders with the inheritance removed, of course, I'd to apply there again those rights.