В этой статье рассмотрим, как правильно перевести хост 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с не знаешь как правильно, там обычно у них сразу написана какая должна быть последняя версия и т.д.
а точно можно через cu прыгать? т.е. допустим сейчас стоит 2019 cu12 и я могу сразу поставить 2019 cu15?
Да, ставьте сразу последний CU, без промужуточных.
Но, возможно, будет нюанс с предварительной установкой обновленной версии .NET Framework под новый CU,
добрый день!
может сможете дать совет…
имею два сервера 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, его отключение — наиболее быстрый способ устранить проблему.
Уязвимость CVE-2024-21410 была обнаружена самими специалистами Microsoft и позволяет удаленным неаутентифицированным злоумышленникам повысить привилегии в рамках атак типа NTLM relay, направленных на уязвимые версии Exchange Server.
Обновление Exchange Server 2019 Cumulative Update 14 (CU14), выпущенное в рамках февральского «вторника обновлений», устранило эту уязвимость путем активации NTLM credentials Relay Protections (эта функциональность также известная как Extended Protection for Authentication или EPA). Кроме того, на этой неделе компания объявила, что расширенная защита Windows Extended Protection будет включена по умолчанию на всех серверах Exchange после установки CU14.
а вот как убедится что «Все клиенты (Outlook) поддерживают Extended Protection.»?
Данная команда отрабатывает только внутри Exchange Management Shell
Более универсальная команда:
cd $env:ExchangeInstallPath\Scripts