Установка обновлений на Exchange Server 2013/2016 в DAG

Exchange Server 2013-2016 DAG Maintenance Mode ScriptsВыпущены долгожданные обновления для почтовых серверов 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)

Всего комментариев: 27 Комментировать

  1. AlektroNik /

    Я не владелец Exchange, но еще бы схемку отката почитать :)

    1. Алексей Максимов /

      Вопрос по принципу "Не съем, так надкушу..."

  2. guznin /

    Из откатов только бэкап или не самый лучший вариант--установка сервера в режиме восстановления. Но для того, чтобы не было проблем, лучше протестировать на стенде.

  3. Хочу поинтересоваться, почему первым нужно обновлять именно CAS? В другой статье я читал про обратный порядок.

    1. Константин Гузнин / Автор записи

      Если быть до конца правильным, то сначала надо обновлять EDGE, затем CAS, затем MBX. Смысл прост: если сервер накроется и не захочет нормально то пусть это будет менее значимый CAS, нежели MBX. Никакой другой логики тут быть не может, т.к. у вас все равно некоторое время будут сервера с разными версиями в одной организации.

      1. Ну вот тут, товарищ имеет противоположное мнение: http://exchangeserverpro.com/exchange-2013-installing-cumulative-updates/
        А разные версии на серверах для exchange 2013 вроде как больше не критично, так как нет кроссайтового проксирования CAS to CAS

        1. guznin /

          Полу респект и уважуха, но и он не безгрешен :-) Эти заморочки были важны в 2010. Сейчас на тебя вообще косо смотрят, если ты скажешь, что разносишь роли 2013 Exchange, а в 2016 и того одна роль (edge не в счет).

          1. Вопрос именно в причинах такого ордера. Либо в 2013 никакого ордера нет и можно лепить ролап в любом порядке, тогда и упоминать о нем не стоит. Вот например, порядок установки ролей (с нуля) точно существует и ставить надо первым именно MBX, так как на нем расположен инстанс EMS. Если поставить первым CAS, то он просто не сможет ни к чему подключиться.
            Гибридное развертывание - это конечно гуд, но если есть аппаратный балансировщик, если нет - добро пожаловать в клуб NLB и вперед разносить роли

          2. Вот здесь тоже предлагают обновить сначала MBX. http://smtp25.ru/archives/1821
            Только никто не говорит почему так.

    2. Константин Гузнин / Автор записи

      В целом, ситуация такая: нету официального документа от МС, в котором прописан порядок установки обновлений для 2013. Для 2010 установлен порядок: CAS,HUB,MBX.

  4. Константин Гузнин / Автор записи

    А если поставить первым MBX, то к нему тоже никто не подключится, т.к. нет CAS :-) Когда я ставлю сервера с нуля, то они все ставятся параллельно, т.к. дни лукавы. На 3000 пользователей DNS балансировка работает вполне нормально. Я уже говорил, что исхожу только из того, что CAS легче и быстрее восстановить, он не выполняет основную работу. Других аргументов я не вижу.

    1. Спросил сегодня про порядок у специалистов премьер поддержки МС. Никакого ордера нет, обновлять можно в любом порядке

      1. guznin /

        Обсуждали вчера этот вопрос с коллегами в Facebook, пришли к такому же мнению.

        1. Michael /

          Логика там была довольно простая - свежий CAS умеет проксировать к MBX старых версий, но не наоборот.

          1. guznin /

            Кто вам сказал, что "старый" CAS не умеет проксировать на "Новый" MBX? Что он там может не уметь?))

  5. Sergey Korotkov /

    Спасибо за статью.
    Добавил бы только перезапуск сервисов транспорта, чтобы он быстрее сообразил что режим работы компонентов изменился.
    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")

    1. Константин Гузнин / Автор записи

      Спасибо, поправил. Что касается служб, то установщик их сам стопит, а потом стартует, после чего предлагает ребут. Очередь проверить можно, чисто для очистки совести, ведь перед этим мы сделали редирект. ("Командлет Redirect-Message используется для извлечения активных сообщений из всех очередей доставки на сервере почтовых ящиков и направления их на другой сервер почтовых ящиков" https://technet.microsoft.com/ru-ru/library/jj215667%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396)

      1. Sergey Korotkov /

        >> Что касается служб, то установщик их сам стопит, а потом стартует, после чего предлагает ребут.
        При включении (Set-ServerComponentState $ServerName -Component ServerWideOffline -State Active -Requester Maintenance) не перезапускает :).

        Просто наткнулся как раз и обратил внимание. Вроде все включил а Get-ServerComponentState - Inactive.

        >> Очередь проверить можно, чисто для очистки совести, ведь перед этим мы сделали редирект.
        Redirect-Message разве не асинхронно работает? Если очередь большая и команды выполняются одним пакетом - не задержим ли доставку, а в случае неудачного обновления - потеряем.

        1. Константин Гузнин / Автор записи

          Компоненты сервера, после обновления будут в состоянии InActive. Можно подождать некоторое время, пока сервер сам их стартанет, а можно сделать это вручную, командлетом Set-ServerComponentState. Я использовал второй вариант, написав скрипт в одну строчку и переведя ВСЕ компоненты в состояние Active.(если интересует, могу написать).

          >>Redirect-Message разве не асинхронно работает? Если очередь большая и команды выполняются одним пакетом — не задержим ли доставку, а в случае неудачного обновления — потеряем.

          Потерять, точно не потеряем (пока копии сообщений не будут на всех серверах, они не отправляются), а вот сообщения которые переместились в очередь на другой сервер будут отправлены с небольшой задержкой (1-2 минуты, что вполне приемлемо). И да, в случае с большой очередью задержка может быть приличная, но это вопрос к сайзнгу почтовой системы, почему на сервере очередь большая. Из практики: 2500 пользователей с активной перепиской создают очередь 10-20 сообщений на 2 серверах. Это норма и это не много.

  6. Обратная ссылка: Миграция с Zimbra на Exchange Server 2016, ресурсный лес, PowerShell и все,все,все… | Блог IT-KB /

  7. ser /

    Подскажите такой вопрос. Имею DAG. переведу сервер в режим обслуживания - выключу. После этого, если сделать снимок сервера. Откатиться на него можно будет при неудачном обновлении ? естественно не выводя его из режима обслуживания после обновления.

    1. guznin /

      Нет, этот сценарий не поддерживается. Если у вас есть кластер, скажем из 4 серверов, один выводите в режим обслуживания и обновляете его, пока он нормально не обновится. Если его не получается нормально обновить, сносите винду, отключаете(!!!не удаляете) учётку сервера, ставите винду, ставите все необходимые Фили сервера + UC компоненты, запускаете установку в режиме восстановления (setup /m:recoverserver https://technet.microsoft.com/ru-ru/library/dd876880(v=exchg.160).aspx)

  8. Кирилл /

    Я бы еще добавил, если у вас балансировка Round-robin DNS, то нужно в DNS удалять запись A обовляемой ноды, которая смотрит на общее имя.

  9. Alex DeBuck /

    "Скрипты для автоматического перевода сервера в режим обслуживания и обратно"
    - пожалуйста, обновите ссылки на скрипты.

    1. Maks /

      Поддержу предыдущего оратора )

      Обновите пожалуйста ссылки.

  10. Алексей Максимов /

    По какой-то причине автор скриптов убрал скрипты с gallery.technet.microsoft.com
    Поэтому ссылки заменены на те, что обнаружены на текущий момент времени в публичном доступе на GitHub.
    Обязательно анализируйте/тестируйте скрипты перед использованием в продуктиве.

  11. Maxim /

    Коллеги, подскажите пожалуйста такой момент - после обновления 1 из серверов dag версии 2019 с CU9 на CU11 (предварительно переводил в maintenance mode) получил проблему по веб с ecp и owa -
    если заходить на сам сервер: "Ошибка сервера в приложении '/owa'.
    ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1 "
    и если заходить по имени общего каталога "https://laura/owa/auth/errorFE.aspx?httpCode=500&quot;... Я так понимаю какая то проблема с рабочим сертификатом (который продолжает работать на 2м сервере)? В настройках пула в IIS на обоих серверах сравнил значения, все одинаково..

Добавить комментарий