• Интеграция 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.

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

  • Бесплатная книга Designing Orchestrator Runbooks

    image

    Стала доступна для скачивания новая бесплатная книга от Microsoft Press:
    Microsoft System Center - Designing Orchestrator Runbooks под авторством David Ziembicki, Aaron Cushner, Andreas Rynes.
    Книга содержит большое количество примеров применения Runbooks с обилием PowerShell-кода.
    Загрузить книгу на английском языке в электронном виде в разных форматах можно по ссылке
    Free ebook: System Center: Designing Orchestrator Runbooks

    Для читателей нашего блога копия книги доступна для загрузки также по ссылке.

  • Перенос БД System Center 2012 Orchestrator на другой сервер

    imageРассмотрим ситуацию, когда все компоненты работающего экземпляра System Center 2012 Orchestrator (SCORCH) развернуты на одном виртуальном сервере под управлением Windows Server 2012 Standard с локальным экземпляром БД SQL Server 2012 Standard и возникла необходимость переместить базу данных SCORCH на отдельный кластеризованный экземпляр SQL Server. По мере эксплуатации сервера SCORCH стало очевидно что размер БД весьма мал и держать отдельный локальный экземпляр SQL Server на этом сервере несколько расточительно, особенно учитывая тот факт, что размер потребляемой оперативной памяти процессом SQL Server чуть ли не в 30 раз превышает размер файла единственной обслуживаемой этим процессом БД. В ходе обдумывания поставленной задачи стало понятно что в нашем случае для переноса БД воспользоваться инструкцией описанной в статье Migrate Orchestrator Between Environments не получится, так как она подразумевает перенос SQL Master Key с исходного SQL сервера на целевой, что в нашем случае невозможно, так как на этом экземпляре уже работает некоторое количество других БД по некоторым предположениям использующих уже имеющийся Master Key. Поэтому было решено отработать альтернативный сценарий переноса БД с использованием функций Экспорта/Импорта консоли Runbook Designer с проведением ряда дополнительных манипуляций для успешного решения поставленной задачи.  Читать далее...

  • SC 2012 SP1 Orchestrator & SCOM IP - Failed to get Monitor…

    imageПосле обновления System Center 2012 Orchestrator до уровня Service Pack 1 заметил что перестала корректно работать задача, описанная в заметке SC 2012 Orchestrator – Режим обслуживания SCOM по расписанию. На этапе выполнения активности Start Maintenance Mode для каждого объекта полученного из SQL запроса к БД SCOM возникала ошибка:

    Failed to get Monitor. The exception was "An object of class MonitoringObject with ID 00000000-0000-0000-0000-000000000000 was not found.".

    image

    После изучения ситуации стало понятно, что в обновлённой версии Orchestrator изменилось представление объектов возвращаемых из SCOM для подстановки в поле Monitor для активности Start Maintenance Mode. Например если ранее значение выглядело так..

    Microsoft.Windows.Computer:KOM-AD01-RDS03.holding.com

    ..то после обновления оно стало выглядеть так..

    KOM-AD01-RDS03 : Microsoft.Windows.Computer:KOM-AD01-RDS03.holding.com

    Таким образом, для того чтобы описанная в ранее указанной заметке задача заработала, пришлось несколько изменить SQL запрос к БД SCOM:

    SELECT (TargetObjectDisplayName + ' : ' + TargetObjectFullName)

    FROM RelationshipGenericView

    WHERE isDeleted=0 AND SourceObjectDisplayName like 'KOM RDS Servers (VMs with App-V Client)'

  • System Center 2012 Orchestrator SP1

    imageСовсем недавно стал доступен Service Pack 1 (SP1) для линейки продуктов Microsoft System Center 2012. Попробую рассмотреть процесс обновления тех продуктов линейки, с которыми у меня есть возможность работать.

    Из документа Upgrade Sequencing for System Center 2012 SP1 можно понять, что в средах, где используется несколько продуктов линейки System Center 2012 важна правильная последовательность обновления этих продуктов до уровня SP1, а именно есть рекомендация соблюдать следующий порядок обновления:

    1. Orchestrator
    2. Service Manager
    3. Data Protection Manager
    4. Operations Manager
    5. Configuration Manager
    6. Virtual Machine Manager
    7. App Controller

    В этой заметке мы рассмотрим первый пункт этой последовательности – обновление System Center 2012 Orchestrator (SCO) до уровня SP1.

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

  • SC 2012 Orchestrator – Ротация текстовых логов

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

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

    • Ротации должны подвергаться файлы DBLog.txt, AppLog.txt, ErrorLog.txt
    • Процесс ротации должен выполняться 1 раз в сутки в 07:00
    • При условии что любой из указанных файлов становиться больше 100 MB, он должен быть переименован и заархивирован в отдельный каталог (подразумевается что приложение способно самостоятельно создавать свежий лог файл)
    • Архивы логов не должны накапливаться и храниться более года

    Результативный рабочий процесс будет выглядеть следующим образом:

    image

    Далее опишем свойства каждого этапа, то есть каждой активности рабочего процесса.

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

  • 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…

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