Аварийное восстановление почтовых серверов Exchange 2007

Предполагается, что до применения процедуры аварийного восстановления сервера существовали, но в силу ряда причин стали недоступны.

Причины могут быть следующие:

• Отказ оборудования сервера
• Неудачная установка сервис-пака (с некоторыми оговорками, подробнее ниже)
• Перенос сервера на новое оборудование.

В нашем случае имя почтового сервера не меняется.

В случае с неудачной установкой сервис-пака перед проведением процедуры аварийного восстановления необходимо удалить следы Exchange с почтового сервера. Процедура удаления следующая:

1. Убеждаемся что Exchange Management Shell и Exchange Management Console закрыты.
2. Идём в оснастку сервисов, останавливаем сервис «Microsoft Exchange Active Directory Topology Service» и меняем его тип запуска на disabled.
3. Останавливаем и меняет типа запуска на disabled у сервисов начинающихся на «Microsoft Exchange» и у сервиса «Microsoft Search (Exchange Server)».
4. Перезапускаем сервер.
5. Через редактор реестра удаляем ветки: «HKLMSOFTWAREMICROSOFTEXCHANGE» и «HKLMSYSTEMCURRENTCONTROLSETSERVICESMSEXCHANGE*».
6. Через любой файловый менеджер переименовываем оставшуюся папку %Program Files%MicrosoftExchange Server в %Program Files%MicrosoftOld Exchange Server.
7. Перезапускаем сервер.
8. Через Windows Installer Cleanup Utility удаляем следующее: Microsoft Exchange 2007 Enterprise Anti-Spam Signature, Microsoft Exchange 2007 Enterprise Block List Update, Microsoft Exchange 2007 Standard Anti Spam-filter Update, Microsoft Exchange Client Language Pack, Microsoft Exchange Server, Microsoft Full Text Indexing Engine for Exchange, Microsoft Exchange Full text indexing Services
9. Перезапускаем сервер.

Предполагается, что к моменту аварийного восстановления новый сервер полностью подготовлен (установлена такая же операционная система, что и на предыдущем, он введён в домен, установлены все необходимые для установки Exchange обновления и программы).

Восстановление транспортного сервера-концентратора (роль Hub Transport)

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

• Очереди сообщений (находятся в папке %Program Files%MicrosoftExchange ServerTransportRolesdataQueue).
• Журналы трассировки сообщений и протоколов (находятся в папке %Program Files%MicrosoftExchange ServerTransportRolesLogs).
• Специфические настройки сервисов, которые хранятся в реестре (ветки HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchange и HKLMSYSTEMcurrentcontrolsetServices).

Все эти данные можно восстановить на новый/восстановленный сервер. Сам процесс восстановления запускается командой setup /m:RecoverServer. Занимает относительно немного времени и после восстановления (если нет необходимости восстанавливать вышеуказанные данные со старого сервера) готов к работе после перезагрузки.

Если же необходимо восстановить вышеуказанные данные, которые не хранятся в AD, то процедура немного усложняется. В этом случае часть настроек необходимо будет делать с остановленной службой транспорта (то есть сразу после восстановления она не должна быть запущенной), поэтому используется команда setup /m:RecoverServer /DoNotStartTransport.

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

Следовательно, мы можем без каких либо проблем провести процедуру переноса файлов очереди (журналы трассировки переносятся простым копирование со старого сервера, ключи реестра через экспорт/импорт). Процедура следующая:

• Переносим папку с файлами очереди в папку data на новом сервере (так как транспортный сервис у нас автоматически не запустился, то файлы очереди не создались).
• Восстанавливаем базу данных очереди с помощью eseutil.
• Дефрагментируем базу данных очереди с помощью eseutil.
• Запускаем очередь.

Перенос файлов очереди затруднений вызвать не должен (если они, конечно, сохранились). Восстановление делается командой eseutil /r trn /d. /8, которую нужно запустить из каталога, где находятся файлы очереди:

Дефрагментация запускается командой eseutil /d mail.que из папки с файлами базы данных очереди:

После этого можно запустить сервис транспорта через оснастку сервисов или через командную строку, используя Net Start MSExchangeTransport. После запуска сервиса очередь запустит процесс повторной отправки сообщений, которые поступили в неё на момент отключения старого сервера.

Восстановление сервера клиентского доступа (роль Client Access Server)

Большая часть настроек этой роли хранится в AD, поэтому при запуске процедуры аварийного восстановления они берутся из базы AD. Часть настроек может храниться локально на сервере, поэтому имеет смысл делать их резервные копии. На сервере хранится следующее:

• Файлы службы Outlook Web Access.
• Файлы настроек разных служб (OWA, ActiveSync, Autodiscovery). Хранятся в файлах web.config в папках соответствующих служб (по умолчанию C:Program FilesMicrosoftExchange ServerClientAccessowa, C:Program FilesMicrosoftExchange ServerClientAccessSync, C:Program FilesMicrosoftExchange ServerClientAccessexchwebews).
• Параметры протоколов POP3 и IMAP4. Хранятся в файлах Microsoft.Exchange.Imap4.Exe.Config, Microsoft.Exchange.Pop3.Exe.Config, в папке C:Program FilesMicrosoftExchange ServerClientAccessPopImap.
• Метабаза IIS.
• Автономная адресная книга (папка C:Program FilesMicrosoftExchange ServerClientAccess ExchangeOAB).

Имеет смысл помнить, что если никакие из этих данных не менялись под специфические требования организации, то при аварийном восстановлении они восстановятся автоматически.

Восстановление запускается командой setup /m:RecoverServer и по времени длится немного дольше восстановления транспортного сервера-концентратора на аналогичной конфигурации сервера.

Изменённые файлы, о которых написано выше, восстанавливаются копированием. Что касается восстановления метабазы IIS, то с ней процесс немного усложняется. Предварительно необходимо иметь резервную копию метабазы, которая выгружается командлетом Exchange Management Shell:

Get-OwaVirtualDirectory “owa (default web site)” | Export-CliXml c:owa.xml –Depth 1

Файл owa.xml можно скопировать в безопасное место. Перед его восстановлением в папке bin сервера Exchange нужно создать сценарий recovervdir.ps1:

$ErrorActionPreference = 'stop'
$savedprops = @(
'DirectFileAccessOnPublicComputersEnabled',
'DirectFileAccessOnPrivateComputersEnabled',
'WebReadyDocumentViewingOnPublicComputersEnabled',
'WebReadyDocumentViewingOnPrivateComputersEnabled',
'ForceWebReadyDocumentViewingFirstOnPublicComputers',
'ForceWebReadyDocumentViewingFirstOnPrivateComputers',
'RemoteDocumentsActionForUnknownServers',
'ActionForUnknownFileAndMIMETypes',
'WebReadyFileTypes',
'WebReadyMimeTypes',
'WebReadyDocumentViewingForAllSupportedTypes',
'AllowedFileTypes',
'AllowedMimeTypes',
'ForceSaveFileTypes',
'ForceSaveMimeTypes',
'BlockedFileTypes',
'BlockedMimeTypes',
'RemoteDocumentsAllowedServers',
'RemoteDocumentsBlockedServers',
'RemoteDocumentsInternalDomainSuffixList',
'LogonFormat',
'ClientAuthCleanupLevel',
'DefaultDomain',
'FormsAuthentication',
'BasicAuthentication',
'DigestAuthentication',
'WindowsAuthentication',
'GzipLevel',
'FilterWebBeaconsAndHtmlForms',
'NotificationInterval',
'DefaultTheme',
'UserContextTimeout',
'ExchwebProxyDestination',
'VirtualDirectoryType',
'RedirectToOptimalOWAServer',
'DefaultClientLanguage',
'LogonAndErrorLanguage',
'UseGB18030',
'UseISO885915',
'OutboundCharset',
'CalendarEnabled',
'ContactsEnabled',
'TasksEnabled',
'JournalEnabled',
'NotesEnabled',
'RemindersAndNotificationsEnabled',
'PremiumClientEnabled',
'SpellCheckerEnabled',
'SearchFoldersEnabled',
'SignaturesEnabled',
'ThemeSelectionEnabled',
'JunkEmailEnabled',
'UMIntegrationEnabled',
'WSSAccessOnPublicComputersEnabled',
'WSSAccessOnPrivateComputersEnabled',
'ChangePasswordEnabled',
'UNCAccessOnPublicComputersEnabled',
'UNCAccessOnPrivateComputersEnabled',
'ActiveSyncIntegrationEnabled',
'AllAddressListsEnabled',
'InternalUrl',
'ExternalUrl'
)
$vdir = import-clixml $args[0]
'Recreating "' + $vdir.name + '"' + ' owa version: ' + $vdir.owaversion
if ($vdir.owaversion -eq 'Exchange2007') {
new-owavirtualdirectory -website $vdir.website -internalurl $vdir.internalurl 
-externalurl $vdir.externalurl
}
else {
new-owavirtualdirectory -website $vdir.website -owaversion $vdir.owaversion 
-name $vdir.displayname -irtualdirectorytype $vdir.virtualdirectorytype
}
$new = get-owavirtualdirectory $vdir.name
'Restoring properties'
foreach ($prop in $savedprops) {
if ($prop -eq 'ExchwebProxyDestination' -or $prop -eq 'VirtualDirectoryType') {
continue
}
$new.$prop = $vdir.$prop
}
$new | set-owavirtualdirectory

