Есть недавно созданный DC (на VM), который является DC для Tree Domain в нашем лесу, и у него есть проблемы. К сожалению, это был единственный DC, который я повысил для этого Domain, когда он упал.
Операционная система находится в плохом состоянии (классы не зарегистрированы, DCOM находится в автономном режиме, SFC и DISM не работают), а также отсутствуют доступные для настройки сетевые адаптеры, поэтому я не могу связаться с ней, чтобы назначить дополнительный контроллер домена.
Итак, на этом этапе можно перенять роли автономного контроллера домена у контроллера домена в другом дереве доменов (том же лесу).
Или есть вариант получше?
Я открыт для устранения вышеуказанных проблем, но до сих пор все, что я делал, обычно заканчивалось "вам просто нужно пересоздать образ". Конечно, даже если я восстановлю сеть и смогу повысить еще один DC, я все равно уберу эту VM.
Я надеюсь избежать ручного удаления неподключенного домена из моего леса, чтобы иметь возможность восстановить его.
ОБНОВЛЯТЬ
После того, как я узнал, что мой сетевой администратор включил защиту портов на коммутаторе с хостом виртуальной машины, мне удалось подключить сломанный контроллер домена к сети.
Машина все еще сильно сломана, но теперь она работает как почти полностью функциональный контроллер домена (не уверен, как).
Моя проблема теперь в том, что когда я попытался добавить вторичный DC и переместить роли FSMO, новый DC не завершил свою первоначальную репликацию правильно. Я смог переместить роли PDC, RID и Infrastructure, но сервер не реплицируется должным образом, и поскольку он фактически не инициализировался, я не могу выполнить восстановление D2/D4 (не могу редактировать атрибуты ADSI).
Я попытался вернуть OperationalRoles обратно, но получил ошибку об отсутствии двоичного файла из-за сломанного контроллера домена.
По сути, мне нужно запустить второй DC, чтобы я мог извлечь сломанный DC и пересоздать образ (я не могу понизить уровень сломанного DC из-за отсутствующих двоичных файлов).
решение1
Итак, мне удалось решить большую часть этой проблемы, и вот что я обнаружил.
Мой сетевой администратор включил безопасность портов в режиме ограничения и значение по умолчанию для числа MAC-адресов, поэтому коммутатор был черной дырой для всех моих виртуальных машин, но не для хостов. Как только это было исправлено, я снова получил сеть на PDC и повысил ADC.
ADC не выполнил свою начальную синхронизацию правильно. Поскольку Powershell был сломан на PDC, я использовал Powershell на недавно повышенном, но все еще сломанном ADC и переместил роли PDC, RID и Infrastructure на новый DC.
Поскольку DFSR не выполнил свою работу на новом DC, DCDIAG показал, что Advertisement был сломан и папки SYSVOL NTLOGON не были синхронизированы. Тестовый сервер: Default-First-Site\server
Starting test: Advertising
Warning: DsGetDcName returned information for
\\DC01.xyz.local, when we were trying to reach
DC02.
SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
В каждой статье, которую я читал на тот момент, говорилось о необходимости выполнить полномочное восстановление, но я столкнулся с проблемой, когда свойства mDFSR-Enable и mDFSR-Options для недавно повышенного DC не поддавались изменению в редактировании ADSI. Я обнаружил, что мне нужно было подключиться к схеме, запущенной на первом контроллере домена, чтобы изменить свойства для обоих DC, поскольку новый DC никогда не завершал свое повышение правильно.
Я следовал этой статье буквально, как только попал в ADSI.
Новый контроллер домена теперь является PDC и проходит все проверки DCDIAG.
К сожалению, поскольку все двоичные файлы и классы испорчены на старом DC, Unistall-ADDSDominController не работает, и мне придется вручную удалить его из AD/DNS и очистить метаданные.