System Center

Detaillierte Zielwahl in Operations Manager 2007

Steve Rachui

Auf einen Blick:

• Verwenden eines vorhandenen Ziels
• Das Problem mit der Attributermittlung
• Erstellen von Zielen mit der Entwicklerkonsole
• Skriptbasierte Ermittlung

Inhalt

Verwenden eines vorhandenen Ziels
Erstellen von Zielen mit der Entwicklerkonsole
Verwenden eines Registrierungsschlüssels
Registrierungswert
Ermittlung über ein Skript
Weitere Überlegungen

Das Erstellen benutzerdefinierter Überwachungsobjekte (Regeln, Monitore, Gruppen und so weiter) gehört zur normalen Arbeitsroutine von Administratoren von System Center Operations Manager (OpsMgr) 2007. Für jedes erstellte Objekt muss die gleiche Frage beantwortet werden, nämlich die Frage, welches Ziel verwendet werden soll.

Das richtige Ziel für ein Objekt auszuwählen, ist wichtig, aber der richtige Ansatz ist möglicherweise nicht immer klar. OpsMgr bietet verschiedene Optionen für die Zielwahl. In diesem Artikel werden mehrere Optionen erläutert. Das Ziel ist, Administratoren Hilfestellung bei der Auswahl der geeigneten Methode für jedes Szenario zu bieten. Dabei sind die hier verwendeten Begriffe „Klasse“ und „Ziel“ austauschbar.

Angenommen, es liegt eine interne Anwendung namens „Widget“ vor, die überwacht werden soll. Alle Überwachungsspezifikationen wurden definiert, und Sie beginnen mit der Erstellung der Überwachungsobjekte für Widget. Sie stellen jedoch bald fest, dass kein präzises Ziel für Widget vorhanden ist. Entsprechend den bewährten OpsMgr-Methoden müssen alle Regeln, Monitore und so weiter auf das nach Möglichkeit spezifischste Objekt abzielen, um die Verteilung lediglich auf die gewünschten Systeme zu begrenzen. Mit welchen Optionen in OpsMgr können Sie diese bewährte Methode am besten befolgen?

Verwenden eines vorhandenen Ziels

Standardmäßig enthält OpsMgr eine umfangreiche Liste von Zielen, die mit einer zunehmenden Anzahl importierter Management Packs immer länger wird. Wenn Sie ein neues Management Pack-Objekt (MPO) erstellen und Überlegungen über das Ziel anstellen, überprüfen Sie zunächst, ob eines der verfügbaren Elemente als vordefiniertes Ziel angemessen ist. Wenn Sie ein MPO erstellen, um beispielsweise die SMS-Serverüberwachung (System Management Server) zu erweitern, können die vorhandenen Ziele, die zusammen mit dem Standard-SMS-Management Pack importiert werden, wahrscheinlich für das MPO wiederverwendet werden.

Das Verwenden von Standardzielen funktioniert jedoch nicht immer. Wenn die verfügbaren Ziele für das gerade erstellte MPO nicht spezifisch genug sind, können Sie das Problem des fehlenden optimalen Ziels entweder umgehen oder ein neues Ziel erstellen.

Ein allgemeiner Ansatz (der allerdings einige Nachteile aufweist) ist, das neue MPO dem Windows-Client oder der Windows-Serverklasse oder einer anderen geeigneten Basisklasse zuzuordnen, die die erforderlichen Ziele enthält (auch hier gilt, die Klasse so spezifisch wie möglich auszuwählen). Erstellen Sie das MPO dabei unbedingt in einem deaktivierten Zustand. Dann können Sie eine Gruppe erstellen, die alle Systeme enthält, in denen diese MPO ausgeführt werden müssen, und die deaktivierten MPO außer Kraft setzen, damit das MPO nur für die Agents in der Gruppe aktiviert ist. Dies ermöglicht dem MPO, nur auf den Agents bereitgestellt und ausgeführt zu werden, die durch die Außerkraftsetzung zugelassen werden.

Welche Nachteile hat dieser Ansatz? Zum einen zielt diese Methode auf eine umfassendere Klasse von Objekten ab (z. B. „Windows Computer“). Daher werden alle überwachten MPO, die auf diese Weise adressiert werden, unter dem adressierten Objekt im Integritäts-Explorer angezeigt (siehe Abbildung 1).

