问题：有没有办法让这 350,000 个文件积压完成得更快？对于几乎每个文件，唯一的变化是对每个受影响文件的 ACL 进行了更改。某些文件已更改内容，但在这种情况下这不是常见情况。
这可能是固定的。经过一段时间和验证后，我将编辑此文本以确认成功/失败。在此问题文本的末尾，我详细介绍了最近可能已修复它的更改。
我们有一个 DFSR 复制组，大约有 450,000 个文件，占用 1.5TB 空间。在这种情况下，有两台相距约 500 英里的 Windows Server 2008 R2 服务器。还有其他服务器，但它们不参与此复制组。Server ALPHA 是主服务器，也是大部分员工使用的服务器。Server BETA 是远程办公室的服务器，不太忙。
这是此复制组（在 Google Drive 上托管的 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）
我相信自从我上次在 ALPHA 和 BETA 上重新启动 DFSR 服务以来，发生了 30.85MB/18.1GB。如果是这样，这表明即使花费了很长时间（比我认为应该花费的时间更长），它实际上并没有通过网络传输文件内容。 …
Windows DFS 推荐如何适用于远离办公室的笔记本电脑？
[编辑 2014-11-26] 我已经了解站点是如何由子网等定义的。但我想知道的是，根本不适合任何站点的用户会发生什么？例如，家庭用户通过 VPN。由于 VPN 系统的工作方式，VPN 不提供任何站点内的 IP，因此这无助于定义站点。它是否将所有 DFS 命名空间目标视为完全相同，因为此时客户端位于零个站点？有什么方法可以鼓励 DFSN 将一个站点中的 DFSN 目标视为基于邻近性或用户常用站点的首选？（我知道怎么说“当一切都平等时，将 X 服务器视为首选”，但这不是我在这里要求的。）
本文的其余部分只是您感兴趣或娱乐的背景。
我的印象是笔记本电脑会保留它所在的最后一个站点或它连接到的最后一个 DC 的站点。然后该站点将出于推荐排名的目的确定该笔记本电脑当前所在的站点。
我问的原因是因为我们让一些笔记本电脑用户得到了一些他们从未真正去过的办公室的奇怪推荐。这些笔记本电脑与它们应该连接到的其他站点中的服务器连接良好。在这种情况下，奇怪的推荐目标是一个不可靠的服务器。如果它基于某种速度或可靠性指标，那就完全错了。问题只是第一行，本文的其余部分只是背景。
所涉及的硬件/软件是：适用于所有事物的 Windows 2008 R2 服务器；Windows 7 64 位和 Windows XP 32 位笔记本电脑。
这是一个关于 DFS 命名空间的问题，而不是关于 DFS 复制的问题。
DFS 的工作原理：DFS 流程和交互说明如下：
启用最便宜的目标选择后，DFS 将按以下顺序将目标放置在引用中：
与客户端位于同一站点的目标以随机顺序列在推荐的顶部。
客户站点之外的目标按最低成本到最高成本的顺序列出。具有相同成本的推荐被分组在一起，并且在每个组中，目标以随机顺序列出。
如果笔记本电脑位于客户办公室、酒店、家庭等，它是否仍被视为在站点内？如果是这样，我假设该站点将用于上述第一组目标。如果它不在站点内，我认为它会完全跳过第一组并随机分配目标。但我们看到的行为是，它更像是后者而不是前者。
编辑：（太平洋时间 5 月 21 日凌晨 3 点）
似乎将“覆盖推荐顺序”设置为“同等成本目标中的第一个”的文件夹变得愚蠢。愚蠢的部分是具有该启用的目标似乎是最后一个，而不是第一个。我正在取消这些设置，看看会发生什么。稍后汇报。
有没有办法以比使用更有效的方式监控 DFSR 积压dfsrdiag.exe backlog？
我写了一个程序，它dfsrdiag.exe backlog /smem:alpha /rmem:beta /rgname:domain\namespace\foldername /rfname:foldername以五分钟的间隔在积压计数中啜饮。每次运行时，需要相当长的时间（2 到 5 分钟之间）才能获得结果值。这意味着它最终会运行几分钟来收集信息，然后延迟五分钟。感觉以某种方式获取这些信息可能很昂贵。它还返回积压工作中的前 100 个文件。我真的只想要积压数量，而不关心文件本身。这用于创建历史图表。
这些 DFSR 对等方的信息：四台服务器上的 Windows 2008 R2、通过 50-100Mb Internet 连接连接的三个远程办公室、30 个复制组、几个复制组的文件总大小非常大（每个 1-2TB）尽管大多数都很小（500MB） -10GB）。