System Center

Windows PowerShell in System Center Operations Manager

Marco Shaw

 

Auf einen Blick:

• Die OpsMgr-Befehlsshell
• Der OpsMgr-Überwachungsanbieter
• Automatisieren häufiger administrativer Aufgaben
• Einige praktische Windows PowerShell-Beispiele

Inhalt

Operations Manager-Befehlsshell
Der OpsMgr-Überwachungsanbieter
Automatisieren häufiger Aufgaben
Praxisbeispiele
Zusammenfassung

Mit System Center Operations Manager 2007 (OpsMgr) haben Administratoren Zugriff auf Windows PowerShell, eine leistungsfähige neue Skriptsprache für das Automatisieren von Aufgaben. Seit ihrer Veröffentlichung im November 2006 wurde sie mehr als zwei Millionen Mal heruntergeladen.

In diesem Artikel wird Windows PowerShell® beschrieben, und es wird erläutert, wie diese Skriptsprache in Operations Manager verwendet werden kann. Zudem wird auf einige häufige Aufgaben eingegangen, die Sie mithilfe von Windows PowerShell viel einfacher und mit einem höheren Automatisierungsgrad durchführen können, und es werden einige Websites genannt, die nützliche Skripts und Erklärungen bieten. Dieser Artikel stützt sich auf Erkenntnisse und Blogbeiträge von zahlreichen Experten, die Windows PowerShell bereits verwenden.

Obwohl Microsoft mit der Veröffentlichung der CTP-Versionen (Community Technology Preview) von Windows PowerShell 2.0 begonnen hat, sind diese Versionen noch nicht produktionsreif, wurden nicht in Verbindung mit OpsMgr getestet und sollten nicht auf einem Produktionssystem installiert werden.

Operations Manager-Befehlsshell

In OpsMgr greifen Sie auf Windows PowerShell über die Befehlsshell zu, die der standardmäßigen Windows PowerShell-Umgebung ähnelt – mit der Ausnahme, dass eine Konsolendatei sowie ein Skript, das die Umgebung mit OpsMgr-Cmdlets, -Funktionen und einer Standardverbindung initialisiert, geladen werden.

Sie können die Befehlsshell über ein Symbol im Startmenü von OpsMgr starten oder durch Klicken mit der rechten Maustaste auf einen Computernamen in der OpsMgr-Benutzeroberflächenkonsole (siehe Abbildung 1). Dadurch wechseln Sie direkt zum Pfad des Monitoring-Laufwerks von OpsMgr (auf das an späterer Stelle eingegangen wird).

Abbildung 1 Öffnen der Befehlsshell über die OpsMgr-Benutzeroberfläche (zum Vergrößern auf das Bild klicken)

Über das OpsMgr SDK verfügt Windows PowerShell über eine Schnittstelle zu OpsMgr. Für Administratoren wurden glücklicherweise bereits Cmdlets für viele der Aufgaben bereitgestellt, die Sie in der Regel automatisieren oder von einer Befehlszeile aus durchführen möchten. Wenn für eine bestimmte Aufgabe kein Cmdlet zur Verfügung steht, können Sie Windows PowerShell für die Interaktion mit dem SDK verwenden.

Die von der Operations Manager-Befehlsshell bereitgestellten Befehle sind in einem Snap-In enthalten – einer DLL, die von Windows PowerShell geladen wird und Cmdlets für die OpsMgr-Verwaltung enthält. Das Snap-In enthält zudem den Windows PowerShell-Anbieter „OperationsManagerMonitoring“. Dieses auch als Überwachungsanbieter bezeichnete Tool ermöglicht die Navigation in Verbindungen, Gruppen und Überwachungsobjekten, die weitgehend mit der Navigation im Dateisystem vergleichbar ist.

Mithilfe des Cmdlet „Get-OperationsManagerCommand“ können Sie wie in Abbildung 2 dargestellt eine Liste aller für OpsMgr spezifischen Cmdlets abrufen. (In der ersten Version war dies eine Funktion, die nicht die Befehlszeilenergänzung mit der Tabulatortaste unterstützte. In SP1 wurde aus ihr ein Cmdlet.) Die ursprüngliche Version von Operations Manager enthielt 74 Cmdlets, während OpsMgr SP1 87 Cmdlets umfasst.