Abbildung 1 Integritäts-Explorer für Computer, die durch Außerkraftsetzung adressiert werden (zum Vergrößern auf das Bild klicken)

Dies ist eigentlich nur kosmetisch, dürfte also in einer vorhandenen Umgebung kein Problem sein. Doch diese Art der Zielwahl wirkt sich auf den Integritätsstatus des übergeordneten Objekts (z. B. „Windows Computer“) aus, wenn der benutzerdefinierte Monitor beeinträchtigt wird. Wenn die Widget-Anwendung also ein Problem hat, könnte die Integrität des gesamten adressierten Objekts davon betroffen sein. Je nachdem, was überwacht wird, kann dies problematisch sein.

Die Gruppenadressierung von MPOs ist in der Regel kein geeigneter Ansatz in OpsMgr. Weshalb funktioniert sie dann? Beachten Sie, dass in diesen Beispielen Gruppen als Außerkraftsetzungen verwendet werden und nicht das eigentliche Ziel des MPO sind.

Dies mag als rein semantische Unterscheidung erscheinen, aber führen Sie sich einmal die Gruppen in OpsMgr vor Augen. Gruppen sind Objekte, so wie jedes anderes Objekt. Wenn ein Objekt als Ziel ausgewählt wird, bedeutet dies, dass das entsprechende MPO den Agents bereitgestellt wird, die das adressierte Objekt besitzen.

Welcher Agent besitzt also das Gruppenobjekt? Richtig, der Stammverwaltungsserver (Root Management Server, RMS). Die Adressierung einer Gruppe führt dazu, dass MPO dem Agent bereitgestellt werden, der die Gruppe besitzt. Das heißt, MPO werden nur dem Stammverwaltungsserver bereitgestellt. Durch korrektes Adressieren können MPO den richtigen Agents auf einfache Weise bereitgestellt werden, doch durch Deaktivieren eines MPO beenden Sie diesen Prozess, noch bevor er starten konnte.

Wenn eine Außerkraftsetzung eingeführt wird, ändert sich das bereits vorhandene Ziel nicht. Durch eine Außerkraftsetzung wird lediglich für einige Agents pro Gruppenmitgliedschaft der deaktivierte Status in den aktivierten Status geändert. Die Agents, bei denen das MPO aktiviert ist, gehören aber bereits zum ursprünglichen Ziel für das MPO. Verständlicherweise ist dies anfangs etwas verwirrend.

Betrachten Sie jetzt ein Szenario, in dem keiner der oben behandelten Punkte durchführbar ist. Was nun? In diesem Fall gibt es nur noch eine Option: Erstellen Sie ein neues Ziel speziell für MPO. Sie können dies entweder durch Verwenden der Dienstüberwachungsvorlage in der Betriebskonsole oder durch Erstellen eines neuen Ziels in der Entwicklerkonsole vornehmen.

Bevor Sie dies jedoch in Betracht ziehen, sollten Sie sich die Attributermittlung näher ansehen. Sie denken möglicherweise, dass dies eine nützliche Option ist, die übersehen wurde. Im Folgenden wird dies näher erläutert. Es ist möglich, eine Attributermittlung zu erstellen, die Informationen von der Registrierung oder von WMI abruft. Um zu funktionieren, muss die Attributermittlung auf eine Klasse abzielen, die die gewünschten Registrierungs- oder WMI-Einträge enthält. Allgemeine Ziele sind der Windows-Client oder die Windows-Serverklassen oder die generische Windows Computer-Klasse.

Beachten Sie, dass der Begriff Attributermittlung impliziert, was tatsächlich geschieht: Ein neues Attribut wird erkannt und zur Erweiterung einer vorhandenen Klasse verwendet. Dadurch wird zwar eine neue Klasse erstellt, aber es handelt sich eigentlich um die alte Klasse mit den gleichen Mitgliedern, nur mit einem neuen gemeldeten Attribut. Hieraus wird ersichtlich, dass das Erstellen einer neuen Attributermittlung nicht mit dem Erstellen eines wirklich eindeutigen Ziels identisch ist.

