![DFS-R 事件 ID 4412 DFS 复制服务检测到文件在多台服务器上发生更改](https://linux22.com/image/548832/DFS-R%20%E4%BA%8B%E4%BB%B6%20ID%204412%20DFS%20%E5%A4%8D%E5%88%B6%E6%9C%8D%E5%8A%A1%E6%A3%80%E6%B5%8B%E5%88%B0%E6%96%87%E4%BB%B6%E5%9C%A8%E5%A4%9A%E5%8F%B0%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E5%8F%91%E7%94%9F%E6%9B%B4%E6%94%B9.png)
为了准备 DFS 复制,我们曾经robocopy /DATSOU...
将共享文件夹(~170G)的内容复制到另一台服务器。
之后,使用这两个文件夹配置一个DFS复制组。
现在,几个小时后,我们收到大量 4412 错误,提示文件在多台服务器上被更改。但事实并非如此。文件时间等都相同(访问时间除外),我可以在将“获胜”文件与 DfsrPrivate\ConflictAndDeleted 中的已删除文件进行比较时验证这一点。这里发生了什么?
答案1
补充一下 syneticon-dj 的回复,根据您执行 robocopy 的方式,源和目标上的权限可能不同。如果是这种情况,文件哈希将不同并导致 4412 事件。它仍应使用 RDC 来最小化从源拉取的内容。
http://blogs.technet.com/b/askds/archive/2008/02/12/get-out-and-push-getting-the-most-out-of-dfsr-pre-staging.aspx讨论了这个问题。请注意,你会发现它删除了基于 robocopy 的详细信息,以指向http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx。这是有关预播种 DFSR 的权威链接。
答案2
你应该使用
dfsrdiag filehash /filepath:<yourfile>
在两台服务器上对同一个文件进行检查,以检查 DFS-R 是否会将该文件识别为“相同”,如中所述KB947726。我怀疑,事实并非如此。