Exclusions Antivirus

Мне не очень нравится когда для работы в различных системах приходится держать запущенными множество разных приложений. К сожалению с этим редко можно что то сделать, но уж если можно… почему бы не попробовать? И я попробовал сделать синхронизацию активных алертов между Operations Manager и списком SharePoint, чтобы можно было открывать консоль Operations Manager только при необходимости Честно говоря я думал что это займёт у меня достаточно много времени, но к моему удивлению я уложился всего за один вечер. За это надо благодарить родную поддержку PowerShell в OpsMgr, достаточно простую объектную модель SharePoint, и скринкаст Александра Романова на TechDays.ru в котором он показал как с этой объектной моделью работать

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

• CreateList.ps1 – для автоматизации создания списка с нужными полями в SharePoint
• Sync-OpsMgr2SP.ps1 – скрипт непосредственно выполняющий синхронизацию.

Оба скрипта можно скачать в этом архиве.

Вместо того чтобы описывать процесс установки, я записал его в скринкаст (9Mb, WMV), надеюсь там ничего сложного Ну и в нём же небольшая демонстрация работы

Еще несколько моментов на которые стоит обратить внимание:

• Запускать скрипт надо на сервере с SharePoint’ом, не уверен что будет работать удалённо.
• На том же сервере должна быть установлена консоль OpsMgr + Command Shell. Из неё надо один раз подключиться к серверу OpsMgr, чтобы он прописался в реестре.
• Разумеется надо разрешить выполнение неподписанных сценариев: Set-ExecutionPolicy "RemoteSigned"
• Не мешает проверить настройки начале скрипта Sync-OpsMgr2SP.ps1 и удостовериться что они соответствуют вашим условиям.
• TimeSkew – смещение времени SharePoint относительно OpsMgr. У меня время в OpsMgr отставало на 4 часа (Видимо время там хранится по GMT 0), соответственно эта переменная равна 4.
• ListURL – адрес списка SharePoint. Можно посмотреть в свойствах списка.
• AlertURL – адрес для просмотра алертов в Web Console OpsMgr. В конце приписывается ID алерта, и добавляется в столбец Link в списке SharePoint.
• States – Здесь указывается соответствие цифровых кодов состояний в OpsMgr и их названий. Если у вас добавлены новые состояния (кроме New и Resolved) вы можете дописать их сюда. Ну и в списке SharePoint нужно будет добавить такие же значения для поля Resolution.
• Для выполнения постоянной синхронизации, лучше не перезапускать сценарий через какие то промежутки времени, а вызвать его например при старте системы (это можно сделать через планировщик задач) с ключом –Continuous, тогда он будет крутиться постоянно, через промежутки времени указанные в параметре -Interval (по умолчанию 10 секунд). Это гораздо эффективнее с точки зрения производительности. Если указан ключ –Force то синхронизация будет работать только в одну сторону – из OpsMgr в SharePoint.

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

Я пока тестировал эту штуку только в лабораторных условиях, так что буду благодарен если кто то попробует её в деле, и расскажет о своих успехах, или моих ошибках

As you probably know all OpsMgr 2007 Sp1/R2 Notitications/Subscrubers/Channels are stored inside unsealed management pack ID:Microsoft.SystemCenter.Notifications.Internal, Name:Notifications Internal Library. And as descriptions says: Microsoft System Center Notifications Library: This management pack is used to hide notification related management pack objects that are exposed directly via the API for Operations Manager.

I believe enumeration is possible via SDK or Powershell. If you know exact call, just drop me some words in comment.

What do we have so far?
Let’s look at powershell commands:
Get-NotificationAction - Gets notification actions.
Get-NotificationEndpoint - Gets notification end points.
Get-NotificationRecipient - Gets notification recipients.
Get-NotificationSubscription  - Gets notification subscriptions.

Non of above commands fits my needs.

Digging inside management pack itself I ended up with the following t-sql query:

declare @xml xml;

select @xml = (select MPXML from ManagementPack where MPName = ‘Microsoft.SystemCenter.Notifications.Internal’)

select t.rows.value(‘data(.)’, ‘varchar(50)’) as Email
from @xml.nodes(‘//ManagementPack/TypeDefinitions/ModuleTypes
/ConditionDetectionModuleType[@ID="Microsoft.SystemCenter.Notification.Recipients"]
/ModuleImplementation/Composite/MemberModules
/ConditionDetection[@ID="RecipientResolver"]/RecipientDirectory
/Recipient[Name="<Name Goes Here>"]
/Devices/Device[Protocol="Smtp"]/Address’) as t(rows)

Exampe output of this comand.
Email
email1@email.com
email2@email.com
email3@email.com
etc.

I saw this error at least two times. First was about 1,5 year ago when i was moving my lab to SCOM 2007 SP1.

Event Type: Warning
Event Source: OpsMgr Config Service
Event Category: None
Event ID: 29106
Date: 1/3/2008
Time: 10:40:08 AM
User: N/A
Computer: srv1
Description:
The request to synchronize state for OpsMgr Health Service identified by
“1cd8ac83-41d0-d716-63c8-4818eeb5b6b6″ failed due to the following exception
“System.Security.Cryptography.CryptographicException: Error occurred during a
cryptographic operation.

Server stack trace: at <cut server stack>

I kindly asked comunnity to help me.

Ye, PaulD is my nick name on MS community
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.opsmgr.sp1&tid=a72aba38-74b6-4981-b0bb-7d6b94ff2a6f&p=1

But this blog post is about other story, i would say,  successfull story of hard struggling with the same event but with different stack trace.

TODO:

<event>
<sql trace>
<opsmgr trace>
<highlights>
<pointing to problem records>
<online fix, config service restart, dirty cfg service event, good event>
<creating CheckDB.vbs/sql>

Nachdem ich diesen Fehler bisher immer geschickt ingoriert habe, habe ich heute eine Lösung gefunden…

http://support.microsoft.com/kb/933061/en-us

Today is “notfication day” I have to (re-) create several notfication subscriptions in OpsMgr 2007 R2 and tumble over some issues, which i have almost forgotten:

Note 1: Adding Subscribers for a existing subscription

If you add a new subscriber to an existing subscription, i recommend to delete ALL existing subscribers and then re-add them including the new subscribers. If you do no delete the existing subscribers i found out, that it is almost certain, that the added subscriber will not get notified…

Note 2: If you use Notification Command Channels, it might be useful to increase the maximum number of asynchronous responses

Maybe you will get an Alert:

The process could not be created because the maximum number of asynchronous responses (5) has already been reached, and it will be dropped.

Then you should consider increasing the number of responses, which can be run on the RMS. You can increase the number via this registry setting:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Modules\Global\Command Executer]
“AsyncProcessLimit”=dword:0000000a

But before doing so, i recommend to read the blog post from Clive Eastwood carefully: http://blogs.technet.com/cliveeastwood/archive/2008/04/16/some-more-command-notification-tricks-and-tips.aspx