Hier ist ein weiteres Beispiel. Angenommen, es wird eine neue Attributermittlung erstellt, um den Registrierungsschlüssel für die Widget-Anwendung zu finden. Diese Ermittlung ist so adressiert, dass sie „Windows Computer“ bereitgestellt wird, damit sie alle Agents enthält, die gegebenenfalls über den Widget-Registrierungsschlüssel verfügen.

Nach dieser Auswahl im Assistenten erhalten Sie eine Warnung, dass die Windows Computer-Klasse nicht erweitert werden kann (sie befindet sich immerhin in einem versiegelten Management Pack. Wenn dies nicht der Fall ist, bleibt die Warnung aus), und es wird zum Fortfahren eine umbenannte Zielklasse zur Auswahl anzeigt (siehe Abbildung 2). Dies geschieht, weil das Ziel der Attributermittlung die Erweiterung der vorhandenen Klasse ist.

Abbildung 2 Die Attributermittlung führt nicht zur Erstellung einer eindeutigen Klasse (zum Vergrößern auf das Bild klicken)

Als Nächstes werden Dienstvorlagen betrachtet, mit denen Sie eindeutige Ziele für Systeme erstellen können, die auf einem installierten Dienst basieren. Die Verwendung von Dienstvorlagen ist äußerst einfach. In Abbildung 3 sehen Sie ein Beispiel.

Abbildung 3 Eine Dienstvorlage

Denken Sie daran, dass die Verwendung der Vorlage dazu führen kann, dass zusätzliche MPO über das beabsichtigte und gewünschte Maß hinaus erstellt werden. Nach dem Verwenden der Dienstvorlage empfiehlt es sich zu prüfen, welche zusätzlichen Objekte erstellt wurden, und zu entscheiden, ob sie beibehalten werden sollen (siehe Abbildung 4).

Abbildung 4 Beim Verwenden einer Vorlage erstellte Objekte (zum Vergrößern auf das Bild klicken)

Außerdem werden durch Dienstvorlagen eine Ermittlung und eine neue Klasse für jeden neuen Dienst erstellt. Es kann sein, dass dies genau Ihren Vorstellungen entspricht oder aber zu präzise ist. Nehmen Sie z. B. an, dass Ihre benutzerdefinierte Anwendung über mehrere Dienste verfügt. In diesem Fall würde für jeden Dienst eine neue Klasse und ein neuer Dienstmonitor erstellt. Es ist wahrscheinlicher, dass der gewünschte Überwachungsansatz eine einzige Klasse vorsieht, wobei jeder Dienstmonitor nur auf diese Klasse abzielt.

Wenn Sie keine Dienstvorlage verwenden können oder wollen, bleibt nur noch die Option, die Entwicklerkonsole zu verwenden. Ein Blick auf die Dokumentation der Entwicklerkonsole zeigt, dass die richtige Verwendung dieses Features eingehend erläutert werden muss, was im Rahmen dieses Artikels nicht möglich ist.

Dennoch sind einige einfache Beispiele angebracht, bei denen die Entwicklerkonsole verwendet wird, um ein neues Ziel in OpsMgr zu erstellen und aufzufüllen. Es folgen zwei Beispiele, bei denen das Konzept in Betracht gezogen wird, einen Registrierungseintrag für die eindeutige Identifikation der Widget-Anwendung zu verwenden, und ein drittes Beispiel, das die Ermittlung durch ein Skript veranschaulicht.

Erstellen von Zielen mit der Entwicklerkonsole

In vielen Fällen ist es möglich, die Registrierung auf einen bestimmten Wert oder Schlüssel zu überprüfen, durch den die entsprechenden Server, die das gewünschte Ziel hosten, eindeutig identifiziert werden. Wenn eine Klasse (ein Ziel) erstellt werden und mit Systemen aufgefüllt werden könnte, bei denen der Widget-Registrierungsschlüssel vorhanden ist, wäre das eine einfache Möglichkeit zum Erstellen eines eindeutigen Ziels.

