Заметки IT Менеджера

27.12.2010

Особенности установки сервис паков на Exchange 2007 кластер


Недавно обнаружил, что, оказывается, Microsoft выпустил Service Pack 3 для MS Exchange 2007 :-) Как ни смешно это звучит, но выпустили его еще летом, а заметил я это только сейчас. Проблема в том, что SP к Exchange во WSUS не прилетают и, при этом, Microsoft продолжает выпускать обновления для версии со вторым сервис паком. Ну, в общем-то, оно и к лучшему. За это время MS выпустил два кумулятивных пакета обновления, и ошибочки там пренеприятные.

Что же там поменялось? Самое главное изменения – поддержка установки сервера на Windows 2008 R2 и установки консоли на Windows 7. Кроме того, добавились полнотекстовые индексы в поиске, и улучшили возможность замены пароля через OWA, ну и другое, по мелочи.

Но писать-то я хотел не об этом, интерес представляет сам процесс установки сервис пака на кластер. Я, в свое время, намучался, когда ставил SP2.

У меня кластеризирована роль Mailbox, да и вообще, Exchange 2007 позволяет кластеризировать только ее. Процесс установки сервис пака на кластер сильно отличается от установки его же в остальных случаях. Там все просто, запустил инсталляцию, в появившемся окошке выбрал проинсталлировать и вперед.

Здесь же следует сделать так. Имеется Mailbox Сервер с именем MailBox (это имя кластерного ресурса, т.е. это виртуальный сервер), который физически состоит из двух узлов MailBox1 и MailBox2. MailBox1 – активный узел.

Начинать нужно, как и при установке любых обновлений, с пассивного узла, т.е. MailBox2

Для начала, нужно остановить все сервисы, которые могут иметь открытые счетчики производительности (performance counters). Как минимум, следует остановить Performance Logs and Alerts и агентов MOM, если таковые есть. Кроме этого, следует сделать restart сервису Remote Registry service. Если на узле установлен какой-либо агент бэкапирования, например BackupExec, то его тоже нужно остановить.

Затем, в командной строке нужно перейти в папку с распакованным сервис паком и набрать

setup.com /m:upgrade

Пойдет процесс обновления, сразу скажу – небыстро это. После успешного окончания, нужно перезагрузить MailBox2. Затем там же вызвать Exchange Management Shell и набрать

Stop-ClusteredMailboxServer MailBox -StopReason "Upgrade to SP3"

Нужно понимать, что с этого момента Exchange недоступен пользователям.

Затем, перемещаем Exchange с MailBox1 на MailBox2

Move-ClusteredMailboxServer MailBox -TargetMachine MailBox2 -MoveComment "Upgrade to SP3"

Снова перехожу в папку с сервис паком и ввожу

setup.com /upgradecms

Это интересный шаг, при установке SP2 я получил там весьма неприятную ошибку

Clustered Mailbox Server         ……………………. FAILED
An unexpected error has occurred and debug information is being generated: Object reference not set to an instance of an object.
     Object reference not set to an instance of an object.

Как оказалось, еще на этапе первичной настройки кластера, я был невнимателен и сделал ошибку – перенес ресурсы Cluster IP Address, Cluster Name & Quorum Disk в группу к другим ресурсам Exchange, а должен был оставить в группе по умолчанию. Как только я исправил это, процесс пошел нормально.

По окончании процесса, узел автоматически перейдет в онлайн.

Затем, те нужно провести похожие операции и на MailBox1.

Нужно остановить все сервисы, которые могут иметь открытые счетчики производительности (performance counters). Как минимум, следует остановить Performance Logs and Alerts и агентов MOM, если таковые есть. Кроме этого, следует сделать restart сервису Remote Registry service. Если на узле установлен какой-либо агент бэкапирования, например BackupExec, то его тоже нужно остановить.

Затем, в командной строке нужно перейти в папку с распакованным сервис паком и набрать

setup.com /m:upgrade

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

Написано по материалу: How to Upgrade a Single Copy Cluster to Exchange 2007 SP1 or SP2

Реклама

2 комментария »

  1. Когда они уже допилять накатку апдейтов…
    Хотя в 2010 с его DAG уже гораздо проще

    комментарий от pandafs2@twitter — 27.12.2010 @ 20:17 | Ответить

    • Да все не так страшно :-) Просто между SP перерыв неслабый, успеваешь забыть последовательность. Поэтому я и решил ее описать.

      А DAG — это хорошо, только места в два раза больше нужно, или в 3-4+ раза, что не радует. А вот что хорошо, что в кластер можно все роли засунуть, ну или почти все. Как-никак пограничный сервер или унифицированные коммуникации отдельно держать нужно.

      комментарий от itpadla — 27.12.2010 @ 20:24 | Ответить


RSS feed for comments on this post. TrackBack URI

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Создайте бесплатный сайт или блог на WordPress.com.

%d такие блоггеры, как: