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

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

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

    imageВ процессе процедуры обнаружения (Discovery) для удалённой установки агента (Push-installation) SCOM 2012 на сервера с Forefront TMG мы можем получить ошибку по причине блокировки необходимых нам соединений.

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

  • Разворачиваем 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, сервера включены в домен.

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

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

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

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