В этой статье рассмотрим, как правильно перевести хост 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 и после этого вывести первый