Abbildung 2 Abrufen einer Liste der OpsMgr-Cmdlets (zum Vergrößern auf das Bild klicken)

Der OpsMgr-Überwachungsanbieter

Mithilfe des Cmdlet „Set-Location“ oder des Alias „cd“ können Sie durch das Layout von Gruppen und Computern navigieren. Das Basislayout für das Monitoring-Standardlaufwerk sieht in etwa folgendermaßen aus:

Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)

Von hier aus können Sie zu spezifischeren Objekten gelangen. Beachten Sie, dass es sich in diesem Fall nur um eine einfache Umgebung mit nur einem einzigen Verwaltungsserver handelt. Der erste Verwaltungsserver, der in einer Verwaltungsgruppe installiert wird, wird als Stammverwaltungsserver (Root Management Server, RMS) bezeichnet.

Wenn die Befehlsshell gestartet wird, wird ein Laufwerk namens „Monitoring“ erstellt, das Laufwerk dem Stamm des OperationsManagerMonitoring-Anbieters zugeordnet und abschließend der aktuelle Speicherort oder Pfad auf das Stammverzeichnis des Monitoring-Laufwerks gesetzt. Die Befehlsshell sucht dann in der Registrierung nach dem Namen des Standard-Stammverwaltungsservers, zu dem eine Verbindung hergestellt werden soll. Wenn die Verbindung zum Stammverwaltungsserver erfolgreich hergestellt wird, wird der aktuelle Speicherort oder Pfad auf den Namen der Verbindung oder des Stammverwaltungsservers gesetzt (siehe Abbildung 3).

Abbildung 3 Der Speicherort der Befehlsshell wird auf den Stammverwaltungsserver gesetzt (zum Vergrößern auf das Bild klicken)

Automatisieren häufiger Aufgaben

Im Folgenden wird erläutert, wie mit Windows PowerShell einige der häufigsten administrativen Aufgaben durchgeführt werden können.

Steuern des Wartungsmodus Unabhängig davon, mit welcher Aufgabe Sie sich befassen, möchten Sie in der Regel das Datum und die Uhrzeit angeben, zu dem bzw. der sie durchgeführt werden soll. Im Folgenden wird kurz das Cmdlet „Get-Date“ beschrieben, um Ihnen zu zeigen, wie einfach dieser Vorgang sein kann. Abbildung 4 zeigt einige Beispiele.

Abbildung 4 Verwenden des Cmdlet „Get-Date“ (zum Vergrößern auf das Bild klicken)

Wie Sie sehen können, wurde eine $date-Variable erstellt, die ein Objekt enthält, das die aktuelle Uhrzeit repräsentiert. Um Ihnen zu zeigen, wie Sie Datum und Uhrzeit mühelos fünf Minuten später und dann fünf Stunden später abrufen können, wurden einige dokumentierte Methoden verwendet, die von dem Objekt unterstützt werden. Falls Sie Werte aus der Vergangenheit abrufen möchten, können Sie einfach (-5) anstelle von (5) verwenden.

Wenn Sie alle Warnungen blockieren müssen, die von einem Computer kommen, können Sie den Wartungsmodus aktivieren. OpsMgr 2007 ermöglicht Ihnen, anstelle ganzer Computer oder Gruppen einen Windows®-Dienst oder sogar eine bestimmte Datenbank in den Wartungsmodus zu versetzen. Es gibt drei Cmdlets, die speziell für Aufgaben in Verbindung mit dem Wartungsmodus vorgesehen sind: „Get-MaintenanceWindow“, „New-MaintenanceWindow“ und „Set-MaintenanceWindow“.

Um einen Computer von der Befehlsshell aus in den Wartungsmodus zu versetzen, navigieren Sie mithilfe des Überwachungsanbieters zum gewünschten Computer oder Überwachungsobjekt, und rufen Sie das Cmdlet „New-MaintenanceWindow“ auf (siehe Abbildung 5). Wie Sie sehen können, wird durch diese Aktion der Computer mit dem Namen „Denver.contoso.com“ in den Wartungsmodus versetzt. Zudem wurde die Startzeit für das Wartungsfenster so definiert, dass es sofort beginnt, und die Endzeit wurde genau auf eine Stunde später gesetzt. Beachten Sie, dass nicht alle Warnungen gestoppt werden, wenn ein Computer mit dieser Methode in den Wartungsmodus versetzt wird, da die HealthService- und HealthServiceWatcher-Instanzen für dieses Objekt immer noch aktiviert sind.