Восстановление метабазы будет выполняться следующим скриптом:

Restorevdir.ps1 owa.xml

Owa.xml в данном случае мы тоже копируем в папку bin. После применения этого скрипта восстановится часть настроек, которые мы делали, до того как сервер вышел из строя. Например, так выглядели свойства дефолтной папки Outlook Web Access:

Как видно, атрибут ExternalUrl отсутствует (его дефолтное значение). После восстановления свойства дефолтной папки будут выглядеть следующим образом:

На этом можно считать восстановление сервера клиентского доступа законченным.

Восстановление сервера почтовых ящиков (роль Mailbox)

Большая часть настроек этой роли хранится в AD, поэтому при запуске процедуры аварийного восстановления они берутся из базы AD. Часть настроек может храниться локально на сервере, поэтому имеет смысл делать их резервные копии. На сервере хранится следующее:

• Файлы баз данных и журналов транзакций (edb-файлы и log-файлы).
• Файлы службы индексации (хранятся в тех же каталогах, что и файлы баз данных в папках, которые начинаются с CatalogData).
• Автономная адресная книга (по умолчанию в C:Program FilesMicrosoftExchange ServerExchangeOAB).

Восстановление запускается командой setup /m:RecoverServer. Вся информация, за исключением указанной выше, берётся из AD.

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

О чём нас предупредят, при попытке подключить базу:

Таким образом, сразу после аварийного восстановления сервера почтовых ящиков имеет смысл восстановить файлы баз данных и журналов транзакций по месту их первоначального размещения на старом сервере. Делается это либо стандартными средствами Windows Server Backup или сторонним ПО (Data Protection Manager, Backup Exec итд).

Что касается файлов службы индексации, то их проще всего сгенерировать заново. Для этого можно использовать скрипт ResetSearchIndex.ps1:

С ключами –force и –all скрипт останавливает службу индексации, удаляет каталоги с индексами и запускает её заново, которая после этого начинает стоить индексы заново.

Оффлайновую адресную книгу можно после восстановления баз сгенерировать вручную заново (Organization Configuration => Mailbox => Закладка Offline Address Book => команда Update), или же подождать пока она сама автоматически не создастся (по умолчанию это происходит каждый день в 5:00).

Восстановление кластера почтовых ящиков

Кластер почтовых ящиков так же как и обычная роль сервера почтовых ящиков использует локальные данные в виде:

• Файлы баз данных и журналов транзакций (edb-файлы и log-файлы).
• Файлы службы индексации (хранятся в тех же каталогах, что и файлы баз данных в папках, которые начинаются с CatalogData).
• Автономная адресная книга (по умолчанию в C:Program FilesMicrosoftExchange ServerExchangeOAB).

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

Перед запуском процесса аварийного восстановления необходимо подготовить кластер средствами операционной системы к состоянию, в котором он был на момент установки первоначального почтового кластера, включая конфигурацию хранилищ, подключенных к узлам кластера. После этого на один из узлов устанавливается пассивная роль кластера почтовых ящиков и запускается команда «Setup.com /recoverCMS /CMSName:<name> /CMSIPaddress:<ip>», где <name> – имя почтового (не путать с кластером, которые поднимается средствами операционной системы) кластера, <ip> – его адрес.

Восстановленный узел станет активным узлом почтового кластера. Останется только восстановить почтовые базы и установить пассивный узел почтового кластера на второй сервер.

Сразу после восстановления кластера почтовые базы будут в отключенном состоянии.

Их будет необходимо восстановить (или из резервных копий, или, подключив существующие базы с внешних систем хранения, если они не пострадали). Кроме этого необходимо помнить, что в случае с CCR после восстановления кластера репликация останавливается и её будет необходимо заново подключить и, возможно, заполнить пассивные копии баз. Для этого необходимо восстановить пассивный узел почтового кластера (достаточно будет его поставить через программу установки Exchange).

Затем запускаем остановленную репликацию (Resume-StorageGroupCopy или через EMS). Нужно согласиться с предупреждением.

После чего будет попытка запуска репликации, которая не пройдёт, так как базы отключены. Надо их подключить. После этого репликация заново инициализируется.

Проверить корректность работы кластера можно, например, через Get-StorageGroupCopyStatus или через свойства группы хранения.