В этой статье рассмотрим, как правильно перевести хост Exchange Server 2019/2016 в режим обслуживания. Сервер группы высокой доступности (Database Availability Group, DAG) Exchange нужно перевести в режим обслуживания (maintenance mode), если вы планируете установить обновления на хосте Exchange (обновления Windows или Exchange CU) или выполнить обслуживание аппаратной платформы сервера. При переводе сервера в maintenance mode нужно перенести активные базы с сервера, и переключить очередь на другие сервера.
В Exchange Server есть два встроенных PowerShell скрипта, связанных с режимом обслуживания:
- StartDagServerMaintenance.ps1 – позволяет перенести активные базы данных, роль диспетчера Primary Active Manager (PAM) на другой сервер и заблокировать обратный перенос почтовых баз до окончания обслуживания;
- StopDagServerMaintenance.ps1 – позволяет вывести сервер Exchange из режима обслуживания, выполнив обратные процедуры.
Эти скрипты находятся в каталоге установки Exchange в папке Scripts (CD $ExScripts). Используется следующий синтаксис этих скриптов:
.\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode
.\StopDagServerMaintenance.ps1 -serverName <ServerName>
Эти скрипты помогают автоматизировать часть операций. Но в большинстве случаев администраторы Exchange предпочитают выполнять все действия по переводу сервера в режим обслуживания вручную.
Ниже рассмотрен пример готового PowerShell скрипта, который можно использовать для перевода Exchange в режим обслуживания. Команды нужно выполнять на компьютере с установленным Exchange Management Shell и модулем RSAT-Clustering:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Import-Module FailoverClusters
Либо вы можете удаленно подключиться к Exchange серверу с помощью PowerShell:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://msk-mbx1.winitpro.ru/PowerShell/ -Authentication Kerberos -Credential (Get-Credential)
Import-PSSession $Session
Задайте имена серверов Exchange:
# сервер, который переводится в режим обслуживания
$maintance_srv = "msk-mbx1.winitpro.ru"
# целевой сервер, на который нужно перенести очереди
$target_srv = "msk-mbx2.winitpro.ru"
#Отключаем компонент HubTransport на сервере и переводим его в режим Draining
Set-ServerComponentState $maintance_srv –Component HubTransport –State Draining –Requester Maintenance
Restart-Service MSExchangeTransport
#Можно проверить, что статус HubTransport изменился на Draining
Get-ServerComponentState -Identity $maintance_srv -Component Hubtransport
Если сейчас выполнить команду
Get-ServerComponentState -Identity $maintance_srv
, то все компоненты Exchnage (кроме Monitoring и RecoveryActionsEnabled) должны быть в состоянии Incative.
#Теперь нужно перенести очереди сообщений на другой сервер
Redirect-Message -Server $maintance_srv -Target $target_srv
# Проверьте, что очереди очистились с помощью команды:
Get-Queue
# Поставьте на паузу ноду кластера, при этом роль Primary Active Manager (PAM) будет перенесена на другой сервер группы DAG
Suspend-ClusterNode –Name $maintance_srv
# Перевод всех смонтированных копий почтовых баз на другие сервера
Set-MailboxServer $maintance_srv –DatabaseCopyActivationDisabledAndMoveNow $true
# Запретите активацию почтовых баз на сервере
Set-MailboxServer $maintance_srv –DatabaseCopyAutoActivationPolicy Blocked
Дождитесь переключения почтовых баз (потребует несколько минут). Убедитесь, что список смонтированных баз на сервер пуст:
Get-MailboxDatabaseCopyStatus -Server $maintance_srv | where {$_.Status -like "Mounted"}
# Перевод компонентов Exchange в режим обслуживания
Set-ServerComponentState $maintance_srv –Component ServerWideOffline –State InActive –Requester Maintenance
# Проверьте, что сервер находится в режиме обслуживания:
Get-ServerComponentState -Identity $maintance_srv -Component ServerWideOffline
Get-MailboxDatabaseCopyStatus
Теперь вы можете выполнить необходимые вам процедуры обслуживания хоста Exchange. После окончания работ с сервером нужно выполнить обратную процедуры вывода Exchange из режима обслуживания:
Set-ServerComponentState $maintance_srv –Component ServerWideOffline –State Active –Requester Maintenance
# Статус можно проверить так (должен стать Active):
Get-ServerComponentState $maintance_srv -Component ServerWideOffline
Resume-ClusterNode –Name $maintance_srv
Set-MailboxServer $maintance_srv –DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer $maintance_srv –DatabaseCopyActivationDisabledAndMoveNow $false
Set-ServerComponentState $maintance_srv –Component HubTransport –State Active –Requester Maintenance
Проверьте статус Exchange Server с помощью:
Test-ServiceHealth $maintance_srv
Распределите почтовые базы по серверам DAG в соответствии с заданными предпочтениями с помощью скрипта RedistributeActiveDatabases.ps1:
cd $exscripts
.\RedistributeActiveDatabases.ps1 -DagName msk-dag –BalanceDbsByActivationPreference
Move-ActiveMailboxDatabase -Server $target_srv -ActivateOnServer $maintance_srv -Confirm:$false
Выполните проверку доступности MAPI:
Test-MAPIConnectivity -Server $maintance_srv
Проверьте статус баз и репликацию в DAG:
Get-MailboxDatabaseCopyStatus
Test-ReplicationHealth -DatabaseAvailabilityGroup
Инструкция огонь. Спасибо! Добавьте пожалуйста в неё нюанс про сайты AD
надо их учитывать. Если группы DAG — находятся на разных сайтах, то надо заменить SCP $maintance_srv — на SCP сайта $target_srv
get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri "https://target_srv.domain.com/Autodiscover/Autodiscover.xml"
и добавить сайт в AutoDiscoverSiteScope
Добрый день.
Я пытался найти, так и не нашел, правильную очередность накатывания обновлений =(
Я правильно понял ? Если установлено cu10, сразу ставить cu12, и после этого переходить к установке последнего SU ( Exchange Server 2019 CU12 Jan23SU) ?
Или SU и CU надо ставить по очерёдно? Если так, то какие действия предпринимаются, если установлено таким образом (с пропуском версий)
Если на сервер уже было установлено SU и CU
Если установлено cu10, сразу ставить cu12, и после этого переходить к установке последнего SU
Верно
Поясню эти моменты:
1) CU это по сути полная версия продукта. Поэтому возможн ообновление со старого CU на более новый CU с пропуском промежуточных релизов.
2) SU нужно ставить в зависимости от того, какой CU у вас установлен. Т.е. Security Update устанавливается на конкретный Cumulative Update.
3) Security Update кумулятивные — т.е. нужно ставить только последниюю версию для вашего CU.
спасибо за понятный ответ!
А то после 1с не знаешь как правильно, там обычно у них сразу написана какая должна быть последняя версия и т.д.
добрый день!
может сможете дать совет…
имею два сервера exchange 2019 на win 2019 в DAG. необходимо на одном из серверов переустановить винду (вот надо и все. такое требование сверху). в голове два пути:
1. перевожу нужный сервер в режим обслуживания. удаляю базы данных. удаляю сервер из DAG. удаляю на сервере (через удаление программ) exchange. переустанавливаю винду. завожу обратно сервер в dag. жду синхронизации. мне кажется это путь камикадзе
2. поднимаю еще одну виртуалку, ставлю винду. поднимаю exchange. настраиваю dag и жду синхронизации баз. потом нужный сервер вывожу из работы.
Все правильно, лучше сначала добавиь третий сервер dag и после этого вывести первый
Добрый день!
— после перевода hubtransport в режим Draining остальные компоненты не сменят статус, как будто бы пропущен кусок кода про перевод в Maintenance остальных компонент.
Так же после включения режима Draining и рестарта службы MsexchangeTransport необходимо подождать, пока все сообщения из очередей заново загрузятся из базы и не будут переданы другим серверам HubTransport (пока очереди не станут 0). Возможно, не у всех очереди такие большие, что этот момент будет очевидным)
Еще хотелось бы добавить, что рекомендуется проверять shadowredundancy очереди на других серверах для сервера, который выводится в Maintenance Mode, чтобы они так же были пустыми перед выводом в режим обслуживания, на случай, если простой будет больше, чем заданное время ShadowResubmitTimeSpan и сообщения из теневых очередей будут отправлены.
По поводу пропущенного куска кода в начале, действительно не хватает шага, на котором сервер выводится из пула балансировки:
Set-ServerComponentState -Identity $maintance_srv -Component ServerWideOffline -State Inactive -Requester Maintenance
После него проверяем статус, что у нас все компоненты, кроме Monitoring и RecoveryActionsEnabled, перешли в Inactive:
Get-ServerComponentState -Identity $maintance_srv
Но если у вас кластер DAG, то Monitoring тоже нужно потушить — он же мониторинг работоспособности или Health Checker:
Set-ServerComponentState -Identity $maintance_srv -Component Monitoring -State Inactive -Requester Maintenance
После того, как работы закончены, мониторинг можно вернуть в работу командой:
Set-ServerComponentState -Identity $maintance_srv -Component Monitoring -State Active -Requester Maintenance
После обновления до версии CU14, у некоторых пользователей отвалился автодискаверинг (автоматическая аутентификация для подключения к почте). Проблема оказалась в том, что в этой версии на IIS автоматически включается Extended Protection для API, MAPI и RPC. Помогло их выключить (IIS -> Default Web Site -> API/MAPI/RPC -> Authentication -> Windows Authentication -> Advanced Settings… -> Off).
Подробнее об этом тут:
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019
Включение Extended Protection (EP) в Windows Authentication усиливает защиту аутентификации за счет защиты от атак посредника (MITM). Однако, если эта настройка включена, но инфраструктура (клиенты, балансировщики нагрузки, прокси-серверы) не поддерживает её корректно, это может привести к проблемам с аутентификацией.
В данном случае Autodiscover работает через MAPI over HTTP и RPC over HTTP, а также взаимодействует с API Exchange. Если Extended Protection включен, сервер требует, чтобы клиент предоставил Channel Binding Token (CBT), который подтверждает, что соединение проходит через ожидаемый защищенный канал.
Как это влияет на работу Autodiscover:
Некорректная поддержка CBT – если клиент (Outlook), балансировщик нагрузки или прокси-сервер не поддерживает Extended Protection, он не сможет предоставить корректный CBT, и сервер отклонит попытку аутентификации.
Проблемы с Kerberos и NTLM – если Extended Protection включен, сервер может требовать использование Kerberos-аутентификации, а NTLM-аутентификация может не работать корректно, что также влияет на работу Autodiscover.
Ошибки при обращении к API, MAPI и RPC – если клиент не проходит аутентификацию на этих уровнях, он не сможет получить корректные параметры конфигурации из Autodiscover.
Зависимость от IIS и настроек безопасности – если IIS обрабатывает запросы Autodiscover и требует Extended Protection, но у клиента нет поддержки, сервер может выдавать ошибку 401 или отбрасывать запросы.
Почему отключение Extended Protection помогло?
Выключение Extended Protection сняло требование по CBT и позволило клиентам снова аутентифицироваться по NTLM/Kerberos без дополнительных проверок. Это устранило блокировку на уровне API, MAPI и RPC, что позволило Autodiscover корректно работать.
Рекомендация:
Если требуется оставить Extended Protection включенным, необходимо убедиться, что:
Все клиенты (Outlook) поддерживают Extended Protection.
Балансировщики нагрузки и прокси поддерживают передачу CBT.
Групповые политики и настройки безопасности согласованы с этим режимом.
Если инфраструктура не поддерживает Extended Protection, его отключение — наиболее быстрый способ устранить проблему.