Granular Targeting in Operations Manager (OpsMgr) 2007

[アーティクル]
08/25/2016

System Center

Operations Manager 2007 で細かくターゲットを指定する

Steve Rachui

概要 :

既存のターゲットを使用する
属性の検出での問題
作成用コンソールを使ってターゲットを作成する
スクリプトベースの検出

カスタム監視オブジェクト (ルール、モニタ、グループなど) を作成することは、System Center Operations Manager (OpsMgr) 2007 の多くの管理者が日常標準的に行っている作業の一部です。どのようなオブジェクトを作成する場合でも、そのオブジェクトの使用対象となるターゲットを決めておかなければなりません。

オブジェクトにとって正しいターゲットを選択することは重要ですが、必ずしも適切なアプローチが明確になっているわけではありません。OpsMgr では、ターゲットの指定に関して多くのオプションが用意されています。この記事では、いくつかシナリオを用意し、管理者がターゲットの選択に適切な方法を選択できるようにシナリオごとに目標を示します。ここでは、"クラス" と "ターゲット" という用語は同じ意味で使用されます。

まず、監視する必要があるウィジェットという内部アプリケーションがあるとしましょう。監視の指定がすべて定義され、ウィジェット用の監視オブジェクトの作成作業を開始しました。しかし、ウィジェットには正確なターゲットが存在しないことにすぐに気づきます。OpsMgr のベストプラクティスによると、目的のシステムのみに配布の範囲を限定する場合、すべてのルール、モニタなどは、できる限り具体的なオブジェクトをターゲットに指定する必要があります。では、このベストプラクティスを満たすには、OpsMgr のどのオプションが有効でしょうか。

既存のターゲットを使用する

OpsMgr には既定でターゲットの長いリストが含まれていて、管理パックをインポートするにつれてこのリストが拡張されていきます。新しい管理パックオブジェクト (MPO) を作成し、ターゲットを検討するときは、まず、既存のターゲットの 1 つで十分目的を果たせるかどうかを確認するために、使用可能な項目を調査します。たとえば、System Management Server (SMS) サーバーの監視を拡張するために MPO を作成する場合、SMS サーバーの既定の管理パックと共にインポートされる既存のターゲットを、作成している MPO に再利用できる可能性があります。

ただし、既定のターゲットを使用しても常に機能するわけではありません。作成している MPO にとって使用可能なターゲットが十分目的を果たさない場合は、最適なターゲットに不足している部分に回避策を適用するか、新しいターゲットを作成することができます。

(いくつか欠点はありますが) 一般的なアプローチの 1 つは、新しい MPO を、Windows クライアントクラスか Windows サーバークラス、または必要なターゲットを含む適切な基本クラス (できる限り具体的なクラス) に関連付けることです。この関連付けを行うときは、MPO を無効状態で作成するようにします。次に、これらの MPO を実行する必要のあるすべてのシステムを含むグループを作成し、無効状態の MPO を上書きできます。その結果、グループ内のエージェントのみを対象に MPO を有効にできます。この方法により、上書きで許可されたエージェントだけに MPO が提供および実行されます。

このアプローチの欠点は何でしょう。まず、この方法を使用すると (Windows コンピュータなど) オブジェクトの広範なクラスがターゲットとなるため、この方法でターゲットに指定された監視対象のすべての MPO が正常性エクスプローラのターゲットオブジェクトに表示されます (図 1 参照)。

図 1 上書きでターゲットに指定されたコンピュータの正常性エクスプローラ (画像をクリックすると拡大表示されます)

これは実に表面的な問題に過ぎないため、特定の環境では問題にならない場合があります。しかし、この方法でターゲットを指定すると、カスタムモニタが影響を受けたときに、親オブジェクト (Windows コンピュータなど) の正常性状態に影響を及ぼすことになります。そのため、ウィジェットアプリケーションに問題があると、ターゲットに指定されたすべてのオブジェクトの正常性状態に影響が及ぶ可能性があります。これは何を監視対象にするかによって、顕著になる場合も、そうでない場合もあります。

