Спрашивающий
Починить домен active directory после некорректного удаления

Вопрос
-
Добрый день.
Перед увольнением главного админа, у нас сломался сервер (sr-mail), где стоял контроллер домена и exchange 2010. Система на 2008r2. Главный админ удалил контроллер домена по инструкции http://winitpro.ru/index.php/2011/04/08/udalyaem-neispravnyj-kontroller-domena-pri-pomoshhi-utility-ntdsutil/ , но только в утилите NTDSutil остальное пока ничего не делалось. Потом он уволился.
В итоге, сломалась репликация между этим контроллером и двумя основыми (на другом контроллере основные роли) и старый контроллер синхронизируется через пень-колоду. Проблема в том, что не могу через dcpromo удалить доменный контроллер на сбойном сервере, пишется куча ошибок. И совсем выключить сервер не могу, там exchange 2010. Поднял новый сервер exchange 2016, начал мигрировать туда пользователей с 2010, вроде всё пошло, потом Майкрософт выпустил косячный патч для 2016, новый почтовый сервер сломался, пришлось в аврале восстанавливать, восстановил, но перестали ходить письма со старого 2010 на новый 2016...
Вот сижу и думаю, как сделать в данной ситуации рабочий exchange 2010 (с дальнейшей миграцией на 2016), но без косячного доменного контроллера.
Очень часто у пользователей возникают ошибки , как недоверительные отношения в домене, проблема с паролями и политиками.
Подскажите, как лучше поступить в этой ситуации?
2 октября 2017 г. 8:06
Все ответы
-
Прежде всего - не торопитесь и не совершайте беспорядочных действий - нагуглить и попробовать то, потом - это... Почти всё плохое у вас уже произошло, но ещё не всё: вы пока что не потеряли содержимое п/я пользователей. Но если будете беспорядочно дёргаться - можете потерять и содержимое.
Поэтому первое, чем надо озаботиться - это полной резервной копией сервера sr-mail. Если её нет - сделайте её, лучше - поддерживаемой программой резервного копирования (хоть Windows Server Backup, только в нём Exchange восстанавливать не совсем удобно), но если что - можно и снять образы дисков чем-нибудь вроде Acronis TrueImage - если sr-mail действительно удалён из контроллеров домена (см. ниже), то восстанавливать его из образа диска безопасно (а вот если контроллер удалён всё же не был - то опасно). Сделать копии файлов баз данных п/я (*.edb) после размонтирования баз данных и выгрузить содержимое п/я в pst тоже не помешает, но это - на ваше усмотрение.
Далее, нужно выяснить, что именно у вас произошло. Ваш рассказ - это одно, но т.к. вы удаление в ntdsutil делали не сами, то вы можете ошибаться. Поэтому подключитесь к одному из двух оставшихся контроллеров домена с помощью AD Sites and services и поищите там в разделе Sites\имя_сайта\Servers sr-mail. Если его там нет или если у него нет дочернего объекта NTDS Settings, то это означает, что ваш главный админ действительно удалил этот контроллер домена из AD. Теперь оставшиеся контроллеры домена его контроллером не считают, и потому реплицироваться с ним не будут.
Затем загляните в AD Users and Computers и найдите учётную запись компьютера sr-mail. Она должна быть либо в папке Computers, либо в Domain Controllers. Если её нет ни там, ни там (и вообще нигде) - ваше дело плохо. Если она где-то осталась - уже лучше. Защитите её от случайного удаления, на всякий случай.
Кроме того, посмотрите, включена ли у вас корзина AD. Посмотреть можно, например, через PowerShell на одном из оставшихся контроллеров домена:
Get-ADOptionalFeature -Filter 'Name -eq "Recycle Bin Feature"' | select EnabledScopes
(возможно, предварительно понадобится загрузить модуль ActiveDirectory: Import-Module ActiveDirectory).
Если в выдаче в фигурных скобках под "EnabledScopes" что-то есть - значит, корзина включена. Возможно, это облегчит вашу участь - если удаление КД sr-mail произошло менее 180 суток назад.
Слава России!
2 октября 2017 г. 10:03 -
По Get-ADOptionalFeature -Filter 'Name -eq "Recycle Bin Feature"' | select EnabledScopes - в квадратных скобках ничего нет...
Чуть подробнее - на sr-mail сейчас стоит и работает сбойный контроллер домена, он даже получает данные с sr-ad-a и sr-ad-b (двух других доменных контроллеров), как работает репликация я не знаю, но если смотреть с рабочего контроллера домена в Sites\имя_сайта\Servers сервера sr-mail действительно нет, но если зайти на сбойный sr-mail, там в adsi в Sites\имя_сайта\Servers есть запись о sr-mail ...
Бекап обязательно сделаю, проблема ещё в том, что при бекапе сервер sr-mail ложится на лопатки (слабенький он)..
После бекапа чтобы порекомендовали сделать? Ситуация с доменом достаточно критическая, каждодневные жалобы на недоверительные отношения, испорченные билеты безопастности в логах итд..
2 октября 2017 г. 10:56 -
Как работает репликация - можно посмотреть командой repadmin /showrepl с контроллера домена. По идее, она работать вообще не должна.
Единственно, что сейчас можно сделать с sr-mail - это понизить его принудительно (командой dcpromo /forceremoval). Но Exchange после этого работать перестанет. Однако есть хорошие (но не 100%)шансы, что он опять заработает, после того, как сервер будет заново сделан контроллером домена. Но для этого необходимо, чтобы сервер использовал старую учётную запись - она при установке Exchange была добавлена в определённые группы. Поэтому я рекомендовал посмотреть её наличие и защитить от удаления.
Если Exchange не заработает, то придётся ставить его заново и подключать к нему существующие базы из резервной копии. А потом, возможно - подсоединять п/я в них существующим пользователям.
Слава России!
2 октября 2017 г. 12:43 -
Интересно.. Если посмотреть repadmin /showrepl с 2х нормальных контроллеров домена, то там указаны только они 2. Но если посмотреть со сбойного, то там указаны 2 основных и он сам. И это как-то работает..
Попробую, что вы сказали, сделать в тестовой среде, но, как я помню, даже форсировано не удался домен..
2 октября 2017 г. 13:17 -
Видать, контроллеры домена, откуда забирается репликация, не проверяют, соответствует ли ему объект подключения.
Кстати, такая работа репликации подсказывает альтернативный путь восстановления: понизить штатно оба оставшихся КД (второй - с установленной галкой "последний в домене"), захватить на sr-mail все роли FSMO и заново поднять нужное число контроллеров домена. При этом Exchange заведомо не пострадает. Но прежде чем делать такое, нужно убедиться, что домен полностью работоспособен с единственным контроллером sr-mail и что на нём нет критических ошибок в AD (смотреть выдачу dcdiag).
И интересно, как это sr-mail у вас так "сломался", что он работает. А ещё хотелось бы, чтобы ваш предыдущий главный админ нашёл бы себе работу грузчика. Ну, или Java-девелопера - не суть важно, главное - чтобы подальше от эксплуатации IT.
Слава России!
2 октября 2017 г. 13:56