Exchange 2019 после аварийного отключения питания: восстановление OWA/ECP, repair Setup и обход блокировки на мёртвой mailbox database

Кратко

После аварийного отключения питания Exchange Server 2019 может перейти в состояние частичной неконсистентности:

• OWA/ECP недоступны;
• repair Setup падает на этапе Install-ExchangeCertificate -services IIS;
• после исправления IIS Setup начинает падать на попытке смонтировать старую mailbox database;
• причиной второго падения может оказаться DiscoverySearchMailbox, привязанный к нерабочей базе.

В этой статье показан практический сценарий восстановления почтового сервера Exchange после power loss.

Исходные симптомы

После сбоя питания сервер Exchange внешне “поднялся”, но фактически работал некорректно:

Web-слой

• не открывались или работали нестабильно OWA/ECP;
• страницы логина вели себя непредсказуемо;
• HTTPS-поведение было нестабильным.

Repair Setup

Попытка штатного восстановления через:

Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

падала на этапе установки роли Mailbox с ошибкой:

FormsAuthenticationMarkPathUnknownSetError
путь: /LM/W3SVC/1
код: 5506

После частичного исправления IIS Setup начинал падать уже на другом шаге:

Unable to mount database
MapiExceptionNetworkError

ошибка ссылалась на одну из несмонтированных mailbox databases.

Что оказалось сломано

На практике проблема состояла не из одного дефекта, а из нескольких:

1. Неконсистентный IIS / Exchange web-layer

Повреждение затронуло:

• IIS bindings;
• Forms Authentication / FBA;
• интеграцию Exchange Setup с IIS.

2. Неконсистентные SSL bindings

IIS был привязан не к тому сертификату, который Exchange считал своим рабочим сертификатом для IIS.

Итог:

• часть HTTPS-проверок проходила;
• браузерные/CLI-запросы вели себя неодинаково;
• repair Setup стабильно падал на шаге Install-ExchangeCertificate -services IIS.

3. Мёртвая mailbox database в конфигурации Exchange

Одна из mailbox databases числилась как обычная рабочая база, но не монтировалась.

На ней оставались:

• DiscoverySearchMailbox
• ArbitrationMailbox
• AuditLogMailbox
• MonitoringMailbox

4. Discovery mailbox блокировал завершение Setup

После починки IIS Setup начал искать Discovery mailbox, видел, что он связан с мёртвой базой, пытался смонтировать её — и снова падал.

Даже после Disable-Mailbox объект Discovery mailbox продолжал существовать в AD как user, и Setup по-прежнему его находил.

Подход к диагностике

Проверка mailbox databases

Get-MailboxDatabase -Status | Format-Table Name,Mounted,Recovery,Server,EdbFilePath -Auto

Проверка системных mailbox’ов

Get-Mailbox -Arbitration | Select-Object Name,Database
Get-Mailbox -RecipientTypeDetails DiscoveryMailbox -ResultSize Unlimited
Get-Mailbox -Database "<ProblemDB>" -AuditLog
Get-Mailbox -Database "<ProblemDB>" -Monitoring

Проверка сертификатов Exchange

Get-ExchangeCertificate | Format-List Thumbprint,Subject,Services,Status,NotAfter

Проверка IIS bindings

Import-Module WebAdministration
Get-WebBinding | Select-Object protocol,bindingInformation,certificateHash,certificateStoreName | Format-Table -Auto

Проверка HTTPS-ответов Exchange

curl.exe -k -I "https://localhost/owa/auth/logon.aspx"
curl.exe -k -I "https://localhost/ecp"

Этап 1. Восстановление IIS / HTTPS / Exchange certificate integration

Симптом

Setup падал на:

Install-ExchangeCertificate -services IIS

Что оказалось важным

Exchange видел своим IIS-сертификатом один сертификат, а IIS bindings фактически были привязаны к другому.

В результате:

• HTTPS работал частично;
• но Exchange Setup не мог корректно завершить интеграцию сертификата с IIS.

Что помогло

Нужно привести базовые IIS SSL bindings в консистентное состояние и назначить на них сертификат, который Exchange уже знает как Services = IIS.

После этого обязательно проверить:

curl.exe -k -I "https://localhost/owa/auth/logon.aspx"
curl.exe -k -I "https://localhost/ecp"

Ожидаемое поведение

/owa/auth/logon.aspx → 200 OK

/ecp → ожидаемый ответ уровня 440 Login Timeout без активной сессии

Если это получено, web-слой, как правило, уже восстановлен достаточно для продолжения repair Setup.

Этап 2. Повторный repair Setup

После нормализации IIS и HTTPS repair Setup запускается повторно:

Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Если IIS-блокер снят, Setup пойдёт дальше и покажет следующий реальный дефект.

Этап 3. Setup упирается в нерабочую mailbox database

После исправления web-слоя Setup начал падать уже с ошибкой смонтировать mailbox database.

Типичная ошибка:

Unable to mount database
MapiExceptionNetworkError
ссылка на конкретную DB

Что проверили

Get-MailboxDatabase -Status | Format-Table Name,Mounted,Recovery,Server,EdbFilePath -Auto

Одна из баз:

• не была Recovery
• не была Mounted
• при этом оставалась обычной mailbox database в конфигурации Exchange.

Этап 4. Поиск объектов на мёртвой базе

