我们有一个DFS基础架构，包含3台服务器和93个复制文件夹。 从DFSpipe理控制台运行运行状况报告时，其中一个文件夹的状态列为“未初始化”。 此文件夹以前已正常复制。
重新启动所有3个DFS服务器可解决“未初始化”状态，并且该文件夹似乎开始正常复制。 然而，通常在一周之内，它会很快回落到“未初始化”的状态。
我一直在DFS中监控这个文件夹，而且在很短的时间内就会出现大量的变化，比如在工作日的清晨，复制积压将跳到超过10万个条目。 通常情况下，积压在接下来的几个小时内迅速下降，所以我并不担心。
但是，此“未初始化”状态现在意味着在文件夹具有此状态的服务器上完全不会发生复制。 这意味着现在我们有一个问题。 我没有跟踪具体的文件或原因，但我已经向桌面团队发出了查询，以帮助确定导致积压的原因。
我没有发现与此文件夹或状态相关的事件日志错误。 我想也许在卷上的文件更改的大量可能会导致日记程序包装错误，但我还没有发现任何与USN日记封装相关的事件日志。 该文件夹确实存在一致的共享冲突，但是在这个“未初始化”问题之前，一旦文件closures，这些文件都将最终自行解决。
我的研究结果为零，除了可能的configurationxml损坏，但在这些情况下，问题只是与sysvol复制。
我唯一的假设是，当差异数量超过某个阈值时，DFSR会自动将状态设置为“未初始化”。 但是我无法testing这个假设，我找不到任何文档来备份它。 即使这是真的，我不知道如何去“重新初始化”文件夹。
涉及的服务器是：
答：发送服务器，2008r2，暂存配额25 GB，状态：正常
B：接收服务器，2008r2，暂存配额175 GB，状态：未初始化
C：接收服务器，2012r2，暂存配额25 GB，状态：正常
所有三个服务器都是AD域控制器的双重任务。 所有93个已复制的文件夹都位于同一个复制组中，因此删除并重新创buildRG将是时间过于紧迫的。 当第一次出现这个问题时，一小撮其他文件夹也显示出这种状态，但是只有这一个文件夹在重新启动后出现问题。 受影响的文件夹大小为202 GB，共有547,252个文件。
是什么导致文件夹变成“未初始化”，我该如何解决这个问题？
– 编辑 – 一些更多的信息。 接收服务器昨天午夜（~36小时前）重新启动。 这使文件夹进入“正常”状态，积压开始产生。 当我昨天检查，这个文件夹的积压是205,662个文件。 当我今天检查时，积压是579,447个文件。 该文件夹目前只有551,706个文件。 积压量大于文件夹大小。 DFS健康报告显示851,592个文件已经收到在这个文件夹中。 到目前为止，没有其他文件夹有这样的问题。
我不知道是否积压导致复制失败，或者复制失败并导致积压，或者是否存在导致复制失败和积压失败的基础数据库或日志日志损坏。 在这两种情况下，我也不知道如何解决问题。
现在有一个93个文件夹的复制组。 我准备把它吹走，configuration93个复制组。 如果这样做不能解决问题，至less可以使问题更容易排除。