我们的DFS命名空间已经设置好，因此\\ company.local \ users被托pipe在英国服务器和美国服务器上，并根据用户的站点进行推荐。 作品除了我们今天怀疑的一个款待，DFS失败到一些用户的美国。 只有怀疑，因为我们可以看到的唯一证据是他们的私人文件（如cookies，漫游configuration文件）从美国复制BACK。 通常情况下，他们走相反的路。 用户如何确定\ company.local \用户在会话中解决的问题？ 有没有一个命令行工具，或者他们可以看看？ 就像networking使用，但为DFS命名空间。 谢谢，罗布。
DFS复制组types – 多用途复制组和数据收集复制组之间有什么区别？ 是否真的只有数据收集的复制组只允许2路连接，而另一个允许多个？ 多用途复制组中只有两台服务器（或缺点）是否有问题？ 如果数据收集的复制组没有太大的优势，我是否应该总是select多用途复制组，以便将来可以添加更多的服务器？ 谢谢！ 编辑： 此外：从MS文档（ http://technet.microsoft.com/en-us/library/cc780303(v=ws.10).aspx ）：“此选项设置两个服务器之间的双向复制，如分支服务器和中心服务器“。 “数据收集的复制组”是两种方式还是一种方式？ 从你所描述的这听起来是一种方式，但从文档说“双向”？ 并澄清我的意思是一两种方式： 1路。 服务器A被复制到服务器B.服务器B上的项目不会返回到服务器A. 2种方法。 服务器A被复制到服务器B，添加到服务器B的项目被复制到服务器A.
到目前为止，我已经看到一篇关于性能和可伸缩性的文章，主要关注添加新链接需要多长时间。 但是有没有关于文件数量，文件夹数量，总大小等方面的限制的信息？ 现在，我有一个单一的文件服务器，数百万JPG（约45 TB），通过几个标准的文件共享在networking上共享。 我计划创build一个DFS名称空间，并将所有这些映像复制到另一台服务器以实现高可用性。 我会遇到与DFS有关的其他问题，否则我不会遇到简单的文件共享问题？ 有更多的build议方式来复制这些数以百万计的文件，并使它们在networking上可用吗？ 编辑2： 所有文件通常写入磁盘一次，之后永远不会修改。 他们唯一被修改的时候是最终被删除，可能几年后。 所以一切都是静止的。 编辑： 我会自己试验一下，写一篇关于它的博客文章，但是我还没有第二台服务器的硬件。 我想在购买45 TB的硬盘空间之前收集信息…
我们正在运行两个相当繁忙的位置，在Windows 2003服务器上共享40 + Gig的客户端数据，并且需要将它们复制到每个服务器上（尽可能地接近即时）。 我们遇到间歇性复制失败，并尝试了各种修复，但基本上是盲目的工作，因为我们在事件日志中收到的错误不是特别有用。 所以，最好的情况应该是总是有效的，而不是透明的。 欢迎任何build议。 谢谢。 更新：我们现在实际上使用FRS来复制，问题仍然存在。
有几个用户正在使用脱机文件夹来引用我们想要停用的服务器…实际上，服务器已经脱机，并且有人正在等待这个共享的更新。 将这些caching文件以新名称移动到新服务器而不丢失新数据的最佳方法是什么？
这里有两个略有不同，但类似的情况： 有一个S：\驱动器映射到\\服务器\共享。 然后实现一个DFS名称空间，并将S：\更改为\\ domain.local \ dfs \ share（指向传统共享）。 现在，一些带有链接/embedded文件和各种应用程序的文件会变得怪异和故障。 要注意的是，这些embedded式文件链接（例如链接的Excel表格）指向传统共享，而父文件则从DFS共享中打开。 2.我的文档中有一个用于POP / IMAP帐户的PST。 然后文件被redirect到networking共享。 现在，Outlook无法访问与该帐户关联的PST，尽pipe数据文件选项卡指出了该文件（\\ server \ share \ user.name \ Documents \ outlook.pst）的正确networkingpath。 Outlook加载，但它声称无法findPST，因此无法查看关联帐户的收件箱。 * *原来这是一个特定的已知问题。 我稍后会发布一个链接 为什么在执行这些types的redirect时，这些事情会“中断”，即使从前端观点来看文件path仍然是相同的？
我无法在Google或Technet上find答案的问题… 授予SYSTEM用户对DFS共享文件和文件夹的权限是否对DFS复制有任何影响？ （而当我们在这里，有没有什么好的理由不让SYSTEM有权限DFS共享文件？） 它出现是因为我有一个DFS命名空间和文件夹的集合，我无法解决别人的问题，并且在解决一个DFS副本只是没有被另一个DFS副本复制的问题时，我观察到SYSTEM帐户没有任何权限授予任何文件夹中的文件或文件夹。 所以我把SYSTEM设置为完全控制并传播下来，我们的DFS健康状况诊断报告从显示积压的〜80个文件变成积压〜100,000 …并开始复制，包括一些已经在一台服务器或另一台服务器上丢失（所以不仅仅是开始复制的权限更改）。 当然，这让我好奇DFS是否需要SYSTEM帐户有权执行其工作，或者如果可能只是提示DFS跳转到行动的文件夹树的任何更改。 重要的是，我们的DFS命名空间是在2000/2003以下build立的，而且我刚刚完成了将所有服务器升级到2008 R2或2012（启用了UAC，blech）的function，但是还没有到达提升DFS命名空间function级别到Server 2008。 （如果有人有关于NTFS文件权限的正式Microsoft文章以及与DFS或networking文件相关的SYSTEM帐户，则奖励积分。）
我们最近迁移了我们的Windowsnetworking以使用DFS共享文件。 DFS运行良好，除了一个恼人的问题：当用户尝试访问他们一段时间没有访问过的DFS名称空间时，他们遇到了很大的延迟。 我试图解决这个问题，但到目前为止还没有取得任何成就，我希望这里有人可能有一些指导来帮助解决问题。 首先，我们networking上的一些背景： networking使用Windows 2008function级别的Active Directory域和两个Windows 2008数据中心和两台DNS服务器（每台数据中心都有一台）。 networking只有DNS – 没有WINS。 所有的计算机都位于同一个站点，并通过千兆以太网连接。 在Windows 2008模式下，我们有大约20个基于域的DFS名称空间，每个DFS名称空间都有两个Windows 2008 DFS名称空间服务器（所有名称空间都是相同的两台服务器）。 所有名称空间服务器都处于FQDN模式，所有文件夹目标均使用其FQDN指定。 所有计算机都是最新的Service Pack和补丁程序。 实际的文件夹目标（即我们的DFS文件夹指向的SMB共享）分散在多个文件和应用程序服务器上，所有运行Windows 2008的应用程序服务器都运行Windows 2003 R2，并且根本没有任何复制设置（例如当前所有的DFS文件夹只有一个文件夹目标）。 关于这个问题的更多细节： 命名空间访问延迟通常为1-10秒，并且当特定计算机大约五分钟或更长时间没有访问所请求的命名空间时似乎发生。 例如，如果用户没有访问超过五分钟的\\ domain.name \ namespace1 \，并尝试通过Windows资源pipe理器访问\\ domain.name \ namespace1 \，资源pipe理器窗口将会冻结1-10秒恢复并显示\\ domain.name \ namespace1中存在的文件夹。 如果他们closures浏览器窗口并尝试在五分钟内再次访问\\ domain.name \ namespace1 \，则内容将几乎立即显示 – 如果等待超过五分钟，则将再次经历1-10秒的暂停。 一旦在命名空间“内部”，一切都很好，活泼，这只是命名空间的初始连接很慢。 浏览延迟似乎影响到我们使用的所有Windows版本（Windows 2008 x64 SP2，Windows 2003 R2 x86 SP2，Windows XP Pro […]