Миграция объектов
На сломанном контроллере устанавливаем Visual Redistributable C++ 2015. Устанавливаем Microsoft SQL Express 2017. Устанавливаем Active Directory Migration Tool. Подразумевается, что связь между контроллерами время от времени теряется, потому перезагружаем сломанный и основной контроллеры. Далее запускаем ADMT, выполняем "Computer Migration Wizard". Указываем домен, с которого хотим забрать данные и выбираем сломанный контроллер. Указываем домен, на который хотим перенести данные и выбираем основной сервер. Выбираем какие компьютеры хотим перенести и ставим все галочки. При миграции компьютеров мигрируют и учетки пользователей со всеми правами, шарами, принтерами и т.д. Если вы уже успели отдельно перенести аккаунты пользователей и теперь собираетесь перенести компьютеры, то это не лучшая затея, поскольку при этом права пользователей и т.д. не будут перенесены и начнутся различные проблемы. И если в ходе решения этих проблем решите вывести компы с домена и вручную или скриптом подключить к основному контроллеру, то вас ждет разочарование в виде ошибки "такой Service Principal Name уже существует". Хотя при поиске этих самых SPN оказывается, что их нет и откуда берется конфликт не понятно. Единственное решение в такой ситуации это переименование компьютеров. Так, что решайте заранее или вы переносите только аккаунты пользователей и вручную переподключаете все компы или сразу переносите все компы. Когда перенос закончится переходим к этапу удаления сломанного контроллера.
Удаляем сломанный контроллер
Подключаемся к сломанному контроллеру. Открываем оснастку «компьютеры и пользователи Active Directory» и меняем пароль локального администратора. Поскольку новые версии стандартного клиента RDP (mstsc) стали пытаться автоматически приписать к логину домен или имя текущего ПК (даже если явно указывать домен или имя сервера), то есть шанс, что не сможем подцепиться удаленно (у меня были с этим проблемы). Потому из Microsoft Store лучше на всякий случай установить приложение "Удаленный рабочий стол".
Поскольку связь с основным контроллером барахлит и удалить его правильным образом не дадут, то просто удаляем роль Active Directory при этом будет понижена его роль. Запускаем менеджер сервера и выбираем удалить роли. Выбираем роль Active Directory, на что предложат понизить роль сервера. Понижаем и не забываем установить галочку принудительного удаления. По ходу прогресса сервер сам перезагрузится.
Чистим метаданные
Подключаемся к основному контроллеру. Запускаем командную строку и вызываем утилиту ntdsutil.
Подключаемся к серверу:
matadata cleanup
connections
connect to server localhost
quitУдаляем данные контекста именования:
select operation target
list naming contexts
select naming context <номер выбора>
quit
remove selected naming contextУдаляем данные о домене:
select operation target
list domains
select domain <номер выбора>
quit
remove selected domain
quit
quitЗапускаем оснастку DNS и открываем зоны прямого просмотра. Ищем данные относящие к сломанному контроллеру и беспощадно удаляем. Загвоздка может возникнуть в разделе _msdcs при удалении NS записи. Для этого надо кликнуть правой кнопкой по записи и зайти в свойства. Выбрать FQDN сломанного контроллера и удалить.
Теперь запускаем оснастку "Active Directory сайты и службы". Подсеть переводим на другой сайт, а в самом сайте в servers, кликаем правой кнопкой по серверу и выбираем удалить. В подтверждающем действие диалоговом окне устанавливаем галочку "удалить поддерево". После удаления сервера таким же образом удаляем и сам сайт. На этом очситка метаданных завершена и можно подключать сервер заново, а поскольку дело это не хитрое да и лень печатать, то просто вставлю видеоролик.
Зачем нужны сайты и сети?
Ну тут все просто. Сайты нужны, для группировки сетей и серверов, чтобы компы с определенной сети обращались к конкретному серверу (например стоящем в их локальной сети). К примеру, создаем сайт petersburg. Добавляем в него контроллер домена, который стоит в Питере. Создаем сеть и указываем адресацию и диапазон Питерской сети. Также добавляем эту сеть в сайт petersburg. Теперь компьютеры в Питере будут обращаться к своему серверу и это быстрее, чем если бы они обращались к серверу скажем в Владивостоке, а значит при логине на комп у пользователей не будет никаких подвисаний в ожидании передачи данных по LDAP.