Beim ersten Beispiel wird in den entsprechenden Schritten hierzu einfach die Existenz eines Registrierungsschlüssels festgestellt. Beim zweiten Beispiel wird nach einem bestimmten Wert gesucht, der dem Registrierungsschlüssel zugeordnet ist. Beachten Sie, dass Sie zwar eine Regel für die Registrierungsattributermittlung (wie oben besprochen) und eine Ermittlung in der Entwicklerkonsole erstellen können, wie in den folgenden Beispielen beschrieben, doch die beiden Beispiele führen nicht zum gleichen Ergebnis. Im ersten Beispiel wird einfach eine vorhandene Klasse erweitert, während im zweiten Beispiel tatsächlich ein neues Ziel erstellt wird.

Verwenden eines Registrierungsschlüssels

Beim ersten Start der Entwicklerkonsole müssen Sie auswählen, ob ein vorhandenes Management Pack geladen oder ein neues erstellt werden soll. Wenn Sie die Option zum Erstellen eines neuen Management Packs auswählen, wird ein Assistent angezeigt, in dem Sie eine Vorlage entweder für ein leeres Management Pack oder für ein Management Pack für eine Windows-Anwendung (Registrierung) auswählen können (siehe Abbildung 5).

Abbildung 5 Auswahl einer Vorlage für ein neues Management Pack (zum Vergrößern auf das Bild klicken)

Mit beiden Optionen werden die gleichen Ergebnisse erzielt, es ist aber denkbar einfach, eine neue Klasse zu erstellen, bei der die Vorlage „Windows-Anwendung (Registrierung)“ verwendet wird. Sie müssen einfach einen Namen bereitstellen und dann die Registrierungsvorlage auswählen. Als Nächstes geben Sie den Namen und die Beschreibung für das Management Pack im Bildschirm „Name und Beschreibung“ an. Hier müssen Sie den Wert angeben, der unter dem Management Pack-Knoten der Operations Manager-Benutzeroberfläche angezeigt wird.

Geben Sie dann eine Beschreibung der Anwendung im Bildschirm „Windows-Anwendung“ an. Der hier eingegebene Wert ist der Wert, der im Knoten „Attribute“ der Operations Manager-Benutzeroberfläche angezeigt wird. Konfigurieren Sie anschließend, wie oft die Ermittlung ausgeführt werden soll. Der Standardwert ist alle 15 Sekunden, was wahrscheinlich viel zu häufig ist. Wägen Sie den Vorteil einer schnellen Ermittlung gegen die Leistungsauswirkungen ab, die bei zu häufiger Ermittlung auftreten könnten. Im Allgemeinen gibt es keinen zwingenden Grund, um eine Ermittlung öfter als ein Mal pro Tag ausführen.

Geben Sie jetzt die Details an, die für die Suche des gewünschten Registrierungsschlüssels/-werts erforderlich sind. Es sind mehrere Attributtypen verfügbar. Wenn Sie einfach die Existenz eines Schlüssels prüfen wollen, verwenden Sie den Bool-Typ.

Erstellen Sie abschließend den Abfrageausdruck. Dies scheint vielleicht wie doppelte Arbeit, denn wurde nicht eben erst der Abfrageausdruck erstellt? Die Antwort lautet nein. Im Bildschirm „Registrierungstestkonfiguration“ wird der zu betrachtende Registrierungsschlüssel näher definiert. Im Bildschirm für den Expression Filter wird definiert, welcher Wert erwartet wird.

Was wurde also nach all diesen Schritten letzten Endes erstellt? Haben Sie das Ziel erreicht, eine neue Klasse zu erstellen? Wählen Sie in der Entwicklerkonsole den Dienstmodellknoten aus, und klicken Sie auf „Klassen“. Sie sehen, dass eine neue Klasse erstellt wurde. Untersuchen Sie die Eigenschaften, um diese neue Klasse besser zu verstehen.

Wie sieht es mit der Ermittlungsdefinition aus? Sehen Sie sich die Ermittlungsregel im Integritätsmodell an, und überprüfen Sie auch hier die Eigenschaften, um zu sehen, wie die Regel tatsächlich erstellt wird.

Registrierungswert

Das Erstellen einer Ermittlung, die nach einem Registrierungswert statt einem Registrierungsschlüssel sucht, ist gleichermaßen einfach. Durchlaufen Sie den Assistenten erneut, und ändern Sie dieses Mal die Eingabe, um einen Registrierungswert statt eines Schlüssels abzurufen.

