我试图用Windows 10的新策略更新我们的中央商店。最初，我在同一位置复制了一个商店，并将其命名为.bak以防万一。
我将本地定义文件夹成功复制到存储中。 不过，我现在看，看到文件夹名称：
PolicyDefinitions_NTFRS_45859c8a PolicyDefinitions_NTFRS_49198af0 毫不奇怪，当我重命名其中一个放弃新的后缀时，它很快就被重新绑定了。 我正在其中一个域控制器上进行这些更改。 我们有4个广告网站和6个DC。
所以这与FRS有关，但是在日志中我看不到与此有关的错误。 我不确定这是什么问题。 复制似乎仍在工作，因为新的名字在我所有的其他DC上都能看到。 然而，组策略不会从中央存储中提取模板; 只是我的本地电脑。
我认为您已经创build了一个FRS冲突通过在复制位置具有相同名称的多个文件夹，如MS KB 328492
症状文件复制服务（FRS）可能通过添加“NTFRS_xxxxxxxx”文件夹名称更改文件夹的名称。
注意在这个例子中，xxxxxxxx表示八个随机的hex数字。
以下是两个经常更改的文件夹的示例：
07/29/2002 09：58a策略07/29/2002 09：58a Policies_NTFRS_000add30 07/29/2002 10：18a脚本07/29/2002 10：02p scripts_NTFRS_000874bb
原因当两个用户在两个不同副本上创build同名文件夹时，文件复制服务（FRS）会在复制过程中检测到名称冲突。
其中一个创build操作优先，该文件夹保留名称。 其他文件夹名称已更改。
我猜这是在你重新命名你的策略定义文件夹然后添加另一个策略定义文件夹时发生的。 我build议几天后删除所有的策略定义文件夹，让复制清除它们的所有数据中心，然后重新添加中央存储策略定义文件夹。
不是这个具体的问题，但我已经读过，可能会出现从2003年到2008年升级的广告森林问题。这是我的情况。 我遵循的解决scheme是将SYSVOL共享责任从文件复制服务（FRS）迁移到DFSR。 为了这个工作，你的域名function级别至less要在2008年
TechNet上提供了有关迁移过程的完整说明。 这种格式的警告和细节可能太长，因为有很多angular度需要考虑。 最简单的方法是在PDC模拟器上运行dfsrmig实用程序。
逐步将GlobalState从开始，准备，复制到消除。 validationsysvol共享是否可用，以及这些步骤中是否将数据复制到新的共享位置（在我的情况下，在windows目录中是一个名为sysvol_dfsr的文件夹）。只有当前状态相同时才将GlobalState更改为下一级所有的DC。
您可以使用dfsrmig /GetMigrationState来validation当前的级别，以便知道何时可以继续进行。
一旦到达GlobalStateredirect（通过运行dfsrmig /SetGlobalState 2并确认），DFSR现在应该托pipe复制sysvol共享。 确认并testing复制。
您可以通过将全局状态更改回来，将整个过程恢复到此状态。 如果您确信一切正常，那么最后一步就是删除旧的FRS设置。 将GlobalState更改为Eliminated将最终确定： dfsrmig /SetGlobalState 3 。