To be continued…

Today i discovered a strange behaviour in the R2 RTM GUI while editing some command channel addresses:

Subsciber address menu

1. Issue: Adding a new Command Channel Address

If you want to add a new command channel address you have to click on “Add”, give the new address a name and then select the “Channel type”.
If you select “Command Channel” the input box delivery address will be greyed out!

Workaround:
First select E-Mail Channel, enter the delivery address …

… and then switch the channel type back to Command:

2. Issue: Editing a command channel delivery address

If you want to edit the delivery address and click on the Edit button, you will loose all of the informations:

I have not found any workarounds for this behaviour yet. If anybody has some hints or suggestions, please let me know.

Nach langem hin und her habe ich nun eine 2te Management Gruppe erstellt. Da sich die Alarme leider nicht so trennen liessen wie ich das gerne gehabt hätte, war das auch die lösung die vom Microsoft Support vorgeschlagen wurde. Anscheind gibt es einen Bug der noch nicht behoben wurde(vielleicht auch niemals wird..) der verhindert, das man das trennen kann. Microsoft geht davon aus, dass Leute welche für eine Applikation verantwortlich sind auch für die Hardware und das OS die nötigen Arbeiten erledigen. Bei uns ist das allerdings nicht so. Die Überwachung der Applikationen erfolgt über ein (meist) separates Service Management und für die Hardware und das OS sind wir verantwortlich.

Egal, nun ist die neue Umgebung installiert und gleich einem Update unterzogen worden. Einziger Wehmutstropfen ist, dass der Engyro Connector nicht auf den neusten Stand gebracht werden kann, weil die Hp OVO Server auf einer nicht supporteten Version V1 laufen. Das wird sich jetzt vermutlich noch bis Ende Jahr so hinziehen, schade. Der Connector zu HP OVO ist leider sehr instabil und schmiert fast täglich ab. Microsoft hat damals die Firma aufgekauft und nun natürlich ein neues Produkt entwickelt, während die alten Versionen von Engyro kaum mehr angeschaut werden.

Nun haben wir eine funktionierende Lösung die so funktioniert.

Bei der Installation mit SMS wird der Agent installiert. In dieser Installation wird die erste Management Gruppe installiert, mit welcher die OS Gruppe arbeitet. Danach taucht der Server in der Konsole auf. Wird nun ein Server mit einer Applikation installiert, welcher einer der Service Management Gruppen unterliegt, kann mit einem Task ein Registry Key für die 2te Management Gruppe geschrieben werden. Anschliessend taucht der Server in der Management Gruppe der Applikationen auf. Alles ein wenig kompliziert, aber es scheint sogar zu funktionieren

As OpsMgr is one of the most demanding SQL applications I am aware of, monitoring the performance of the database is always a very important task. One could use the usual performance reports, but they have some disadvantages in my opinion:

• There is not a “one stop shop” report for all necessary information. You need multiple reports to gain a complete overview of the performance.
• Some important information are not available in standard reports like the table sizes or table fragmentation

So how can we get a better solution with all necessary information in one place? A lot of folks on the web (thanks to Kevin Holman and Steve Rachui and many others) have published SQL queries, which can help to analyze the health of the OperationsManager database.

So I tried some of the queries and was amazed, what wealth of information they provide.  But what always disturbs me was on the one hand the number of different scripts I had to run and on the other hand the lack of automation.

Ok, so let’s create a simple automated SQL Performance reporting solution:

Step 1:  Create a structured SQL script, with all necessary queries
Step 2:  Create a PowerShell wrapper for the command
Step 3: Run the wrapper as an automated task with a task scheduler

Step 1: the SQL Script

Please note, that I am not a DBA, in fact I am a complete SQL newbie, so if you can provide some optimizations to my script, please let me know.

The attached SQL script generates a text file with the following information:

• All Event counts per Day, incl. Sum for the whole DB
• TOP 50 Events, sorted by Creator
• Top 20 Computer with most Events in the DB
• Alerts per Day
• Top 50 Monitors with most State Change Events
• Top 20 Alerts, sorted by  Alert count
• Top 20 Alerts, sorted by  Repeat count
• Inserted Performance counter per day
• Top 100 Performance Counter
•  Database Size
• Top 10 Tables sorted by size
• Database Defragmentation (Scan Density should be > 80%, Logical Scan Fragmentation < 30%)

Of course you can extend this script indefinitely

What about the runtime? This script runs about 1-2 Minutes on a very slow SQL 2005 cluster with a 7 GB DB.

If you work with bigger OpsMgr environments, especially when you have a Test-/Integ- and a Production environment you will love Silects MP Studio. The current version 3 is a great tool, but version 4, which Silect presents as an early beta on MMS 2009, promised to be much better.

New announced features for version 4 are:

• MP Development Center with far better capabilities to create new MPs
• The whole MP workflow can now be automated via PowerShell, so it is much easier to comply with  your company processes
• Better Source and version control of MPs
• Improved administrative capabilities

I will test the current Beta in the next days and will post my experiences here.

Schlechte Nachrichten…

So wie es aussieht, lassen sich applikationsbezogene Alerts nicht von den Hardware/OS Alerts trennen.

Das Hauptproblem an der ganze Sache ist, das sich keine Exclude-Views definieren lassen. Und zusätzlich ein Problem ist, dass ein Objekt, zbsp. ein Server, der in 2 Klassen ist, dann jeweils alles Alerts an beide Klassen weitergereicht werden. Derzeit habe ich einen Advisory-Call bei Microsoft offen, aber ich bin mir fast sicher, dass da nichts gescheites rauskommen wird.

В данном сообщении опишу наш пакет мониторинга (management pack) для System Center Operations Manager 2007 (далее – SCOM), с помощью которого можно мониторить источники бесперебойного питания APC.

Почему вообще возникла идея создания подобного пакета? Когда приходится обслуживать несколько серверных, разнесенных географически, вопрос мониторинга питания встает с особой остротой. Никак не получится выбрать какой-нибудь один ИБП, мониторить его бесплатной утилитой APC, идущей в комплекте с ИБП и считать, что все остальные ИБП в серверной ведут себя примерно так же.

Итак, посмотрим на существующие решения, позволяющие мониторить ИБП. Так как в нашей организации внедрен SCOM, то различные пакеты под другие системы мониторинга нас не интересовали. Кроме того, далеко не все наши ИБП имеют установленную карту мониторинга окружающей среды, некоторые просто подключены к серверам через USB- или COM-порты. Разумеется, хотелось иметь универсальный инструмент для мониторинга, не зависящий от типа подключения ИБП. В итоге список рассмотренных нами вариантов такой:

• Можно настроить на каждом ИБП отсылку почтовых сообщений выбранным пользователям. Самый простой вариант, но он имеет кучу недостатков:

1) каждый ИБП должен иметь доступ к почтовому серверу;

2) ИБП склонен генерировать сообщение за сообщением, если проблема не решается. Например, если температура датчика будет превышать разрешенную в течение получаса, в почтовый ящик свалится с десяток сообщений. Но в то же время уведомить оператора о решившейся проблеме ИБП не умеет, такой функциональности в ПО нет. Это принципиальный момент. Например, за ночь может произойти множество событий и с утра оператору важно будет в первую очередь уделить внимание тем, которые все еще остаются актуальными;

3) необходимо настраивать уведомления (типы событий, получателей, почтовый сервер) на каждом ИБП в отдельности. Сами уведомления настраивать нельзя, это тоже является минусом. Например, при превышении установленной температуры ИБП просто пришлет сообщение, что температура превысила установленную отметку. О том, насколько превышена температура, оператор из сообщения не узнает;

4) невозможно гибко настроить получателей сообщения. Например, информация о результатах последней калибровки актуальна только операторам, тогда как уведомление о сбое питания будет важно и другим людям, в том числе системным администраторам и т.д.;

5) данная система подходит только для ИБП, напрямую подключенных к сети;

• Вполне логично обратиться к решению от APC. Речь идет о Powerchute Business Edition. Версия Basic достаточно интересна в данном случае, она позволяет наблюдать (и управлять) за 5 ИБП одновременно, но все проблемы, описанные выше (генерация кучи предупреждений, невозможность получения сообщения об устранении проблемы, отсутствие настроек уведомлений) остаются и здесь. Преимуществом по сравнению с предыдущим вариантом является лишь возможность мониторить ИБП, подключенные через USB- или COM-порты.
• Продукт Power Management Packs for Operations Manager от Quest Software. Данный софт работает независимо от SCOM, по сути, на сервер ставится отдельная программа, а к SCOM делается коннектор. Из-за этого все настройки и конфигурирование происходят не в среде SCOM‘а, а в интерфейсе утилиты. Помимо очевидных вещей (например, оператору придется фактически изучать новый продукт в дополнение к уже используемому), это неудобно еще и тем, что мы лишаемся возможности управления через Powershell. Кроме того, начальная инсталляция системы довольно сложная.
• Различные бесплатные пакеты для мониторинга ИБП APC от самостоятельных разработчиков. Все эти пакеты объединяет то, что они нацелены на работу с SNMP-трапами, отсылаемыми ИБП. Это плохо тем, что инициатором уведомления выступает сам ИБП, причем он никак не контролирует, доставлено ли уведомление.

Таким образом, было решено создавать собственный пакет для мониторинга ИБП (в данный момент поддерживаются ИБП фирмы APC, в скором времени – и другие ИБП, соответствующие стандарту RFC1628). Задачи при создании пакета ставились следующие:

• Мониторинг ИБП APC с помощью SCOM в native-режиме, без использования коннекторов к сторонним продуктам.
• Удобство использования для оператора: стандартный интерфейс, привычные для операторов функции типа моделей состояния (об этом ниже).
• Широкие возможности по кастомизации – изменение порогов срабатывания алертов, частоты опроса параметров и т.д. В распределенной структуре любой организации это важно, т.к. параметры питания в разных серверных могут отличаться и можно гибко подстроить пакет под нормальное поведение конкретного ИБП в конкретной серверной.
• Поддержка мониторинга ИБП с разными типами подключения – Ethernet, COM, USB.

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

Общий список устройств

На этом списке легко увидеть состояние всех мониторящихся ИБП сразу. Благодаря способу представления – таблице – на одном экране отображается большое число устройств. Например, при разрешении 1024х768 одновременно можно наблюдать порядка 30-40 ИБП:

Диаграммы

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

Если мы захотим получить чуть больше информации по ИБП, просто откроем его свойства:

Мы легко можем узнать модель ИБП, его размещение (конечно, это должно быть указано в свойствах конкретного ИБП) и IP, а также другую информацию, которая может оказаться полезной для идентификации ИБП.

Возвращаясь к диаграмме устройств – явно, что у некоторых ИБП есть проблемы. Чтобы понять точнее, раскрываем заинтересовавшее нас устройство:

Это Smart-UPS 5000 с установленной картой управления / мониторинга (Environmental monitoring card).  Видно, что с системой мониторинга окружающей среды все хорошо, а вот по батарее есть какие-то предупреждения.

Диаграммы вполне можно считать основным рабочим интерфейсом оператора. Они позволяют через контекстные меню быстро открыть любые другие виды SCOM (например, графики производительности или список алертов), при этом оператор получит только те данные, которые соответствуют выбранному элементу. Например, если выбрать вид «графики производительности» для ИБП – то откроются все доступные для данного ИБП графики. Если же сделать аналогичное действие на батарее данного ИБП – то число графиков заметно уменьшится, останутся только те, которые соответствуют батарее данного ИБП.

Модель состояния

Выяснив по диаграмме, что проблема кроется в батарее ИБП, мы захотим выяснить, в чем же именно она заключается. Для этой цели нам больше всего подходит Health Explorer или Модель состояния. Вот что мы увидим для данной батареи:

Сразу видно, в чем проблема – ожидаемое время, в течение которого ИБП сможет поддерживать текущую нагрузку, опустилось ниже порога срабатывания алерта. Можно увидеть значение, при котором сработало уведомление и время, когда это произошло. В списке видны все события по данному инциденту в прошлом, что может помочь выявить проблему и то, как часто она бывает.

Алерты

Модель состояния хороша, если требуется просмотреть список текущих событий. Однако для анализа закрывшихся событий удобнее использовать Alert View. Тут сразу можно окинуть взором все, что происходило за выбранный интервал времени как с конкретным ИБП (или даже его батареей), так и со всеми ИБП сразу. Например, мы можем видеть, что за выбранный нами интервал времени было 2 события от одного из ИБП, одно из них уже не актуально, а второе все еще активно:

Графики

Еще одним средством анализа проблем можно считать графики. Естественно, графики могут быть только для тех параметров, которые можно как-то измерить. Вот, например, график изменения входного напряжения на ИБП, собранный за несколько часов:

Вот два температурных графика, снятых с одного и того же ИБП. Значения для красного графика получены со встроенного датчика температуры, находящегося внутри ИБП, а значения для оранжевого графика собраны с внешнего термодатчика, прикрепленного на серверной стойке недалеко от ИБП. Как можно увидеть, графики повторяются, а сдвиг вызван разностью температур внутри ИБП и снаружи:

А вот более интересный график связи ожидаемого времени работы ИБП (фиолетовый график) и текущей нагрузки (желто-зеленый график):

События

Для событий, которые важны лишь в случае многократного повторения (например, попытка подбора пароля), удобнее использовать Event View:

Уведомлять оператора логично лишь когда число повторов события превысит критическую величину за определенный интервал времени

Оповещения

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

Графики и алерты/уведомления

В настоящий момент пакет поддерживает ведение следующих графиков (естественно, все зависит еще и от самого устройства):

• Input Voltage, V
• Input Frequency, Hz
• Output Voltage, V
• Output Frequency, Hz
• Output Current, A
• Output Load, %
• Battery Capacity, %
• Battery Current, A
• Battery Voltage, V
• Battery Time Remaining, m
• Battery Temperature, C
• Probe Temperature, C
• Probe Humidity, %

Поддерживаются следующие уведомления и алерты:

Availability

UPS Basic Status

Если ИБП изменил свой статус (например, на Hardware Failure Bypass и т.д.,
всего различаются все 12 статусов)

UPS DC Fan

В случае отказа вентилятора

UPS has switched to
battery backup power

В случае переключения ИБП на встроенную батарею

UPS Link check

В случае отсутствия n ответов от ИБП за m промежуток времени

Battery replace indicator

В случае, если ИБП требует замену батареи

Test Calibration Results

В случае, если результаты последней калибровки неизвестны или она прошла с ошибкой

Test Diagnostic Results

В случае, если результаты последней диагностики неизвестны или она прошла с ошибкой

Performance

Input Line Voltage

В случае, если входное напряжение выше или ниже установленных порогов

Input Line Frequency

В случае, если частота напряжения на входе выше или ниже установленных порогов

Output Load

В случае превышения допустимого порога нагрузки на ИБП

Output Voltage

В случае, если выходное напряжение выше или ниже установленных порогов

Battery Capacity

В случае, если емкость батареи ниже установленного порога

Battery Runtime Remaining

В случае, если ожидаемое время работы от батарей ниже заданного порога

Battery Temperature

В случае превышения заданного порога встроенным датчиком температуры

Output contact

В случае замыкания контакта

Input relays

В случае срабатывания реле

Probe temperature

В случае превышения заданного порога внешним датчиком температуры

Security

UPS Password

В случае смены пароля на ИБП

UPS HTTP Access

В случае ввода n числа неверных паролей за m интервал времени при доступе к ИБП через HTTP

UPS Console Access

В случае ввода n числа неверных паролей за m интервал времени при доступе к ИБП через консоль

В настоящее время менеджмент-пак активно развивается, в частности в ближайшее время планируется расширение числа поддерживаемых устройств за счет ИБП сторонних фирм (не APC), соответствующих RFC1628. Но уже сейчас можно отметить отдельные моменты пакета:

• Установка пакета практически не отличается от установки большинства других пакетов для SCOM, практически никаких предварительных действий не требуется. Не требуется и установка какого-либо стороннего ПО. После установки пакет сам находит ИБП APC среди присутствующих сетевых устройств в SCOM, сам разбирается, установлена ли в ИБП плата мониторинга окружающей среды и т.д.
• Поддерживается мониторинг как ИБП, подключенных напрямую в сеть, так и работающих через USB- и COM-порты.
• Все алерты сделаны максимально кастомизируемыми, можно гибко подстроить пакет под конкретный ИБП.

]]> http://alexxb.wordpress.com/2009/05/04/apc-scom/ Mon, 04 May 2009 14:05:21 +0000 Alexx_B http://alexxb.wordpress.com/2009/05/04/apc-scom/

В данном сообщении опишу наш пакет мониторинга (management pack) для System Center Operations Manager 2007 (далее – SCOM), с помощью которого можно мониторить источники бесперебойного питания APC.

Почему вообще возникла идея создания подобного пакета? Когда приходится обслуживать несколько серверных, разнесенных географически, вопрос мониторинга питания встает с особой остротой. Никак не получится выбрать какой-нибудь один ИБП, мониторить его бесплатной утилитой APC, идущей в комплекте с ИБП и считать, что все остальные ИБП в серверной ведут себя примерно так же.

Итак, посмотрим на существующие решения, позволяющие мониторить ИБП. Так как в нашей организации внедрен SCOM, то различные пакеты под другие системы мониторинга нас не интересовали. Кроме того, далеко не все наши ИБП имеют установленную карту мониторинга окружающей среды, некоторые просто подключены к серверам через USB- или COM-порты. Разумеется, хотелось иметь универсальный инструмент для мониторинга, не зависящий от типа подключения ИБП. В итоге список рассмотренных нами вариантов такой:

• Можно настроить на каждом ИБП отсылку почтовых сообщений выбранным пользователям. Самый простой вариант, но он имеет кучу недостатков:

1) каждый ИБП должен иметь доступ к почтовому серверу

2) ИБП склонен генерировать сообщение за сообщением, если проблема не решается. Например, если температура датчика будет превышать разрешенную в течение получаса, в почтовый ящик свалится с десяток сообщений. Но в то же время уведомить оператора о решившейся проблеме ИБП не умеет, такой функциональности в ПО нет. Это принципиальный момент. Например, за ночь может произойти множество событий и с утра оператору важно будет в первую очередь уделить внимание тем, которые все еще остаются актуальными

3) необходимо настраивать уведомления (типы событий, получателей, почтовый сервер) на каждом ИБП в отдельности. Сами уведомления настраивать нельзя, это тоже является минусом. Например, при превышении установленной температуры ИБП просто пришлет сообщение, что температура превысила установленную отметку. О том, насколько превышена температура, оператор из сообщения не узнает.

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

5) данная система подходит только для ИБП, напрямую подключенных к сети

• Вполне логично обратиться к решению от APC. Речь идет о Powerchute Business Edition. Версия Basic достаточно интересна в данном случае, она позволяет наблюдать (и управлять) за 5 ИБП одновременно, но все проблемы, описанные выше (генерация кучи предупреждений, невозможность получения сообщения об устранении проблемы, отсутствие настроек уведомлений) остаются и здесь. Преимуществом по сравнению с предыдущим вариантом является лишь возможность мониторить ИБП, подключенные через USB- или COM-порты
• Продукт Power Management Packs for Operations Manager от Quest Software. Данный софт работает независимо от SCOM, по сути, на сервер ставится отдельная программа, а к SCOM делается коннектор. Из-за этого все настройки и конфигурирование происходят не в среде SCOM‘а, а в интерфейсе утилиты. Помимо очевидных вещей (например, оператору придется фактически изучать новый продукт в дополнение к уже используемому), это неудобно еще и тем, что мы лишаемся возможности управления через Powershell. Кроме того, начальная инсталляция системы довольно сложная
• Различные бесплатные пакеты для мониторинга ИБП APC от самостоятельных разработчиков. Все эти пакеты объединяет то, что они нацелены на работу с SNMP-трапами, отсылаемыми ИБП. Это плохо тем, что инициатором уведомления выступает сам ИБП, причем он никак не контролирует, доставлено ли уведомление

Таким образом, было решено создавать собственный пакет для мониторинга ИБП (в данный момент поддерживаются ИБП фирмы APC, в скором времени – и другие ИБП, соответствующие стандарту RFC1628). Задачи при создании пакета ставились следующие:

• мониторинг ИБП APC с помощью SCOM в native-режиме, без использования коннекторов к сторонним продуктам
• удобство использования для оператора: стандартный интерфейс, привычные для операторов функции типа моделей состояния (об этом ниже)
• широкие возможности по кастомизации – изменение порогов срабатывания алертов, частоты опроса параметров и т.д. В распределенной структуре любой организации это важно, т.к. параметры питания в разных серверных могут отличаться и можно гибко подстроить пакет под нормальное поведение конкретного ИБП в конкретной серверной
• поддержка мониторинга ИБП с разными типами подключения – Ethernet, COM, USB

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

Общий список устройств

На этом списке легко увидеть состояние всех мониторящихся ИБП сразу. Благодаря способу представления – таблице – на одном экране отображается большое число устройств. Например, при разрешении 1024х768 одновременно можно наблюдать порядка 30-40 ИБП:

Диаграммы

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

Если мы захотим получить чуть больше информации по ИБП, просто откроем его свойства:

Мы легко можем узнать модель ИБП, его размещение (конечно, это должно быть указано в свойствах конкретного ИБП) и IP, а также другую информацию, которая может оказаться полезной для идентификации ИБП.

Возвращаясь к диаграмме устройств – явно, что у некоторых ИБП есть проблемы. Чтобы понять точнее, раскрываем заинтересовавшее нас устройство:

Это Smart-UPS 5000 с установленной картой управления / мониторинга (Environmental monitoring card).  Видно, что с системой мониторинга окружающей среды все хорошо, а вот по батарее есть какие-то предупреждения.

Диаграммы вполне можно считать основным рабочим интерфейсом оператора. Они позволяют через контекстные меню быстро открыть любые другие виды SCOM (например, графики производительности или список алертов), при этом оператор получит только те данные, которые соответствуют выбранному элементу. Например, если выбрать вид «графики производительности» для ИБП – то откроются все доступные для данного ИБП графики. Если же сделать аналогичное действие на батарее данного ИБП – то число графиков заметно уменьшится, останутся только те, которые соответствуют батарее данного ИБП.

Модель состояния

Выяснив по диаграмме, что проблема кроется в батарее ИБП, мы захотим выяснить, в чем же именно она заключается. Для этой цели нам больше всего подходит Health Explorer или Модель состояния. Вот что мы увидим для данной батареи:

Сразу видно, в чем проблема – ожидаемое время, в течение которого ИБП сможет поддерживать текущую нагрузку, опустилось ниже порога срабатывания алерта. Можно увидеть значение, при котором сработало уведомление и время, когда это произошло. В списке видны все события по данному инциденту в прошлом, что может помочь выявить проблему и то, как часто она бывает.

Алерты

Модель состояния хороша, если требуется просмотреть список текущих событий. Однако для анализа закрывшихся событий удобнее использовать Alert View. Тут сразу можно окинуть взором все, что происходило за выбранный интервал времени как с конкретным ИБП (или даже его батареей), так и со всеми ИБП сразу. Например, мы можем видеть, что за выбранный нами интервал времени было 2 события от одного из ИБП, одно из них уже не актуально, а второе все еще активно:

Графики

Еще одним средством анализа проблем можно считать графики. Естественно, графики могут быть только для тех параметров, которые можно как-то измерить. Вот, например, график изменения входного напряжения на ИБП, собранный за несколько часов:

Вот два температурных графика, снятых с одного и того же ИБП. Значения для красного графика получены со встроенного датчика температуры, находящегося внутри ИБП, а значения для оранжевого графика собраны с внешнего термодатчика, прикрепленного на серверной стойке недалеко от ИБП. Как можно увидеть, графики повторяются, а сдвиг вызван разностью температур внутри ИБП и снаружи:

А вот более интересный график связи ожидаемого времени работы ИБП (фиолетовый график) и текущей нагрузки (желто-зеленый график):

События

Для событий, которые важны лишь в случае многократного повторения (например, попытка подбора пароля), удобнее использовать Event View:

Уведомлять оператора логично лишь когда число повторов события превысит критическую величину за определенный интервал времени

Оповещения

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

Графики и алерты/уведомления

В настоящий момент пакет поддерживает ведение следующих графиков (естественно, все зависит еще и от самого устройства):

• Input Voltage, V
• Input Frequency, Hz
• Output Voltage, V
• Output Frequency, Hz
• Output Current, A
• Output Load, %
• Battery Capacity, %
• Battery Current, A
• Battery Voltage, V
• Battery Time Remaining, m
• Battery Temperature, C
• Probe Temperature, C
• Probe Humidity, %

Поддерживаются следующие уведомления и алерты:

Availability

UPS Basic Status

Если ИБП изменил свой статус (например, на Hardware Failure Bypass и т.д.,
всего различаются все 12 статусов)

UPS DC Fan

В случае отказа вентилятора

UPS has switched to
battery backup power

В случае переключения ИБП на встроенную батарею

UPS Link check

В случае отсутствия n ответов от ИБП за m промежуток времени

Battery replace indicator

В случае, если ИБП требует замену батареи

Test Calibration Results

В случае, если результаты последней калибровки неизвестны или она прошла с ошибкой

Test Diagnostic Results

В случае, если результаты последней диагностики неизвестны или она прошла с ошибкой

Performance

Input Line Voltage

В случае, если входное напряжение выше или ниже установленных порогов

Input Line Frequency

В случае, если частота напряжения на входе выше или ниже установленных порогов

Output Load

В случае превышения допустимого порога нагрузки на ИБП

Output Voltage

В случае, если выходное напряжение выше или ниже установленных порогов

Battery Capacity

В случае, если емкость батареи ниже установленного порога

Battery Runtime Remaining

В случае, если ожидаемое время работы от батарей ниже заданного порога

Battery Temperature

В случае превышения заданного порога встроенным датчиком температуры

Output contact

В случае замыкания контакта

Input relays

В случае срабатывания реле

Probe temperature

В случае превышения заданного порога внешним датчиком температуры

Security

UPS Password

В случае смены пароля на ИБП

UPS HTTP Access

В случае ввода n числа неверных паролей за m интервал времени при доступе к ИБП через HTTP

UPS Console Access

В случае ввода n числа неверных паролей за m интервал времени при доступе к ИБП через консоль

В настоящее время менеджмент-пак активно развивается, в частности в ближайшее время планируется расширение числа поддерживаемых устройств за счет ИБП сторонних фирм (не APC), соответствующих RFC1628. Но уже сейчас можно отметить отдельные моменты пакета:

• Установка пакета практически не отличается от установки большинства других пакетов для SCOM, практически никаких предварительных действий не требуется. Не требуется и установка какого-либо стороннего ПО. После установки пакет сам находит ИБП APC среди присутствующих сетевых устройств в SCOM, сам разбирается, установлена ли в ИБП плата мониторинга окружающей среды и т.д.
• Поддерживается мониторинг как ИБП, подключенных напрямую в сеть, так и работающих через USB- и COM-порты
• Все алерты сделаны максимально кастомизируемыми, можно гибко подстроить пакет под конкретный ИБП

Александр Бурцев aka Alexx_B

]]> http://metrex.wordpress.com/?p=14 Thu, 30 Apr 2009 07:08:54 +0000 mbugriy http://metrex.wordpress.com/?p=14

Этот пост посвящён пакету мониторинга (management pack) цисок для Microsoft System Center Operations Manager 2007 (далее в тексте SCOM), который родился в недрах нашей компании.

Начну с того, как вообще мы дошли до жизни такой – почему стали писать собственный пакет мониторинга цисок. Дело в том, что SCOM у нас уже был внедрён, серверы он мониторил вполне успешно. Появилось естественное желание свести в единую консоль оператора мониторинг серверов, сетевого оборудования и источников бесперебойного питания. Я занялся исследованием вопроса мониторинга цисок с помощью SCOM. В каталоге на сайте Microsoft для этого предлагается два сторонних пакета (разрабатываемых партнёрами Microsoft и приобретаемыми отдельно). Я ставил и изучал оба – от Quest Software и Jalasoft, показывал их нашим сетевым администраторам… и в итоге мы решили, что их функционал нас не устраивает, и лучше будет написать свой management pack.

Немного расскажу о недостатках сторонних пакетов.

• Они работают совершенно отдельно от SCOM’а. Фактически, на сервер (иногда на отдельный) ставится некая программа, которая постоянно опрашивает циски, а в SCOM перебрасываются уже готовые для визуализации результаты мониторинга. Из-за такого принципа работы конфигурировать пакет приходится не из интерфейса SCOM, а из интерфейса самого пакета, как правило, запутанного и не интуитивного.
• Складывается впечатление, что эти пакеты делают люди далёкие от сетевого администрирования. Пакеты умеют собирать огромное количество параметров, но при этом не умеют собирать именно ту информацию, которая особенно интересна.
• В этих пакетах довольно слабо реализована самая классная фича SCOM’а. Я имею ввиду оповещения. При грамотно настроенных оповещениях в консоль управления SCOM’ом даже заглядывать не нужно, всё ясно из пришедших на e-mail писем, ну или sms на телефон, кому как удобно. У нас сетевики получают SMS о критических на их взгляд событиях и письма о некритических.
• Кастомизация. В сетевом администрировании многое зависит от качества сети и от требований, которые предъявляются к этому самому качеству. Если оставить все настройки пакета по умолчанию, то администраторы рискуют оказаться, либо заваленными SMS-ками, либо получать SMS раз в полгода при том, что конечные пользователи будут недовольны качеством работы сети. Конечно, каждый пользователь пакета может настроить пороги под себя, но иногда порогов недостаточно, нужно менять гораздо более глубокие механизмы.
• Способ распространения. Мониторинг сетей – штука сложная, и внедрить её просто нажав несколько раз NEXT в инсталлере – не реально. Самым разумным способом продажи такой системы мне представляется продажа продукта вместе с проектом по его внедрению и кастомизации. Сторонние пакеты написаны западными компаниями и приехать чтобы его внедрить они либо не смогут, либо смогут за совсем неразумные деньги.

Но довольно лирики, перейдём к обзору нашего пакета.

Во-первых, мы разделили циски на 3 не совсем равноправных класса: Routers, Switches и Firewalls. Самый интересный в плане мониторинга класс – Routers, на втором месте – Switches и замыкает тройку лидеров класс Firewalls.

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

1. Общий список.

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

Общий список.

2. Диаграммы.

Чтобы понять, какие компоненты мониторятся в конкретной циске и в каком состоянии эти компоненты находятся в данный момент, подходит это представление. Вот как выглядит один из наших рутеров модели 1841 на диаграмме:

У бедняжки всего один вентилятор, да и тот сломан.

Рутеры более старших моделей конечно же интереснее в плане мониторинга. Вот кусок скрина с диаграммы рутера 2851. Целиком диаграмма не влезла на лист, но на моём 19″ мониторе в консоли оператора SCOM диаграммами пользоваться вполне комфортно.

cisco2851 на диаграмме

А вот тут видны наиболее ресурсоёмкие процессы рутера.

Список самых ресурсоёмких процессов

Как видите, мониторинг даром не обходится, процессы, связанные с ответами на SNMP запросы попали в топ лист.

Ну и конечно, гордость коллекции – IP SLA мониторы. Их много, поэтому SCOM их разбивает на группы по состоянию.

С каналом в Самару явно не всё хорошо.

3. Графики.

Конечно, возможность оценить состояние циски одним взглядом – это очень круто, но иногда хочется узнать подробности. Не всё конечно можно показать на графиках (например, состояние блоков питания на графиках никак не покажешь), но многие вещи на графиках смотреть можно и нужно.

Классика жанра - % свободной памяти.

Графики температур нескольких цисок.

Трафик на одном из интерфейсов (in, out и total).

По некоторым объектам можно нарисовать много графиков. Например, для UDP-Jitter’а я оставил только самые необходимые, но всё равно их 13 штук.

% потерянных пакетов.

RTTMax и RTTMin

На самом деле графиков рисуется довольно много, все скриншотами не охватить. Если кому-то интересен полный список – смотрите таблицу в конце.

4. Алёрты.

Каждое изменение состояния циски в положительную и отрицательную сторону вызывает появление алёрта или закрытие алёрта. Чтобы узнать, какие алёрты в данный момент открыты (или какие вообще возникали за N дней) открываем соответствующее представление.

Активные алёрты.

5. Оповещения.

Естественно хочется получать по почте или на телефон уведомления о наиболее важных события. И это мы тоже можем, причём в довольно информативном виде.

Оповещение о высокой загруженности процессора.

Видим, что процессор был перегружен (>75%) , видим насколько сильно (81%). Видим список процессов, которые грузили процессор в этот момент (SNMP Engine), видим, какая часть процессора была занята обработкой прерываний (84%). Сразу можно сделать заключение, в чём причина высокой загрузки процессора. Тут немного хромает арифметика (2%+84%=81%). Небольшая погрешность возникает из-за того, что загрузка процессора, связанная с прерываниями, к сожалению, отдаётся циской только в мгновенном виде.

Канал в Тольятти слегка просел.

Тут у нас ощутимые потери на канале. Из 10 семплов в среднем не проходит 13% пакетов. Порог в 12% и количество усредняемых семплов – переопределяемые значения.

Канал в Новосибирск совсем упал.

В оповещении не видно, но тут мы тоже не ориентируемся на мгновенные показания. Канал считается упавшим, если не подаёт признаков жизни 2 семпла подряд. Само-собой количество семплов легко переопределяется.

6. Модели состояния.

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

Модель состояния

Видим, что данная циска пожелтела потому, что у неё вентилятор перешёл в состояние shutdown. Ещё видим, что этот вентилятор умер не до конца, иногда он переходит в состояние ок.

7. Syslog.

Ну и конечно мониторинг логов, куда же мы без этого. Наиболее важные события попадают в почту и в список алёртов:

Пользователь подключился по ssh.

8. Кастомизация.

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

