Я администрирую сеть с контроллерами домена Server 2003. Я планирую заменить контроллеры домена новыми контроллерами домена Server 2008. При запуске DCDIAG я получаю сообщение об ошибке, что контроллеры домена отказали в чем-то вроде «test MachineAccount». Я забыл точное сообщение об ошибке. Это сообщение появляется потому, что предыдущий администратор переместил учетные записи компьютеров контроллера домена из подразделения «Контроллеры домена». Я знал это заранее, но теперь мне интересно, может ли это вызвать новые проблемы во время процесса ADPREP. В некоторых документах, которые я прочитал, возникают проблемы с состоянием Exchange и другими аспектами инфраструктуры, когда объекты перемещаются из подразделения контроллеров домена. На сегодняшний день это не было моим опытом, так как сейчас все в порядке. Мне интересно, есть ли у кого-нибудь еще опыт в этой области. Я бы не хотел снова перемещать объекты Контроллера домена, пока не охватил свои базы и не спланировал заранее.
Спасибо.
Из http://technet.microsoft.com/en-us/library/cc728418%28WS.10%29.aspx
Подразделение контроллера домена
Когда контроллеры домена добавляются в домен, их объекты компьютеров автоматически добавляются в подразделение контроллера домена. К этому подразделению применен набор политик по умолчанию. Чтобы гарантировать, что эти политики применяются единообразно ко всем контроллерам домена, рекомендуется не перемещать объекты компьютеров контроллеров домена из этого подразделения. Несоблюдение политик по умолчанию может привести к неправильной работе контроллера домена.
Я думаю, что самая большая проблема возникает, когда контроллеры домена размещаются в отдельных подразделениях, к которым не применена политика контроллеров домена по умолчанию, хотя было бы неплохо сохранить их в подразделении контроллеров домена, если они в любом случае просто находятся в контейнере с другим именем.
Просто чтобы добавить свой собственный опыт читателям:
Я переместил свои учетные записи DC в другое подразделение при реорганизации структуры активного каталога, а также связал ту же политику с новым подразделением. Все казалось прекрасным, пока я не перезапустил одну из моих машин с SQL Server.
После перезагрузки машина не загрузилась (зависает на экране «Подождите ...» во время загрузки). Я протестировал свой резервный SQL Server, чтобы убедиться, что он работает, и увидел, что учетная запись администратора не может войти в систему. Мне потребовалось два дня (хорошо, что система еще не была запущена!), Чтобы понять, что учетная запись DC перемещается в другой OU, вызывающий сбой запуска службы KDS (службы распределения ключей). А в случае сбоя ни одна из учетных записей службы AD не будет работать.
Перемещение учетной записи DC назад устранило все проблемы.
Я только предполагаю, что KDS каким-то образом использует полный путь к DC ...
Примечание: это было в среде Windows Server 2012.
Теоретически вы можете это сделать, но, как минимум, вам также потребуется связать GPO политики контроллера домена по умолчанию с новым подразделением, а также обновить что-либо в разделе конфигурации, который ссылается на контроллеры домена по различающемуся имени, чтобы отразить новое расположение. Также следует рассмотреть вопрос о стороннем программном обеспечении - некоторые из них могут ожидать Контроллеры домена должны быть в контроллерах домена и сильно кричать, если это не так. Наконец, если что-то использует файлы конфигурации вместо AD для хранения своей конфигурации, эти файлы конфигурации необходимо будет просмотреть. в заключение Ну наконец тополная проверка всего, что в настоящее время работает, включая перезагрузку серверов для очистки всех кэшированных ссылок, может показаться правильной, поскольку некоторые проблемы могут проявляться только во время запуска компьютера или службы.
Если все это звучит немного "а, что?" тогда вам не следует этого делать. ПЛОХОЙ предыдущий админ!