SCOM: PowerShell-Skripte in Regeln einbetten statt auf jeden Server zu kopieren

Eine Regel soll regelmäßig ein PowerShell-Skript ausführen – ohne die Datei auf hunderte Agenten zu verteilen. So betten Sie das Skript als Modul direkt ins Management Pack ein.

Eine Command-Line-Regel kann zwar jedes beliebige Skript starten – das Skript muss dann aber auf allen überwachten Systemen liegen. Bei vielen Agenten ist das weder praktikabel noch wartbar. Operations Manager bietet einen besseren Weg: Das Skript wird Teil des Management Packs und automatisch mit ihm an die Agenten verteilt.

Das Bausteinprinzip

Workflows in SCOM bestehen aus Modulen. Für eine zeitgesteuerte PowerShell-Regel brauchen Sie drei Bausteine:

1. Data Source: Ein Scheduler (System.SimpleScheduler) löst den Workflow in einem festen Intervall aus und ruft eine Probe Action auf, die das Skript ausführt – etwa Microsoft.Windows.PowerShellPropertyBagTriggerOnlyProbe.
2. Condition Detection: Ein System.ExpressionFilter prüft die Rückgabewerte aus dem Property Bag.
3. Write Action: System.Health.GenerateAlert erzeugt den Alarm – oder eine andere Aktion schreibt Daten weg.

Für den häufigsten Fall gibt es seit Operations Manager 2012 ein fertiges zusammengesetztes Modul: Microsoft.Windows.TimedPowerShell.PropertyBagProvider vereint Scheduler und PowerShell-Probe.

Beispiel: Prüfen, ob ein Pfad existiert

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedPowerShell.PropertyBagProvider">
  <IntervalSeconds>600</IntervalSeconds>
  <SyncTime />
  <ScriptName>CheckPath.ps1</ScriptName>
  <ScriptBody><![CDATA[
param([string]$Path)
$api = New-Object -ComObject 'MOM.ScriptAPI'
$bag = $api.CreatePropertyBag()
$bag.AddValue('PathExists', [string](Test-Path -LiteralPath $Path))
$bag
]]></ScriptBody>
  <Parameters>
    <Parameter><Name>Path</Name><Value>D:\Import\Inbox</Value></Parameter>
  </Parameters>
  <TimeoutSeconds>60</TimeoutSeconds>
</DataSource>

Die Regel filtert anschließend auf Property[@Name='PathExists'] gleich False und erzeugt nur dann einen Alarm.

Werkzeuge

Solche Module lassen sich nicht in der normalen Betriebskonsole anlegen. Früher war dafür die Authoring Console von SCOM 2007 R2 zuständig, heute sind es die Visual Studio Authoring Extensions (VSAE) oder Drittanbieter-Werkzeuge. Die Vorgehensweise ist in allen Fällen gleich: Modultypen in der Type Library definieren, Regel darauf aufbauen, Management Pack versiegeln oder als XML importieren.

Wenn die Regel in der Simulation läuft, im Betrieb aber nicht

Ein Klassiker aus unserem Forum: Die Regel funktioniert im Test, auf dem Zielserver passiert jedoch nichts. Die häufigsten Ursachen:

• Falsches Ziel: Die Regel ist auf eine Klasse ausgerichtet, die auf dem Server gar nicht entdeckt wurde – oder sie ist standardmäßig deaktiviert und das Override greift nicht.
• Management Pack nicht angekommen: Auf dem Agenten im Ereignisprotokoll Operations Manager prüfen, ob die neue Konfiguration geladen wurde.
• Skriptfehler zur Laufzeit: Fehler beim Ausführen eines Skripts protokolliert der Agent ebenfalls im Ereignisprotokoll Operations Manager. Häufig fehlen Rechte des Run As-Kontos oder ein Parameter ist leer.
• Umgebungsunterschiede: Funktioniert dieselbe Regel in einer anderen Verwaltungsgruppe, liegt das Problem nicht am Workflow, sondern an Agentenversion, PowerShell-Version oder Berechtigungen.