我们一直都有DFS的问题，但最近变得更糟了，没有明显的原因，并且变得有害。 我们有一个主服务器和DFS连接到其他四台服务器。 四个服务器不修改任何文件，所以所有的复制总是从主服务器传播到另外四个服务器。 复制的目录有大约900,000个文件。 在最近几周里，我们每次检查DFS积压都有几十万个文件。 例如，目前，主服务器将大约70万个文件复制到四台服务器中的三台，而第四台服务器没问题。 有时候，只有一个是closures的，有时是两个，这次是三个。 而且，它从来不是同一组服务器。 定期触及全部900,000个文件是不可思议的。 发生的最大变化是每六小时更新几千个文件。
有人有同样的问题吗？ 这是一个已知的问题吗？
更新:(这也是Jeff Miles提出的一些问题的答案）。 这个问题在几个小时前再次发生。 我在早上设置了一些探测器，并在白天监视服务器，并在一个看似随机的时间，三分钟内积压到300万次（这比文件总数还要多）。 没有什么有趣的DFS事件日志。 甚至没有“开始初始复制”。 只有几个“DFS连接丢失或没有响应”的错误，但他们发生约10分钟后事实。 很可能是因为积压的东西窒息而死。 更重要的是，第四台服务器没问题。 这表明300万的变化很可能是假的。 另外，我无法想象在这么短的时间间隔内改变了很多文件。 关于技术设置; 它是Win2003R2和Win2008R2的组合。 会不会是一个问题？
首先，validation您的拓扑。 仔细查看复制集属性中“连接”选项卡下的复制连接：
我已经看到全网状拓扑结构意外添加，导致像你所看到的问题。
其他可能的罪魁祸首： – 在一台或多台服务器或其客户端上进行防病毒扫描或文件索引。 （打开一个文件更新访问时间，然后必须复制到所有的同行。） – 一个或多个非常大的文件干扰复制 – 这应该显示在您的DFS-R日志中。
最后，您是否需要DFS-R，或者是否可以使用常规的robocopy来保持文件夹同步？
如果定期看到积压成千上万的文件，我猜想有些事情会改变文件上的安全性ACL，特别是当积压清除时没有看到太多networkingstream量。
检查什么是修改这些文件的一种方法是打开审计。 与Microsoft目录服务团队的Ned Pyle最近推出了一个使用全局对象访问审计的博客，可以帮助您确定发生了什么变化： http : //blogs.technet.com/b/askds/archive/2011/03/10/10/全局对象的访问审计，是-magic.aspx
我也会检查你的DFSR事件日志，并查找任何事件ID 4102（开始初始复制）或4104（初始复制完成）。 如果您的文件没有被修改，我可以想到的积压成千上万的文件的唯一原因是初始复制。 如果您的DFSR服务崩溃，则可能会损坏DFSR数据库并触发初始复制。
如果可以，我会尝试使用只读DFSR，在这里描述： http : //blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx
我想基于你的Server 2003标签，你不能这样做，但值得一提的基础上你的用例。
http://blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx
由于您看到在很短的时间内复制的文件数量不合理，因此必须有一个应用程序正在更改文件属性或USN日志值，而不更改文件数据。例如，更改存档位的备份软件会触发此操作以及某些AV软件。
testing与DFS复制的防病毒应用程序互操作性
我将设置一个testing复制组来排除故障，并testing备份软件，AV软件等复制效果。 除了您收到的其他build议之外，我还会logging并观察USN日志中的更改，而不更改文件数据。 提供的链接是一个很好的文章，用于检查更改USN日记本的应用程序，而不更改文件数据，从而导致过度复制。
注意文件屏幕，配额等。 我已经看到一些文件屏幕完全停止复制的情况。
您是否将防病毒软件设置为扫描DFSR专用文件夹（分段，冲突和已删除等）？
-Ken