Я занимаюсь заменой серверов в системе с Server 2012 R2 к Server 2016. Я полагаю, что для DC лучше всего:
create a `new 2016 DC`
replicate from the `current primary 2012 R2 DC`
transfer the primary roles to the `new 2016 DC`
then decommission the `2012 R2 DC` that is being replaced.
then create a new 'backup 2016 DC'
Однако, когда я начинаю этот процесс, мой текущий backup 2012 R2 DC имеет так много проблем, что я хочу просто удалить его из домена, так как он все равно будет заменен.
Я видел много руководств по удалению DC, но мне не ясно, что происходит на самом деле. Могу ли я предположить, что DC, удаляемый в этих руководствах, по необходимости говорит о резервном DC? Я предполагаю, что это, поскольку удаление последнего DC завершает домен, верно?
Причина, по которой я задаю этот вопрос, заключается в том, что я изначально хочу избавиться от messed up backup DC так что я могу получить primary DC снова в добром здравии и готов повторить свой new 2016 DC. Я обеспокоен, что не смогу отремонтировать current primary DC если он сохраняет какие-либо артефакты своих отношений с текущим messed up backup DC. Я заметил, что когда я запускаю dcdiag на текущем PDC, он зависает, если BDC не в сети. Это вызывает у меня опасения, что основной DC нельзя будет исправить, если я не удалю все подключения к messed up BDC.
Отсюда мой вопрос, как мне убедиться, что backup DC полностью выведен из эксплуатации, а остальные primary DC снова является автономным, то есть все остатки его отношения к BDC удаляются.
Мой DC запускает все: ADDS, DNS, DHCP
(Это своего рода продолжение сообщения от Вот)
Это очень общий вопрос, которому не хватает четкости, поэтому на него сложно ответить. Но я попробую, разбив его на мелкие кусочки.
Как «отсоединить» резервный контроллер домена от основного контроллера домена?
Этот процесс известен как «Понижение». Вы понижаете роль контроллера домена, чтобы избавиться от него. В прошлом это делалось с dcpromo.exe. Сегодня вы делаете это либо с помощью PowerShell. Uninstall-ADDSDomainController или с помощью графического интерфейса диспетчера сервера.
Всегда хочется предпочесть «изящное» понижение в должности. То есть понижение статуса, при котором все необходимые сетевые подключения и репликация AD работают, чтобы вторичный контроллер домена мог сообщить другим контроллерам домена в домене, что его понижают.
Но иногда, если подключение к сети нарушено или репликация нарушена, так что контроллер домена, который вы хотите понизить, не может взаимодействовать с другими контроллерами домена, вам придется «принудительно» или «неуклюже» понизить роль контроллера домена. Это было сделано с dcpromo.exe /forceremoval в прошлом, но в более новых ОС вы используете -Force с помощью вышеупомянутого командлета PowerShell или отметьте параметр «Принудительное удаление» в графическом интерфейсе диспетчера серверов.
Обратной стороной «принудительного» или «некорректного» понижения роли контроллера домена является то, что оно оставляет метаданные в Active Directory на остальных контроллерах домена, которые необходимо очищать вручную. Это потому, что другие DC не знали, что списанный DC был понижен в должности - он просто «исчез». Но это нормально - очистка метаданных старого контроллера домена - это хорошо документированный процесс чего тебе не нужно бояться.
Я полагаю, что лучший план - это:
create aновый 2016 DCreplicate from theтекущий первичный 2012 R2 DCtransfer the primary roles to theновый DC 2016then decommission the2012 R2 DCthat is being replaced. then create a new 'backup 2016 DC'
Я не уверен, что это лучший план. Мне кажется, что после выполнения этого плана вам придется вручную перенастроить всех клиентов в вашей сети, чтобы использовать новые IP-адреса новых контроллеров домена в качестве преобразователей DNS. Может быть, не беда, если у вас 10 клиентов. Но гораздо важнее, если у вас 1000+.
Однако, когда я начинаю этот процесс, моя текущая резервная копия 2012 R2 DC имеет так много проблем, что я хочу просто удалить его из домена, поскольку он все равно будет заменен.
Какие проблемы? Такое заявление пугает меня, потому что оно демонстрирует, что мы недостаточно хорошо понимаем нашу среду, чтобы иметь возможность описать состояние, в котором она находится. И без этого знания трудно понять, какие действия предпринять и каких действий следует избегать.
Я видел много руководств по удалению DC, но мне не ясно, что происходит на самом деле. Могу ли я предположить, что DC, удаляемый в этих руководствах, по необходимости говорит о резервном DC? Я предполагаю, что это, поскольку удаление последнего DC завершает домен, верно?
Как я описывал ранее, когда вы понижаете роль контроллера домена, он удаляет метаданные контроллеров домена из Active Directory. Такие вещи, как объекты подключения репликации, записи DNS, объекты ntDSDSA (параметры NTDS) и т. Д. Это происходит автоматически при постепенном понижении роли. При принудительном удалении вы должны очистить его самостоятельно.
Да, удаление последнего контроллера домена из домена исключает его существование.
В многодоменном лесу для этого также требуется такое же подключение дочернего домена к родительскому. Вы должны сообщить родительскому домену, что дочерний домен уходит до свидания.
Я обеспокоен тем, что не смогу восстановить текущий первичный DC, если он сохранит какие-либо артефакты своих отношений с текущим испорченным резервным DC.
Опять же, я беспокоюсь, что вы можете поставить телегу впереди лошади. Мы не знаем, что это за «проблемы», о которых вы говорите, но, вероятно, лучше сначала вернуть свой домен AD в рабочее состояние, прежде чем приступать к его изменению.
Следовательно, у меня вопрос, как мне убедиться, что резервный контроллер домена полностью выведен из эксплуатации, а оставшийся основной контроллер домена снова является «автономным», т.е. все остатки его отношения к BDC удалены.
Сначала я бы попытался изящно понизить уровень вашего вторичного контроллера домена, а затем проверить на вашем существующем контроллере домена, что объект NTDS Settings из списанного контроллера домена исчез и что у вас нет вопиющих ошибок из dcdiag или в журнале службы каталогов.
Если DC не может быть понижен в должностях изящно, то принудительно и очистите метаданные самостоятельно, используя процедуру, с которой я связался ранее. Если после понижения роли у вас осталось более 1 контроллера домена, убедитесь, что репликация исправна и завершена, прежде чем переходить к повторному назначению любых новых контроллеров домена. (Если у вас остался только 1 DC, то репликации нет.)
Делайте это быстро, но не настолько, чтобы сделать ошибку. Работать с одним контроллером домена рискованно, поэтому вам нужно восстановить и запустить этот вторичный контроллер.
HTH