Для подготовки репликации DFS мы использовали robocopy /DATSOU... для копирования содержимого общей папки (~ 170G) на другой сервер.
После этого была настроена группа репликации DFS с двумя папками.
Теперь, через час, мы получаем массу ошибок 4412, говорящих о том, что файл был изменен на нескольких серверах. Это определенно не так. Время файлов и т. Д. Одинаковы (кроме времени доступа), что я могу проверить, сравнивая "выигравшие" файлы с удаленными в DfsrPrivate \ ConflictAndDeleted. Что здесь происходит?
Вы должны использовать
dfsrdiag filehash /filepath:<yourfile>
на обоих серверах для одного и того же файла, чтобы проверить, распознает ли DFS-R файл как «такой же», как описано в KB947726. Я подозреваю, что это не так.
Чтобы добавить к ответу от 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 обсуждает этот вопрос. Обратите внимание, что вы обнаружите, что он вычеркивает детали, основанные на роботах, чтобы указать http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx . Это окончательная ссылка на предварительную рассылку DFSR.