Abbildung 5 Verwenden des Cmdlet „New-MaintenanceWindow“ (zum Vergrößern auf das Bild klicken)

Boris Yanushpolsky, Programmmanager im Microsoft OpsMgr-Team, hat äußerst nützlichen Windows PowerShell-Code bereitgestellt, mit dem alle Objekte, die auf einen Computer im Wartungsmodus verweisen, festgelegt werden können. Er erklärt zudem, wie Sie diesen Code nach der Erstellung eines Skripts verwenden können. Weitere Informationen hierzu finden Sie in seinem Blog unter blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.

Manchmal müssen Sie feststellen, ob sich Objekte im Wartungsmodus befinden, bei denen dies nicht beabsichtigt ist. Es kann jedoch eine relativ umfangreiche Aufgabe darstellen, alle Objekte durchzugehen, um dies herauszufinden. Glücklicherweise kommt Ihnen Boris Yanushpolsky erneut mit einem Windows PowerShell-Skript zu Hilfe, bei dem das OpsMgr SDK verwendet wird. Sie können den Code direkt aus seinem Blogbeitrag kopieren (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) und ihn in ein Befehlsshellfenster einfügen, um eine Liste aller im Wartungsmodus befindlichen Objekte abzurufen.

Wenn sich ein Objekt im Wartungsmodus befindet, möchten Sie eventuell den Wartungszeitraum vor der ursprünglich angegebenen Endzeit beenden. Falls Sie mit Windows PowerShell vertraut sind, erwarten Sie möglicherweise ein Cmdlet mit einem stop- oder remove-Verb. Tatsächlich müssen Sie aber „Set-MaintenanceWindow“ wie in Abbildung 6 verwenden.

Abbildung 6 Ändern der Endzeit mithilfe von „Set-MaintenanceWindow“ (zum Vergrößern auf das Bild klicken)

Verwalten von Agents Administratoren arbeiten sehr häufig mit Agents, und es sind sechs Cmdlets und eine Funktion (ab der aktuellen Version) vorhanden, die für verschiedene Aufgaben im Zusammenhang mit Agents vorgesehen sind. Sie können eine entsprechende Liste mit dem folgenden Befehl abrufen:

Get-Command *-agent*

Ab der SP1-Version wird Install-AgentByName nicht mehr als Funktion, sondern als Cmdlet bereitgestellt. Es wird empfohlen, dass Sie das Cmdlet „Install-AgentByName“ verwenden, da es eine bessere Grundlage für Unterstützung und Konsistenz bietet.

Die integrierte Hilfe der Befehlsshell enthält einige gute Beispiele für die Verwendung der Cmdlets „Install-Agent“ und „Uninstall-Agent“. Roger Sprague, Senior Software Design Engineer im Microsoft OpsMgr-Team, hat eine alternative Methode in seinem Blog veröffentlicht, die in Abbildung 7 dargestellt ist (seinen ursprünglichen Beitrag finden Sie unter blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).

Dieses Skript funktioniert in Verbindung mit der RTM-Version von OpsMgr problemlos (Sie müssen es im Stammverzeichnis des Überwachungsanbieters ausführen – in diesem Artikel monitoring:\oxford.contoso.com), schlägt aber bei OpsMgr SP1 fehl. Damit das Skript in Verbindung mit OpsMgr SP1 funktioniert, sollte der erste Befehl in Abbildung 7 wie folgt geändert werden:

 $managementServer = Get-RootManagementServer

Abbildung 7 Installieren eines Agent

# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects

Jetzt ist der Agent auf dem Remotesystem installiert, das überwacht werden soll. Es muss aber noch ein letzter Schritt durchgeführt werden, bei dem der Verwaltungsserver den neuen Agent tatsächlich akzeptieren muss, bevor er vollständig überwacht wird. Wenn keine weitere Aktion durchgeführt wird, akzeptiert der Überwachungsserver den neuen Agent automatisch für die Überwachung. Dieser Annahmeprozess kann aber auch mithilfe des Cmdlet „Get-AgentPendingAction“ beschleunigt werden. Mit der folgenden Codezeile wird der Agentannahmeprozess beschleunigt:

Get-AgentPendingAction | Where Object {$_.AgentName –like 
'computer*'} | Approve-AgentPendingAction

Durch das Weiterleiten an „Reject-AgentPendingAction“ anstelle von „Approve-AgentPendingAction“ können Sie die Annahme dieses Agent durch den OpsMgr-Server blockieren, wenn die Aktion noch aussteht. Wenn sie nicht mehr aussteht, verwenden Sie stattdessen das Cmdlet „Uninstall-Agent“.

Wie bereits erwähnt, können Sie auch mithilfe von „Install­AgentByName“ direkt in der Befehlszeile einen Computer angeben, auf dem der Agent installiert werden soll.

Arbeiten mit Management Packs Es gibt vier Cmdlets, die Ihnen bei verschiedenen Aufgaben in Verbindung mit Management Packs helfen. Sie können sie mit dem folgenden Befehl auflisten:

Get-Command –noun ManagementPack

Mit diesem einfachen Befehl werden die derzeit installierten Management Packs und ihre Versionsnummern abgerufen:

Get-ManagementPack | Format-Table –autosize

Jetzt wird die Befehlsshell verwendet, um zwei Standard-Management Packs mithilfe der folgenden Installationsprogramme zu installieren:

• Internet Information Services System Center Operations Manager2007 Management Pack.msi
• Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi

Da das Ziel darin besteht, Ihnen zu zeigen, wie mithilfe der Befehlsshell reguläre Aufgaben vereinfacht werden können, werden hierzu so wenige Befehle wie möglich verwendet (siehe Abbildung 8). Dieses Installationsverfahren hätte auch so geändert werden können, dass das quiet-Kennzeichen an das Installationsprogramm (die .msi-Dateien) übergeben wird, aber es sollte der Speicherort ausgewählt werden, an dem die Dateien manuell extrahiert werden.

Abbildung 8 Installieren von Management Packs (zum Vergrößern auf das Bild klicken)

Als Nächstes müssen die gemeinsamen Bibliotheken installiert werden, was folgendermaßen erreicht werden kann:

Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

Dann werden die anderen erforderlichen Management Packs installiert:

Get-ChildItem –Path C:\MPs –filter *200?.mp | 
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

Wie in Abbildung 9 zeigt, bietet die integrierte Hilfe der Befehlsshell ein hervorragendes Beispiel für den Export von nicht versiegelten Management Packs mithilfe des Cmdlet „Export-ManagementPack“. Wenn Sie alle Management Packs exportieren möchten, ändern Sie die folgende Zeile:

 $mps=Get-ManagementPack | 
Where-Object {$_.Sealed –eq $false} 

 $mps=Get-ManagementPack

Abbildung 9 Exportieren eines Management Packs (zum Vergrößern auf das Bild klicken)

Bearbeiten von Benutzerrollen Das Cmdlet „Get-UserRole“ bietet bestimmte Funktionen für das Verwalten von Benutzern, wird aber seltsamerweise nicht zusammen mit einem komplementären Set-Cmdlet bereitgestellt, und es wird (gemäß der Windows PowerShell SDK-Dokumentation) in der Regel nicht für Bearbeitungs- oder Aktualisierungsvorgänge verwendet. Wie Sie in Abbildung 10 sehen können, wird zuerst eine Liste der aktuellen Benutzerrollen abgerufen und dann der Gruppe der schreibgeschützten Operatoren ein Benutzer hinzugefügt (siehe Abbildung 11).

Abbildung 10 Anzeigen von Benutzerrollen (zum Vergrößern auf das Bild klicken)

Abbildung 11 Hinzufügen eines Benutzers (zum Vergrößern auf das Bild klicken)