Um den Assistenten nach Abschluss der anfänglichen Vorlage zu initiieren, navigieren Sie zu „Health Model“ | „Discoveries“ (Integritätsmodell | Ermittlungen). Klicken Sie im mittleren Fensterbereich mit der rechten Maustaste, und wählen Sie „Neu“ | „Registry (filtered)“ (Registrierung (gefiltert)) aus. Die Einträge sind identisch mit den vorherigen, doch dieses Mal wird ein Registrierungswert angegeben.

Es ist wirklich ganz einfach. Die neuen Ziele sind jetzt erstellt, und dieses Beispiel ist somit abgeschlossen. Es ist aber noch zusätzliche Arbeit erforderlich, um das Management Pack mit Management Pack-Objekten aufzufüllen. MPO können entweder über die Operations Manager-Benutzeroberfläche oder direkt in der Entwicklerkonsole erstellt werden. Beide Möglichkeiten funktionieren gut.

Sie müssen jedoch Folgendes bedenken: Wenn Sie ein in der Betriebskonsole erstelltes MPO in der Entwicklerkonsole öffnen, hat es nicht den ursprünglichen von Ihnen angegebenen Namen. Stattdessen wird der Name durch eine Zeichenfolge ersetzt, die mit „UIGenerated“ beginnt. Dies wirkt sich zwar in keiner Weise auf die Funktion des MPO aus, kann aber sehr frustrierend sein, wenn Sie ein bestimmtes MPO in der Entwicklerkonsole suchen.

Unabhängig davon, für welche Methode Sie sich entscheiden, es wird eine neue Klasse erstellt, die für die Bereitstellung von Regeln verwendet werden kann. Wie erkennen Sie, ob diese neue Klasse und die Ermittlung funktionieren? Sie können sich die ermittelten Inventarinformationen für die neue Klasse ansehen, und die neue Klasse wird außerdem als gültiges Ziel für einen neuen Monitor angezeigt (siehe Abbildung 6).

Abbildung 6 Die neue Klasse ist ein gültiges Ziel für einen Monitor (zum Vergrößern auf das Bild klicken)

Ermittlung über ein Skript

Um eine skriptbasierte Ermittlung in einem vorhandenen Management Pack zu erstellen, laden Sie das Management Pack in die Entwicklerkonsole. Wenn Sie ganz von vorn beginnen, öffnen Sie die Entwicklerkonsole, und wählen Sie ein neues Management Pack aus.

Da es sich hierbei um eine skriptbasierte Ermittlung handelt, besteht die einzige anwendbare Option darin, ein leeres Management Pack zu erstellen. Der erste Schritt in diesem Prozess besteht darin, die Klasse zu definieren, die zusammen mit den gewünschten Klasseneigenschaften (Attributen) mit dem Skript aufgefüllt wird. FileName, FileDirectory und FileDescription sind von dieser Klasse definierte verfügbare Eigenschaften, die im Skript geändert werden können. Mehr dazu später.

Außerdem wird die DisplayName-Eigenschaft von der System.Entity-Klasse geerbt und kann ebenfalls durch ein Skript geändert werden. Beachten Sie, dass nur in dieser Liste aufgeführte Attribute mit dem Ermittlungsskript geändert werden können. Stellen Sie daher sicher, dass alle gewünschten Elemente hier angezeigt werden. Beachten Sie weiterhin, dass bei der Auswahl einer Eigenschaft (eines Attributs) Details über die Eigenschaft rechts angezeigt werden. Füllen Sie unbedingt den Anzeigenamen für alle Eigenschaften (Attribute) aus. Wenn Sie keine Einträge vornehmen, werden die Ermittlungsinformationen zwar zurückgegeben, doch die Spaltenüberschriften in der OpsMgr-Umgebung, z. B. in der Ansicht „Ermitteltes Inventar“, bleiben leer.

Nach der Definition der Klasse können Sie die skriptbasierte Ermittlung erstellen. Navigieren Sie zu „Health Model“ | „Discoveries“ (Integritätsmodell | Ermittlungen). Klicken Sie mit der rechten Maustaste auf „Neu“ | „Skript“, und erstellen Sie die Ermittlung. Hier finden sich sehr viele Informationen. Erstens ermöglicht die Registerkarte „Allgemein“ die Benennung der Ermittlung und das Bereitstellen eines Ziels, für das die Ermittlung ausgeführt werden soll. Denken Sie daran, beim Definieren des Ziels so spezifisch wie möglich zu sein.