一般に、MPO のターゲットとしてグループを指定することは、OpsMgr では適切なアプローチではありません。では、なぜこのような作業を行うのでしょう。この例のグループは上書きとして使用され、MPO の実際のターゲットではないことを忘れないでください。

これは意味論のように思えるかもしれませんが、OpsMgr でのグループについて考えてください。グループは、他のすべてのオブジェクトとまったく同様のオブジェクトの 1 つです。オブジェクトをターゲットとして選択するときは、ターゲットに指定されたオブジェクトを所有するエージェントに対象の MPO を展開することを意味します。

では、どのエージェントがグループオブジェクトを所有するのでしょうか。正解は、ルート管理サーバー (RMS) です。グループをターゲットに指定すると、MPO がそのグループを所有するエージェントに提供されることになります。つまり、MPO は RMS のみに展開されます。MPO が適切にターゲット指定されると、展開される MPO に対してステージが既に適切なエージェントに設定されていますが、MPO を無効にすることによって、そのプロセスは開始できるようになるまで停止されています。

上書きを導入しても、既存のターゲットは依然としてターゲットのままです。上書きは、グループのメンバシップごとに少数のエージェントの無効状態を有効に変更するだけです。ただし、MPO が有効にされるエージェントは、既に MPO の本来のターゲットの一部です。当初はこれは少々の混乱を招くことがわかっています。

ここで、これまで説明してこなかった実行可能なシナリオについて考えてみましょう。何をすればよいのでしょう。残っているオプションは 1 つだけです。つまり、MPO のターゲットを具体的に作成することです。そのためには、オペレーションコンソールでサービス監視テンプレートを使用するか、作成用コンソールで新しいターゲットを作成します。

ただし、このことを検討する前に、属性の検出を作成するとはどういうことかを考えてみましょう。これをこれまで見落としていた実行可能なオプションと考えているかもしれません。では、はじめましょう。レジストリまたは WMI から情報を取得する属性の検出を作成できます。そのためには、対象となるレジストリエントリまたは WMI エントリを含むクラスで属性の検出をターゲットに指定します。一般的なターゲットは、Windows クライアントクラスや Windows サーバークラス、またはさらに汎用の Windows コンピュータクラスです。

属性の検出という用語自体に注意してください。この用語は、実際に行われることを示しています。つまり、新たな属性が検出され、既存のクラスの拡張に使用されます。まさに、結果として新しいクラスが作成されますが、実際には同じメンバを備えた古いクラスと同じものです。ただ、検出された新たな属性を備えているだけです。このことに基づけば、新しい属性の検出を作成することと、真に一意のターゲットを作成することは同じではないことがお分かりでしょう。

例を挙げて説明しましょう。ウィジェット製品のレジストリキーを検索するために新しい属性の検出を作成するとします。この検出は、ウィジェットのレジストリキーを含むすべてのエージェントを含むように、Windows コンピュータに展開されるターゲットに指定されます。

ウィザードでこの選択を行うと、Windows コンピュータクラスは拡張できないという警告が表示され (結局のところ、シールされた管理パックであることを示しています。シールされた管理パックでなければ警告は表示されません)、続行するために使用できる選択肢として名前が変更されたターゲットクラスが表示されます (図 2 参照)。これは、属性の検出の目的が既存のクラスの拡張であるために発生します。

図 2 属性の検出は一意のクラスを作成しない (画像をクリックすると拡大表示されます)

ここで、サービステンプレートを見てみましょう。このテンプレートを使用して、インストール済みのサービスを基に見つけることのできる、システムに対して一意のターゲットを作成できます。サービステンプレートは実に容易に使用できます。図 3 に例を示します。

図 3 サービステンプレート

