TMG 2010 - Установка Service Pack 2 в массиве NLB

imageРассмотрим пример установки последнего пакета обновлений и исправлений Service Pack 2 для Forefront TMG 2010 в конфигурации с двумя серверами находящимися в отдельном массиве TMG (Standalone Array) и объединёнными в NLB-кластер.

Список обновлений и исправлений вошедших в состав пакета можно найти по ссылке: KB2555840 - Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Загрузить сам пакет: Microsoft Download Center -  Forefront TMG 2010 Service Pack 2

В нашем случае нам понадобиться файл TMG-KB2555840-amd64-ENU.exe, который после установки изменит версию TMG с 7.0.9027.441 до 7.0.9193.500

Версия 7.0.9027.441 соответствует Forefront TMG 2010 SP1 с установленным обновлением Software update 1 и является необходимым минимумом для установки Service Pack 2.

В инструкции по установке Service Pack обозначен следующий обязательный порядок обновления серверов являющихся членами массива:

1) Enterprise Management Servers (master and replicas);
2)
Array managers;
3)
Array members.

В нашем примере массив является отдельным и не использует EMS и поэтому сначала мы должны обновить управляющий сервер массива (Array Manager) а затем остальные управляемые сервера – члены массива (Array Managed). Для того чтобы посмотреть текущие роли серверов в консоли Forefront TMG Management выберем ветку System > закладка Servers

 

image

 

В нашем случае управляющим сервером массива является сервер KOM-AD01-TMG01 и поэтому процесс установки SP2 мы должны начать на нём в первую очередь.

Также следует обратить внимание на то, что в инструкции по установке Service Pack есть ещё одно требование, которое говорит о том, что первым в массиве должен обновляться сервер отчетности (Report Server). Чтобы определить какой сервер отвечает в нашем массиве за данную роль и при необходимости переопределить его, – в консоли выберем ветку Log & Reports и на закладке Reporting выберем задачу Configure Reporting Settings

 

image

 

Перед началом процедуры установки важно выполнить резервное копирование конфигурации массива и отдельных его членов. Сделать это с помощью задачи консоли Export (Back up) в корне дерева консоли

 

image

 

Выполнить операцию экспорта настроек необходимо отдельно на каждом сервере – члене массива. Также неплохо иметь традицию отдельного документирования всех выполненных настроек серверов TMG. Дополнительную информацию о резервном копировании и восстановлении конфигурации TMG можно найти в статье Microsoft Forefront TechCenter - Backing up and restoring the Forefront TMG configuration

Есть еще одно предварительное требование, которое может показаться странным, но тем не менее оно есть в документации и про него не стоит забывать. Для того чтобы процесс обновления Forefront TMG Enterprise Edition (EMS) прошёл успешно, его необходимо выполнять из под учетной записи того пользователя, который производил развертывание сервера EMS.

Итак, общий процесс обновления всего массива в нашем случае будет так:

1) На сервере Array Manager (KOM-AD01-TMG01)

  • Останавливаем службу NLB (Drain and Stop)
  • Блокируем службу NLB (Suspend)
  • Устанавливаем SP2. При необходимости перезагружаем сервер.
  • Восстанавливаем состояние службы NLB (Resume)
  • Запускаем службу NLB (Start)

2) Повторяем указанные действия на всех остальных серверах - членах массива (Array Managed).

Поехали…

Открываем консоль TMG на сервере управления, в ветке Monitoring на закладке Services выбираем службу Network Load Balancing для обновляемого сервера (KOM-AD01-TMG01) и выполняем задачу Drain and stop

 

image

 

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

Дожидаемся пока статус службы не изменится на соответствующий:

 

image

 

После этого закрываем консоль TMG и из под прав Администратора запускаем инсталлятор пакета обновлений. При запуске инсталлятор определит сервер управления конфигурацией массива

 

image

 

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

 

image

 

В моём случае таким процессом оказался MonitoringHost.exe. Это один их процессов агента SCOM запускаемых службой System Center Management (HealthService). И поэтому перед продолжением установки обновления я зашёл в оснастку управления службами (services.msc) и остановил соответствующую службу, что привело к закрытию указанно процесса.

 

image

 

Дожидаемся успешного окончания процесса установки.

 

image

 

После окончания установки не забываем обратно запустить службу агента SCOM.

 

image

 

Открываем обновлённую консоль TMG и в ветке System > закладка Servers проверяем версию обновлённого члена массива.

 

image

 

Обратите внимание на то, что после обновления управляемого сервера в консоли появляется предупреждение о том, что в нашем массиве есть не обновлённые члены.

Переходим в консоли на ветку Monitoring и на закладке Services выбираем службу Network Load Balancing для уже обновлённого сервера (KOM-AD01-TMG01) и выполняем задачу восстановления службы Resume

 

image

 

 

 

В своём случае я обратил внимание на то, что операция Resume поменяла статус состояния службы на Stopped только со второй попытки.

 

image

 

