• Разворачиваем SCOM 2012 - Часть 4 – Установка роли Report Server

    image

    В этой части мы установим роль SCOM Reporting Server на ранее сконфигурированный сервер с SQL Server 2008 R2 StandardSCOMDB. Официальное руководство в документе - How to Install the Operations Manager Reporting Server

    Требования, предъявляемые к серверу для роли SCOM Reporting Server можно найти в документе Supported Configurations for System Center 2012 - Operations Manager

    Выполняем ряд предварительных условий…

    1. Для начала убедимся в том, что на нашем SQL сервере запущена и настроена на автоматический запуск служба Remote Registry

    image

    2. Во второй части Разворачиваем SCOM 2012 - Часть 2 – Настройка сервера БД  - мы уже установили и настроили .NET Framework 3.5 SP1 и .NET Framework 4 на сервере SCOMDB

     

    3. Убеждаемся в том, что учётные записи s-OM-Action, s-OM-DA-Svc, s-OM-DB-Svc, s-OM-Writer и s-OM-Reader включены в группу локальных Администраторов на сервере SCOMDB

    4. Убеждаемся в том что SQL Server Reporting Services настроена и запущена – открываем из меню Пуск - Microsoft SQL Server 2008 R2Configuration ToolsReporting Services Configuration Manager

    image

    image

    5. Проверяем доступность веб-части сервера отчетов, попробовав с удалённого компьютера открыть ссылки http://SCOMDB/reportserver и http://SCOMDB/reports

    Если ссылки не открываются, значит возможно на брандмауэре заблокирован порт TCP 80. Откроем его командой:

    netsh advfirewall firewall add rule name = "SQL Server Reporting Services" dir = in protocol = tcp action = allow localport = 80

    Теперь запускаем программу установки SCOM 2012 и на шаге выбора компонент отмечаем Reporting Server

    image

    Затем указываем имя сервера на который мы ранее установили компоненту Web console

    image

    Далее указываем сервер и экземпляр SQL в котором предварительно развернута службы SQL Server Reporting Services (SSRS), в нашем случае это будет текущий сервер, на котором мы сейчас выполняем установку – SCOMDB 

    image

    На шаге конфигурирования учетных записей, указываем учетные данные пользователя s-OM-Reader, которого мы создали ранее на подготовительном этапе - Разворачиваем SCOM 2012 – Часть 1 – Подготовкаimage

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

    image

    После окончания процесса установки запускаем консоль Operations console и убеждаемся в том, что в левой панели навигации появился раздел Reporting и нам доступна возможность формирования отчетов. Стоит заметить, что не все отчёты появятся сразу, надо будет выждать какое-то время пока отчеты SCOM Reporting развернуться в службе SSRS

    image

    Источники информации и полезные ссылки:

  • Разворачиваем SCOM 2012 - Часть 3 - Установка серверов управления

    image

      Для серверов управления у нас заранее подготовлены две виртуальные машины (SCOM01 и SCOM02) с конфигурацией - RAM 6 Gb ; VHD1 60 Gb; ОС - Windows Server 2008 R2 Standard SP1 English.

    Требования, предъявляемые к установке роли сервера управления SCOM берём из документа Supported Configurations for System Center 2012 - Operations Manager

    На каждом сервере где планируется установка компонент Management Server и Operations Console  (в нашем случае это SCOM01 и SCOM02) выполняем следующие подготовительные действия:

    1. Включаем Windows Remote Management. Сделать это можно например через оснастку Server Manager

    image

    2. Открываем консоль PowerShell с правами администратора и включаем компоненту Net Framework Core.

    Import-Module ServerManager

    Add-WindowsFeature NET-Framework-Core

    image

    3. Скачиваем и устанавливаем .NET Framework 4. В моём случае этого делать не пришлось так как этот пакет уже был установлен на сервер ранее в составе обновлений, прикатившихся с локального сервера WSUS.

    4. Скачиваем пакет Microsoft Report Viewer 2008 SP1 Redistributable и выполняем его установку.

    image

    Несмотря на то, что в списке требований речь идёт о пакете Microsoft Report Viewer 2008 SP1 Redistributable, если дополнительно не установить пакет Microsoft Report Viewer 2010 Redistributable Package, то в процессе установки SCOM может возникать ошибка зависимости, после чего процесс установки невозможен. Устанавливаем этот пакет.

    image

    5. Убеждаемся в том, что учетные записи действия (s-OM-Action) и доступа к данным (s-OM-DA-Svc) включены в группу локальных Администраторов.

    На сервере, где планируется установка компоненты Web Console (в нашем случае это SCOM01), дополнительно выполняем следующие подготовительные действия:

    1. Открываем с правами администратора консоль PowerShell и выполняем установку компонент IIS:

    Import-Module ServerManager

    Add-WindowsFeature NET-Framework-Core,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net,Web-Windows-Auth -Restart

    image

    2. Выполняем регистрацию ASP.NET 4 в Internet Information Services (IIS). Для этого открываем командную строку с правами администратора и выполняем команду:

    %WINDIR%Microsoft.NETFramework64v4.0.30319aspnet_regiis.exe –r

    image

    3. Открываем оснастку управления IIS, переходим в настройку ISAPI and CGI Restrictions и разрешаем выполнение ASP.NET v4.0.30319

    image

    Теперь можно приступить к самому процессу установки SCOM…

    Шаг первый.
    Установка первого сервера управления (Management Server).

    Официальное описание процесса установки первого сервера можно найти в документе How to Install the First Management Server in a Management Group

    Распаковываем образ инсталляционного диска SCOM 2012, запускаем файл SETUP.EXE и выбираем Install

    image

    На шаге выбора устанавливаемых компонент SCOM отмечаем Management server, Operations console и Web console 

    image

    Каталог установки оставляем по умолчанию.

    image

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

    image

    На шаге указания информации о группе управления (management group) выбираем создание новой группы – Create the first management server in new management group и вводим имя создаваемой группы управления. В нашем примере имя группы будет MG01. В некоторых источниках в интернете можно встретить рекомендацию не использовать в имени группы спецсимволы, к чему я решил прислушаться.

    image

    На шаге указания параметров создаваемой операционной базы данных SCOM  укажем имя сервера SQL Server, экземпляр и порт. Если, как в нашем случае, используется экземпляр по умолчанию (MSSQLSERVER), то его можно не указывать. Имя операционной базы данных и начальный её размер оставляем в значении по умолчанию. В полях указания путей файлов БД укажем пути к каталогам на ранее специально созданных логических дисках сервера SCOMDB.

    image

    На шаге указания параметров создаваемой базы данных хранения SCOM укажем имя сервера SQL Server, экземпляр и порт. Если, как в нашем случае, используется экземпляр по умолчанию (MSSQLSERVER), то его можно не указывать. Параметром Create a new data warehouse database определяем то, что мы создаем новую БД.

    Имя базы данных и начальный её размер оставляем в значении по умолчанию. В полях указания путей файлов БД укажем пути к каталогам на ранее специально созданных логических дисках сервера SCOMDB.

    image

    На следующем шаге укажем имя существующего на нашем сервере сайта IIS, который будет использоваться под размещение Web console. Оставляем значение по умолчанию – Default Web Siteimage

    На шаге выбора метода аутентификации для веб-консоли SCOM выбираем смешанный режим - Use Mixed Authentication, так как мы планируем использовать этот веб-узел только внутри локальной сети и хотим чтобы нам был доступен метод сквозной проверки учетных данных (SSO) 

    image

    На шаге конфигурирования учетных записей, указываем учетные данные пользователей, которых мы создали ранее на подготовительном этапе - Разворачиваем SCOM 2012 – Часть 1 – Подготовка

    image

    Пропустим следующие два шага с настройками участия в программе улучшения качества Microsoft CEIP и Windows Update и перейдя к финальному шагу нажмём Install image

    image

    image

    image

    Дождавшись успешного окончания процесса установки проверим работоспособность консолей Operations console и Web console.

    В частности, в консоли Operations console в панели навигации перейдём в раздел Administration и выберем Device Management > Management Servers, чтобы убедиться в том, что там присутствует первый наш сервер управления и находиться он в состоянии Healthy

    image

    Теперь переходим в раздел консоли Monitoring и в секции просмотра активных предупреждений Active Alerts видим, что появилось критическое предупреждение об отсутствии регистрации SPN для службы Data Access Service. На самом деле, в нашем случае это предупреждение можно считать ложным, так как оно реагирует на отсутствие SPN MSOMSdkSvc/* у учетной записи сервера управления, а в нашем случае служба доступа к данным работает от имени доменной учетной записи пользователя и регистрация SPN MSOMSdkSvc/* в таком случае должна выполняться именно для этой учётной записи. Пост Кевина Холмана OpsMgr 2012: What should the SPN’s look like? подтверждает это.

    И несмотря на то, что мы заранее выполнили необходимое условие для успешной регистрации SPN – расширили права для учетной записи s-OM-DA-Svc, – всё равно автоматическая регистрация SPN для этой учётной записи не выполняется. Ветка обсуждения SCOM 2012: Data Access Service SPN Not Registered говорит о том, что мы не одиноки в этой проблеме и на данный момент, я полагаю, это можно расценивать как баг. 

    image

    Несмотря на то, что избавиться от этого предупреждения нам не удастся (надеюсь до первого CU), мы должны самостоятельно зарегистрировать SPN для учетной записи службы доступа к данным s-OM-DA-Svc командами:

    Setspn.exe -A MSOMSdkSvc/SCOM01 s-OM-DA-Svc

    Setspn.exe -A MSOMSdkSvc/SCOM01.holding.com s-OM-DA-Svc

    После этого проверяем результат командой:

    Setspn -L s-OM-DA-Svc

    image

    После этого, чтобы изменения вступили в силу, нужно закрыть консоль SCOM и перезапустить службу System Center Data Access Service.

    Шаг второй.
    Разворачиваем дополнительные сервера управления.

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

    Официальный документ по развертыванию дополнительных серверов управления SCOM здесь: How to Install Additional Management Servers

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

    Запускаем процесс установки компонент Management Server и Operations Console, доходим до шага указания группы управления SCOM и выбираем вариант подключения к уже существующей группе управления - Add a Management server to an existing management group.
    image

    Далее указываем параметры уже созданной ранее операционной базы данных SCOM

    image

    На следующем шаге указываем учетные записи действия и доступа к данным, то есть те же доменные учетные записи, которые мы указывали при установке первого сервера управления SCOM

    imageПосле окончания установки дополнительного сервера обновляем SPN учётной записи службы доступа к данным:

    Setspn.exe -A MSOMSdkSvc/SCOMMS02 s-OM-DA-Svc

    Setspn.exe -A MSOMSdkSvc/SCOMMS02.holding.com s-OM-DA-Svc
     

    Проверяем результат:

    Setspn -L s-OM-DA-Svc

    image

    После этого, чтобы изменения вступили в силу, нужно закрыть консоль SCOM и перезапустить службу System Center Data Access Service.

  • SCOM 2007 R2 - Ручная установка Operations Manager Shell

    В некоторых ситуациях может возникнуть необходимость использования PS консоли  Operations Manager Shell на системах, где не произведена установка Operations Console (UI консоль). Рассмотрим вариант быстрого ручного прикручивания командной консоли SCOM.

    Первым делом, с системы, где произведена соответствующая установка Operations Manager Shell с полного дистрибутива скопируем 6 файлов из каталога установки. Например, в качестве исходной системы мы используем один из серверов управления SCOM с установленной командной консолью (в нашем примере это сервер KOM-AD01-MON01). Если на исходной системе каталог установки – “C:Program FilesSystem Center Operations Manager 2007”, то создадим такой же каталог на системе, в которую хотим прикрутить командную консоль. Это нужно для того, чтобы в дальнейшем не вносить сложных корректировок в системный реестр.

    MKDIR “C:Program FilesSystem Center Operations Manager 2007”

    Скопируем необходимые файлы с исходной системы в созданный каталог. Нам понадобиться всего 6 файлов:

    • Из папки C:Program FilesSystem Center Operations Manager 2007:

      Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll-help.xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml

    • Из папки C:Program FilesSystem Center Operations Manager 2007SDK Binaries:

      Microsoft.EnterpriseManagement.OperationsManager.dll
      Microsoft.EnterpriseManagement.OperationsManager.Common.dll

    Быстро это сделать можно, например, при помощи скрипта PowerShell J (только замените имя исходной системы):

    # Каталог куда копируем

    $LocalDir = 'C:Program FilesSystem Center Operations Manager 2007'

    # Каталог откуда копируем. Имените имя исходного компьютера

    $RemoteDir = '\kom-ad01-mon01C$Program FilesSystem Center Operations Manager 2007'

    New-Item -Path $LocalDir -ItemType Directory

    Copy-Item $RemoteDir+'Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll' -Destination $LocalDir -Force

    Copy-Item $RemoteDir+'Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll-help.xml' -Destination $LocalDir -Force

    Copy-Item $RemoteDir+'Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml' -Destination $LocalDir -Force

    Copy-Item $RemoteDir+'Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml' -Destination $LocalDir -Force

    Copy-Item $RemoteDir+'SDK BinariesMicrosoft.EnterpriseManagement.OperationsManager.*' -Destination $LocalDir –Force

    Далее экспортируем параметры Powershell Snap-in с исходной системы на целевую, например, так:

    REG EXPORT HKLMSOFTWAREMicrosoftPowerShell1PowerShellSnapInsMicrosoft.EnterpriseManagement.OperationsManager.Client C:TempOpsMgrCmdShellSnapIn.reg


    Выгруженный reg файл должен иметь примерно следующее содержание:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1PowerShellSnapInsMicrosoft.EnterpriseManagement.OperationsManager.Client]
    "ApplicationBase"="C:\Program Files\System Center Operations Manager 2007\"
    "AssemblyName"="Microsoft.EnterpriseManagement.OperationsManager.ClientShell, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
    "ModuleName"="C:\Program Files\System Center Operations Manager 2007\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll"
    "PowerShellVersion"="1.0"
    "Vendor"="Microsoft Corporation"
    "Version"="6.0.4900.0"
    "Description"="Microsoft Operations Manager Shell Snapin"
    "Types"="C:\Program Files\System Center Operations Manager 2007\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml"
    "Formats"="C:\Program Files\System Center Operations Manager 2007\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml"

    Загружаем полученный reg файл в реестр на целевой системе:

    REG IMPORT '\kom-ad01-mon01C$TempOpsMgrCmdShellSnapIn.reg'


    Осталось сделать скрипт, который будет подгружать в PowerShell консоль необходимый Snap-in:

    # В переменной $rootMS необходимо указать RMS сервер

    $rootMS = 'SCOM-RMS-SERVER'

    $checksnappin = Get-PSSnapin | where {$_.Name -eq "Microsoft.EnterpriseManagement.OperationsManager.Client"}

    if ($checksnappin -eq $null)

    {

    add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;

    }

    Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;

    new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ;

    set-location $rootMS -ErrorVariable errSnapin ;


    Назовём этот скрипт, например, Start.ps1… В итоге мы получим всего 7 файлов которые обеспечат нам работоспособность Operations Manager Shell без процедуры установки из полного инсталлятора размером более 1 Gb.

    image

    Найдено в блоге Derek Ops Manager - Operation Manager Command Shell on any system (12 July 2007) и проверено применительно версии SCOM 2007 R2 CU#2. Работает J

  • Установка и базовая настройка системы мониторинга Zabbix 3.0 LTS на Ubuntu Server 14.04 LTS

    Zabbix 3 on Ubuntu 14Мелкие и средние компании зачастую пренебрегают таким компонентом IT инфраструктуры, как мониторинг разных узлов локальной сети. При возникновении проблем в таких компаниях может проходить достаточно много времени, пока инженеры поймут, что происходит в их IT инфраструктуре, что, само по себе, очень критично для бизнеса.  Имплементация и правильная настройка системы мониторинга облегчает жизнь IT специалиста на порядок, но стоит заметить, что на начальном этапе сбора и анализа информации в системе мониторинга увеличивается количество рабочих часов. Почему? Всплывают те ошибки, которые вы могли не замечать или просто игнорировали в течении долгого периода времени. При этои рынок программного обеспечения предлагает целый ряд продуктов, так или иначе связанных с мониторингом. В ряде широко используемых продуктов присутствуют такие, как Microsoft System Center Operations Manager (SCOM), Nagios, Zabbix, Cacti и т.д.

    Читать далее...

  • Интеграция SCOM 2012 R2 и SCDPM 2012 R2 со сторонней системой ServiceDesk с помощью SCOrch 2012 R2

    Так уж получилось что в нашей компании используется система ServiceDesk не из состава System Center (я говорю о Service Manager). Возник вопрос об интеграции этого продукта с используемыми продуктами System Center, а конкретно с System Center 2012 R2 Data Protection Manager и System Center 2012 R2 Operations Manager. Первая задача по интеграции была следующая – необходимо отслеживать инциденты, возникающие в процессе резервного копирования, и регистрировать их в системе ServiceDesk.

    Первым делом были рассмотрены возможности нашей системы ServiceDesk – у нее обнаружился удобный REST API для взаимодействия. Общей шиной для взаимодействия был выбран System Center Orchestrator и именно этот выбор побудил меня написать эту статью (а может и цикл статей, посвященный Orchestrator, так как по нему не очень много статей на русском, да и вообще).

    Алгоритм работы процесса такой:

    1. Operations Manager собирает информацию обо всех алертах Data Protection Manager

    2. Orchestrator запускает каждые два часа RunBook в котором считывает все новые алерты из Operations Manager и создает на их основе инциденты в ServiceDesk, после чего обновляет алерты вписывая им номера инцидентов (TicketID) и меняя статус (ResolutionState).

    Итак, имея все исходные данные и алгоритм работы, остается только реализовать его в виде RunBook в System Center Orchestrator.

    Читать далее...

  • SC 2012 Orchestrator - Режим обслуживания SCOM по расписанию

    imageДля начала хочу рассказать предысторию того как я пришёл к использованию System Center 2012 Orchestrator (SCO), которая по сути прямого отношения к самому этому продукту не имеет, но возможно информация изложенная здесь кому-то покажется интересной и даст ответы на некоторые вопросы.

    Итак, жила-была ферма Remote Desktop (RD) Connection Broker состоящая из трёх виртуальных серверов RD Session Host на базе Hyper-V, которые обслуживали пользователей в рабочее время и без каких-либо проблем подвергались резервному копированию с помощью System Center 2012 DPM в нерабочее время. И всё бы ничего если бы не возникшая необходимость начать использовать на этих виртуальных серверах клиента Application Virtualization Client (App-V) for Remote Desktop Services. Клиент то конечно установился и прекрасно справляется со своей задачей – виртуализацией в многопользовательской среде весьма специфических приложений, требующих от пользователей расширенных привилегий в системе. Но вот незадача…сразу после начала использования клиента App-V я заметил две вещи: во первых - на DPM пропала возможность нативно на горячую с помощью метода Backup Using Child Partition Snapshot бэкапить виртуальные сервера фермы полноценно используя VSS (осталась доступной лишь возможность бэкапа с помощью Backup Using Saved State), а во вторых – при бэкапе в режиме Save State каждую ночь фиерично разваливался кластерный экземпляр службы RD Connection Broker. По сути вторая проблема является прямым следствием первой. Но это стало ясно позже...А пока я взялся за изучение проблемы систематично разваливающегося кластера RDS…

    Резервное копирование виртуальных серверов (нод кластера) выполнялось в 3.00 каждую ночь и как раз в это время происходил развал кластера. При этом в логе серверов фиксировалось довольно занятное событие:

    Event ID:10 - The miniport 'Microsoft Virtual Machine Bus Network Adapter' disconnected.

    …и затем буквально через пару минут…

    Event ID: 9 - The miniport 'Microsoft Virtual Machine Bus Network Adapter' connected.

    image_thumb2

    Стало очевидно что в процессе создания резервной копии виртуального сервера методом Save State происходит фактически его кратковременное “замораживание”, что влечёт за собой кратковременную потерю сетевого соединения, и как следствие, приводит к коллапсу службы кластера…Ох уж мне этот Save State… Но почему же исчезла возможность бэкапа на горячую с помощью снапшотов?… Колупание недр интернета привело к мысли о том, что в такой “неполноценности” с точки зрения DPM, виноват виртуальный диск который создаётся в системе для нужд клиента App-V.

    image_thumb1

    Натолкнувшись на заметки Deutscher App-V Blog - App-V und VSS–Backup oder kein Backup… и Gridmetric Blog - Enabling (service) process access to App-V virtual environment пришёл к выводу о том, что между VSS и виртуальным диском App-V какая то давняя врождённая нелюбовь, вызванная, на мой взгляд, аскетичностью архитектуры последнего. Обнаружил на своих виртуальных серверах то, что vssadmin действительно не может получить полный список томов

    image_thumb

    Воспользовался рецептом описанным в немецком блоге, разрешив провайдеру VSS доступ к виртуальному тому App-V c помощью ключа реестра:

    [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSoftGrid4.5ClientAppFSServiceInclusions]

    "VSS"="swprv" (STRING)

    swprv в данном случае это имя процесса Microsoft Volume Shadow Copy Service software provider. После изменения реестра и перезагрузки виртуальных серверов стало понятно, что ошибка с vssadmin исчезла, но он всё равно не воспринимает виртуальный том App-V как что-то съедобное, и причиной того вероятно является тип файловой системы этого самого тома…

    Надеясь поставить точку в этом вопросе, создал обращение в тех.поддержку MS, изложив всю фактуру происходящего и расписав все проделанные манипуляции в попытках самостоятельно разобраться с проблемой. Результатом стал удручающий ответ с европейского саппорта, подтверждающий мои предположения и не имеющий решения (инцидент был закрыт без списания). Ну что-ж…будем ждать следующей версии App-V и надеяться на то, что ситуация в дальнейшем измениться к лучшему… А пока как-то надо работать дальше и что-то делать с пачкой алертов приходящих от Operations Manager (SCOM) в почту каждое утро после очередного ночного краха кластера.

    Логичным решением подавления генерации алертов SCOM конечно является перевод ресурсов кластера в режим обслуживания (Maintenance Mode) на время выполнения резервной копии. Но штатными средствами SCOM не позволяет выполнять запланированный перевод в режим обслуживания (в будущем времени). Поиск нештатных способов привёл к инструменту Maintenance Mode Scheduling Tool разработанному под SCOM 2007. Сразу смутили попадающиеся в интернете сообщения о глючности данной тулзы, и такие “особенности” как неперевариваемость non-EN локали. И несмотря на утверждения, встречающиеся на формах TechNet, о том, что утилита работает с SCOM 2012, у меня так и не получилось добиться от неё адекватного поведения.

    Далее виделся один путь – использовать командлеты Powershell от SCOM в связке с планировщиком заданий Windows Scheduler. На глаза попадались решения типа OpsMgr 2012: Group Maintenance Mode via PowerShell (the way it should be) но хотелось сделать что-то своё – более гибкое и универсальное, и тут я вспомнил про то, что недавно читал какой-то обзорный материал про возможность управления объектами SCOM из System Center 2012 Orchestrator (в прошлой жизни Opalis). Стало понятно что пора знакомится с этим продуктом Улыбка

    В общем-то здесь и кончается предыстория и начинается история использования Orchestrator.

    Заострять большого внимания на развертывании сервера Orchestrator со всеми необходимыми компонентами, в том числе SQL Server, наверно особого смысла нет, так как эта процедура не должна вызвать особых сложностей. Собственно системные требования к серверу можно найти здесь TechNet Library - System Center 2012 – Orchestrator. Единственное, что вызвало у меня затруднения - это выбор редакции SQL Server, так как в текущем варианте документации есть информация лишь о требовании к версии (Microsoft SQL Server 2008 R2) и Collation (SQL_Latin1_General_CP1_CI_AS). Требование к редакции удалось найти только в документации к Opalis, где сказано что редакция SQL Express не поддерживается и необходима как минимум редакция SQL Standard. Итак, был развёрнут отдельный виртуальный сервер на котором было выполнено:

    • Установка SQL Server 2008 R2 Standard с набором компонент: 
      - Database Engine
      - Client Tools Connectivity
      - Management Tools - Complete
      Порядок сортировки -
      SQL_Latin1_General_CP1_CI_AS
    • Установка System Center 2012 Orchestrator с настройками по умолчанию с полным набором компонент:
      - Management Server
      - Runbook Designer
      - Runbook Server
      - Web Features

    После установки открываем консоль Orchestrator Deployment Manager и сначала импортируем загруженные пакеты интеграции System Center 2012 – Orchestrator Component Add-ons and Extensions (System_Center_2012_Orchestrator_Integration_Packs.EXE), а затем в этой же консоли выполняем Deploy этих пакетов, чтобы они стали нам доступны в консоли Runbook Designer

    Возможно вам окажется полезной пошаговая инструкция от Кевина Холмана Orchestrator 2012: a quickstart deployment guide

    Для нашей задачи важно чтобы был загружен пакет интеграции SCO для SCOM. После его загрузки в консоли Runbook Designer нам станет доступ набор активностей (Activities) этого пакета. Перед началом использования этих активностей при построении нужных нам цепочек Runbook, необходимо настроить глобальные параметры подключения SCO к экземпляру SCOM. Сделать это можно через меню Options > SC 2012 Operations Manager

    image

    Для того чтобы успешно произвести настройку параметров подключения к SCOM необходимо установить на сервер SCO консоль Operations Manager (не забываем также прикрутить к ней последний CU/RU). Задаём имя сервера SCOM и учётные данные пользователя входящего в роль администраторов Operations Manager (я создал для этих целей специальную сервисную учетную запись). После установки параметров проверяем подключение и если оно прошло успешно, то можно приступать к процессу создания Runbook

    image

    В нашем примере Runbook будет состоять из довольно простой цепочки активностей.

    image

    На первом этапе мы ждём кода наступит определённое время суток. Используем для этого активность Monitor Date/Time из раздела Scheduling. В настройках этой активности задаём только один параметр – время запуска.

    image

    На втором этапе выполняется запрос параметров из базы данных SCOM с помощью активности Query Database из раздела Utilities. В свойствах активности на закладке Details укажем содержимое SQL запроса:

    SELECT TargetObjectFullName

    FROM RelationshipGenericView

    WHERE isDeleted=0

    AND SourceObjectDisplayName like 'RDS Servers (VMs with App-V Client)'

    ORDER BY TargetObjectFullName

    image

    Запрос выполняет выборку объектов включённых в специально созданную группу SCOM по имени этой самой группы. В эту группу по правилу явного членства (Explicit Members) включены три ноды кластера (как объекты класса Microsoft.Windows.Computer) и кластерные группы страдающие при распаде кластера (объекты класса  Microsoft.Windows.Cluster.Group)

    image

    Вернёмся к свойствам активности Query Database. На закладке Connection указываем тип базы данных, тип аутентификации, имя сервера и имя БД SCOM (по умолчанию используется OperationsManager)

    image

    На закладке Security определяемся с тем от имени какой учетной записи  будет происходить подключение к БД SCOM. Можно использовать учетную запись службы SCO или же специально созданную сервисную учетную запись, которая, как вы понимаете, должна входить в группу роли администраторов SCOM

    image

    Связываем между собой первую и втору активность с помощью соединителя (Link) с помощью мыши:

    image

    Далее создаём третью активность Start Maintenance Mode из раздела SC 2012 Operations Manager. И сразу создаём соединитель с предыдущей активностью

    image

    В свойствах последней активности на закладке Details с помощью кнопки обзора выбираем ранее созданное глобальное подключение к серверу SCOM. В поле Reason с помощью кнопки обзора выбираем причину перевода объектов в режим обслуживания. В полях Duration и Comment соответственно указываем продолжительность активации режима обслуживания и произвольный комментарий.image

    Подробней остановимся на поле Monitor в котором собственно и нужно указать тот объект/объекты для которых будет включаться режим обслуживания. Если пользоваться кнопкой обзора для этого поля, то откроется не очень удобное окно выбора среди всех полученных из SCOM объектов. Нас эта кнопка не интересует и мы воспользуемся механизмом передачи параметров между активностями, чтобы вставить в это поле значение SQL запроса полученного в активности Query Database. Для этого, наведя курсор на это окно, откроем контекстное меню и выберем пункт Subscribe > Published Data

    image

    Суть в том, что каждая активность в цепочке имеет свои выходные данные (Published Data) которые можно использовать в последующих активностях цепочки. В нашем случае мы должны выбрать выходные данные SQL запроса и параметр хранящий результат запроса - Full line as string with fields separated by ';'

    image

    После этого можно считать, что наша примитивная логическая цепочка выстроена, и теперь мы можем запустить её на постоянное исполнение, нажав на верхней панели инструментов кнопки Check In а затем Run. После этого мы можем наблюдать за результатом выполнения каждой активности в цепочке с помощью окна Log History

    image

    Удалённо можно управлять Runbook и просматривать результаты выполнения с помощью веб-консоли SCO, опубликованной в конфигурации по умолчанию на порту 82

    image

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

  • SCOM 2012 Discovery & Agent Push Install для серверов Forefront TMG

    imageВ процессе процедуры обнаружения (Discovery) для удалённой установки агента (Push-installation) SCOM 2012 на сервера с Forefront TMG мы получим ошибку по причине блокировки необходимых нам соединений. Официальный список используемых для этой процедуры портов можно найти в документе Supported Configurations for System Center 2012 - Operations Manager - Supported Firewall Scenarios

    image

     

    Руководствуясь представленным списком портов у меня так и не получилось добиться желаемого результата. И даже рецепты, предложенные в статьях Kevin Holman's System Center Blog > Agent discovery and push troubleshooting in OpsMgr 2007 и DefinIT > Remote Installation of SCOM 2007 R2 Agent on Threat Management Gateway Servers не помогли, хотя и стали в совокупности подспорьем в обнаружении работоспособного варианта решения проблемы. Рассмотрим его.

    В консоли Forefront TMG Management создадим набор компьютеров (Computer Set) с названием System Center Operations Manager Servers. Включим в этот набор наши сервера SCOM, с которых будет выполняться удалённая установка и последующие обновления агента SCOM

    image

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

    Описания протоколов которые есть в TMG по умолчанию:

    Описание Протокол Порты Направление
    System Center Operation Manager Agent TCP 5723 Outbound
    NetBios Datagram UDP 138 Send
    NetBios Name Service UDP 137 Send/Recieve
    NetBios Session TCP 139 Outbound
    Ping ICMP 0/8 Send/Recieve
    RPC (all interfaces) TCP 135 Outbound

    Описания протоколов, которые мы создадим дополнительно:

    Описание Протокол Порты Направление
    RPC/DCOM High Ports TCP 1024-65535 Outbound
    SMB over IP TCP 445 Outbound

     

    Создадим правило разрешающее обнаружение и удалённую установку, назовём его “SCOM Agent Push Install”:

    image

    В качестве разрешённых протоколов в этом правиле будут перечислены все протоколы перечисленные в таблицах, за исключением первой позиции.image

    После того как правило создано, откроем его свойства и на закладке настройки протоколов, используя кнопку Filtering > Configure PRC protocol выключим включенный по умолчанию режим Enforce strict RPC compilance 

    image

    Затем создадим ещё одно правило, разрешающее исходящий трафик от агента до сервера SCOM по порту TCP 5723 , назовём его, например “Allow remote monitoring (from TMG to SCOM)”:

    image

    Сохраняем конфигурацию TMG и проверяем результат.

  • Разворачиваем SCOM 2012 - Часть 2 - Настройка сервера БД

    image

    Ранее: Разворачиваем SCOM 2012 - Часть 1 – Подготовка

    Все действия описанные в этой части выполняем на сервере SCOMDB.

    Требования предъявляемые к серверу БД можно найти в документе Supported Configurations for System Center 2012 - Operations Manager

    Так как на этом сервере будут расположены две основные БД SCOM - Operational Database и Operations Manager Data Warehouse, создадим специальную дисковую конфигурацию, которая позволит распределить нагрузку на дисковую подсистему сервера. В нашем случае создано 7 виртуальных дисков, разнесённых по разным физическим носителям в следующем порядке:

    Виртуальный диск Размер Описание
    VHD1 60 GB ОС, исполняемые файлы SQL Server и SCOM
    VHD2 10 GB БД temp. Файл данных
    VHD3 5 GB БД temp. Файл лога транзакций
    VHD4 30 GB БД OperationsManager. Файл данных
    VHD5 10 GB БД OperationsManager. Файл лога транзакций
    VHD6 90 GB БД OperationsManagerDW. Файл данных
    VHD7 10 GB БД OperationsManagerDW. Файл лога транзакций


    В конечном итоге картина получается примерно такая:

    image_thumb19_thumb

    Перед запуском программы установки SQL Server 2008 R2 открываем PowerShell с правами администратора и включаем компоненту Net Framework Core.

    Import-Module ServerManager

    Add-WindowsFeature NET-Framework-Core

    Затем нам нужно скачать и установить .NET Framework 4файл dotNetFx40_Full_x86_x64.exe. В моём случае этого делать не пришлось, так как этот пакет уже был установлен на сервер ранее в составе обновлений, “прикатившихся” с локального сервера WSUS.

    Теперь запускаем программу установки SQL Server 2008 R2 Standard EN и в открывшемся SQL Server Installation Center выбираем опцию установки – Installation > New installationimage_thumb3_thumb

    Проходим шаг предварительной проверки для возможности установки SQL Server, ввода ключа продукта, дожидаемся когда установятся файлы поддержки и затем, если у нас включена служба Windows Firewall, можем получить предупреждение о необходимости открытия портов SQL Server

    image_thumb7_thumb

    Чтобы не откладывать это “в долгий ящик”, открываем командную строку и выполняем команду добавления разрешающего правила для всех входящих подключений на порт TCP 1433:

    netsh advfirewall firewall add rule name = "SQL Server Default Port" dir = in protocol = tcp action = allow localport = 1433

    Подробности можно найти в документе Настройка Брандмауэра Windows для разрешения доступа к SQL Server

    image_thumb8_thumb

    Дойдя до шага выбора устанавливаемых компонент, выбираем компоненты:

    • Database Engine Services, в том числе Full-Text Search
    • Reporting Services
    • Business Intelligence Development Studio (возможно пригодится при разработке своих отчетов)
    • Management Tools Complete

    image_thumb

    Далее выполняется проверка Installation Rules на соответствие ОС для установки выбранных компонент и на следующем шаге настройки экземпляра SQL Server оставляем значения по умолчанию – Default Instance

    image_thumb[1]

    Далее выполняется проверка на наличие минимально необходимого свободного места на диске, выбранном для установки экземпляра SQL Server, и выполняется переход к шагу настройки служб экземпляра - Server Configuration, где мы используя кнопку Use the same account for all SQL Server services задаём учетную запись, от имени которой будут выполняться все основные службы SQL Server. В нашем примере это доменная учетная запись - s-OM-DB-Svc

    Обратите внимание так же на то, что тип запуска службы SQL Server Agent мы меняем на Automatic.

    image_thumb[2]

    Здесь же переключаемся на закладку Collation и задаём значение - SQL_Latin1_General_CP1_CI_AS, так как согласно документации официально поддерживается только этот порядок сортировки.

    image_thumb12_thumb

    На шаге Database Engine Configuration оставляем тип аутентификации в значении по умолчанию – Windows authentication mode и в группу администраторов SQL Server включаем группу локальных Администраторов сервера SCOMDB

    image_thumb13_thumb

    Здесь же переключаемся на закладку Data Directories и в настройках расположения служебных каталогов SQL Server меняем расположение каталогов для служебной БД – tempdb (как отмечалось в начале этой заметки, для этих файлов у нас созданы отдельные логические диски) 

    image_thumb[3]

    На следующем шаге Reporting Services Configuration оставляем тип пред-настройки служб отчётов SQL Server в значении по умолчанию – Install the native mode default configuration

    image_thumb[4]

    Далее, после очередной проверки изучив Summary на шагe Ready to Install запускаем процесс непосредственной установки SQL Server и дождавшись его окончания, после запуска всех его служб, проверяем корректность динамической регистрации SPN для учетной записи, от имени которой мы настроили запуск основных служб экземпляра SQL Server командой:

    Setspn –L s-OM-DB-Svc

    image_thumb16_thumb

    Далее производим обновление работающего экземпляра SQL Server 2008 R2 с WSUS. В моём случае была выполнена установка Service Pack 1, после чего перезагружаем сервер SCOMDB, чтобы удостовериться в том, что после запуска системы все службы SQL Server успешно стартуют.

  • Разворачиваем SCOM 2012 - Часть 1– Подготовка

    imageРассмотрим процедуру развёртывания новой инфраструктуры System Center Operations Manager (SCOM) 2012 в конфигурации, подразумевающей распределение ролей SCOM между несколькими серверами. В нашем примере это будет три виртуальных сервера:

    Имя сервера Опорные компоненты Компоненты SCOM
    SCOMDB SQL Server 2008 R2 DB & Reporting Services Report Server
    SCOM01 IIS Management Server (RMS Emulator),
    Operational Console, Web Console
    SCOM02 - Management Server,
    Operational Console

    На всех трёх серверах установлена ОС Windows Server 2008 R2 Standard EN SP1, установлены все обновления с WSUS, сервера включены в домен.

    Весь процесс развёртывания инфраструктуры SCOM 2012 будет в нашем примере состоять из нескольких частей:

    Часть 1 – Подготовка. В этой части мы рассмотрим создание в домене сервисных учетных записей, от имени которых в дальнейшем будут функционировать компоненты SCOM;

    Часть 2 – Настройка сервера БД. Будет рассмотрен процесс предварительной подготовки сервера, который будет выполнять функции сервера баз данных SCOM (операционной и БД хранения) с установкой всех необходимых компонент SQL Server 2008 R2 Standard на этот сервер (SCOMDB);

    Часть 3 – Установка серверов управления. Будет рассмотрен процесс установки ролей Management Server, Operational Console, Web Console на первый сервер в группе управления SCOM (Management Group) - SCOM01, а затем процесс установки дополнительного сервера управления - SCOM02.

    Часть 4 – Установка роли Report Server. Будет рассмотрен процесс установки роли сервера отчётов SCOM на сервер БД c ранее установленной службой SQL Server 2008 R2 Reporting Services (SCOMDB).

    Суть первой части сводится к предварительному созданию сервисных учетных записей в домене. В качестве источника информации для создания учётных записей и определения необходимого уровня привилегий для них используем документы Account Information for Operations Manager и Deploying System Center 2012 - Operations Manager

    Создаём в домене пять пользовательских учетных записей:

    Имя учётной записи Объект SCOM Краткое описание
    HOLDINGs-OM-DB-Svc Учетная запись пользователя от имени которой на сервере SCOMDB будут выполняться службы SQL Server
    HOLDINGs-OM-Action Management Server Action Account Учетная запись действия сервера управления. Используется в частности для работы процессов SCOM на серверах управления, а также как учётная запись по умолчанию для процедур обнаружения и развёртывания агентов
    HOLDINGs-OM-DA-Svc System Center Configuration Service and System Center Data Access Service Учетная запись служб конфигурации и доступа к данным. Используется в частности для чтения чтения и модификации информации в операционной БД (Operational database)
    HOLDINGs-OM-Reader Data Reader Account Учетная запись чтения данных. Используется для взаимодействия с компонентами управления отчётами SQL Server Reporting Services
    HOLDINGs-OM-Writer Data Warehouse Write Account Учетная запись модификации хранилища. Отвечает за чтение данных из операционной базы данных (Operational database) и запись данных в БД хранения (которая используется для построения отчетов)

    Учётные записи s-OM-Action и s-OM-DA-Svc включаем в группу локальных Администраторов на серверах SCOMDB, SCOM01 и SCOM02. Обратите внимание на то, что эти две учетные записи в дальнейшем будут использоваться также при установке дополнительных серверов управления и должны также включаться в группу локальных Администраторов на этих серверах перед началом процесса установки SCOM.

    Учётные записи s-OM-DB-Svc, s-OM-Writer и s-OM-Reader включаем в группу локальных Администраторов на сервере SCOMDB

    Для того, чтобы у процессов SCOM и SQL Server не было проблем с динамической регистрацией Service Principal Name (SPN) в домене, нам потребуется немного расширить права учетных записей s-OM-DA-Svc и s-OM-DB-Svc, добавив разрешения для изменения значения атрибута servicePrincipalName

    • Read servicePrincipalName
    • Write servicePrincipalName

    Подробно об этой процедуре я писал ранее в заметке SQL Server и динамическая регистрация SPN (Service Principal Name)

    image_thumb_thumb

  • 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, я предпочёл мануальный способ инсталляции, так как он на мой взгляд является более осязаемым и в случае возможных проблем даёт понять на каком этапе процесса установки возникают эти проблемы.

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