Почему моя папка PolicyDefintions переименовывается?
Я пытался обновить наш Центральный магазин новыми политиками для Windows 10. Изначально я сделал копию магазина в том же месте и на всякий случай назвал его .bak.
Я успешно скопировал локальную папку определений в Магазин. Однако сейчас я смотрю и вижу имена папок:
PolicyDefinitions_NTFRS_45859c8a
PolicyDefinitions_NTFRS_49198af0
Неудивительно, что когда я переименовываю одну из них, чтобы удалить новый суффикс, он довольно быстро присоединяется снова. Я вношу эти изменения на одном из контроллеров домена. Всего у нас 4 сайта AD и 6 DC.
Это связано с FRS, но я не вижу связанных с этим ошибок в журналах. Я не уверен, в чем проблема. Репликация все еще работает, поскольку новые имена видны на всех моих других DC. Однако групповая политика не извлекает шаблоны из центрального хранилища; просто мой локальный компьютер.
Я думаю, что Вы создали конфликт FRS, имея несколько одноименных папок в реплицируемых местах, как описано в MS KB 328492
SYMPTOMS. Служба репликации файлов (FRS) может изменять имя файла папки путем добавления "NTFRS_xxxxxxxx" к имени папки.
Примечание В данном примере xxxxxxx представляет собой восемь случайных шестнадцатиричных цифры.
Ниже приведен пример двух часто меняющихся папок:
07/29/2002 09:58a Политики 07/29/2002 09:58a Политики_NTFRS_000add30 07/29/2002 10:18a скрипты 07/29/2002 10:02p скрипты_NTFRS_000874bb
CAUSE Когда два пользователя создают папку с одним и тем же именем на двух разных реплики, служба репликации файлов (FRS) обнаруживает конфликт имен во время репликации.
Одна из операций создания имеет приоритет, и в этой папке сохраняется имя. Имя другой папки изменено.
Я предполагаю, что это произошло, когда вы переименовали папку дефиниций политики, а затем ?добавили другую папку дефиниций политики. Я бы посоветовал удалить все папки дефиниций политик на несколько дней и позволить репликации очистить их от всех DC, а затем заново добавить папку дефиниций политик центрального хранилища
.Не эта конкретная проблема, но я читал, что могут возникнуть проблемы, связанные с лесами AD, которые были модернизированы в период с 2003 по 2008 год. Так было в случае с моим. Решение, которого я придерживался, заключалось в миграции SYSVOL, разделяющей ответственность с File Replication Services(FRS) на DFSR. Чтобы это работало, ваш функциональный уровень домена должен быть как минимум 2008
Полные инструкции доступны на TechNet для процедуры миграции. Оговорки и подробности могут быть слишком длинными для этого формата, поскольку существует множество углов, которые необходимо учитывать. В его простейшем из вас запущена утилита dfsrmig на эмуляторе PDC.
Постепенно поднимайте Глобальное Государство с Начала, Подготовки, Реплицирования до Уничтожения. Убедитесь, что ресурс sysvol доступен, и что данные копируются в новое место расположения ресурса на этих шагах (в моем случае это папка с именем sysvol_dfsr в каталоге windows.) Переключите GlobalState на следующий уровень только после того, как текущее состояние будет одинаковым для всех DC.
Вы можете использовать dfsrmig /GetMigrationState для проверки текущего уровня, чтобы знать, когда вы можете комфортно продолжить работу.
Как только вы достигнете GlobalState Redirected (запустив dfsrmig /SetGlobalState 2 и подтвердив это), в DFSR должна появиться репликация акций sysvol. Подтвердите и протестируйте репликацию.
Вы можете откатить весь процесс в этом состоянии, изменив Глобальное состояние обратно. Если вы уверены, что все работает, то последним шагом будет удаление старой настройки FRS. Изменение состояния GlobalState на Eliminated завершит этот процесс: dfsrmig /SetGlobalState 3 .