Für die in diesem Artikel verfolgten Zwecke ist „Windows Computer“ angemessen. Konfigurieren Sie auf der Registerkarte „Ermittelte Typen“ die Art des Objekts, die ermittelt werden soll. Beachten Sie, dass der Name des hier ermittelten Typs dem Klassennamen entspricht, der zuvor definiert wurde.

Als Nächstes folgt die Registerkarte „Konfiguration“, auf der die Informationen angezeigt werden, die bei Skriptdefinition automatisch generiert werden. (Wählen Sie „Konfigurieren“ aus, um das Skript und den Zeitpunkt anzuzeigen, der für die Ausführung des Skripts festgelegt wurde.) Beachten Sie außerdem das Feld „Parameter“ (auf das Sie über „Konfigurieren“ | „Skript“ | „Parameter“ zugreifen können). Sehen Sie sich die aufgelisteten Parameter an. Diese werden später in diesem Artikel erläutert.

Das Skript, das den Prozess der Ermittlungssammlung und die Weitergabe der Ergebnisse an OpsMgr steuert, ist in Abbildung 7 dargestellt. Es ist ein äußerst einfaches Skript, stellt aber das Framework für die Hauptelemente bereit, die für eine skriptbasierte Ermittlung erforderlich sind.

Abbildung 7 Ermittlungsskript

Option Explicit
Dim oArgs
Set oArgs = WScript.Arguments

Dim oAPI

  'All of the work to submit discovery data is done in the context of
  'API's defined in the OpsMgr 2007 SDK.  Creating the oAPI object allows
  'access to the OpsMgr 2007 scripting environment
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim SourceId, ManagedEntityId, targetComputer

  ' SourceId is the GUID of the discovery object that runs the script.
SourceId = oArgs(0)

  ' ManagedEntityId is the GUID of the computer class that is targeted by the script.
ManagedEntityId = oArgs(1)

  ' targetComputer is the Fully Qualified Domain Name
  ' of the computer targeted by the script. The FQDN
  ' is in Arg(2) of the command prompt.
targetComputer = oArgs(2)

Dim oFSO, oDiscoveryData, oInst

  'This operation sets the stage for creating new discovery data.  Note that the
  'values passed to the CreateDiscoveryData function are variables that are defined
  'by the command line when executed.  The parameters box was displayed earler.  This
  'is where the command-line parameters required by the CreateDiscoveryData object are 
  'defined and passed to the script.
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

  'This section defines objects needed to access the file system environment
Set oFSO = CreateObject("Scripting.FileSystemObject") 
If (oFSO.FolderExists("C:\WServer")) Then 

    'Assuming a folder called WServer was found on the root of the C drive, the script proceeds to create a new
    'class instance.  Once it's created, a number of property (attribute) values are filled in; note that all 
    'three of the properties (attributes) defined on the class are used in the script along with one property
    '(attribute) from the windows computer class.  Note the difference in how the script refers to properties 
    '(attributes) defined in the local class vs. a class that is accessed by reference.  Also note the Name field
    'as defined in the script.  Here the name is a friendly name that easily maps back to a known class name.  
    ' When the management pack is saved and imported into the Operations Console and the script delivered to the
    ' agents, these name values will no longer be friendly, they will be converted to the appropriate class GUID.  
    'Normally these converted values wouldn't be seen, but if the script directly on the agent is examined, 
    'the difference will be seen. Note that if the script attempts to define/use a property (attribute) 
    'that has not been defined in the referenced class, validation errors will be displayed.
  Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']$")
  Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", targetComputer)
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileName$", "TestFileName.exe")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDirectory$", "TestFileDirectory")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDescription$", "TestFileDescription.exe")

    'Class Instance has now been created so the AddInstance method of the CreateDiscoveryData class is used to add
    'the completed instance.  From there the script returns the discovery data to OpsMgr for further processing.
  Call oDiscoveryData.AddInstance(oInst)
  Call oAPI.Return(oDiscoveryData)