ただし、テンプレートを使用すると、意図した以上、または希望した以上に多くの MPO が作成される結果となることに注意してください。サービステンプレートを使用後、どのようなオブジェクトが追加で作成されたかチェックおよび確認し、どのオブジェクトを保持するかを判断することをお勧めします (図 4 参照)。

図 4 テンプレートの使用時に作成されたオブジェクト (画像をクリックすると拡大表示されます)

さらに、サービステンプレートでは、すべてのサービスに対し、サービスごとに検出と新しいクラスが作成されます。これがまさに希望していることかもしれません。あるいは、細かすぎるかもしれません。たとえば、カスタムアプリケーションに複数のサービスが含まれているとします。この場合、新しいクラスと新しいサービスモニタがサービスごとに作成されます。多くの場合、希望する監視アプローチは、1 つのクラスを持ち、そのクラスのみをターゲットとするサービスモニタを持つことでしょう。

サービステンプレートを使用できない場合、または使用したくない場合、残っている選択肢は作成用コンソールを使用することだけです。作成用コンソールのドキュメントを一読すると、この機能を正しく使用するには非常に細かい議論が必要であることが示されています。これは、この記事の範囲を超えてしまいます。

そうは言うものの、OpsMgr で新しいターゲットを作成および設定するために作成用コンソールを使用する少数の簡単な例を用意しています。ウィジェットアプリケーションを一意に特定するためにレジストリエントリを使用する 2 つの例と、スクリプトで検出のデモを行う 1 つの例を用意しました。

作成用コンソールを使ってターゲットを作成する

多くの場合、レジストリをスキャンして、目的のターゲットをホストするサーバーを一意に識別する特定の値やキーを検索できます。クラス (ターゲット) を作成し、ウィジェットのレジストリキーが存在するシステムを設定できる場合、これが一意なターゲットを作成する簡単な方法になります。

最初の例では、単純にレジストリキーの存在を探すことでこれを行う方法を示しています。2 つ目の例では、レジストリキーに関連付けられた特定の値を探します。作成用コンソールではレジストリ属性の検出ルール (前述) および検出を作成できますが、両者は同じ結果にはなりません。前者は単純に既存のクラスを拡張するのに対し、後者は実際に新しいターゲットを作成します。

レジストリキーを使用する

作成用コンソールを最初に起動するときに、既存の管理パックを読み込むか、新しい管理パックを作成するかを選択する必要があります。新しい管理パックの作成を選択すると、ウィザードが表示され、空の管理パック用または Windows アプリケーション (レジストリ) 管理パック用のいずれかのテンプレートを選択できます (図 5 参照)。

図 5 新しい管理パック用のテンプレートの選択 (画像をクリックすると拡大表示されます)

どちらのテンプレートを使用しても同じ結果を実現できますが、Windows アプリケーション (レジストリ) テンプレートを使用して新しいクラスを作成する方が簡単です。単純に名前を指定してからレジストリテンプレートを選択してください。次に、[Name and Description](名前と説明) 画面で、管理パックの名前と説明を指定します。ここに入力する値は、Operations Manager UI の管理パックノードの下に表示される値です。

続いて、[Windows Application](Windows アプリケーション) 画面でアプリケーションの説明を指定します。ここに入力する値は、Operations Manager UI の属性ノードの下に表示される値です。次に、検出を実行する頻度を構成します。既定値は 15 秒間隔ですが、あまりに頻繁すぎるかもしれません。迅速な検出の必要性と、検出の頻度が高すぎることで生じるパフォーマンスへの影響とのバランスを取ってください。一般に、1 日に 1 度以上検出を行うことに説得力のある理由はありません。

ここで、目的のレジストリキーまたは値を検索するために必要な詳細を入力します。使用できる属性の種類は複数あります。単にキーの存在を確認する場合は、種類にブールを使用します。