Проверили содержимое проблемной DB:

Get-Mailbox -Database "<ProblemDB>" -ResultSize Unlimited
Get-Mailbox -Database "<ProblemDB>" -Arbitration
Get-Mailbox -Database "<ProblemDB>" -AuditLog
Get-Mailbox -Database "<ProblemDB>" -Monitoring

Что выяснилось

На базе не было обычных пользовательских ящиков. Там находились только:

• DiscoverySearchMailbox
• ArbitrationMailbox
• AuditLogMailbox
• MonitoringMailbox

Это важный момент: значит блокером Setup являлись не production mailboxes, а системные объекты на нерабочей базе.

Этап 5. Discovery mailbox как блокер Setup

Setup явно пытался:

• найти Discovery mailbox;
• определить его базу;
• смонтировать эту базу;
• проставить права группе Discovery Management.

Поскольку база была мёртвая, Setup завершался ошибкой.

Попытка штатного MoveRequest

Переместить Discovery mailbox обычным move request не удалось:

• source database была недоступна;
• mailbox не открывался.

Этап 6. Отключение Discovery mailbox

Сначала проверили возможность отключения:

Disable-Mailbox -Identity "<DiscoveryMailboxIdentity>" -WhatIf

После подтверждения выполнили:

Disable-Mailbox -Identity "<DiscoveryMailboxIdentity>" -Confirm:$false

Затем проверили:

Get-Mailbox -RecipientTypeDetails DiscoveryMailbox -ResultSize Unlimited

Mailbox как Exchange mailbox исчез.

Этап 7. Удаление orphaned AD-объекта Discovery mailbox

Несмотря на отключение mailbox, Setup всё ещё находил Discovery mailbox по имени.
Причина: объект остался в AD как обычный user.

Проверка

Get-ADObject -Identity "<DN Discovery object>"

Удаление orphaned объекта

Remove-ADObject -Identity "<DN Discovery object>" -Confirm:$false

Контроль

Get-Mailbox -RecipientTypeDetails DiscoveryMailbox -ResultSize Unlimited
Get-ADObject -LDAPFilter "(cn=<Discovery mailbox CN>)" -SearchBase "<domain DN>"

Оба запроса должны вернуть пустой результат.

Этап 8. Финальный запуск repair Setup

После удаления блокирующего Discovery mailbox/object снова запускается:

Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

На этом этапе Setup уже проходит до конца:

• роли завершаются успешно;
• установка завершается;
• ECP/OWA возвращаются в рабочее состояние.

Проверка после восстановления

Сервисы

Get-Service W3SVC,WAS,MSExchangeADTopology,MSExchangeServiceHost,MSExchangeFrontEndTransport,MSExchangeTransport,MSExchangeIS | Format-Table Name,Status -Auto

Базы

Get-MailboxDatabase -Status | Format-Table Name,Mounted,Recovery,Server,EdbFilePath -Auto

OWA / ECP

curl.exe -k -I "https://localhost/owa/auth/logon.aspx"
curl.exe -k -I "https://localhost/ecp"

Очереди транспорта

Get-Queue | Format-Table Identity,Status,MessageCount,NextHopDomain -Auto

Реальный пользовательский тест

Обязательно:

• отправить письмо извне на рабочий mailbox;
• отправить письмо из Exchange наружу;
• убедиться, что почта приходит и уходит.

Что показал этот кейс

1. После power loss Exchange часто ломается не в одном месте

Если после аварии не работают одновременно: OWA/ECP, repair Setup, база, системные ящики, — это нормально для повреждённого stateful-продукта вроде Exchange.

2. Setup может падать по цепочке на разных слоях

Типичный порядок: сначала IIS / certificate / forms authentication; потом mailbox database; потом системные mailbox objects.

3. Discovery mailbox на мёртвой базе — реальный блокер Setup

Если Setup пытается работать с Discovery mailbox, а его база не монтируется, repair install не завершится.

4. Disable-Mailbox не всегда решает проблему до конца

Если AD-объект остался и Setup продолжает искать его по имени, может потребоваться удаление orphaned AD object.

5. Выключенный backup VM перед дальнейшим cleanup — обязательная хорошая практика

После успешного аварийного восстановления стоит сразу зафиксировать рабочее состояние: сохранить конфигурацию; сделать backup/export выключенной VM; только потом переходить к cleanup.

Что делать после успешного восстановления

После того как сервис уже работает, нужно отдельным плановым этапом:

• разобраться с мёртвой mailbox database;
• восстановить Discovery mailbox;
• нормализовать системные Arbitration/Audit/Monitoring mailboxes;
• привести сертификаты Exchange/IIS в нормальное финальное состояние;
• проверить transport и DNS-маршрутизацию;
• сохранить новую рабочую резервную копию.

Вывод

После аварийного отключения питания Exchange 2019 может потерять консистентность сразу в нескольких компонентах:

• IIS / SSL / FBA;
• Exchange Setup certificate integration;
• mailbox database state;
• системные mailbox objects.

В рассмотренном кейсе восстановление удалось только после последовательного снятия блокеров: исправление IIS и HTTPS; повторный repair Setup; локализация нерабочей mailbox database; отключение Discovery mailbox; удаление orphaned AD object; повторный запуск Setup; проверка сервисов, OWA/ECP и почтового потока.