Существует две точки зрения на процесс вывода из эксплуатации контроллеров домена Active Directory, которые активно используются в качестве DNS-серверов.
Добавьте IP-адрес исходящего контроллера домена в новый контроллер домена и убедитесь, что DNS прослушивает этот адрес.
Понизьте уровень старого контроллера домена, оставьте на нем роль DNS и настройте глобальный сервер пересылки DNS на новый сервер.
Очевидно, что оба являются временными промежутками, пока все серверы и устройства не будут настроены на использование основного IP-адреса нового сервера, но иногда этот переходный период может быть относительно длительным в зависимости от размера среды.
Есть ли здесь четкая передовая практика?
Дорога в ад Active Directory вымощена временными бинтами. Назначение IP-адреса списанного или подлежащего списанию DNS-сервера вашему новому DC и DNS-серверу - это временная перевязка.
Как отметил @gravyface в комментариях, в идеальном сценарии вы бы изменили все области DHCP и статические конфигурации, чтобы обновить предпочтение DNS клиента на новый IP-адрес вместо старого, прежде чем полностью списать старый DC.
Я понимаю, что уверенность в том, что все клиенты были перенастроены, не всегда возможно вовремя, но я определенно рассматриваю вариант номер 2 (пересылка всего пространства имен) как наименее нежелательный вариант.
В дополнение к тому, что старый сервер может пересылать запросы даже после его понижения, я бы рекомендовал включить ведение журнала отладки для входящих запросов на DNS-сервере - это немного упрощает оценку не только если клиенты по-прежнему указывают на старый DNS-сервер, но также идентифицируют упомянутых клиентов.
При этом, я думаю, вы упустили очевидный третий вариант: Шлейфовые зоны!
Я не решаюсь отвечать, потому что я думаю, что это скорее вопрос «для обсуждения», чем строго ответ на вопрос ... но сегодня ленивое субботнее утро, так что я все равно отвечу.
Есть ли здесь четкая передовая практика?
Нет. (Блин, может быть, это был простой ответ ...)
Microsoft предоставляет очень общий, без труда Googleable Руководство Bingable о том, как понизить роль контроллеров домена и выполнить миграцию AD и DNS, но я не буду утруждать себя ссылками на них и не буду делать вид, что они отвечают на ваш конкретный вопрос, потому что Microsoft, очевидно, не может документировать каждый конкретный случай для каждого другого среда организации.
Таким образом, системные администраторы / инженеры, подобные нам, должны заполнять пробелы с помощью наших собственных знаний и опыта, в то время как Microsoft не написала специальный скрипт только для нас, и это то, что делает нас ценными.
Я могу привести вам пример того, что мы сделали для решения этой же проблемы, поскольку я также работаю в глобальных средах с десятками или более контроллерами домена, разрозненными лесами AD, сосуществующими в одних и тех же сетях, устройствами, отличными от Windows, также потребляющими DNS-сервисы от одних и тех же контроллеров домена и т. Д. Перемещение в новые центры обработки данных и выход из старых, необходимость перехода на новое оборудование или новые версии ОС, а также простая старая бизнес-политика - все это возможные причины, по которым нам потребуется списать контроллеры домена, которые потенциально все еще использовались. А когда у вас есть несколько разнородных организаций, которые в настоящее время используют эти DC / DNS-серверы, это обычно изнурительный, длительный процесс перенастройки каждого клиента (многие из которых могут быть не под вашим контролем) перед списанием контроллера домена с участием менеджеров проектов, заявок различным другим командам, работа которых может занять дни или недели и т. д.
Вот почему я говорю, что не думаю, что кто-то может дать вам в ответ на этот вопрос. Есть тысячи способов сделать это, и некоторые из них будут лучше других в зависимости от структуры и потребностей вашей организации.
Что-то, что мы сделали, чтобы решить эту проблему, - это создать VIP для каждого центра обработки данных и объединить все контроллеры домена в этом центре обработки данных за этим VIP. (Этот VIP предназначен для службы DNS только по понятным причинам я не Говоря о балансировке нагрузки Kerberos и LDAP.) Таким образом, клиенты могут быть настроены на использование этого виртуального IP-адреса в качестве преобразователя DNS, и мы можем добавлять и удалять контроллеры домена за этим виртуальным IP-адресом в любое время и в любом удобном случае.
Но вы не стоите перед проблемой ... поэтому, учитывая предоставленные вами варианты:
Добавьте IP-адрес исходящего контроллера домена в новый контроллер домена и убедитесь, что DNS прослушивает этот адрес.
Понизьте уровень старого контроллера домена, оставьте на нем роль DNS и настройте глобальный сервер пересылки DNS на новый сервер.
Я бы выбрал вариант №1, потому что ваша цель - как можно быстрее списать старый сервер, а вариант №2 не поможет вам избавиться от старого сервера. При варианте №2 наличие сервера по-прежнему необходимо. Я бы также не согласился с предложением Матиаса Р. Джессена о заглушках, потому что, опять же, вам все равно придется оставить старый сервер на месте и в рабочем состоянии, что не способствует достижению вашей конечной цели.
С вариантом №1, каким бы уродливым он ни был, вы можете вывести старый сервер из эксплуатации, потребовать экономии средств для своей компании, избежать необходимости платить еще один месяц за аренду этого центра обработки данных и получить награду за то, что вы являетесь таким хорошим сотрудником.
Редактировать: Подумав еще немного о нашем чате, я думаю, что, возможно, я спроецировал на вас свои собственные требования, потому что сейчас у меня есть требования к немедленному использованию некоторых вещей, так что это было свежо в моей голове. Похоже, у вас нет особой необходимости отключать сервер как можно скорее.
Тем не менее, я не изменяю свое предложение, поскольку все равно предпочел бы это. Привязка дополнительного IP-адреса к существующему контроллеру домена хорошо работала для меня в прошлом в очень похожих сценариях, и я предпочел бы это, чем иметь странный рудиментарный придаток сервера, сидящего там неопределенное количество времени.