问题：有没有办法使这350,000个文件积压工作更快完成？对于几乎每个文件，唯一的变化就是对每个受影响文件的ACL进行了更改。某些文件的内容已更改，但是在这种情况下并不常见。
这可能是固定的。经过一段时间的验证后，我将编辑此文本以确认成功/失败。在本问题文本的结尾，我详细介绍了最近可能已解决的更改。
我们有一个DFSR复制组，其中包含约450,000个文件，并占用1.5TB的空间。在这种情况下，有两台Windows Server 2008 R2服务器相距约500英里。还有其他服务器，但是这些服务器不参与此复制组。服务器ALPHA是主要服务器，并且是大多数员工使用的服务器。服务器测试版是远程办公室中的服务器，不太忙。
这是此复制组（Google云端硬盘上托管的PNG）的积压工作图，显示了同步进度缓慢。
我需要删除该复制组的根目录中的一个权限条目，该权限条目当然是在大多数子文件夹中继承的。我在服务器ALPHA上进行了此更改。此后，DFSR立即积压了350,000个文件。已经有一个多星期了，现在是267,000。唯一更改的内容（最初）是单个权限的更改。
这就是发生的情况（这不是解决方案，只是对导致此问题的原因的另一种解释）：http : //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack因为它可以星期五星期五晚上打架了。aspx＃dfsr
服务器BETA上发生的任何更改都将很快复制到服务器ALPHA，因为该方向没有积压。在BETA上更改的任何文件都可以毫无问题地添加到ALPHA。
它通过一端的50Mbps连接以全速复制24/7，另一端则是100Mbps光纤。每台服务器上的暂存区域为100GB。事件日志中没有任何有趣的东西。对于不相关的复制组，将显示一个不相关的高水印事件，该事件既不适用于此特定复制也不适用于此ALPHA / BETA服务器对。特别是，没有高水位或连接错误的事件日志条目。
ALPHA对复制组的看法：
节省带宽：减少99.83％（复制了30.85 MB，而不是18.1 GB）
我相信30.85MB / 18.1GB是自上次在ALPHA和BETA上重新启动DFSR服务以来发生的。如果是这样，这表明即使花费了很长时间（比我认为的要长），它实际上并没有通过网络传输文件内容。
复制文件夹：1.46TB（实际大小），439,387（文件），52,886（文件夹）
冲突和已删除文件夹：100.00GB（配置的大小），34.01GB（实际大小），19,620（文件），2,393（文件夹）
暂存文件夹：200.00GB（已配置大小），92.54GB（实际大小）
我在日志中（5月14日晚上7点）遇到了一个高水印错误，因此将暂存配额从100GB增加到了200GB。我知道Microsoft批准的途径将增加20％，但是我并没有对此进行讨论。我们有足够的磁盘空间可用于暂存磁盘阵列。
禁用防病毒软件的所有服务器上并没有帮助，但我认为这将有助于一点点。现在，我已经重新启用了防病毒功能，但是将复制组的路径设置为不扫描，以便从公式中删除该变量。
有没有办法让它更快？我也将在服务器BETA上进行此更改，但是有些文件在ALPHA上已更改但尚未复制到BETA，并且通过在BETA上进行继承的权限更改会将旧文件从BETA 推送到ALPHA（因为DFSR似乎比较哪个文件是冲突中的胜者时，请忽略文件时间戳记。发生这种情况将是相当糟糕的。
积压量正在缓慢减少。非常非常缓慢 不过，它正在向前发展。但以这种速度，还需要数周才能完成。我正在考虑只是将数据集的副本推到3TB驱动器上，然后将其运送到远程办公室。有没有更好的办法？
5月16日凌晨4点（美国时间）：可能已解决了该问题（无论如何，如果确实是已解决）：
我对DC进行了许多更改，而这些更改本应该是很久以前的。问题是该网络是从其他人那里继承的，而该人可能是从其他人那里继承的，等等。我不能保证哪个更改可以解决问题。在这里，它们没有特定的顺序：
- 所有DC都不在“域控制器” OU中。我从未见过Windows域在其他地方具有DC。我将它们移回了它们所属的地方。他们以前是在OU中，按每个办公室所在城市的名称来区分。（我觉得我搬走了那些，现在我需要做一些管道工作，但目前看来还可以。）
- AVG Anti-Virus在所有参与DC和DFSR的服务器上运行。我从主动/按访问扫描中排除了复制的文件夹和临时文件夹。我认为这不能解决问题，以后可能会测试该问题，以了解是否撤消该更改是否会干扰DFSR的复制速度。这是另一天的挑战。
- dcdiag.exe抱怨有关RODC的DNS问题。即使我们在域上根本没有RODC，我也解决了这个问题。我怀疑这没有解决任何问题。
- 对于其中一个DC（不是DFSR服务器之一），缺少_ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV记录之一，我对此进行了纠正。我也不认为这有帮助。
- 我重启服务器测试版的其中一次，它抱怨DFSR数据库严重关闭（事件2212），然后它花费了数小时来重建数据库。完成后，它报告事件2214，让我知道它已完成。此后，复制仍然非常缓慢地运行，但是它可能有助于解开任何卡住的内容。
- 其中一个DC在其接口配置中没有127.0.0.1作为辅助DNS服务器。我加了 这不是DFSR服务器之一，因此可能与它无关。
- 我关注了TechNet博客：在DFSR中优化复制性能建议使用DFSR服务器的注册表设置。我使用了所有“经过测试的高性能值”值，但AsyncIoMaxBufferSizeBytes设置为4194304，这比高值低了一个档次。这本来可以解决问题的……或可能没有。很难说出何时更改了太多变量。
- dcdiag.exe抱怨与BETA上的RPC服务通信存在问题，但仅在进行了上述更改之后。这似乎是最有可能发生的问题，但是我没有做任何纠正。VPN运行正常，防火墙没有阻止它。以上问题之一可能是引起该问题的原因，然后纠正了RPC问题，或者这可能是偶然的。我现在没有收到该错误，复制目前正在顺利进行。
这个故事的寓意是：一次更改一件事，否则您将永远无法真正知道解决问题的方法。但是我很拼命，没有时间来修复它，所以我只是为解决这个问题开了一枪。如果我能找到正确的解决方法，我将在此处报告。不过，请不要依靠我来缩小范围。
编辑5/21/2012： 我昨天用备用服务器（GAMMA）开车到远程办公室大约七个小时，解决了这个问题。GAMMA现在充当其主要本地服务器，而其常规服务器（BETA）则赶上了复制。自从我将其放置到位以来，服务器的复制速度一直在翻倍。尽管这告诉我这可能是与VPN相关的问题，但我不太倾向于相信这是因为所有似乎从ALPHA复制到GAMMA的新更新都非常快而且进展顺利。
编辑5/22/2012： 现在是12000，应该在几个小时内完成。我将发布一张从慢速开始到快速完成的进度图表。问题在于，真正真正“修复”的唯一东西是本地服务器连接。我目前在想，也许VPN是问题的一部分。如果是这样，我觉得这个问题还没有完全解决。在我有更多时间检查通过VPN复制事物并看到任何故障之后，我将调试并报告进度。
如果有什么变化，我会在这里更新。
dfsrdiag replicationstate /a显示它仅发送两个文件，但是文件名相同。它说，无论如何，它有两个从ALPHA到BETA的出站连接。它发送的文件是850MB。如前所述，我不确定它实际上是在发送整个文件的内容，尽管我不确定如果不发送该文件会做什么，因为处理单个文件需要很长时间。该文件的最新更新时间是2008年（在两台服务器上），因此，除了在BETA上更新该文件上的ACL信息外，没有任何其他理由。