最後に、クエリ式を作成します。これは重複する作業のように見えます。クエリ式を作成するだけではなかったのですか。実際には違います。[レジストリプローブ構成] 画面では、検索するレジストリキーと検索方法を定義します。[Expression Filter](式フィルタ) 画面は、目的の値を定義するために使用します。

さて、ここまですべてを行うと、実際には何が作成されるのでしょう。新しいクラスを作成するという目標は達成されたのでしょうか。作成用コンソールでサービスモデルノードを選択し、クラスをクリックします。新しいクラスが作成されていることに注意してください。この新しいクラスの詳細を把握するために、プロパティを調べます。

検出の定義はどうなっていたでしょう。正常性モデルの下を見て、検出のルールに注意します。ここでプロパティを調べ、実際にルールがどのように作成されているかも確認します。

レジストリ値

レジストリキーではなく、レジストリ値を探す検出の作成も同様に簡単です。ウィザード全体を再度実行しますが、このとき、キーではなくレジストリ値を取り出すように入力を変更します。

初期テンプレートが完成した後にウィザードを起動するには、[Health Model](正常性モデル)、[Discoveries](検出) の順に移動します。中央のペインを右クリックし、[New](新規)、[Registry (filtered)](レジストリ (フィルタ適用)) を選択します。今回レジストリ値を指定している点を除いて、以前と同じ入力を行います。

とても簡単ですね。新しいターゲットが作成されたところで、この例を終了します。しかし、管理パックに MPO を設定するため、さらに追加の作業を実行する必要があることに注意してください。MPO は Operations Manager UI を使用して、または作成用コンソールで直接作成できます。どちらの方法も適切に機能します。

ただし、オペレーションコンソールで作成した MPO を作成用コンソールで開く場合、指定した元の名前ではなくなっていることを思い出してください。指定した名前は、UIGenerated で始まる文字列に置き換えられています。このことは MPO のどのような機能にも影響しませんが、作成用コンソールで特定の MPO を探そうとすると大きなストレスになる可能性があります。

どの方法を選択したとしても、ルールの提供に使用できる新しいクラスが作成されています。この新しいクラスと検出がどのように機能するかわかりますか。新しいクラス用に検出されたインベントリ情報と、新しいクラスが新しいモニタの有効なターゲットとして表示されることを確認できます (図 6 参照)。

図 6 モニタの有効なターゲットとしての新しいクラス (画像をクリックすると拡大表示されます)

スクリプトによる検出

既存の管理パックにスクリプトベースの検出を作成するには、その管理パックを作成用コンソールに読み込みます。最初から作業を行う場合は、作成用コンソールを開き、新しい管理パックの作成を選択します。

スクリプトベースの検出が目的であるため、適用可能な唯一の選択肢は空の管理パックを作成することです。このプロセスの最初の手順では、スクリプトを設定するクラスを、クラスの目的のプロパティ (属性) と共に定義します。このクラスで定義され、スクリプトで操作できる利用可能なプロパティは、FileName、FileDirectory、および FileDescription です。これについては、この後示します。

さらに、DisplayName プロパティが System.Entity クラスから継承されますが、これもスクリプトから操作できます。このリストに表示される属性しか検出スクリプトから操作できないため、目的のすべての項目がここに表示されていることを確認します。また、各プロパティ (属性) を選択するときに、そのプロパティの詳細が右側に表示されます。プロパティ (属性) ごとに Display Name エントリを必ず設定します。これを設定しないと、検出情報は返されますが、[検出された一覧] ビュー内など、OpsMgr 環境内の列見出しが空白になります。

クラスを定義すると、スクリプトベースの検出を作成できます。[Health Model](正常性モデル)、[Discoveries](検出) の順に移動します。表示されるペインを右クリックし、[New](新規)、[Script](スクリプト) の順に選択して、検出を作成します。ここには大量の情報があります。まず、[全般] タブでは検出の名前、検出が返すターゲットを指定できます。ターゲットを定義するときは、できる限り具体的に定義することを忘れないでください。