Теперь запускаем службу задачей Start и ждём пока статус не измениться на Running. После этого удостоверимся в том, что все другие службы на обновлённом сервере находятся в запущенном состоянии и теперь можно приступать к обновлению второго сервера, являющегося рядовым управляемым членом массива. Для этого сразу выполним задачи Drain and stop и затем Suspend для его службы NLB.

 

image

 

 

После этого войдём на второй сервер и в оснастке управления службами остановим службу System Center Management  чтобы избежать предупреждений инсталлятора.

Теперь можно запускать сам процесс установки обновления на втором сервере и после его успешного завершения, открыв обновлённую консоль TMG, проверяем версию и убеждаемся в том, что предупреждение о не обновлённых серверах из консоли исчезло.

 

image

 

Не забываем на втором сервере восстановить состояние службы агента SCOM а консоли TMG восстановить состояние службы NLB для обновлённого сервера

 

image

 

Затем запускаем службу NLB.

 

image

 

На этом общий процесс обновления массива можно считать законченным. А для того, чтобы убедиться в том, что все службы TMG на обоих обновлённых серверах самостоятельно адекватно стартуют при запуске системы, - можно по очереди перезагрузить оба сервера, если этого не делалось в процессе установки.

Несмотря на то, что установка SP2 доступна и через клиента WSUS, я предпочёл мануальный способ инсталляции, так как он на мой взгляд является более осязаемым и в случае возможных проблем даёт понять на каком этапе процесса установки возникают эти проблемы.

Источники информации:

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

  1. Баф /

    Забавное требование про учётную запись для установки :)

    А если человек уволился и она удалена? :)

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

      Ну наверняка существует какое-то обходное решение этой проблемы. Я думаю если у вас этой проблемы нет то и заморачиваться на эту тему не стоит.

  2. Oleg /

    День добрый.
    Существует рекомендации по созданию учетных записей для сервисов и административных ролей.
    Не привязывать сервисы к личным учетным записям. Всегда должны использоваться обезличенные учетные записи.

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

      Речь идёт не про сервисы и их запуск от имени служебных учетных записей в классическом понимании. А про то, что процедура установки по обычной практике производится от имени учетной записи администратора. Если честно, я не видел в документации по установке TMG требования или хотябы рекомендации, - выполнять этот процесс от имени обезличенной служебной учетной записи. Поэтому данное требование при установке SP и выглядит как-то нелепо.

  3. Обратная ссылка: TMG 2010 – Локализация и кастомизация сообщений об ошибках « ИТ Блог Алексея Максимова /

  4. Александр /

    у меня конфигурация TMG с двумя EMS-массивами (NLB-кластер) и одним CSS. Процедуру обновления можно запускать "в продакшене"?

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

      Странный вопрос. Не понимаю какой ответ вы хотите от меня услышать. Я у себя в продуктивной среде SP развернул. А вы уж решайте сами.

  5. Саша /

    вроде ж так:
    до установки SP1 версия 7.0.7734.100
    после SP1 - 7.0.8108.200
    после Update1 - 7.0.9027.400
    у меня wsus говорит о готовности ставить SP2 и в документации я нашел упоминание что этого достаточно.
    Алексей, откуда информация про 7.0.9027.441. Что это за обновление?

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

      У меня до установки SP2 был установлен SP1 SU1 Rollup 3. Вот полезная ссылка которая поможет разобраться с версиями: http://blog.forefront-tmg.de/?page_id=27

  6. Дмитрий /

    "Выполнить операцию экспорта настроек необходимо отдельно на каждом сервере – члене массива." - В чём здесь прикол? (или что ещё нужно дополнительно экспортнуть на кадом сервере кроме экспорта Array Configuration?). Ведь в посте "Резервное копирование Array Configuration с PowerShell" было достаточно Array Configuration.

  7. Zer0CooL /

    Может кто нибудь подскажет =)
    После обновления до SP2 возникла проблема с отчетами (User Activity и Site Activity)
    При создании отчета и указании время начала (для примера 24 часа) в столбике Start date отражается One week ago
    и так с любой датой ! и именно для данных 2-х типов отчета.

    уже пробовал обновиться до sp rollup1
    и позже до sp2 rollup 2

    и даже интегрировал все обновления в дистрибутив и ставил на тестовой машине с нуля

    итог один и тот-же =(

    а щас отчеты резко приспичило =(

  8. Антон /

    Добрый день!

    А никто случаем не сталкивался с ошибкой :

    Microsoft Forefront TMG Control failed to start. The failure occurred during Security Watchdog notification processing because the system call ApplyAccessControlSettings failed. Use the source location 122.86.7.0.9193.644 to report the failure. The error description is: An attempt was made to reference a token that does not exist.
    ID 11004

    Две ноды TMG в кластере NLB Multicast. На одной из них не стартуют службы TMG.
    Предыстория : Одна из нод была восстановлена на 4 дня назад из бекапа (конфигурация за 4 суток не менялась). При старте обнаружилось "потеря дов. отношений с доменом". Была выведена и заведена в домен заново. Как результат - свыше ошибка. Причем TMG Storage запускаются и синхронизация со второй нодой есть.

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