Aktivieren der Überwachungssammeldienste (Audit Collection Services, ACS) ACS ist ein neues optionales Feature von Operations Manager 2007, das, kurz gesagt, ein zentralisiertes Verfahren für den Umgang mit Sicherheitsüberwachungsinformationen bietet. ACS ist standardmäßig nicht aktiviert und wird in der Regel in einer späteren Phase einer OpsMgr-Bereitstellung konfiguriert.

Wenn es an der Zeit ist, eine große Anzahl von Agents für ACS zu aktivieren, kann das Setup mithilfe von Windows PowerShell automatisiert werden. Während der Betaphase von OpsMgr stellte Microsoft ein Skript bereit, mit dem ACS für alle Agents aktiviert werden kann. Neale Browne, Autor und Blogger bei SystemCenterForum.org, hat dieses Skript weiterentwickelt und Unterstützung für zusätzliche Parameter hinzugefügt.

Auf der Website unter SystemCenterForum.org (eine Communitywebsite, auf der Microsoft® System Center-Lösungen bereitgestellt werden) wurden zwei verschiedene Windows PowerShell-Skripts zum Automatisieren des Setups von ACS zur Verfügung gestellt. Um alle Agents in einer bestimmten Gruppe einzurichten, verwenden Sie systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Um alle überwachten Agents einzurichten, laden Sie systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip herunter.

Aktivieren der Proxyfunktion des Agent Ihre OpsMgr-Umgebung kann ohne Agents überwachte Geräte enthalten. Diese Geräte müssen einem Verwaltungsserver oder einem mit Agents verwalteten Gerät, das die Remoteüberwachung bereitstellt, zugewiesen werden. Eine ausführliche Beschreibung dazu, wie Sie mithilfe eines Windows PowerShell-Skripts eine große Anzahl von Agents konfigurieren können, finden Sie unter systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Eine aktualisierte Version des Skripts ist unter systemcenterforum.org/wp-content/uploads/Set­AgentProxyBulk_FQDN.zip verfügbar.

Es gibt weitere Bedingungen, unter denen bestimmte Management Packs es erfordern, dass ein Agent auch für die Funktion als Proxy eingerichtet wird. Weitere Einzelheiten finden Sie in der Management Pack-Dokumentation.

Praxisbeispiele

Es folgen einige praktische Beispiele, um Ihnen zu zeigen, wie Ihnen Windows PowerShell bei der Automatisierung helfen kann.

Auflösen von Warnungen Mussten Sie jemals mehrere Warnungen für einen bestimmten Computer löschen? Vielleicht ist bei einer Anwendung ein Fehler aufgetreten, oder die Warnungen wurden nicht aktiv aufgelöst. Mit dem folgenden einzeiligen Befehl können alle Warnungen mit dem Auflösungsstatus „null“ aufgelöst werden:

Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null

Im nächsten Beispiel wird das gleiche Ergebnis wie im ersten Beispiel erzielt, aber der Code wird in einer größeren Umgebung mit mehr ausstehenden Warnungen viel schneller ausgeführt:

Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null

Der Grund für den Leistungsunterschied besteht darin, dass bei Verwendung des criteria-Parameters der übergebene Wert direkt an die SQL Server®-Datenbank weitergeleitet wird und nur die relevanten Daten zurückgegeben werden. Dadurch verringert sich die Zahl der Objekte, die an die Windows PowerShell-Konsole zurückgegeben werden müssen.

Jetzt verfügen Sie über eine schnelle Methode zum Entfernen aller ausstehenden Warnungen für einen Computer. In Abhängigkeit von Ihren Anforderungen können Sie festlegen, dass dieser Vorgang automatisch ausgeführt werden soll.

Mit dem folgenden kurzen Befehl können Sie alle Warnungen für einen bestimmten Tag anzeigen:

Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''

Sie können den Datumswert problemlos ändern und die Ausgabe an das Cmdlet „Resolve-Alert“ weiterleiten.

Prüfen von Warnungen Manchmal ist es erforderlich, bestimmte Ereignisse in der Windows-Ereignisanzeige zu überwachen und auf sie zu prüfen. Durch die folgenden beiden Zeilen wird schnell ein Ereignisprotokolleintrag erstellt:

 $api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")