この記事の目的からは、Windows コンピュータが妥当です。[検出された種類] タブでは、検索されるオブジェクトの種類を構成します。ここでの検出される種類の名前は、以前に定義したクラス名に一致させます。

[構成] タブには、スクリプトを定義するときに自動的に生成される情報が表示されます (スクリプトとスクリプトの実行スケジュールを確認するには [構成] を選択します)。また、[パラメータ] ボックスもあります ([構成]、[スクリプト]、[パラメータ] の順に選択するとこのボックスにアクセスできます)。一覧されるパラメータを確認してください。この後、これらのパラメータを参照します。

検出収集プロセスを実行し、結果を OpsMgr に送信するスクリプトを図 7 に示します。これはごく基本的なスクリプトですが、スクリプトベースの検出が機能するために必要な主要素のフレームワークを提供します。

図 7 検出スクリプト

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

この管理パックを OpsMgr にインポートすると、結果として、図 8 に示すように、適切なシステムが検出されるようになります。スクリプトで定義されたプロパティ (属性) のそれぞれが、関連する値と共に UI に表示されます。

図 8 スクリプトによる検出 (画像をクリックすると拡大表示されます)

スクリプトを見ると、検索された項目の値を明示的または変数を使用して渡せることがわかります。また、上記で説明したように、クラスの特定のプロパティ (属性) の DisplayName フィールドを空白のままにしておくと、列見出し FileName、FileDirectory、および FileDescription (図 8 参照) も同様に空白になることを覚えておいてください。

その他の考慮事項

バージョンの追跡作成用コンソールで作業しているときは、完成するまでに複数のリビジョンを生成することが一般的です。OpsMgr で使用する各リビジョンは、バージョン番号を増やしながら保存するようにしてください。

作成用コンソールでは、[ファイル]、[管理パックのプロパティ] の順に選択すると、バージョン番号にアクセスできます。バージョン番号を増加しないと、新しい管理パックをインポートしたときに、同じバージョン番号を持つ既存の管理パックが上書きされる結果になる場合があります。その結果、インポート中に混乱を生じる可能性があります。

シールされた管理パックとシールされていない管理パック管理パックを完了するときに、運用目的にシールするか、シールされない状態のままにするかを決定する必要があります。管理パックに直接上書きを保存する機能など、管理パックをシールされない状態のままにしておくことには利点があります。しかし、カスタム管理パックを運用環境に導入する前にシールすべき理由の方がより切実でなのです。

運用環境で使用するためにカスタム管理パックをシールすることはベストプラクティスです。
シールすることで、厳密なバージョン管理と厳密な変更管理が可能になります。
シールすることで、カスタム管理パックと商用の管理パックに同じ運用手順を使用できます。カスタム管理パックと商用管理パックに上書きを行うなどの異なる手順を必要とすると、多くの混乱が生じます。
シールされていない管理パックに作成されたクラスは、同じ管理パックに格納された他の MPO からのみ確認と使用が可能です。シールすることにより、MPO が格納されている場所に関係なく、オブジェクトを使用できます。
シールされていない "ソース" 管理パックのライブラリは、不注意による変更や意図しない変更を防ぐために、OpsMgr 管理者の管理下でメンテナンスすることができます。

ターゲットを完全に理解することが、OpsMgr での成功の手段になります。「ルールとモニタのターゲット指定のベストプラクティス」というポスターを go.microsoft.com/fwlink/?LinkId=125048 から .pdf 形式で入手できます。このポスターは、さまざまなターゲットを理解し、そのターゲットを適切に使用する際の優れた参考資料になることがわかります。

Steve Rachui は、Microsoft のプレミアフィールドエンジニアリンググループで専任サポートエンジニアを務めています。彼は、SMS をバージョン 1.2 から、MOM をバージョン 2000 からサポートしています。Steve の連絡先は steverac@microsoft.com (英語のみ) です。

目次

図 7 検出スクリプト

その他のリソース