Передо мной стояла достаточно легкая задача по переносу адреса и имени контроллера домена на новый сервер. Её можно разбить на следующие подзадачи:

1. проверить текущих владельцев FSMO-ролей,  при необходимости – передать их на другой сервер, остающийся в работе;
2. проверить настройки DNS, чтобы оба сервера использовали в первую очередь рабочий DNS;
3. проверить статусы репликации NTDS (AD) и SYSVOL;
4. убедившись, что все работает, понизить контроллер домена, сменить имя и адрес;
5. назначить имя и адрес новому готовому серверу;
6. поднять на нем роль контроллера домена.

Как видите, ничего сложного, поэтому я оценил общую трудоемкость задачи в 4 часа, как обычно заложив запас под 100% на работы.

Кстати, в статье заложена пасхалочка-бонус 🙂

Давайте вместе посмотрим, что же из этого вышло…

Для удобства отчета, я начинаю работы в 0:00.

0:00 – 0:30 – подготовительные работы

Заходим по RDP на оба контроллера (удаляемый – DC01, рабочий – DC02). Проверяем статус репликации NTDS и SYSVOL. Настраиваем оба контроллера на предпочтительный DNS-сервер DC02. Проверяем, что контроллер DC02 настроен как глобальный каталог. Проверяем, кто является владельцем FSMO-ролей – DC02.

0:30 – 0:45 – первый заход на удаление роли AD

Запускаем Server Manager и ждем минут 5. Старенький IBM, отметивший 10-летний юбилей, не очень быстр. Запускаем удаление служб AD и ждем еще некоторое время. Получаем от ворот поворот – перед удалением служб AD надо удалить службы сертификатов AD.

0:45 – 2:50 – удаление служб сертификатов AD

Запускаем удаление служб сертификатов AD. Каких-то 30 минут – и службы почти удалены, необходимо перезагрузиться.

На всякий случай уточняю у коллег – есть ли удаленная консоль сервера? “Нет” – радостно отвечают мне. “Лицензии на RSA нет, IP KVM в серверной отсутствует”.

“Ну нет, так нет” – вздыхаю я, отправляя сервер в перезагрузку…

За час с лишним я прошел стадии от принятия до непринятия поездки в серверную.

В качестве диагностики использовался ping -t DC01 и оценка количества потерянных пакетов.

Наконец, сервер загрузился и еще минут 20 продолжал выпиливать службы.

2:50 – 3:40 – второй заход на удаление роли AD

Ну что, сервер загрузился, и теперь мы можем продолжить удаление роли AD. Запускаем наш замечательный визард и на этапе удаления получаем замечательную ошибку:

“Доменным службам Active Directory не удалось передать оставшиеся в разделе DC=DomainDnsZones,DC=lan,DC=local данные
контроллеру домена Active Directory \\LOREN-DNS.lan.local.

“В службе каталогов утеряна обязательная информация и невозможно определить владельца передаваемых монопольных операций (FSMO).”

Достаточно известная, как оказалось, ошибка. В качестве лечения советуют взять ADSIEdit и отредактировать путь к владельцу разделов приложений DNS (DomainDNSZones и ForestDNSZones) на FSMO-мастере инфраструктуры (DC02).

“Да ну, наркоманство какое-то” – подумал я и пошел дальше искать.

Проверяю содержимое параметра fSMORoleOwner:

CN=NTDS Settings\0ADEL:de6bd410-c2c6-459d-bf47-880931f9c8e2,CN=DC01\0ADEL:158594b2-ced9-4a95-acef-eb0ff2557f3c,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lan,DC=local

“0ADEL” – БЛИН!!!111

“Не наркоманство” – подумал я спустя некоторое время. Microsoft даже сподобился написать скрипт, исправляющий эту проблему…

Исправляю значение, запускаю повторно процедуру удаления контроллера домена.

“Операция не выполнена по следующей причине: Доменным службам Active Directory не удается настроить учетную запись компьютера DC01$ на удаленном контроллере домена Active Directory \\DC02: “Отказано в доступе”.

3:40 – 5:00 – третий заход на удаление роли AD

Первым делом проверяю, что на учетной записи ПК отсутствует защита от удаления.

Затем перебираю несколько учеток с правами администратора домена и предприятия.

Затем проверяю результирующие права на учетную запись ПК DC01$ – предоставлены полные права…

Опять начинаю гуглить и наталкиваюсь на подобную статью от MS: ошибка в правах доступа может выдаваться, если учетной записи пользователя, используемой для выполнения DCPROMO, не предоставлено право: “Сделать учетные записи компьютеров и пользователей доверенными для делегирования”.

Выполняю whoami /all и…

Не предоставлено, хотя данное право предоставляется по умолчанию членам группы администраторы. Проверяем политику управления доменными контроллерами:

Добавляем в групповую политику это право для группы Администраторы, применяем политику (gpupdate /force) и перезаходим в систему.

Контрольная проверка через whoami /all показывает наличие этого права. Повторяем удаление роли AD.

УРА!!!111

ВАЖНО: мы удалили данные AD, однако роль DNS с пустым содержимым осталась. Чтобы после перезагрузки сервер не вносил смуту в клиентов, переведите службу DNS в состояние “Отключено”.

5:00 – 5:50 – зачистка старых ролей и поднятие нового контроллера домена

После загрузки DC01 удаляем с него роли AD&DNS, меняем имя и IP и отправляем в очередную перезагрузку. Для перезагрузки по расписанию используем утилиту shutdown: shutdown -r -t 60.

Проверив через ping, что адрес недоступен, идем и захватываем его на новом сервере. Затем переименовываем его в DC01 и перезагружаем.

После успешной загрузки устанавливаем роли AD&DNS, затем настраиваем AD, добавляя этот сервер как дополнительный контроллер домена.

Перезагружаемся, проверяем успешность репликации и отсутствие ошибок в логе DFS репликации. А также отсутствие ошибок в других журналах.

Вывод

Говорят, что в правильно заданном вопросе содержится половина ответа. Удачи всем с формулировками.