Hierbei wird jedoch standardmäßig in das Operations Manager-Ereignisprotokoll geschrieben, das Sie wahrscheinlich nicht dahingehend überprüfen, ob ein bestimmtes Ereignis protokolliert wurde. Glücklicherweise hat Stefan Stranger, Premier Field Engineer bei Microsoft, ein Skript für das Erstellen von Ereignissen in der Windows-Ereignisanzeige geschrieben, das mehr Flexibilität hinsichtlich der Möglichkeit bietet, in ein bestimmtes Protokoll zu schreiben. Sie finden das Skript unter go.microsoft.com/fwlink/?LinkId=120308. (Stefan Stranger hat das Skript in einer .cab-Datei verpackt. Sie müssen die Datei herunterladen und dann mit der rechten Maustaste auf sie klicken, um das Skript zu extrahieren.)

Bei Stefan Strangers Skript müssen Sie lediglich beachten, dass der für die Ereignisquelle eingegebene Wert bestimmt, in welches Protokoll der Eintrag geschrieben wird. Die vielleicht einfachste Möglichkeit, um sicherzustellen, dass eine Warnung an das richtige Protokoll weitergeleitet wird, besteht darin, die Windows-Ereignisanzeige zu öffnen und nach der Quelle des neuesten Eintrags zu suchen.

Festlegen des Besitzers Manchmal kann es nützlich sein, den Besitzer einer Warnung automatisch festzulegen. Es folgt eine einfache Methode, mit der Sie diesen Vorgang von der Befehlsshell aus durchführen können:

 $alert = Get-Alert 
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")

Durch die erste Zeile dieses Codes wird die ID eines bestimmten Warnungsobjekts abgerufen und an die $alert-Variable übergeben. In der zweiten Zeile wird diese Variable zum Festlegen des Besitzers verwendet, und abschließend wird die Aktualisierung auf die OpsMgr-Datenbank angewendet. Wenn Sie den Besitzer der Warnung mit dem folgenden Befehl prüfen, werden Sie feststellen, dass er geändert wurde:

Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner

Um den Besitzer für einen ganzen Satz von Warnungen festzulegen, könnten Sie den Code folgendermaßen vereinfachen:

Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}

Wiederherstellen des Überwachungsstatus Wahrscheinlich haben Sie schon einmal Agents mit dem Status „Nicht überwacht“ gefunden. Wenn dies geschieht, müssen Sie möglicherweise alle Agents schnell wieder in den vollständig überwachten Zustand versetzen und dann versuchen festzustellen, was passiert ist. Wenn Sie das Skript in Abbildung 12 direkt von der Befehlsshell aus ausführen, sollte die vollständige Überwachung aller betroffenen Agents wiederhergestellt werden.

Abbildung 12 Zurücksetzen des Speichers für den Integritätsdienst

 $all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}

Betrachten Sie den Code in Abbildung 12. Nach dem Deklarieren einer Variablen wird eine Liste aller Agents auf diesem Stammverwaltungsserver abgerufen und nach den Agents gefiltert, bei denen anscheinend ein Problem vorliegt. Dann wird asynchron eine Aufgabe aufgerufen, die den Speicher für den Integritätsdienst für alle Agents in der gefilterten Liste zurücksetzt.

Zuordnen von Warnungen zu Management Packs In wird Abbildung 13 gezeigt, wie eine Liste aller neuen Warnungen sowie das Management Pack, dem die einzelnen Warnungen zugeordnet sind, abgerufen werden.

Der Code erforderte einige Tricks, um sicherzustellen, dass alle Management Pack-Namen aufgelöst werden konnten. Die verwendeten Cmdlets variieren in Abhängigkeit davon, ob die Warnung von einer Regel oder einer Überwachung stammt. (Beachten Sie, dass in Abbildung 13 eine kleine Problemumgehung für das Cmdlet „Get-Monitor“ implementiert werden musste. Ab OpsMgr SP1 unterstützt das Cmdlet jetzt einen neuen ID-Parameter, der den Code etwas vereinfachen würde.)

Abbildung 13 Suchen des Management Packs

Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }  
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}

Einfache Berichterstattung Wenn Sie Ihre Umgebung aktualisieren, kann es nützlich sein, die Versionen aller installierten Agents zu überprüfen. Sie benötigen nur ein einfaches Skript, um einen übersichtlichen Bericht auszugeben:

Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}

