none
Починить домен active directory после некорректного удаления RRS feed

  • Вопрос

  • Добрый день.

    Перед увольнением главного админа, у нас сломался сервер (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