End If

Das Importieren dieses Management Packs in OpsMgr führt dazu, dass das richtige System ermittelt wird (siehe Abbildung 8). Beachten Sie, dass jede im Skript definierte Eigenschaft (Attribut) auf der Benutzeroberfläche mit den zugeordneten Werten angezeigt wird.

Abbildung 8 Ermittlung über ein Skript (zum Vergrößern auf das Bild klicken)

Bei näherer Betrachtung des Skripts werden Sie feststellen, dass der Wert für ein ermitteltes Element explizit oder durch eine Variable übergeben werden kann. Bedenken Sie außerdem Folgendes: Wenn wie oben angeführt das Feld „Anzeigename“ für die bestimmte Eigenschaft (Attribut) in der Klasse leer gelassen wird, werden die Spaltenüberschriften FileName, FileDirectory und FileDescription (siehe Abbildung 8) ebenfalls leer gelassen.

Weitere Überlegungen

Behalten Sie den Versionsverlauf im Auge Bei der Arbeit in der Entwicklerkonsole werden im Allgemeinen mehrere Versionen generiert, bevor die Arbeit beendet ist. Achten Sie darauf, dass jede für die Verwendung in OpsMgr vorgesehene Version mit einer aufsteigenden Versionsnummer gespeichert wird.

Auf die Versionsnummer greifen Sie in der Entwicklerkonsole durch Auswählen von „Datei“ | „Management Pack-Eigenschaften“ zu. Falls die Versionsnummer nicht erhöht wird, hat dies möglicherweise den Import eines neuen Management Packs mit derselben Versionsnummer wie ein bereits vorhandenes Management-Pack zur Folge. Dies kann während des Imports Verwirrung stiften.

Versiegelt oder nicht versiegelt? Wenn die Erstellung des Management Pack abgeschlossen ist, müssen Sie entscheiden, ob es für Produktionszwecke versiegelt werden soll oder nicht. Es hat Vorteile, das Management Pack nicht zu versiegeln, z. B. die Möglichkeit, Außerkraftsetzungen im Management Pack direkt zu speichern. Es gibt aber zwingendere Gründe, ein benutzerdefiniertes Management Pack vor der Einführung in die Produktionsumgebung zu versiegeln:

• Ein benutzerdefiniertes Management Pack für die Verwendung in der Produktion zu versiegeln, ist eine bewährte Methode.
• Das Versiegeln ermöglicht eine strengere Versions- und Änderungskontrolle.
• Es ermöglicht die Verwendung der gleichen Betriebsverfahren für benutzerdefinierte sowie kommerzielle Management Packs. Die Tatsache, dass verschiedene Verfahren erforderlich sind, z. B. beim Speichern von Außerkraftsetzungen für benutzerdefinierte im Vergleich zu kommerziellen Management Packs, sorgt für Verwirrung.
• Klassen, die in einem nicht versiegelten Management Pack erstellt werden, sind nur für andere MPO sichtbar und können nur von anderen MPO verwendet werden, die im selben Management Pack gespeichert sind. Das Versiegeln ermöglicht eine Verwendung von Objekten, unabhängig davon, wo das MPO gespeichert ist.
• OpsMgr-Administratoren haben die Möglichkeit, eine Bibliothek nicht versiegelter „Quell“-Management Packs zu verwalten, um zufällige oder unbeabsichtigte Änderungen zu verhindern.

Für die erfolgreiche Anwendung von OpsMgr ist ein gutes Verständnis des Konzepts von Zielen sehr wichtig. Ein Poster namens „Bewährte Methoden für die Adressierung von Regeln und Monitoren“ ist im PDF-Format unter go.microsoft.com/fwlink/?LinkId=125048 verfügbar. Sie werden feststellen, dass dies eine sehr hilfreiche Referenz für das Verständnis der verschiedenen Ziele und deren geeignete Verwendung ist.

Steve Rachui ist Dedicated Support Engineer in der Gruppe „Premier Field Engineering“ bei Microsoft. Er hat an der Unterstützung von SMS ab Version 1.2 und von MOM ab Version 2000 mitgewirkt. Steve Rachui kann unter steverac@microsoft.com erreicht werden.