А как у нас поживают циски, ответственные за канал в Екатеринбург?

9. Отчёты.

Если есть желание показать начальству, как классно у вас работали каналы между офисами в течение квартала, можно сгенерировать отчёт доступности. Например, такой:

А теперь обещанные таблицы.

Routers

Switches

Firewalls

Management pack, получившийся в результате почти года разработки нравится мне самому, и устраивает наш сетевой отдел. Фактически, у нас получилось уйти от недостатков сторонних пакетов мониторинга цисок. Перечислю в кратце достоинства конечного продукта.

• Наш пакет не требует установки отдельных приложений для своей работы. Он фактически является таким же обычным пакетом мониторинга, как пакеты для MS SQL или MS Exchange. Его внедрение сводится к тому, что нужно стандартным образом импортировать пакет в SCOM и задискаверить в SCOMе циски как обычные сетевые устройства. Пакет сам разберётся, что это циски, сам отнесёт их к нужным классам, выяснит, какие модули в этих цисках есть, и, собственно, начнётся таинство мониторинга.
• Инициаторами разработки пакета и активными участниками проекта были сетевые администраторы. Поэтому пакет мониторит только то, что нужно им, а не то, что в принципе можно мониторить. Я несколько раз порывался встроить мониторинг всяких штук, которые есть в пакетах от Jalasoft и Quest, но в итоге не сделал этого, потому что это оказывалось не нужно конечным пользователям – сетевым администраторам.
• Система алёртинга делалась с учётом российских реалий. Пакет не предназначался изначально для идеальной европейской сети, в которой не бывает неожиданных пропаданий соединения на несколько секунд или регулярной потери нескольких процентов пакетов на каком-нибудь канале. Наш пакет тестировался в обычных российских сетях и уверяю вас, даже если оставить всё по умолчанию, вы не будете завалены тысячей сообщений, а получите только действительно имеющие смысл уведомления. В тоже время никто не мешает конечному пользователю переопределить пороги так, чтобы пакет на любое икание сети разражался десятком смс-сообщений.
• Главный плюс пакета для русских клиентов – то, что его разработчики находятся в России. Мы готовы заниматься его внедрением, кастомизацией и даже наращивать его функционал по желанию заказчика.

Работы над пакетом продолжаются. Вот фичи, которые скорее всего появятся в очередных новых версиях:

• Собственные отчёты. В данный момент можно использовать стандартные отчёты SCOM, но иногда их не достаточно.
• Визуализация схемы сети. Всё просто – рисуете в Visio схему вашей сети (наверняка такая схема у вас уже есть) пристыковываете её к SCOMу и схема оживает красными, жёлтыми и зелёными огоньками.

]]> http://mssystemcenter.wordpress.com/2009/04/24/scom-2007-r2-release-candidate-is-ready-for-evaluation/ Fri, 24 Apr 2009 16:46:25 +0000 mariusvilemaitis http://mssystemcenter.wordpress.com/2009/04/24/scom-2007-r2-release-candidate-is-ready-for-evaluation/

Naujienos iš Microsoft System Center stovyklos rodo, kad ši komanda pasiruošusi rimtai padirbėti su System Center šeimos produktais. Atrodo visai neseniai šie produktai buvo pristatyti viešai ir mes nuolat matome leidžiamus atnaujinimus ir patobulinimus.

Šįkart System Center Operations Manager 2007, kuriam išleistas R2 release candidate (RC) su tikrai įdomiu patobulinimų sąrašu.

Unix ir Linux “mašinų” valdymas. Mano manymu, su šiuo žingsniu SCOM tik dar labiau paspartins savo plėtrą. Iki šiol SCOM domino tik kompanijas, kuriose visą “serverinę” sudarė Windows operacinės sistemos pagrindu veikiantys serveriai, arba kur valdymo sistemos buvo padalintos pagal operacines sistemas. Dabar jau galima pretenduoti į ženkliai platesnį spektrą “serverinių”.

Paslaugų lygio stebėjimas (Service Level Tracking).Šis funkcionalumas leidžia pažvelgti į “serverinę” iš reikiamų paslaugų pusės IR palyginti su turimomis paslaugų teikimo sutartimis (SLA). Dabar ir IT specialistai gali naudotis “paslaugų televizorium”, kuris veikia kaip vertėjas tarp verslo kalba kalbančių žmonių ir IT terminais žongliruojančių profesionalų. Ne paslaptis, dažniausiai tarpusavio kalba reikalauja vertėjo, kad suprasti ką kiekvienas iš jų nori pasakyti Iki R2 išleidimo, SCOM turėjo galimybę kurti paslaugų priklausomybes bei jas susieti su infrastruktūros objektais, tačiau R2 jau leidžia paslaugas aprašyti pagal turimus SLA ir stebėti jų vykdymą.

Nauji šablonai stebėjimui. Filtrai (wildcard) stebint Windows servisus, procesų kiekio stebėjimą tik praplečia SCOM galimybes tiksliau aprašyti stebėjimo taisykles. Taip pat yra nauji šablonai, pritaukyti Unix ir Linux įrangos stebėjimui.

Patobulintas naudojimas. Valdymo paketai (MP) gali būti parsiųsti naudojant SCOM konsolę.

Našumo pagerinimas. Greitesnis konsolės veikimas, patobulintas URL stebėjimas (iki 1000 kiekvienam valdymo serveriui [MS]). Palaikomas MS SQL 2008.

Ich habe eine kleine Anleitung geschrieben, damit man dynamische Gruppen mit der Authroing Konsole erstellen kann, damit man in den späteren Reports keine kryptischen Namen und Bezeichnungen hat.

Anleitungen Authoring Guide Opsmgr 2007

Erstellen eine Management Packs

ONCEAGAIN

Unter Tool | Options die Namenskonvention für die Firma einstellen, das muss nur einmal gemacht werden, alle folgenden Management Packs werden danach diesen Kürzel verwenden, mit OK bestätigen und falls nötig, Notepad als Editor hinzufügen.

Danach ein neues Management Pack erstellen mit einem aussagekräftigen Namen, in diesem Beispiel der Namenskürzel einer Applikation (bsp. SCOM oder TBS).

Titel des Management Packs setzen und eine kurze Beschreibung der Applikation, mit Create das Management Pack erstellen.

Nach der erfolgreichen Erstellung müssen noch zwei Management Packs referenziert werden.
In File | Management Pack Properties | Tab References wird mittels Add Reference die gewünschte Referenz ausgewählt:

System.Performance.Library.mp

Microsoft.SystemCenter.InstanceGroup.Library.mp

Anschliessend sollten die Properties so aussehen:

Klasse erstellen

Nun wird eine Klasse erstellt, damit die Rules, Monitor und Task darauf bezogen werden können. Das kann im Service Model Tab | New | Custom Class gemacht werden. Anschliessend öffnet sich ein Wizard mit dem eine Klasse erstellt werden kann.

