Рассмотрим пример установки последнего пакета обновлений и исправлений 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
В нашем случае управляющим сервером массива является сервер KOM-AD01-TMG01 и поэтому процесс установки SP2 мы должны начать на нём в первую очередь.
Также следует обратить внимание на то, что в инструкции по установке Service Pack есть ещё одно требование, которое говорит о том, что первым в массиве должен обновляться сервер отчетности (Report Server). Чтобы определить какой сервер отвечает в нашем массиве за данную роль и при необходимости переопределить его, – в консоли выберем ветку Log & Reports и на закладке Reporting выберем задачу Configure Reporting Settings
Перед началом процедуры установки важно выполнить резервное копирование конфигурации массива и отдельных его членов. Сделать это с помощью задачи консоли Export (Back up) в корне дерева консоли
Выполнить операцию экспорта настроек необходимо отдельно на каждом сервере – члене массива. Также неплохо иметь традицию отдельного документирования всех выполненных настроек серверов 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
После этого обновляемый сервер перестанет принимать клиентские подключения и немного подождав выполняем для этой же службы задачу Suspend, то есть переводим службу в такое состояние, при котором наш сервер не будет участвовать в обслуживании клиентских подключений даже после перезагрузки.
Дожидаемся пока статус службы не изменится на соответствующий:
После этого закрываем консоль TMG и из под прав Администратора запускаем инсталлятор пакета обновлений. При запуске инсталлятор определит сервер управления конфигурацией массива
Далее, вы можете получить от инсталлятора сообщение о том что какие-то процессы в системе используют файлы которые требуется обновить. И такие процессы для успешного окончания установки желательно завершить.
В моём случае таким процессом оказался MonitoringHost.exe. Это один их процессов агента SCOM запускаемых службой System Center Management (HealthService). И поэтому перед продолжением установки обновления я зашёл в оснастку управления службами (services.msc) и остановил соответствующую службу, что привело к закрытию указанно процесса.
Дожидаемся успешного окончания процесса установки.
После окончания установки не забываем обратно запустить службу агента SCOM.
Открываем обновлённую консоль TMG и в ветке System > закладка Servers проверяем версию обновлённого члена массива.
Обратите внимание на то, что после обновления управляемого сервера в консоли появляется предупреждение о том, что в нашем массиве есть не обновлённые члены.
Переходим в консоли на ветку Monitoring и на закладке Services выбираем службу Network Load Balancing для уже обновлённого сервера (KOM-AD01-TMG01) и выполняем задачу восстановления службы Resume
В своём случае я обратил внимание на то, что операция Resume поменяла статус состояния службы на Stopped только со второй попытки.
Теперь запускаем службу задачей Start и ждём пока статус не измениться на Running. После этого удостоверимся в том, что все другие службы на обновлённом сервере находятся в запущенном состоянии и теперь можно приступать к обновлению второго сервера, являющегося рядовым управляемым членом массива. Для этого сразу выполним задачи Drain and stop и затем Suspend для его службы NLB.
После этого войдём на второй сервер и в оснастке управления службами остановим службу System Center Management чтобы избежать предупреждений инсталлятора.
Теперь можно запускать сам процесс установки обновления на втором сервере и после его успешного завершения, открыв обновлённую консоль TMG, проверяем версию и убеждаемся в том, что предупреждение о не обновлённых серверах из консоли исчезло.
Не забываем на втором сервере восстановить состояние службы агента SCOM а консоли TMG восстановить состояние службы NLB для обновлённого сервера
Затем запускаем службу NLB.
На этом общий процесс обновления массива можно считать законченным. А для того, чтобы убедиться в том, что все службы TMG на обоих обновлённых серверах самостоятельно адекватно стартуют при запуске системы, - можно по очереди перезагрузить оба сервера, если этого не делалось в процессе установки.
Несмотря на то, что установка SP2 доступна и через клиента WSUS, я предпочёл мануальный способ инсталляции, так как он на мой взгляд является более осязаемым и в случае возможных проблем даёт понять на каком этапе процесса установки возникают эти проблемы.
Источники информации:
- Forefront TMG (ISA Server) Product Team Blog > How to patch a TMG array– some thoughts on NLB high availability
- Microsoft Forefront TechCenter - Installing Forefront TMG Service Packs
- What’s New in Forefront Threat Management Gateway (TMG) 2010 Service Pack 2
- Yuri Diogenes's Blog > Five reasons you should apply Forefront TMG 2010 SP2
RSS - Записи
Забавное требование про учётную запись для установки :)
А если человек уволился и она удалена? :)
Ну наверняка существует какое-то обходное решение этой проблемы. Я думаю если у вас этой проблемы нет то и заморачиваться на эту тему не стоит.
День добрый.
Существует рекомендации по созданию учетных записей для сервисов и административных ролей.
Не привязывать сервисы к личным учетным записям. Всегда должны использоваться обезличенные учетные записи.
Речь идёт не про сервисы и их запуск от имени служебных учетных записей в классическом понимании. А про то, что процедура установки по обычной практике производится от имени учетной записи администратора. Если честно, я не видел в документации по установке TMG требования или хотябы рекомендации, - выполнять этот процесс от имени обезличенной служебной учетной записи. Поэтому данное требование при установке SP и выглядит как-то нелепо.
Обратная ссылка: TMG 2010 – Локализация и кастомизация сообщений об ошибках « ИТ Блог Алексея Максимова /
у меня конфигурация TMG с двумя EMS-массивами (NLB-кластер) и одним CSS. Процедуру обновления можно запускать "в продакшене"?
Странный вопрос. Не понимаю какой ответ вы хотите от меня услышать. Я у себя в продуктивной среде SP развернул. А вы уж решайте сами.
вроде ж так:
до установки SP1 версия 7.0.7734.100
после SP1 - 7.0.8108.200
после Update1 - 7.0.9027.400
у меня wsus говорит о готовности ставить SP2 и в документации я нашел упоминание что этого достаточно.
Алексей, откуда информация про 7.0.9027.441. Что это за обновление?
У меня до установки SP2 был установлен SP1 SU1 Rollup 3. Вот полезная ссылка которая поможет разобраться с версиями: http://blog.forefront-tmg.de/?page_id=27
"Выполнить операцию экспорта настроек необходимо отдельно на каждом сервере – члене массива." - В чём здесь прикол? (или что ещё нужно дополнительно экспортнуть на кадом сервере кроме экспорта Array Configuration?). Ведь в посте "Резервное копирование Array Configuration с PowerShell" было достаточно Array Configuration.
Может кто нибудь подскажет =)
После обновления до SP2 возникла проблема с отчетами (User Activity и Site Activity)
При создании отчета и указании время начала (для примера 24 часа) в столбике Start date отражается One week ago
и так с любой датой ! и именно для данных 2-х типов отчета.
уже пробовал обновиться до sp rollup1
и позже до sp2 rollup 2
и даже интегрировал все обновления в дистрибутив и ставил на тестовой машине с нуля
итог один и тот-же =(
а щас отчеты резко приспичило =(
Добрый день!
А никто случаем не сталкивался с ошибкой :
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 запускаются и синхронизация со второй нодой есть.