В процессе процедуры обнаружения сетевых устройств (Network Devices Discоvery) в SCOM 2012 можно получить статус No Response Ping, то есть якобы устройство не отвечает на запросы ICMP, хотя на самом деле устройство доступно.
У нас нет таких OU.
Собрание заметок об информационных технологиях
В этой части мы установим роль SCOM Reporting Server на ранее сконфигурированный сервер с SQL Server 2008 R2 Standard – SCOMDB. Официальное руководство в документе - How to Install the Operations Manager Reporting Server
Требования, предъявляемые к серверу для роли SCOM Reporting Server можно найти в документе Supported Configurations for System Center 2012 - Operations Manager
Для серверов управления у нас заранее подготовлены две виртуальные машины (SCOM01 и SCOM02) с конфигурацией - RAM 6 Gb ; VHD1 60 Gb; ОС - Windows Server 2008 R2 Standard SP1 English.
Ранее: Разворачиваем SCOM 2012 - Часть 1 – Подготовка
Все действия описанные в этой части выполняем на сервере SCOMDB.
Требования предъявляемые к серверу БД можно найти в документе Supported Configurations for System Center 2012 - Operations Manager
Так как на этом сервере будут расположены две основные БД SCOM - Operational Database и Operations Manager Data Warehouse, создадим специальную дисковую конфигурацию, которая позволит распределить нагрузку на дисковую подсистему сервера.
Рассмотрим процедуру развёртывания новой инфраструктуры 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 может появится сбивающее с толку предупреждение о недоступности того или иного логического диска:
Это может быть вызвано тем, что WMI класс Win32_LogicalDisk возвращает значение TRUE для свойства VolumeDirty для проблемного логического диска при опросе ОС скриптом SCOM.
По мере расширения инфраструктуры SCOM и увеличения серверов управления (Management Server) может возникнуть необходимость в форсированном назначении значений Primary Management Server и Failover Management Server для агентов, чтобы избежать ситуации когда при недоступном ближайшем первичном сервере управления агенты начнут обращаться на сервера управления на удалённых площадках нагружая при этом WAN-каналы там где это не желательно. Такое поведение агентов в конфигурации по умолчанию может быть обусловлено настройками, которые можно видеть в конфигурационном файле клиента в кэше коннектора соответствующей ему группы управления.
В больших доменных инфраструктурах имеющих несколько доменных администраторов может быть весьма актуальным вопрос аудита изменений, производимых в членстве предопределённых административных групп.
Для решения этой задачи воспользуемся возможностями SCOM и на примере доменной группы “Domain Admins” создадим правила, которые будут отслеживать события, регистрируемые в журнале “Security” на контроллерах домена в момент добавления и удаления пользователей в эту доменную группу безопасности.
Если возникает необходимость мониторинга сетевых устройств поддерживающих протокол SNMP, - в SCOM 2007 R2 мы можем через консоль “Operations Console” на закладке “Authoring” с помощью помощника “Create a unit monitor” создать SNMP Probe Based Monitor, который будет через указанные нами интервалы времени выполнять к сетевому устройству запрос определённых значений OID и на основании полученных данных изменять статус этого сетевого устройства по принципу Healthy/Unhealthy
Однако на практике вы можете столкнуться с ситуацией когда созданный вами монитор ведёт себя не совсем так как вы этого от него ожидаете. Например вы создали монитор, который раз в несколько минут опрашивает источник бесперебойного питания (ИБП) в серверной на предмет значения конкретного OUD возвращаемого текущее значение входного напряжения. Если этот OID опросить по SNMP с помощью любого стороннего приложения (например MIB Browser) то возможно мы увидим что тип возвращаемого значение – целочисленное значение – “Integer”, в то время как визард SCOM “Create a unit monitor” по умолчанию задает тип значения – строка – “String”.
Соответственно получаемое от устройства значение будет преобразовываться в строку и уже в дальнейшем подвергаться например некорректным операциям сравнения которые могут присутствовать в нашем мониторе, что само по себе и становится причиной необъяснимых срабатываний алертов.
Для исправления этой ситуации нам необходимо выгрузить Management Pack в котором сохранён наш SNMP Probe Based Monitor в XML файл и найти в нём секции Expression и в тэгах XPathQuery Type и Value Type в которых задаётся тип значения…
Нужно выполнить замену типа получаемого значения на тот в котором непосредственно значение отдается самим сетевым устройством, в нашем случае это будет “Integer”…
После этого сохраняем XML файл и загружаем его обратно в SCOM в качестве Management Pack.
Решение проблемы найдено здесь: Gefufna - How to create SNMP Probe Based Two-State Monitor in SCOM?
В окружении с большим количеством агентов мониторинга 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- 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)
Последние комментарии