In Abbildung 14 wird die die Ausgabe des Skripts gezeigt. Dieses Skript ist eine erweiterte Version der Beispiele unter systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.

Abbildung 14 Ausgabe, die die Versionen bestimmter Agents zeigt (zum Vergrößern auf das Bild klicken)

Planen einer Aufgabe Möglicherweise möchten Sie ein Windows PowerShell-Skript regelmäßig ausführen. Angenommen, Sie verwenden einen Clientcomputer, um eine Verbindung zu Ihrem OpsMgr-Server herzustellen und diesen zu verwalten, und Sie haben die OpsMgr-Verwaltungstools lokal installiert. Sie möchten den Bericht zur Agentversion täglich ausführen und die Ausgabe in einer Datei speichern, wobei das aktuelle Datum als Name der Datei verwendet werden soll. Mithilfe der in Windows integrierten Aufgabenplanung können Sie das Skript von Ihrem lokalen Computer aus ausführen.

Hierzu richten Sie einfach eine neue Aufgabe ein und setzen das Programm auf powershell.exe (in der Regel im Verzeichnis „C:\Windows\System32\WindowsPowerShell\v1.0“ gespeichert). Nachdem Sie die Aufgabe erstellt haben, bearbeiten Sie sie und legen den auszuführenden Befehl in etwa wie folgt fest:

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe 
  –Command "& {& 'c:\agent_report2.ps1'}"

Es stellte sich heraus, dass an dem ursprünglichen Windows PowerShell-Code relativ viele Änderungen vorgenommen werden mussten, wie Sie in Abbildung 15 sehen können. Das PowerShell-Snap-In für OpsMgr musste hinzugefügt, das dem OperationsManagerMonitoring-Anbieter zugeordnete Monitoring-Laufwerk erstellt und eine Verbindung zum Stammverwaltungsserver hergestellt werden. Zudem wird das benutzerdefinierte Windows PowerShell-Skript für OpsMgr (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) geladen, um OpsMgr-spezifische Funktionen zu laden.

Abbildung 15 Planen der Ausführung des Skripts für den Bericht zur Agentversion

Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file

Das ist jedoch noch nicht alles. Sie stellen vielleicht fest, dass bei jeder Ausführung der Aufgabe ein schwarzes Konsolenfenster auf dem Bildschirm angezeigt wird, wenn ein Benutzer bei dem System angemeldet ist, auf dem das Skript ausgeführt wird. Sie können dies durch einen kleinen Trick vermeiden, der von Don Jones und Jeffery Hicks von Sapien unter blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell bereitgestellt wurde.

Im Grunde müssen Sie das Skript mit einem VBScript umschließen. Hierzu verwenden Sie ähnlichen Code wie den in Abbildung 16, statt mit Ihrer geplanten Aufgabe Folgendes aufzurufen:

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"

Abbildung 16 Ausblenden der Popupfenster

Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths 
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34) 

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0

Die Aufgabe verwendet jetzt das Programm „wscript.exe“, und der Aufruf würde in etwa wie folgt aussehen:

C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs 

Sie können nun automatisierte Berichte erstellen, und der Prozess wird vor angemeldeten Benutzern verborgen.

Zusammenfassung

In diesem Artikel wurden kurz die neuen Automatisierungsfeatures vorgestellt, die in OpsMgr 2007 verfügbar sind. Es wurde jedoch nur ein kleiner Teil der Möglichkeiten behandelt, die Ihnen Windows PowerShell für die OpsMgr-Verwaltung bietet.

Ich möchte mich bei allen in diesem Artikel genannten Personen sowie bei Pete Zerger, MVP für MOM und Gründer von SystemCenterForum.org, für ihre wertvolle Hilfe bedanken.

Marco Shaw ist als IT-Systemanalytiker bei einem kanadischen Telekommunikationsunternehmen tätig. Er arbeitet seit mehr als 10 Jahren in der IT-Branche und erhielt vor kurzem die MVP-Auszeichnung für Windows PowerShell. Marco Shaw ist zudem stellvertretender Communityleiter für die neue PowerShell-Communitywebsite unter powershellcommunity.org. Er führt einen Blog unter marcoshaw.blogspot.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.