Die Klasse wird mit *.Class beschriftet, damit man später weiss, was es genau ist. Diese Namensgebung ist entsprechend einzuhalten, ansonsten kann es zu Verwechslungen kommen.

Als Base Class wird die Klasse Microsoft.Windows.Server.Computer gewählt, und die Accessibility wird auf Public gestellt.

Im Tab Proberties | Rechtsklick | Add Property | SystemManager

Anschliessend den Display Name ergänzen und mit OK abschliessen.

Gruppe für alle Server erstellen
Nun wird eine Gruppe erstellt. Das kann im Service Model Tab | New | Custom Class gemacht werden.

Die Klasse wird mit *.Computers oder *.Computers.Prod beschriftet, damit man später weiss, was es genau ist. Diese Namensgebung ist entsprechend einzuhalten, ansonsten kann es zu Verwechslungen kommen.

Displayname wählen, als Base Class „Microsoft.SystemCenter.InstanceGroup“ einstellen, Name und Beschreibung eintippen und Accessibility auf Public setzen und mit OK den Wizard beenden. Das wird für jede Umgebung wiederholt.

Discovery für die Klasse erstellen

Nun ist eine Klasse erstellt, allerdings hat diese Klasse noch keine Objekte enthalten. Dazu wird eine Zuweisung oder Discovery mittels eines Registry Eintrages gemacht. Das kann auch per WMI oder mit einem Script geschehen. Gehe zu Health Model | Discoveries | New | Custom Discovery danach öffnet sich wiederum ein Wizard.

Die Element ID wird am besten mit *.Discovery beschriftet, mit einem passenden Titel und einer kurzen Beschreibung wird die Wiedererkennung gewährleistet.
Als Target wird die Klasse „Microsoft.Windows.Server.Computer“ eingefügt

Im Tab Discovered Types fügen wir mit Add die Variable SystemManager hinzu.

Im Tab Configuration wählen wir Browse for a type.., wählen Microsoft.Windows.RegistryDiscoverySingleProvider, tippen in der Module ID den Applikationkürzel ein und beenden mit OK

Jetzt müssen die Eingaben eingefügt werden. Mit Edit öffnen wir das Konfigurationsfile im Notepad und kopieren disen Inhalt in das File:

<Configuration >
<ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<AttributeName>*Name des RegistryKeys*</AttributeName>
<Path>*hier den registrykey Pfad eintragen*</Path>
<PathType>1</PathType>
<AttributeType>1</AttributeType>
<Frequency>3600</Frequency>
<ClassId>$MPElement[Name="APPL.SCOM.Class"]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name="APPL.SCOM.Class"]/SystemManager$</Name>
<Value>$Data/Values/SystemManager$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
</Setting>
</Settings>
</InstanceSettings>
</Configuration>

Die rot markierten Punkte müssen entsprechend mit dem Namen der Applikation angepasst werden.

Im Tab Options wird die Category von Custom auf PerformanceCollection gewechselt.

Discovery für die Klasse erstellen

Nun müssen die Gruppen noch mit Objekten befüllen. Dies geschieht mit einer weiteren Discovery unter Health Model | Discoveries | New | Custom Discovery
Hier wird die Zuweisung der Gruppen gemacht, somit ist im Titel zu beschreiben, welche Gruppe damit befüllt wird.

Als Target wird die gewünschte Gruppe gewählt, in diesem Beispiel ist das PF.SCOM.Computers.All eingetragen.

Im Tab Discovered Types wird mit Add die Relationships Micorsoft.SystemCenter.InstanceGroupContainsEntities hinzugefügt.

Im Tab Configuration wählen wir Browse for a type.. anschliessend Microsoft.SystemCenter.GroupPopulator, als Module ID tippen wir SCOM ein.

Die Fehlermeldung die nach dem OK klicken erscheint kann ignoriert werden.

Im Tab Configuration auf Edit klicken.

In das offene Notepad Fenster diesen Inhalt hinein kopieren:

<GroupInstanceId>$MPElement[Name="PF.SCOM.Computers.All"]$</GroupInstanceId>
Der rote markierte Abschnitt muss mit dem richtigen Gruppennamen angepasst werden!

Das File Speichern und schliessen.

Im Tab Options wird die Category von Custom auf Discovery gewechselt.

Mit OK wird der Vorgang beenden.

Das wird für jede Gruppe wiederholt die im vorherigen Schritt erstellt wurde.

Die Bilder dazu folgen..

Ab sofort ist über Microsoft Connect die RC Version von Opsmgr/SCOM2007  R2 erhältlich.

https://connect.microsoft.com/default.aspx

Hier finedt ihr eine sehr nette Linkliste. Alles zum Thema Installation, Troubleshooting, diverse Guides.

Viel Spass

SCOM2007 Linksliste

You may have already seen the ‘Campaign against SCCM‘ which talks about the use of the SCCM acronym for System Center Configuration Manager. I have to admit that internally we do use that acronym, along with SCOM, and I’m also guilty of its use on twitter. However you will not these those acronyms on this blog, which brings me onto standards and conventions that I will use.

Firstly I’m British, so my blogs will be written in British English meaning that a Data Center is Data Centre, Virtualization is Virtualisation etc. Secondly I’ll be adhering to standards that manufacturers set for their products. For System Center the following apply

Die Fehlersuche kann manchmal ganz schln deprimierend sein, vor allem wenn keine Fehlermeldung auftritt oder diese irgendwie nichtsagend ist. So heute geschehen. Opsmgr liess sich einfach nicht starten, bzw das Installations-GUI schlug schon weit vor jeder Eingabe fehl ohne gross eine Fehlermeldung auszugeben….

Der Fehler lag zum Schluss an einem per SMS installierten .Net Framework 3.0 Paket.

Merkt euch eins, wenn es bei Google oder einer anderen Suchmaschine zu eurem Problem keine oder wenig ähnliche Einträge gefunden werden, dann ist eure Umgebung schuld oder ihr habt es mit einem neuen Produkt zu tun.

Haut rein.

Hier findet ihr ein paar nette Powershell Befehle für Opsmgr 2007

http://myitforum.com/cs2/blogs/smoss/archive/2009/02/05/smug-presentation-february-3rd-2009-administrative-uses-of-powershell-in-opsmgr-2007.aspx

Derzeit laufen verschiedene Test mit Windows 2008 und System Center Operations Manager R2 Beta.
Die Installation ging im Vergleich zu den Betaversionen der ersten Version relativ glatt von der Hand. Die Webkonsole habe ich zwar bisher nicht zum laufen gebracht, allerdings habe ich bisher wenig Zeit mit Troubleshooten verbracht.
Einzig die Anbindung an HP OpenView wird vermutlich so nicht klappen. Wir setzen eine zu alte Version von der Host-Os darunter ein und die Beta des Interop Connectors unterstützt nur HP_UX v3.
So wird wohl ein downgrade auf die alte Version unumgänglich, da die zeit langsam knapp wird und der Connector bisher noch nie funktioniert hat.