Сбой операции active manager ошибка сбой действия базы данных

Представим, что у нас есть Exchange сервер в организации и внезапно железо, на котором он крутится, умирает. Причем умирает так, что восстановить ни чего уже нельзя, а актуальных бэкапов самого сервера (с System State) нет. Есть только бэкап баз данных.

Ситуация не приятная, но не критичная и из неё есть по крайней мере два выхода:

1. Переустановить сервер в режиме восстановления – setup.com /m:RecoverServer. Подобный подход я уже описывал ранее в статье «Аварийное восстановление сервера Exchange 2010» и даже записал пару веб-кастов;
2. Иногда бывает так, что не удается сбросить учетку сервера в Active Directory, чтобы его переустановить. В этом случае первый вариант не подходит, и сейчас мы поговорим о втором.

Потеряв сам сервер, но имея актуальный бэкап баз данных, мы достаточно быстро можем вернуть систему в рабочее состояние. Фактически, мы можем поднять совершенно новый сервер Exchange с теми же ролями, назвать сервер другим именем, но подключить старые базы данных, после чего переключить на новый сервер старых пользователей. Далее по пунктам:

Поднимаем новый сервер и подключаем базы данных:

В установке сервера ни чего сложного нет, напомню только, что мы его поднимаем на новом железе, на свежеустановленной и обновленной операционке с новым именем. Далее надо подключить к нему базы данных, предварительно восстановив их из бэкапа.

Дело в том, что восстановленные из бэкапа базы данных находятся в состоянии Dirty Shutdown, прежде чем их смонтировать, нужно перевести базы в состояние Clean Shutdown. Для этого придется вооружиться утилитой ESEUTIL, о том, как ей пользоваться я писал ранее в статьях «Восстановление баз данных при помощи ESEUTIL» и «Исправление базы данных почтовых ящиков в Exchange» (желательно использовать первый вариант).

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

• Создадим новую базу и во время создания снимем галку «Подключить эту базу данных»;
• Откроем свойства базы и на вкладке Обслуживание установим галку «База данных может быть перезаписана при восстановлении»;
• Переместим восстановленный из бэкапа и переведенный в состояние Clean Shutdown EDB-файл в папку новой базы данных;
• Смонтируем базу.

Теперь можно сказать, что почтовые ящики пользователей возвращены в организацию, но сами пользователи об этом пока ни чего не знают.

Переключение пользователей на работу с новым сервером и новой базой данных:

Пользователи узнают о том к какой базе и к какому серверу почтовых ящиков они подключены, читая атрибуты своей учетной записи в Active Directory. Т.е. для того, чтобы перенацелить пользователей на новый сервер и новую базу, нужно изменить всего 3 атрибута:

• homeMDB
• homeMTA
• msExchHomeServerName

Рис.1: Атрибуты, указывающие на сервер и базу данных.

Сделать это можно руками, через программу ADModify всем сразу, либо через PowerShell (EMS). Команда в EMC будет выглядеть следующим образом:

Get-Mailbox –Database <old_DB> | Set-Mailbox –Database <New_DB>

Рис.2: Перенацеливаем пользователей на другую базу данных.

Теперь, открывая Outlook пользователь и не заметит, что его почтовый ящик переехал на новый сервер.

Примечание: В Exchange 2007 это команда работать не будет, нужно использовать командлет Move-Mailbox с параметром –ConfigurationOnly.

Восстановление параметров сервера:

Восстановив доступ пользователей к своим почтовым ящикам, мы решили только половину задачи. Т.к. мы поднимали новый сервер, а не восстанавливали его в режиме Восстановления, то теперь осталось самое трудное – перенести все настройки со старого сервера на новый. В большинстве своем сделать это придется руками.

Облегчить задачу может ситуация, если мы ещё не удалили сервер из Active Directory. В этом случае в консолях управления сервером мы можем прочитать большинство параметров со старого сервера и установить аналогичные на новом.

