Выпущены долгожданные обновления для почтовых серверов Exchange. Обновления весьма существенные, поэтому настоятельно советую ознакомиться с перечнем изменений. Команда Exchange отказалась от сервис паков и сейчас концепция такова, что накопительные обновления выходят каждый квартал и могут содержать в себе как исправления багов, дыр в безопасности, так и новый функционал продукта. Но сегодня я хотел бы поговорить не об этом, а о процедуре установки обновлений на серверах Exchange Server 2013/2016.
К установке обновлений для почтовых серверов нужно подходить максимально ответственно. Бывают случаи, когда почтовый сервер отказывается работать после этой процедуры. Есть ряд важных замечаний, о которых всегда стоит помнить при планировании обновления:
-
Не рекомендуется устанавливать обновления сразу в рабочей среде. Необходимо иметь стенд, для тестирования вашей конфигурации.
-
Не рекомендуется настраивать почтовый сервер на автоматическую установку обновлений получаемых от WSUS или из внешнего источника. Это справедливо как для Exchange Server, так и для Windows Server.
-
Если у вас развёрнут Exchange Server 2013, а его роли CAS и MBX разнесены по разным серверам, то первым должен обновляться CAS сервер.
-
При обновлении CAS сервера советую вывести его из балансировки подключений (если она есть).
-
При обновлении CAS сервера все ваши персональные настройки веб сервера IIS сбросятся на дефолтные, так что нужно сделать бэкап.
-
При обновления почтовых серверов, находящихся в DAG, обновляемый сервер необходимо вывести в режим обслуживания.
-
Если у вас единственный сервер Exchange в организации, то желаю вам удачи и не забудьте сделать бэкап :). При обновлении почтовый сервер будет недоступен для пользователей.
Итак, перейдем непосредственно к самой процедуре обновления. Качаем дистрибутив с CU (отмечу, что это полноценный дистрибутив Exchange и если вы устанавливаете новый сервер, сразу качайте CU) и распаковываем его в папку C:\tmp. В случае с Exchange Server 2016 это будет ISO-образ а не архив [ура товарищи!]. ISO-образ нужно подмонтировать, открыть и так же распаковать.
Мы рассмотрим установку обновлений на сервере почтовых ящиков, входящим в DAG. Открываем любимый инструмент администратора Exchange PowerShell (с повышенными привилегиями) и приступаем к работе.
Переводим компонент сервера Hub Transport в режим обслуживания:
Set-ServerComponentState EX-SRV –Component HubTransport –State Draining –Requester Maintenance
Переводим все активные сообщения из очередей почтового сервера на другой сервер (нужно указать FQDN севера):
Redirect-Message -Server EX-SRV -Target EX2-SRV.contoso.com
(подтверждаем действие нажав “y”)
Приостанавливаем членство в кластере:
Suspend-ClusterNode –Name EX-SRV
Следующая команда перемещает все активные копии баз данных с сервера EX-SRV и блокирует политику активацию новых копий:
Set-MailboxServer EX-SRV –DatabaseCopyActivationDisabledAndMoveNow $true
Переводим сервер в режим обслуживания:
Set-ServerComponentState EX-SRV -Component ServerWideOffline –State InActive –Requester Maintenance
Теперь перейдем в директорию с распакованным обновлением (CU) и расширим схему AD (нужен компонент Windows Server "RSAT-ADDS" и обновление безопасности) будем использовать для этого cdm.exe запущенную от Администратора:
setup.exe /prepareschema /IAcceptExchangeServerLicenseTerms
Подготовим Active Directory:
setup.exe /preparead /IAcceptExchangeServerLicenseTerms
Подготовим домен (запускается для каждого домена, содержащего почтовый сервер Exchange):
setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms
Начнем установку обновления:
setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms
После установки возвращаем все в рабочее состояние:
Resume-ClusterNode –Name EX-SRV Set-MailboxServer EX-SRV –DatabaseCopyAutoActivationPolicy Unrestricted Set-MailboxServer EX-SRV –DatabaseCopyActivationDisabledAndMoveNow $false Set-ServerComponentState EX-SRV –Component HubTransport –State Active –Requester Maintenance
Возвращаем персональные настройки виртуальных каталогов (если они были сделаны).
Раскидываем базы данных, согласно приоритету активации, для этого переходим в папку C:\Program Files\Microsoft\Exchange Server\V15\scripts и выполняем команду:
.\RedistributeActiveDatabases.ps1 –DagName DAGNAME –BalanceDbsByActivationPreference –confirm: $false
Готово. Проверяем репликацию:
Test-ReplicationHealth -Identity EX-SRV
Осталось убедиться в отсутствии проблем у пользователей и сторонних сервисов и можно приступать к обновлению следующего сервера.
Полезные ссылки:
О содержании обновлений и вносимых изменениях см. Блог команды Exchange
Скрипты для автоматического перевода сервера в режим обслуживания и обратно:
Exchange Server 2013 Start Maintenance Mode Script (Start-ExchangeServerMaintenanceMode)
Exchange Server 2013 Stop Maintenance Mode Script (Stop-ExchangeServerMaintenanceMode)
RSS - Записи
Я не владелец Exchange, но еще бы схемку отката почитать :)
Вопрос по принципу "Не съем, так надкушу..."
Из откатов только бэкап или не самый лучший вариант--установка сервера в режиме восстановления. Но для того, чтобы не было проблем, лучше протестировать на стенде.
Хочу поинтересоваться, почему первым нужно обновлять именно CAS? В другой статье я читал про обратный порядок.
Если быть до конца правильным, то сначала надо обновлять EDGE, затем CAS, затем MBX. Смысл прост: если сервер накроется и не захочет нормально то пусть это будет менее значимый CAS, нежели MBX. Никакой другой логики тут быть не может, т.к. у вас все равно некоторое время будут сервера с разными версиями в одной организации.
Ну вот тут, товарищ имеет противоположное мнение: http://exchangeserverpro.com/exchange-2013-installing-cumulative-updates/
А разные версии на серверах для exchange 2013 вроде как больше не критично, так как нет кроссайтового проксирования CAS to CAS
Полу респект и уважуха, но и он не безгрешен :-) Эти заморочки были важны в 2010. Сейчас на тебя вообще косо смотрят, если ты скажешь, что разносишь роли 2013 Exchange, а в 2016 и того одна роль (edge не в счет).
Вопрос именно в причинах такого ордера. Либо в 2013 никакого ордера нет и можно лепить ролап в любом порядке, тогда и упоминать о нем не стоит. Вот например, порядок установки ролей (с нуля) точно существует и ставить надо первым именно MBX, так как на нем расположен инстанс EMS. Если поставить первым CAS, то он просто не сможет ни к чему подключиться.
Гибридное развертывание - это конечно гуд, но если есть аппаратный балансировщик, если нет - добро пожаловать в клуб NLB и вперед разносить роли
Вот здесь тоже предлагают обновить сначала MBX. http://smtp25.ru/archives/1821
Только никто не говорит почему так.
В целом, ситуация такая: нету официального документа от МС, в котором прописан порядок установки обновлений для 2013. Для 2010 установлен порядок: CAS,HUB,MBX.
А если поставить первым MBX, то к нему тоже никто не подключится, т.к. нет CAS :-) Когда я ставлю сервера с нуля, то они все ставятся параллельно, т.к. дни лукавы. На 3000 пользователей DNS балансировка работает вполне нормально. Я уже говорил, что исхожу только из того, что CAS легче и быстрее восстановить, он не выполняет основную работу. Других аргументов я не вижу.
Спросил сегодня про порядок у специалистов премьер поддержки МС. Никакого ордера нет, обновлять можно в любом порядке
Обсуждали вчера этот вопрос с коллегами в Facebook, пришли к такому же мнению.
Логика там была довольно простая - свежий CAS умеет проксировать к MBX старых версий, но не наоборот.
Кто вам сказал, что "старый" CAS не умеет проксировать на "Новый" MBX? Что он там может не уметь?))
Спасибо за статью.
Добавил бы только перезапуск сервисов транспорта, чтобы он быстрее сообразил что режим работы компонентов изменился.
Set-ServerComponentState EX-CTR –Component HubTransport ...
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
Set-ServerComponentState EX-SRV -Component ServerWideOffline ....
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
Ну и неплохо бы очередь проверить, перед:
Set-ServerComponentState EX-SRV -Component ServerWideOffline –State InActive –Requester Maintenance
А в первой команде ошибка в имени сервера ("Set-ServerComponentState EX-CTR")
Спасибо, поправил. Что касается служб, то установщик их сам стопит, а потом стартует, после чего предлагает ребут. Очередь проверить можно, чисто для очистки совести, ведь перед этим мы сделали редирект. ("Командлет Redirect-Message используется для извлечения активных сообщений из всех очередей доставки на сервере почтовых ящиков и направления их на другой сервер почтовых ящиков" https://technet.microsoft.com/ru-ru/library/jj215667%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396)
>> Что касается служб, то установщик их сам стопит, а потом стартует, после чего предлагает ребут.
При включении (Set-ServerComponentState $ServerName -Component ServerWideOffline -State Active -Requester Maintenance) не перезапускает :).
Просто наткнулся как раз и обратил внимание. Вроде все включил а Get-ServerComponentState - Inactive.
>> Очередь проверить можно, чисто для очистки совести, ведь перед этим мы сделали редирект.
Redirect-Message разве не асинхронно работает? Если очередь большая и команды выполняются одним пакетом - не задержим ли доставку, а в случае неудачного обновления - потеряем.
Компоненты сервера, после обновления будут в состоянии InActive. Можно подождать некоторое время, пока сервер сам их стартанет, а можно сделать это вручную, командлетом Set-ServerComponentState. Я использовал второй вариант, написав скрипт в одну строчку и переведя ВСЕ компоненты в состояние Active.(если интересует, могу написать).
>>Redirect-Message разве не асинхронно работает? Если очередь большая и команды выполняются одним пакетом — не задержим ли доставку, а в случае неудачного обновления — потеряем.
Потерять, точно не потеряем (пока копии сообщений не будут на всех серверах, они не отправляются), а вот сообщения которые переместились в очередь на другой сервер будут отправлены с небольшой задержкой (1-2 минуты, что вполне приемлемо). И да, в случае с большой очередью задержка может быть приличная, но это вопрос к сайзнгу почтовой системы, почему на сервере очередь большая. Из практики: 2500 пользователей с активной перепиской создают очередь 10-20 сообщений на 2 серверах. Это норма и это не много.
Обратная ссылка: Миграция с Zimbra на Exchange Server 2016, ресурсный лес, PowerShell и все,все,все… | Блог IT-KB /
Подскажите такой вопрос. Имею DAG. переведу сервер в режим обслуживания - выключу. После этого, если сделать снимок сервера. Откатиться на него можно будет при неудачном обновлении ? естественно не выводя его из режима обслуживания после обновления.
Нет, этот сценарий не поддерживается. Если у вас есть кластер, скажем из 4 серверов, один выводите в режим обслуживания и обновляете его, пока он нормально не обновится. Если его не получается нормально обновить, сносите винду, отключаете(!!!не удаляете) учётку сервера, ставите винду, ставите все необходимые Фили сервера + UC компоненты, запускаете установку в режиме восстановления (setup /m:recoverserver https://technet.microsoft.com/ru-ru/library/dd876880(v=exchg.160).aspx)
Я бы еще добавил, если у вас балансировка Round-robin DNS, то нужно в DNS удалять запись A обовляемой ноды, которая смотрит на общее имя.
"Скрипты для автоматического перевода сервера в режим обслуживания и обратно"
- пожалуйста, обновите ссылки на скрипты.
Поддержу предыдущего оратора )
Обновите пожалуйста ссылки.
По какой-то причине автор скриптов убрал скрипты с gallery.technet.microsoft.com
Поэтому ссылки заменены на те, что обнаружены на текущий момент времени в публичном доступе на GitHub.
Обязательно анализируйте/тестируйте скрипты перед использованием в продуктиве.
Коллеги, подскажите пожалуйста такой момент - после обновления 1 из серверов dag версии 2019 с CU9 на CU11 (предварительно переводил в maintenance mode) получил проблему по веб с ecp и owa -
если заходить на сам сервер: "Ошибка сервера в приложении '/owa'.
ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1 "
и если заходить по имени общего каталога "https://laura/owa/auth/errorFE.aspx?httpCode=500"... Я так понимаю какая то проблема с рабочим сертификатом (который продолжает работать на 2м сервере)? В настройках пула в IIS на обоих серверах сравнил значения, все одинаково..