• Разворачиваем 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

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

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

    imageПредыдущие заметки:

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

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

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

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

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

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

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

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

  • Разворачиваем 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 2007 R2 - Alert: Logical Disk Not Available

    В некоторых случаях на SCOM может появится сбивающее с толку предупреждение о недоступности того или иного логического диска:

    image

    Это может быть вызвано тем, что WMI класс Win32_LogicalDisk возвращает значение TRUE для свойства VolumeDirty для проблемного логического диска при опросе ОС скриптом SCOM.

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

  • SCOM 2007 R2 - Назначение Primary и Failover серверов на агентах

    imageПо мере расширения инфраструктуры SCOM и увеличения серверов управления (Management Server) может возникнуть необходимость в форсированном назначении значений Primary Management Server и Failover Management Server для агентов, чтобы избежать ситуации когда при недоступном ближайшем первичном сервере управления агенты начнут обращаться на сервера управления на удалённых площадках нагружая при этом WAN-каналы там где это не желательно. Такое поведение агентов в конфигурации по умолчанию может быть обусловлено настройками, которые можно видеть в конфигурационном файле клиента в кэше коннектора соответствующей ему группы управления.

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

  • SCOM 2007 R2 - Аудит изменений доменных групп безопасности

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

    Для решения этой задачи воспользуемся возможностями SCOM и на примере доменной группы “Domain Admins” создадим правила, которые будут отслеживать события, регистрируемые в журнале “Security” на контроллерах домена в момент добавления и удаления пользователей в эту доменную группу безопасности.

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

  • SCOM 2007 R2 - Странное поведение мониторов SNMP Probe при операциях сравнения.

    Если возникает необходимость мониторинга сетевых устройств поддерживающих протокол SNMP, -  в SCOM 2007 R2 мы можем через консоль “Operations Console” на закладке “Authoring” с помощью помощника “Create a unit monitor” создать SNMP Probe Based Monitor, который будет через указанные нами интервалы времени выполнять к сетевому устройству запрос определённых значений OID и на основании полученных данных изменять статус этого сетевого устройства по принципу Healthy/Unhealthy

    image

    Однако на практике вы можете столкнуться с ситуацией когда созданный вами монитор ведёт себя не совсем так как вы этого от него ожидаете. Например вы создали монитор, который раз в несколько минут опрашивает источник бесперебойного питания (ИБП) в серверной на предмет значения конкретного OUD возвращаемого текущее значение входного напряжения. Если этот OID опросить по SNMP с помощью любого стороннего приложения (например MIB Browser) то возможно мы увидим что тип возвращаемого значение – целочисленное значение – “Integer”, в то время как визард SCOM “Create a unit monitor” по умолчанию задает тип значения – строка – “String”.

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

    Для исправления этой ситуации нам необходимо выгрузить Management Pack в котором сохранён наш SNMP Probe Based Monitor в XML файл и найти в нём секции Expression и в тэгах XPathQuery Type и Value Type в которых задаётся тип значения…

    image

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

    image

    После этого сохраняем XML файл и загружаем его обратно в SCOM в качестве Management Pack.

    Решение проблемы найдено здесь: Gefufna - How to create SNMP Probe Based Two-State Monitor in SCOM?

  • SCOM 2007 R2 – Пакетный перевод агентов в Maintenance Mode

    imageВ окружении с большим количеством агентов мониторинга SCOM 2007 R2 массовый перевод этих агентов  в режим обслуживания (Maintenance Mode) через UI консоль может стать весьма хлопотным занятием. На помощь в таком случае как всегда приходит Operations Manager Shell.

    Например, для того чтобы перевести в Maintenance Mode все сервера в имени которых встречается “SQL”, с текущего момента сроком на 2 часа в Operations Manager Shell можно выполнить следующий нехитрый скрипт:

    $Time1 = [DateTime]::Now

    $Time2 = $Time1.AddMinutes(120)

    $Agents  = Get-Agent | Where {$_.Name –match "SQL"}

    $Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedOther" -Comment "Maintenance Mode Window" -MonitoringObject $_.HostComputer}

    Здесь вместо функции AddMinutes() можно также использовать AddHours() и AddDays()

    Или другой пример, когда необходимо указать конкретный диапазон дат:

    [DateTime] $Time1 = "11/23/2010"

    $Time1 = $Time1.ToUniversalTime()

    [DateTime] $Time2 = "11/28/2010"

    $Time2 = $Time2.ToUniversalTime()

    $Agents  = Get-Agent | Where {$_.Name –match "SQL"}

    $Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedHardwareMaintenance" -Comment "Hardware Maintenance" -MonitoringObject $_.HostComputer}

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

    %SYSTEMROOT%system32WindowsPowerShellv1.0powershell.exe C:MaintenanceModeStartMaintenanceModeWindow.ps1

    Так же для того чтобы скрипт успешно отработал при таком вызове из планировщика задач, в начало скрипта следует добавить строки инициализации командлетов Operations Manager Shell и вызов подключения к корневому серверу управления SCOM (RMS):

    $RMSServer = 'RMSServerName'

    Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";

    Set-Location "OperationsManagerMonitoring::";

    New-ManagementGroupConnection -ConnectionString:$RMSServer;

    Set-Location $RMSServer;

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

    System Center TechCenter - How to Put a Monitored Object into Maintenance Mode in Operations Manager 2007

    System Center TechCenter- Operations Manager 2007 R2 Cmdlets - New-MaintenanceWindow

    Collection of Maintenance Mode Scripts, Utilities and MPs for Opsmgr and Essentials 2007 (Updated for SCOM 2007 R2)

    System Center Operations Manager Forums > Extensibility > Setting all entities to maintenance based on a particular class

  • SCOM 2007 R2 – Изменение статуса ManuallyInstalled для агентов

    В некоторых случаях может возникнуть ситуация, когда по каким-то причинам произведена ручная установка агентов SCOM на ряд компьютеров. Для таких агентов в UI консоли недоступны опции смены основного сервера управления (Change Primary Management Server), восстановления (Repair) и удаления (Uninstall). Помимо этого после применения новых кумулятивных обновлений (CU) такие агенты не будут переходить в режим принудительного обновления, что опять же потребует их обновления «в рукопашную». Получить список таких агентов можно как в UI консоли, так и в  Operations Manager Shell:

     

    Get-Agent | where {$_.ManuallyInstalled -match ‘true’} | ft name,ManuallyInstalled

     

    Для повышения централизованной управляемости нам потребуется изменить статус ручной установки для таких агентов. Через UI консоль это сделать невозможно by design. Через Operations Manager Shell у нас в данном случае также не получится изменить данное свойство, так как оно установлено как ReadOnly. Для решения данной задачи можно воспользоваться советом из блога Кевина Холмана: Kevin Holman's OpsMgr Blog - How to get your agents back to "Remotely Manageable" in OpsMgr 2007 R2

     

    Для того чтобы вывести список агентов установленных вручную, подключимся к базе данных «OperationsManager» и выполним запрос:

     

    SELECT bme.DisplayName FROM MT_HealthService mths

    INNER JOIN BaseManagedEntity bme ON bme.BaseManagedEntityId = mths.BaseManagedEntityId

    WHERE IsManuallyInstalled = 1

     

    Для того чтобы изменить статус всех вручную установленных агентов, выполним запрос:

     

    UPDATE MT_HealthService

    SET IsManuallyInstalled=0

    WHERE IsManuallyInstalled=1

     

    Если же мы не хотим менять статус для всех агентов, а лишь для одного какого то конкретного агента, выполним запрос:

     

    UPDATE MT_HealthService

    SET IsManuallyInstalled=0

    WHERE IsManuallyInstalled=1

    AND BaseManagedEntityId IN

    (SELECT BaseManagedEntityID FROM BaseManagedEntity

    WHERE BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'

    AND DisplayName = 'agentname.domain.com')

     

    После этого, в UI консоли, для измененных агентов станут доступными вышеописанные опции управления.

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