この記事は、Microsoft Operations Manager (MOM) 2005 でのスクリプト作成に関する 4 部構成のシリーズの第 1 部です。このシリーズの目的は、MOM と Windows Script Host (WSH) のスクリプトを比較し、Windows Script Host のスクリプトにこれまで蓄積された膨大な知識や資料を有効利用できるようにすることです。背景情報や、関連ドキュメントのリファレンスは適宜示されていますが、このシリーズは MOM 2005 の使用経験があり、Windows Script Host で基本的なスクリプトを作成できる読者を対象にしています。 この 4 部シリーズの各記事の概要を以下に示します。
トピック
MOM スクリプトはどこにあるのか皆さんは既に MOM を使っているため、MOM がリモート コンピュータ上でスクリプトを実行する優れたツールであることがおわかりだと思います。MOM は実際に、スクリプトの自動保存、リモート コンピュータへの送信、ターゲット コンピュータでのローカル起動、結果の返送を行います。スクリプトは、定期的な起動、特定のイベントに応じた起動、またはタスクを使用して随時起動することが可能です。すばらしいではありませんか。この最初の興奮がおさまると、MOM に接続するためのサンプル スクリプトがないか見て回ることになります。当然、Windows スクリプトの唯一にして最良の宝庫であるスクリプト センターから探し始めようと思います。 しかし、ちょっと待てよ、ここには MOM に関するスクリプトが存在しないじゃないか、などと思う方もいるでしょう。便利なサンプル スクリプトやユーティリティがあるにもかかわらず、MOM のスクリプトはまったくありません。何があったのでしょう。MOM は忘れられたのでしょうか。それとも、MOM でのスクリプト作成が難しすぎるために専門家である管理パック作成者に任せるためでしょうか。実は、スクリプト センターに MOM スクリプトが存在しないことには理由があるのです。 理由は非常に簡単です。スクリプト センターのほとんどのスクリプトが MOM スクリプトとして使用できるからです。ただし、すべてのスクリプトが MOM に適しているとは限りません。たとえば、Active Directory サイトを作成するスクリプトを MOM から自動で起動したいという要望があるかどうかは疑問ですが、やろうと思えば可能です。MOM で起動するスクリプトの選択は各自の判断にお任せします。重要なことは、スクリプト センターに存在するすべてのスクリプトは MOM で実行できるということです。 しかし、お待ちください。スクリプトをコピーして貼り付ける前に、スクリプトを MOM に直接出力し、すぐにスケジューリングされたイベント ルールで起動できるほど単純ではないということを承知しておいてください。私は嘘をついたのではありません。すべてのスクリプトは MOM で使用できます。最初に若干の変更が必要なだけです。ここが、この記事の重点です。 この記事では、WSH のスクリプト作成方法を知っていることを前提に説明を進めます。ご存知ない場合は、WSH スクリプトの基本を理解してから MOM スクリプトに取り組んでください。それにはスクリプト センターから始めることをお勧めします。ほとんどのトレーニング、ドキュメント、Windows スクリプト作成のサンプルは、Windows Script Host に重点を置いています。このシリーズでは、WSH スクリプトを変更して MOM で使用する方法を説明します。 Windows Script Host と MOM スクリプトWindows でのスクリプトの作成方法を学ぶときは、常に Windows Script Host から始めてください。WSH は柔軟性が高く、Active Directory Service Interfaces (ADSI) や Windows Management Instrumentation (WMI) などの各種の便利なテクノロジを利用してスクリプトをコマンド ラインで実行できます。つまり、WSH がスクリプトと同義であり、唯一のスクリプト環境であることを前提にしています。 WSH と MOM スクリプトとの間にはどのような関係があるのでしょうか。MOM から WSH を呼び出してスクリプトを実行するのでしょうか。MOM で WSH 環境全体を複製して同様の機能を実行するのでしょうか。WSH と MOM スクリプトにはどのような共通点があるのでしょうか。同一の言語を使用できるのでしょうか。VBScript や JScript は使用できると考えられますが、PerlScript など他の言語は使用できるのでしょうか。それから、これは根本的な質問ですが、WSH スクリプトを MOM で使用するためには変更が必要でしょうか。必要であるとすれば、どのような変更をするのでしょうか。このように、多くの質問があるようですので、これらのさまざまな質問に答えていきます。 WSH は、Windows に含まれているスクリプト コンポーネントを利用したモジュール化アーキテクチャに基づいています。スクリプトの実行に関連するコンポーネントが複数存在するため、"Windows Script Host" という用語の意味が混同されやすい場合があります。これらのコンポーネントのすべてを総称して WSH と呼ぶ場合もあります。個々のコンポーネントを逐一示すことは重要でないため、この記事では実際の実行可能ファイル wscript.exe と cscript.exe のみを WSH と呼ぶことにします。その他のコンポーネントは別のスクリプト環境間で共有されます。これを簡単に示したものが図 1 です。 ![]() 図 1: スクリプト環境 WSH と MOM はスクリプト環境です。どちらのスクリプトも Windows の同一スクリプト サービスで動作します。どちらも VBScript、JScript、またはスクリプトを実行するコンピュータ上にロードされているその他のスクリプト言語で作成されたスクリプトを実行可能です。WSH と MOM の機能が類似しているのは、同一のオブジェクトを使用し、これらのオブジェクトが大部分の機能を果たしているためです。そのため、ほぼ同一のスクリプトを変更なしで実行することが可能です。あくまでも、ほぼ同一の、です。 WScript オブジェクトを使用する前に生成する必要がないということを奇妙に感じたことはないでしょうか。スクリプトではオブジェクトを使用する前に、CreateObject または GetObject で生成する必要がありますが、WScript は何もしなくても存在するように見えます。次の単純なスクリプトを検討してみましょう。 WScript.Echo "Hello world." このスクリプトは実用性はありませんが、Windows Script Host で起動すれば機能します。CreateObject が存在しなくても、WScript オブジェクトは使用可能です。これは、WSH で WScript オブジェクトが自動生成されてスクリプト ホストの機能を果たし、WSH スクリプト固有のコア機能が提供されるためです。他のスクリプト環境で WScript オブジェクトにアクセスすることはできませんが、類似の機能が提供される場合があります。 図 2 をよく見てください。この図は、MOM スクリプトおよび WSH スクリプトが多くの共通オブジェクトにアクセス可能であることを示しています (この図のオブジェクト一覧にすべてが含まれているわけではありません。この一覧は、よく使われるスクリプト可能オブジェクトの一部を示すことを目的としています)。これらのオブジェクトには、ADSI や WMI などのおなじみのスクリプト可能オブジェクトがあります。相違点は、MOM スクリプトでは WScript オブジェクトを使用できないということです。また、WSH では ScriptContext オブジェクトは使用できません。このオブジェクトは MOM 環境のみで使用可能です (詳細は後述)。 ![]() 図 2: MOM および WSH で使用可能なオブジェクト 注目すべき点を 1 つ挙げると、WScript を MOM で使用することはできませんが、WScript で作成したオブジェクトを MOM で使用することは可能です。スクリプトで CreateObject コマンドまたは GetObject コマンドを使って生成したオブジェクトは、そのまま使用可能です。たとえば、WScript.Shell や WScript.Network などがあります。これらのオブジェクトはスクリプト ホストのロジックの一部と見なされますが、WScript オブジェクトから切り離して、MOM などの Windows スクリプト環境で使用することが可能です。 少し紛らわしいかもしれませんが、基本ルールに立ち返ってみましょう。CreateObject または GetObject で生成しなくてもスクリプトで使用できるオブジェクトは、1 つのスクリプト環境でのみ使用可能です。CreateObject または GetObject で生成したオブジェクトは、Windows スクリプト テクノロジを利用している任意のスクリプト環境で使用可能です。 そのため技法としては、WSH スクリプトの変更は、WScript オブジェクトの使用を削除するだけで済むはずです。ご承知のとおり、スクリプト センターでよく使われる WScript.Echo コマンドは使用できません。また、WScript.Arguments を実行しても引数は返されず、WScript.ScriptName を実行してもスクリプト名は取得できません。 ScriptContext の登場多くのことが行えなくなってしまいました。私たちがよく使った WScript は MOM では何の効果もありません。そこで、新しく WScript に取って代わる、ScriptContext を使用します。ScriptContext を使わない MOM スクリプトは存在しないと言っても過言ではないので、ScriptContext の機能を理解することはきわめて重要です。 ScriptContext は WScript に相当する機能であると考えればわかりやすいかもしれません。両者には共通するメソッドもありますので、安心してください。ScriptContext の主な機能は WScript と同様です。それは、MOM スクリプト環境へのアクセスと MOM 固有の機能を提供することです。MOM スクリプトは、画面でユーザーとの対話によって実行するのではなく、通常はリモート コンピュータ上で (スケジューリングやイベント トリガなどにより) 自動実行されます。一度に複数のコンピュータで実行可能です。MOM スクリプトは単純に画面に出力することはできず、MOM ワークフロー エンジンを介して出力を送信する必要があります。ScriptContext にはそのためのメソッドがあります。 表 1 に、ScriptContext と WScript の一般的なメソッドおよびプロパティの比較を示します。この表に記載されているのは一部のメソッドとプロパティのみです。ScriptContext の完全なドキュメントについては、「MOM 2005 Software Development Kit」(英語) を参照してください。一覧の内容は、2 つのオブジェクトの相違点と類似点を示すことを主眼に置いて選択しています。 表 1. ScriptContext と WScript のメソッドおよびプロパティの比較
この表で重要な点は、各オブジェクトに固有のプロパティやメソッドと、相当するプロパティやメソッドとの比較です。相当するプロパティが ScriptContext に存在しない WScript のプロパティは MOM では使用しないため、通常はこれらのプロパティへの参照を削除してもかまいません。Sleep と Quit は相当するプロパティなので、単純に置き換えることができます。ScriptContext.Parameters を使ってパラメータを操作する方法については、このシリーズの第 2 部を参照してください。次に Echo について説明します。 WScript.Echo を置換するWScript オブジェクトで特によく使われるメソッドは WScript.Echo です。画面に情報を返すこのメソッドは、スクリプト センターのほぼすべてのスクリプトで使用されます。 MOM にも ScriptContext.Echo がありますが、このメソッドは主にデバッグ用であり、MOM スクリプトでデータを取得する方法として一般的ではありません。ScriptContext.Echo については後述します。まずは、WScript.Echo ステートメントを置換する最も一般的な方法を説明します。 通常、MOM スクリプトは人手を介さずに、一定のイベント ルールに応答して起動するのを覚えているでしょうか。出力を送信するコマンド ラインがあっても、その内容を見ているユーザーがいません。代わりに、スクリプトでイベントまたはパフォーマンス データを作成する必要があります。各オプションを個別に検討していきましょう。 イベントを作成するMOM イベントの作成には ScriptContext.CreateEvent メソッドを使います。必要な操作は、Event オブジェクトの主なプロパティをいくつか設定して MOM に送信するだけです。値を設定しなかったプロパティには既定値が設定されます。この処理には数行記述する必要があり、単純な WScript.Echo より若干複雑です。参考までに、イベントを作成するサブルーチンの例を示します。サブルーチンに関する知識がない場合は、「Windows 2000 Scripting Guide」(英語) で概要を参照できます。ここでは、値をサブルーチンに渡します。処理は少し複雑になりますが、詳細はこのガイドを参照してください。 サブルーチンを使用する理由は、皆さんがスクリプトでイベントを生成し、各イベントで 1 つのコマンドを発行する場合に、貼り付けるだけで使えるからです。サブルーチンの動作を知らなくても、効果的に使うことができます。 さあ、どうぞ。お役に立てればさいわいです。サブルーチンの詳細には触れません。皆さんが既にロードしているかもしれない管理パックの MOM スクリプトにも同様のルーチンがきっと見つかります。
Sub CreateEvent(intEventNumber,intEventType,strEventSource,strEventMessage)
Set objEvent = ScriptContext.CreateEvent()
objEvent.EventNumber = intEventNumber
objEvent.EventType = intEventType
objEvent.EventSource = strEventSource
objEvent.Message = strEventMessage
ScriptContext.Submit objEvent
End Sub
サブルーチンの 1 行目では新しい Event オブジェクトを生成し、オブジェクト変数に割り当てています。次に、Event オブジェクトの各種プロパティに値を割り当て、最後に ScriptContext.Submit で MOM ワークフローに送信します。 Event オブジェクトに設定可能なプロパティは他にもありますが、ここでは特に一般的なプロパティのみを設定しました。多くの場合、スクリプトの作成には、これらのプロパティだけで十分です。その他のプロパティを使用する場合は、「MOM 2005 Software Development Kit」(英語) を参照してください。ScriptContext.Submit コマンドの前に、これらの値を設定するだけです。表 2 に、サブルーチンで使用する各プロパティを示します。 表 2. イベントの一般的なプロパティ
CreateEvent サブルーチンを呼び出すには、次の構文でスクリプトに記述します。この行で WScript.Echo を置き換えます。 CreateEvent <EventNumber>,<EventType>,<EventSource>,<Message> 簡単な例から始めましょう。Hello World スクリプトを変更してイベントを送信します。このスクリプトは実用性はなく、概念を示すためのものです。サブルーチンのほか、各種イベント タイプの値を示す定数を追加しています。これらも自由にコピーしてお使いください。
Const EVENT_TYPE_SUCCESS = 0
Const EVENT_TYPE_ERROR = 1
Const EVENT_TYPE_WARNING = 2
Const EVENT_TYPE_INFORMATION = 4
Const EVENT_TYPE_AUDITSUCCESS = 8
Const EVENT_TYPE_AUDITFAILURE = 16
CreateEvent 100,EVENT_TYPE_INFORMATION,"Script Test","Hello world."
Sub CreateEvent(intEventNumber,intEventType,strEventSource,strEventMessage)
Set objEvent = ScriptContext.CreateEvent()
objEvent.EventSource = strEventSource
objEvent.EventNumber = intEventNumber
objEvent.EventType = intEventType
objEvent.Message = strEventMessage
ScriptContext.Submit objEvent
End Sub
やれやれ。1 行のスクリプト コードが 15 行になりました。ただ、定数の定義と CreateEvent サブルーチンはスクリプトにコピーするだけで使えます。ここまでで、有効なコードを 1 行記述しただけです。実際悪くないでしょう。 このスクリプトは、イベント番号 100、ソース "Script Test" を指定し、メッセージに 1 行のテキスト "Hello world." を指定して Information イベントを発行します。 このサブルーチンを使用して、実用性のあるスクリプトを作成してみましょう。ここでは「リモート コンピュータが使用可能かどうかの調査」で提供されているスクリプトを使用します。このスクリプトでは、WMI を使用してネットワーク デバイスに ping を発行し、稼動状態を確認します。このスクリプトを使用して、MOM で監視されていないコンピュータまたはデバイスが存在するかどうかを確認することもできます。監視されていないのは、おそらくコンピュータまたは重要なルーターの既定のゲートウェイです。
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colPingedComputers = objWMIService.ExecQuery _
("Select * from Win32_PingStatus Where Address = '192.168.1.37'")
For Each objComputer in colPingedComputers
If objComputer.StatusCode = 0 Then
Wscript.Echo "Remote computer responded."
Else
Wscript.Echo "Remote computer did not respond."
End If
Next
このスクリプトを見ると、WScript.Echo の行が 2 か所あります。このスクリプトを MOM で動くようにするには、CreateEvent サブルーチンを貼り付け、WScript.Echo の行を CreateEvent の呼び出しで置き換える必要があります。このソリューションでは、ping の成功または失敗を示すイベントを生成します。イベント ルールを設定して、これらのイベントをキャプチャし、アラートを生成できるようにします。これらのイベントで成功イベントと失敗イベントを明確に区別するには、各イベント タイプに一意のイベント番号を割り当てる必要があります。 新しいスクリプトは次のようになります。
Const EVENT_TYPE_SUCCESS = 0
Const EVENT_TYPE_ERROR = 1
Const EVENT_TYPE_WARNING = 2
Const EVENT_TYPE_INFORMATION = 4
Const EVENT_TYPE_AUDITSUCCESS = 8
Const EVENT_TYPE_AUDITFAILURE = 16
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colPingedComputers = objWMIService.ExecQuery _
("Select * from Win32_PingStatus Where Address = '192.168.1.37'")
For Each objComputer in colPingedComputers
If objComputer.StatusCode = 0 Then
CreateEvent 100,EVENT_TYPE_SUCCESS,"Ping Check",
"Remote computer responded."
Else
CreateEvent 200,EVENT_TYPE_ERROR,"Ping Check",
"Remote computer did not respond."
End If
Next
Sub CreateEvent(intEventNumber,intEventType,strEventSource,strEventMessage)
Set objEvent = ScriptContext.CreateEvent()
objEvent.EventSource = strEventSource
objEvent.EventNumber = intEventNumber
objEvent.EventType = intEventType
objEvent.Message = strEventMessage
ScriptContext.Submit objEvent
End Sub
CreateEvent ステートメントにイベント コード 100 および 200 があることに注意してください。このスクリプトでは、成功イベントを 100、エラー イベントを 200 とすることに決めました。より複雑なスクリプトでは、201、202 などを他のエラー イベントに割り当てることも考えられます。こうすれば、MOM の多くのイベント ルールと同様に、イベント番号を条件にしたイベント ルールを作成できます。イベント ソースは、イベント ルールの条件に指定できるように "Ping Check" としました。MOM のイベント ルールで最も一般的な条件は、イベント ソースとイベント番号です。これらの値は任意に設定できますが、値の選択は慎重に行う必要があります。 図 3 に、変更したスクリプトで生成されたイベントの例を示します。 イベント ルールと言えば、この例を完成させるためにイベント ルールを作成して、変更したスクリプトで生成されるイベントからアラートを生成してみましょう。通常、アラートはエラー時のみに生成すると思われるので、このスクリプトで成功イベントをキャプチャするイベント ルールを作成する必要はないでしょう。 スクリプトで生成されたすべての MOM イベントには、プロバイダ名 Script-generated Data が割り当てられます。このプロバイダをイベント ルールで使用します。表 3 に、図 3 のエラー イベントからアラートを生成するイベント ルールの属性を示します。 表 3. サンプル イベントをキャプチャするイベント ルールの詳細
このようなイベント ルールを設定し、時間指定のルールによりスクリプトを定期的に起動して、ping テストが失敗した場合に必ずアラートを受信するようにすることが可能です。 パフォーマンス データを作成するイベントの説明が完了したので、次にパフォーマンス データを作成します。前のセクションで作成した CreateEvent サブルーチンに似た CreatePerfData サブルーチンから始めます。CreateEvent サブルーチンと同様に、CreatePerfData も任意のスクリプトに貼り付けて、呼び出すコードを 1 行追加するだけです。
Sub CreatePerfData(strObjectName,strCounterName,strInstanceName,numValue)
Set objPerfData = ScriptContext.CreatePerfData
objPerfData.ObjectName = strObjectName
objPerfData.CounterName =strCounterName
objPerfData.InstanceName = strInstanceName
objPerfData.Value = numValue
ScriptContext.Submit objPerfData
End Sub
このサブルーチンは、新しいパフォーマンス データを作成し、オブジェクトの各種プロパティを設定して、そのオブジェクトを MOM ワークフローに送信します。これらのプロパティは説明しなくても内容がわかりやすいと思いますが、念のために表 4 に定義を示します。 表 4. パフォーマンス データのプロパティ
サブルーチンを呼び出すには、次の構文を使用します。 CreatePerfData <ObjectName>,<CounterName>,<InstanceName>,<Value> MOM の各パフォーマンス データは、Windows の標準カウンタから収集されたパフォーマンス データと同様、オブジェクト名、カウンタ名、インスタンス名で識別されます。Windows NT パフォーマンス カウンタ プロバイダを MOM で作成すると、サーバー上にインストールされた実際のカウンタに制限されます。MOM スクリプトでパフォーマンス データを作成すると、これらの値に任意の名前を定義できます。 この例では、「ファイル プロパティの列挙」で提供されているスクリプトを使用します。元のスクリプトを次に示します。
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.GetFile("c:\windows\system32\scrrun.dll")
Wscript.Echo "Date created: " & objFile.DateCreated
Wscript.Echo "Date last accessed: " & objFile.DateLastAccessed
Wscript.Echo "Date last modified: " & objFile.DateLastModified
Wscript.Echo "Drive: " & objFile.Drive
Wscript.Echo "Name: " & objFile.Name
Wscript.Echo "Parent folder: " & objFile.ParentFolder
Wscript.Echo "Path: " & objFile.Path
Wscript.Echo "Short name: " & objFile.ShortName
Wscript.Echo "Short path: " & objFile.ShortPath
Wscript.Echo "Size: " & objFile.Size
Wscript.Echo "Type: " & objFile.Type
このスクリプトは、指定したファイルのすべてのプロパティを返します。当然ですが、これらの WScript.Echo 行のすべてを削除する必要があります。特定のファイルのサイズをパフォーマンス データとして追跡すると仮定しましょう。このファイルは継続して増大するログ ファイルかもしれません。このファイルのサイズをレポート作成用に追跡し、一定のサイズに達したらアラートが生成されるようにします。必要な情報はサイズだけなので、スクリプトで参照するプロパティを Size のみにします。スクリプトにサブルーチンを貼り付け、WScript.Echo の呼び出しを CreatePerfData の呼び出しに変更するだけです。(サンプル スクリプトでは静的サイズの scrrun.dll を使用しているため、サイズを追跡するファイルも変更しました。)
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.GetFile("c:\logs\AppLog.txt")
CreatePerfData "File","File Size",objFile.Path,objFile.Size
Sub CreatePerfData(strObjectName,strCounterName,strInstanceName,numValue)
Set objPerfData = ScriptContext.CreatePerfData
objPerfData.ObjectName = strObjectName
objPerfData.CounterName =strCounterName
objPerfData.InstanceName = strInstanceName
objPerfData.Value = numValue
ScriptContext.Submit objPerfData
End Sub
ファイルのサイズを追跡するだけなら、これで完了です。スクリプトを実行すると、すぐに MOM にパフォーマンス カウンタが表示されます。パフォーマンス収集ルールは不要です。スクリプトで作成したカウンタのオペレータ コンソールからのスクリーンショットを図 4 に示します。 このカウンタのしきい値ルールを設定し、一定の値を超えたらアラートが発行されるようにするには、表 5 に示すようなしきい値ルールと詳細が必要になります。 表 5. サンプル パフォーマンス データのパフォーマンス ルールの詳細
ScriptContext.Echo前述のように、ScriptContext.Echo は WScript.Echo と同等の機能ですが、WScript.Echo ほど多くは使いません。MOM スクリプトからデータを取得する方法としては、イベントやパフォーマンス データを作成する方が一般的です。ただし、ScriptContext.Echo は 2 つの目的のために役立ちます。それらの目的とは、タスクから実行したスクリプトで情報を取得する場合と、デバッグする場合です。デバッグについてはこのシリーズの第 3 部で説明します。ここではタスクについて説明します。 タスクの出力スクリプトをタスクから実行する場合、ScriptContext.Echo からの出力は、タスクの完了を示す MOM イベントに示されます。これを、MOM の他の場所で使うスクリプトのテストに使用したり、有用なタスクの基礎にすることができます。次に、「プロセス所有権の判別」で提供されているスクリプトについて検討してみましょう。このスクリプトは、コンピュータ上で現在実行中のすべてのプロセスとプロセスの所有者を一覧表示します。
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colProcessList = objWMIService.ExecQuery("Select * from Win32_Process")
For Each objProcess in colProcessList
colProperties = objProcess.GetOwner(strNameOfUser,strUserDomain)
Wscript.Echo "Process " & objProcess.Name & " is owned by " _
& strUserDomain & "\" & strNameOfUser & "."
Next
このスクリプトをタスクで起動し、1 台または複数台のリモート サーバー上で実行中のプロセスを識別することは有効です。このリストをトラブルシューティング シナリオで使用することもできます。スクリプトの WScript.Echo を ScriptContext.Echo に変更するだけで、この機能を実行できます。
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colProcessList = objWMIService.ExecQuery("Select * from Win32_Process")
For Each objProcess in colProcessList
colProperties = objProcess.GetOwner(strNameOfUser,strUserDomain)
ScriptContext.Echo "Process " & objProcess.Name & " is owned by " _
& strUserDomain & "\" & strNameOfUser & "."
Next
このスクリプトをテストするには、スクリプトを実行するタスクを作成し、エージェント コンピュータに対してタスクを起動します。すぐに図 5 のようなイベントが返されます。 まとめWSH スクリプトを変更して MOM で使用できるようにし、スクリプトから取得した情報を MOM ワークフローに送信する方法を説明しました。このシリーズの第 2 部では、情報をスクリプトに取得する方法を説明します。内容には、パラメータの使い方も含まれます。パラメータは WSH スクリプトの引数に相当する機能です。スクリプトを起動するイベント、パフォーマンス データ、またはアラートへのアクセスについても説明します。これは、MOM 独自の概念です。 著者紹介 Brian Wren は Microsoft Consulting Services のインフラストラクチャ コンサルタントを数年にわたって勤め、管理製品および管理テクノロジを専門にしています。
|