目前正在执行一个项目，将所有用户从映射的驱动器主文件夹迁移到redirect的文件夹（文档）。
目前有一个奇怪的问题，即用户redirect文件夹文件是真的很慢（本地），即使浏览文件夹可能需要几秒钟来填充文件列表。
我已经将驱动器映射到相同的DFS命名空间，并且速度很好，我也通过将文件夹redirectredirect到共享名称而不是DFS命名空间进行了testing，这也很好。 所以看起来文件夹redirect到DFS命名空间的组合导致了缓慢。
根据微软的build议，DFS是不可复制到NAS的一个特点。
任何人有类似的东西或任何想法可能会导致这个问题？
我也有类似的问题在我的设置，似乎由于下面的问题
http://support.microsoft.com/kb/2610379
在低networking延迟期间，我们面对的是迟缓，起初我们没有看清楚。 但是当我们查看日志时，我们发现问题是延迟。
另外，如果在Windows 7的机器（即客户端）上观察到缓慢，则下面可能会有所帮助
应用修补程序可以帮助我们。 希望这可能有一些帮助。
我过去也有同样的问题，有时甚至没有工作。
用这种方法检查故障排除。 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
然后，如果这不起作用，只需重新从控制台重新开始，并在执行此操作之前在文件中创build一个模式，这真的很有帮助。
创build一个名称空间，然后关联共享文件夹（假设您正在创build域名选项）。 如果使用\ domain.com \ namespace \ resource访问资源，则从域中的任何计算机执行testing，然后通过添加其他资源并接受选项来执行复制。
这种方式总是对我有用。
我希望这有帮助
我也会遇到这个问题： \\dfs\resource很慢甚至不能正常工作，而\\targetserver\resource很好。
在我的情况下，问题是DFS根服务器是W2008 R2和目标位于W2003。 显然，他们使用不同版本的NTFS，所以当没有指定时，w2003假设用户总是有Traverse folders ，但是w2008 R2则假设相反。
因此，将w2003文件夹中的Traverse folders权限添加到Domain users组为我解决了它。 除了那些inheritance权被删除的文件夹，当然，我会再次申请那些权利。