Конкретные рекомендации тут дать трудно, подскажу только, что надо не забыть сменить сервер, отвечающий за генерацию ОАВ (см. рис.3)

Рис.3: Изменение параметров ОАВ.

После того, как все параметры будут перенесены, и вы убедитесь, что новый сервер работает не хуже старого, можно почистить все упоминания о старом сервере, т.е. удалить его совсем из организации. Для этого необходимо удалить учетную запись в Active Directory и удалить объект сервера в разделе Конфигурация базы данных AD, через оснастку ADSIEdit.

Для этого откроем ADSIEdit, подключимся к разделу

Configuration развернем CN=Services -> CN=Microsoft Exchange -> <Имя организации> -> CN=Administrative Group -> CN=Exchange Administrative Group -> CN=Servers -> удалим объект старого сервера

(см.рис.4)

Рис.4: Объект сервера Exchange в базе данных Active Directory.

Заключение

Берегите свои сервера, делайте регулярные бэкапы и не ставьте Exchange на контроллер домена! К сожалению, команда metadata cleanup не всегда отрабатывает так, как должна, а сбросить учетку контроллера, не сделав его рядовым сервером, мы не можем.

Во время подготовки данной статьи, в роли технического эксперта выступал Александр Станкевич (Stanky), за что ему огромное спасибо! Без него данный материал не появился бы на страницах этого блога, да и задача, на основе которой написана статья, была бы решена другим, менее рациональным способом.

«С каждым бывает…» «С каждым случается…» И даже если у вас есть ИБП (как это было и  в нашем случае) — никто не гарантирует, что при резком выключении электричества — ваша почтовая база данных выживет. А точнее: захочет ли она с вами дальше работать?
Один из таких случаев нас привел к печальным последствиям, которые все-же удалось решить с наименьшими потерями.
Помогли различные ресурсы,  а один даже удалось найти на русском языке
Поэтому статья не будет ничем новым, кроме как копией, с целью гарантированной сохранности этой ценной информации

Ошибка Microsoft Exchange
--------------------------------------------------------
Не удалось подключить базу данных 'Managers'.
Managers
Ошибка
Ошибка:
Не удалось подключить указанную базу данных. Указанная база данных: Managers; код ошибки: Сбой операции Active Manager. Ошибка: Сбой действия базы данных. Ошибка: Сбой операции с сообщением: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-550)

При этом остальные базы успешно подключились и работают, все службы запущены.Как исправлять почтовую базу Exchange:

На всякий случай делаем копию базы и всех логов.

Проведем диагностику:

1.    Запускаем Exchange Manager
2.    Проверяем базу. Выполняем команду:
eseutil /mh d:ExBasesMybaseMybase.edb

3.    Ищем сообщение как на скриншоте. Это означает, что наша база некорректно выключилась и часть информации не перенесена из лога в базу. Если у нас есть логи и они не испорчены, то мы сможем все восстановить. Если логов нет или они испорчены, то часть данных будет потерена.
4.    Проверяем логи :
eseutil /ml d:ExBasesMyBase

Восстанавливаем базу Exchange

5.    Если тест логов не выдал ошибку, то восстанавливаем базу:
eseutil /r «E02» /l d:ExBasesMyBase /d d:ExBasesMybaseMybase.edb
E02 — имя лога
Если восстановление прошло успешно пробуем подключить почтовую базу. Иначе смотрим п.6
6.    Если с логами что-то не так, можно попробовать восстановить базу игнорируя ошибку в логах:
eseutil /r «E02» /a /i /l d:ExBasesMyBase /d d:ExBasesMybaseMybase.edb
Если восстановление прошло успешно пробуем подключить почтовую базу. Иначе смотрим п.7
7.    Если логи содержат ошибки и база не восстановилась по п.5,6, то восстанавливаем базу без логов
eseutil /p d:ExBasesMybaseMybase.edb
8.    После этого пробуем подключить базу

Важно! Команды очень чувствительны к синтаксису. Будьте внимательны.