JP2005531864A - Ｏｐｃクライアントに対するシステムイベントのフィルタリングおよび通知 - Google Patents

Abstract

イベントの通知をＯＰＣクライアントに提供する、Ｗｉｎｄｏｗｓ（登録商標）環境で動作するシステムが開示される。システムで生成されたＮＴイベントは、フィルタリングされ、ＯＰＣクライアントに提示するためのＯＰＣ形式に変換される。変換されたＮＴイベント通知は、ＮＴイベントを生成したソースの名称を含む。システムは、ユーザ定義のフィルタ基準および変換情報の入力を可能にするフィルタ構成ツールを含む。変換情報は、ソースの名称、イベントの重大度、イベントのタイプ（単純、追跡、および条件）、イベントのカテゴリ、イベントの条件、イベントのサブ条件、およびイベントの属性を含む。

Description

本発明は、一般に、ネットワーク内で接続された複数のコンピューティングノード間におけるシステムイベントの濾過および通知に関し、より詳細には、Ｗｉｎｄｏｗｓ（登録商標） Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）環境で濾過および通知を達成する方法およびデバイスに関する。

本願は、その内容全体を参照により組み込んだ２００２年６月２８日出願の米国仮出願番号６０／３９２，４９６号および２００２年１２月２７日出願の米国仮出願番号６０／４３６，６９５号の特典を請求する。

ウェブベースの企業管理（ＷＢＥＭ：Ｗｅｂ−Ｂａｓｅｄ Ｅｎｔｅｒｐｒｉｓｅ Ｍａｎａｇｅｍｅｎｔ）は、企業のシステムマネージャにその管理の必要性に応じた標準的な低価格の解決策を提供するために、分散マネージメントタスクフォース（ＤＭＴＦ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｍａｎａｇｅｍｅｎｔ Ｔａｓｋ Ｆｏｒｃｅ）によって企画された構想である。ＷＢＥＭ構想は、単純なワークステーション構成から複数のプラットフォームにわたるフルスケール企業管理に至る、多数のタスクを包含する。この構想の要としては、典型的な管理環境に存在するオブジェクトを表すための拡張可能なデータモデルである、共通情報モデル（ＣＩＭ：Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）がある。

ＷＭＩは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）プラットフォーム用のＷＢＥＭ構想の一実施態様である。ＷＭＩ環境に存在するオブジェクトを表すためにＣＩＭを拡張し、管理オブジェクト形式（ＭＯＦ：Ｍａｎａｇｅｄ Ｏｂｊｅｃｔ Ｆｏｒｍａｔ）言語と共通プログラミングインターフェースの両方をサポートするために管理基盤を実施することにより、ＷＭＩは、種々のアプリケーションが様々な企業の構成要素を透過的に管理することを可能にする。

ＷＭＩ基盤は、次に示すコンポーネントを含む。
・実際のＷＭＩソフトウェア（Ｗｉｎｍｇｍｔ．ｅｘｅ）、すなわち管理データへの均等なアクセスをアプリケーションに提供するコンポーネント。

・共通情報モデル（ＣＩＭ）レポジトリ、すなわち管理データの中央記憶域。
ＣＩＭレポジトリは、新しいオブジェクトクラスの定義により拡張される。ＣＩＭレポジトリは、静的に定義されたクラスインスタンスにより、または動的インスタンスプロバイダを介してポピュレートすることができる。

ＯＬＥ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ（商標）（ＯＰＣ（商標））は、工場のフロアデータに対する簡易かつ共通のアクセスをビジネスアプリケーションに提供するように設計された、新進のソフトウェア標準である。従来、それぞれのソフトウェアまたはアプリケーション開発業者には、ハードウェアフィールドデバイスとデータを交換するためのカスタムインターフェースまたはサーバ／ドライバを書き込むことが要求された。ＯＰＣは、上記作業を一度行えば、それ以後はヒューマンマシンインターフェース（ＨＭＩ：Ｈｕｍａｎ Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃｅ）、監視制御データ収集（ＳＣＡＤＡ：Ｓｕｐｅｒｖｉｓｏｒｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｄａｔａ Ａｃｑｕｉｓｉｔｉｏｎ）、制御およびカスタムアプリケーションにより容易に再利用することを可能とする、共通の高性能インターフェースを定義することにより、この必要条件を解消した。

ＯＰＣ仕様は、ＯＰＣ Ｆｏｕｎｄａｔｉｏｎにより維持されており、非専売の技術仕様であり、Ｍｉｃｒｏｓｏｆｔ社製ＯＬＥ／ＣＯＭ技術に基づく一組の標準インターフェースを定義する。コンポーネントオブジェクトモデル（ＣＯＭ：Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）は、分散型制御システム、プログラム可能な論理コントローラ、入出力（Ｉ／Ｏ）システム、およびスマートフィールドデバイスのような、リアルタイム情報のサーバに関する標準オブジェクト、メソッド、およびプロパティの定義を可能にする。さらに、Ｍｉｃｒｏｓｏｆｔ社製ＯＬＥ Ａｕｔｏｍａｔｉｏｎ技術を使用することにより、ＯＰＣはローカルエリアネットワーク、遠隔サイト、またはインターネットを介して工場のフロアデータをオフィスアプリケーションに提供することができる。

ＯＰＣは、エンドユーザとハードウェア／ソフトウェア製造業者の両方に対して、次に示す項目を含む特典を提供する。
・オープン接続性：ユーザは、より適切に最高品位のアプリケーションを利用することを可能にする、より広範囲にわたる工場のフロアデバイスおよびクライアントソフトウェアから選択することができるようになる。

・高性能：「フリースレッディング（ｆｒｅｅ ｔｈｒｅａｄｉｎｇ）」のような最新技術を使用することにより、ＯＰＣは非常に高性能な特性を提供する。
・供給業者の生産性の向上：ＯＰＣがオープンスタンダードであるため、ソフトウェアおよびハードウェアの製造業者は、作業の重複を大幅に解消して、接続性に関する事項をより短時間で処理し、アプリケーションに関する事項により多くの時間を費やせるようになる。

ＯＰＣは、自動化／制御アプリケーション、フィールドデバイス、およびビジネス／オフィスアプリケーションの間における、より高度な相互運用性を促進する。

ＰＣベースの処理制御環境では、処理関連のイベントが重要であるばかりでなく、一部のＷｉｎｄｏｗｓ（登録商標）システムイベントも制御戦略および／または診断において決定的な役割を担う。例えば、ＣＰＵまたはメモリ使用量がある一定の閾値に達したことを示すイベントは、ユーザに対して、システム性能が劣化し始める前に処置を取ることを要求する。しかし、Ｗｉｎｄｏｗｓ（登録商標）システムイベントは、ＯＰＣ標準に準拠しておらず、ＯＰＣクライアントには使用不可能である。本発明は、この問題を解消する機構を提供する。

本発明は、以下の記述から明らかになる多くのさらなる利点も提供する。

本発明の方法は、ＯＰＣクライアントに対するＯＰＣ警報およびイベント（ＯＰＣ−ＡＥ）ならびにＮＴ警報およびイベント（ＮＴ−ＡＥ）の通知に関する。この方法は、ＮＴ−ＡＥのＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知に変換し、そのＯＰＣ−ＡＥ通知をＯＰＣクライアントに提示する。

ＯＰＣクライアントは、例えば、ＮＴ−ＡＥを作成したソースのローカルまたは遠隔にある。ＯＰＣ−ＡＥ通知は、マルチキャストリンクまたはＷＭＩサービスによりＯＰＣクライアントに提示されることが好ましい。

本発明の方法の一実施形態では、ＯＰＣ−ＡＥ通知は、マルチキャストリンクを介して複数のノード間で同期が取られる。
本発明の方法の別の実施形態では、ＮＴ−ＡＥは、フィルタ構成ツールまたはシステムイベントフィルタ・スナップイン（ｓｎａｐ−ｉｎ）により提供されることが好ましい、フィルタ基準に従いフィルタリングされる。

本発明の方法のさらに別の実施形態では、変換するステップは、ＯＰＣ−ＡＥ通知を提供するためにＮＴ−ＡＥ通知に追加情報を付加する。
本発明の方法の上記実施形態の１つの態様では、追加情報は、ＮＴ−ＡＥ通知を作成したソースの名称を含む。これは、ＮＴ−ＡＥ通知を作成したコンピュータ名およびＮＴ−ＡＥの挿入ストリングを含むことが好ましい。挿入ストリングは、例えば、ＮＴ−ＡＥを生成したコンポーネントを特定する。

上記方法の上記実施形態の別の態様では、追加情報は、ＮＴ準拠の重大度であるイベントの重大度を含む。上記変換するステップは、ＮＴ準拠の重大度のＯＰＣ準拠の重大度への変換を提供する。好ましくは、この変換は、ＮＴ−ＡＥの規定の重大度値またはロギングされた重大度値に基づく。

上記方法の上記実施形態のさらに別の態様では、追加情報は、イベントのクッキー、ソースの名称、イベントの重大度、イベントのカテゴリ、イベントのタイプ、イベントの認知可能性、およびイベントの認知状態からなるグループから選択された１つまたは複数の項目を含む。

本発明の方法の上記実施形態では、ＮＴ−ＡＥは、条件イベント、単純イベント、または追跡イベントを含む。条件イベントは、例えば特定ソースの状態を反映する。
本発明のデバイスは、ＮＴ−ＡＥのＮＴ−ＡＥ通知を追加情報にリンクするシステムイベントプロバイダと、ＯＰＣクライアントに提示するためにＮＴ−ＡＥ通知と追加情報をＯＰＣ−ＡＥ通知としてパッケージするシステムイベントサーバとを含む。

ＯＰＣクライアントは、例えば、ＮＴ−ＡＥ通知を作成したソースのローカルまたは遠隔にある。ＯＰＣ−ＡＥ通知は、マルチキャストリンクまたはＷＭＩサービスによりＯＰＣクライアントに提示されることが好ましい。

本発明のデバイスの一実施形態では、ＯＰＣ−ＡＥ通知は、マルチキャストリンクを介して複数のノード間で同期が取られる。
本発明のデバイスの別の実施形態では、ＮＴ−ＡＥ通知は、フィルタ構成ツールまたはシステムイベントフィルタ・スナップインにより提供されることが好ましい、フィルタ基準に従いフィルタリングされる。

本発明のデバイスのさらに別の実施形態では、システムイベントプロバイダは、ＯＰＣ−ＡＥ通知を提供するためにＮＴ−ＡＥ通知に追加情報を付加する。
本発明のデバイスの上記実施形態の１つの態様では、追加情報は、ＮＴ−ＡＥ通知を作成したソースの名称を含む。これは、ＮＴ−ＡＥ通知を作成したコンピュータ名およびＮＴ−ＡＥの挿入ストリングを含むことが好ましい。挿入ストリングは、例えば、ＮＴ−ＡＥを生成したコンポーネントを特定する。

本発明のデバイスの上記実施形態の別の態様では、追加情報は、ＮＴ準拠の重大度であるイベントの重大度を含む。システムイベントプロバイダは、ＮＴ準拠の重大度のＯＰＣ準拠の重大度への変換を提供する。好ましくは、この変換は、ＮＴ−ＡＥの規定の重大度値またはロギングされた重大度値に基づく。

本発明のデバイスの上記実施形態のさらに別の態様では、追加情報は、イベントのクッキー、ソースの名称、イベントの重大度、イベントのカテゴリ、イベントのタイプ、イベントの認知可能性、およびイベントの認知状態からなるグループから選択された１つまたは複数の項目を含む。

本発明のデバイスの上記実施形態では、ＮＴ−ＡＥは、条件イベント、単純イベント、または追跡イベントを含む。条件イベントは、例えば、特定ソースの状態を反映する。
本発明のデバイスのさらに別の実施形態では、ＮＴイベントプロバイダはＮＴ−ＡＥを提供し、フィルタは、フィルタ基準を満たすＮＴ−ＡＥ通知のみがシステムイベントプロバイダによってＯＰＣ−ＡＥにリンクされるように、フィルタ基準に従いＮＴ−ＡＥ通知をフィルタリングする。この実施形態の１つの態様では、ＮＴ−ＡＥの１つまたは複数は、ソースによって生成され、このソースの状態を反映する条件イベントである。システムイベントプロバイダは、このソースの状態の変更により生成された複数の条件イベントのうちの後で発生する１つの条件イベントに合わせて、複数の条件イベントのうちの既に発生している１つの条件イベントの活動状態と非活動状態との間で状態を変更する。システムイベントプロバイダは、既に発生している条件イベントと後で発生する条件イベントのＮＴ−ＡＥ通知を、ＯＰＣクライアントに提示するためにさらにＯＰＣ−ＡＥ通知にリンクする。

本発明の上記方法のさらに別の実施形態では、ＮＴ−ＡＥの１つまたは複数は、ソースによって生成され、このソースの状態を反映する条件イベントである。上記方法は、このソースの状態の変更により生成された複数の条件イベントのうちの後で発生する１つの条件イベントに合わせて、複数の条件イベントのうちの既に発生している１つの条件イベントの活動状態と非活動状態との間で状態をさらに変更する。好ましくは、変換するステップおよび提示するステップは、既に発生している条件イベントと後で発生する条件イベントのＮＴ−ＡＥ通知を、ＯＰＣクライアントに提示するためにＯＰＣ−ＡＥ通知に変換する。

本発明のさらなる方法は、ＯＰＣ−ＡＥ通知に変換するためにＮＴ−ＡＥ通知をフィルタリングするフィルタをポピュレートする。この方法は、その通知がフィルタを通過すべきＮＴ−ＡＥを入力し、入力されたＮＴ−ＡＥを、イベントのタイプ、イベントのソース、イベントの重大度、イベントのカテゴリ、イベントの条件、イベントのサブ条件、およびイベントの属性からなるグループから選択された１つまたは複数のイベント特性により構成する。

本発明の上記さらなる方法の１つの態様によれば、イベントのタイプは、条件、単純、および追跡を含む。
本発明の上記さらなる方法の別の態様によれば、イベントのソースは、特定のＮＴ−ＡＥを作成したコンピュータ名およびその特定のＮＴ−ＡＥの挿入ストリングを含む。

本発明の上記さらなる方法のさらに別の態様によれば、イベントの重大度は、規定の重大度値またはロギングされた重大度値を含む。
本発明の上記さらなる方法のさらに別の態様によれば、イベントのカテゴリは、デバイスの状態を含む。

本発明の上記さらなる方法のさらなる１つの態様によれば、イベントの属性は、特定のイベントのカテゴリに関して、特定のＮＴ−ＡＥの認知可能性および活動状態または非活動状態の状態を含む。

本発明のコンフィギュレータは、ＯＰＣ−ＡＥ通知に変換するためにＮＴ−ＡＥ通知をフィルタリングするフィルタをポピュレートする。このコンフィギュレータは、フィルタを通過すべきＮＴ−ＡＥのフィルタへの入力と、イベントのタイプ、イベントのソース、イベントの重大度、イベントのカテゴリ、イベントの条件、イベントのサブ条件、およびイベントの属性からなるグループから選択された１つまたは複数のイベント特性による、その入力されたＮＴ−ＡＥの構成とを提供する構成デバイスを含む。

本発明のコンフィギュレータの１つの態様によれば、イベントのタイプは、条件、単純、および追跡を含む。
本発明のコンフィギュレータの別の態様によれば、イベントのソースは、特定のＮＴ−ＡＥ通知を作成したコンピュータ名およびその特定のＮＴ−ＡＥの挿入ストリングを含む。

本発明のコンフィギュレータのさらに別の態様によれば、イベントの重大度は、規定の重大度値またはロギングされた重大度値を含む。

本発明のこの他およびさらなる目的、利点、および特徴は、添付の図面と共に以下の明細書を参照することにより理解されよう。添付の図面では、構成の類似の要素は類似の参照記号で示す。

図１を参照すると、システム２０は、１つのネットワーク３０を介して相互接続される複数のコンピューティングノード２２、２４、２６および２８を含む。ネットワーク３０は、いかなる適切な有線、無線、および／または光学ネットワークであってもよく、インターネット、イントラネット、公衆電話網、ローカルエリアネットワークおよび／または広域ネットワーク、および／または他の通信網を含むことができる。４つのコンピューティングノードが示されているが、コンピューティングノード２６と２８の間の破線は、これ以上またはこれ以下の数のコンピューティングノードを使用することが出来ることを示している。

システム２０は、複数のコンピューティングノード内で発生するか、または複数のコンピューティングノードの１つまたは複数によって認知されるイベントを追跡する、いかなるアプリケーション用にでも構成することができる。一例として、また説明を完全にするために、システム２０は、本明細書ではプロセス３２の制御用として記述する。この目的のために、コンピューティングノード２２および２４は、プロセス３２を制御し、監視し、かつ／または管理するように割り付けられる。コンピューティングノード２２および２４は、プロセス３２への接続と共に示される。これらの接続は、様々なセンサおよび／または制御デバイスが接続されるバスに対する接続であってよい。例えば、コンピューティングノード２２および２４の１つまたは複数に対するローカルバスは、フィールドバス・ファンデーション（Ｆｉｅｌｄｂｕｓ Ｆｏｕｎｄａｔｉｏｎ：ＦＦ）ローカルエリアネットワークであってよい。コンピューティングノード２６および２８は、プロセス３２への直接接続を有さず、コンピューティングノードの管理、監視および他の目的のために使用することができる。

図２を参照すると、コンピューティングノード２２、２４、２６および２８は、それぞれに本発明のノードコンピュータ３４を含む。ノードコンピュータ３４は、複数の実行時システムコンポーネント、すなわちＷＭＩサービス３６、リダイレクタサーバ３８、システムイベントサーバ（ＳＥＳ）４０、ＨＣＩクライアントユーティリティマネージャ４２、コンポーネントマネージャ４４、およびシステムステータスディスプレイ４６を含む。ＷＭＩサービス３６は、ローカルコンポーネント管理サービス（ＣＡＳ：Ｃｏｍｐｏｎｅｎｔ Ａｄｍｉｎｉｓｔｒａｔｉｖｅ Ｓｅｒｖｉｃｅ）プロバイダ４８、遠隔ＣＡＳプロバイダ５０、システムイベントプロバイダ（ＳＥＰ：Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｐｒｏｖｉｄｅｒ）５２、ネームサービスプロバイダ（ＮＳＰ：Ｎａｍｅ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）５４、同期レポジトリプロバイダ（ＳＲＰ：Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｒｅｐｏｓｉｔｏｒｙ Ｐｒｏｖｉｄｅｒ）５６、およびハートビートプロバイダ５８を含む。図２中の線は、様々な実行時システム管理コンポーネント間の通信経路を表す。

ＳＲＰ ５６は、そのコンピューティングノードのレポジトリのデータを、システム２０の他のコンピューティングノードに配置されたレポジトリのデータと同期するよう動作可能である。

例えば、どちらも関連付けられたデータレポジトリを有し、ＳＲＰ ５６のクライアントである、ＳＥＰ ５２およびＮＳＰ ５４のような、コンピューティングノードの同期プロバイダのそれぞれ。

システムステータスディスプレイ４６は、ユーザがコンピューティングノード２２、２４、２６、または２８およびそれらが管理するコンポーネントを構成し、監視することを可能にするツール、例えばプロセス３２を監視し制御するセンサおよび／またはトランスデューサとして働く。システムステータスディスプレイ４６は、遠隔ＴＰＳノードおよびコンポーネント構成を実行する機能を提供する。システムステータスディスプレイ４６は、ノードおよびシステムステータスをそのローカルハートビートプロバイダ５８およびＳＥＰ ５２から受信する。システムステータスディスプレイ４６は、管理されたコンポーネント状態を受信するために、それぞれの監視されたノードのローカルコンポーネント管理サービスプロバイダ４８に接続する。

ＮＳＰ ５４は、ＷＭＩクライアントに別名および関連付けられたコンポーネント情報の部分集合を提供する。コンピューティングノードのＮＳＰ ５４は、異なるコンピューティングノードの別の設定済みＮＳＰ ５４（１つあれば）のデータベースから関連付けられたデータベースを初期設定し、次いでその関連付けられたデータベースをそのコンピューティングノードのＳＲＰ ５６を使用して同期化された状態に保つ。

ＳＥＰ ５２は、ローカルイベントをシステムイベントとして発行し、システムイベントの同期化されたローカルコピーを所定範囲内に維持する。ＳＥＰ ５２は、そのシステムイベントをＷＭＩクライアントに公開する。図２に示すように、システムステータスディスプレイ４６とＳＥＳ ４０は、どちらもＳＥＰ ５２に対するクライアントである。

コンポーネントマネージャ４４は、ローカルに管理されたコンポーネントを監視し管理する。コンポーネントマネージャ４４は、管理されたコンポーネント状態を標準ＷＭＩクライアントに公開するＷＭＩプロバイダインターフェースを実施する。

ハートビートプロバイダ５８は、接続されたＷＭＩクライアントに、ハートビートプロバイダ５８のマルチキャスト範囲内でコンピューティングノードのハートビートと追加または削除のイベント通知とを現在報告中の、すべてのコンピューティングノードのリストを提供する。

ＳＲＰ ５６は、情報を同期化した状態に保つために必須の低レベルのノード間通信を実行する。ＳＥＰ ５２およびＮＳＰ ５４は、ＳＲＰ ５６の機能に基づいて構築される。これにより、ＳＥＰ ５２およびＮＳＰ ５４は、システムイベントおよび別名の同期化されたデータベースをそれぞれに維持することができる。

図３を参照すると、ＳＲＰ ５６およびハートビートプロバイダ５８は、ノード間通信用にマルチキャストリンク７０を使用する。一方、システムステータスディスプレイ４６は、そのローカルハートビートプロバイダ５８およびＳＥＰ ５２と通信するためにＷＭＩサービスを使用する。システムステータスディスプレイ４６も、ローカルで管理されたノードおよび遠隔で管理されたノードのローカルＣＡＳプロバイダ４８および遠隔ＣＡＳプロバイダ５０と通信するためにＷＭＩサービスを使用する。

システムステータスディスプレイ４６は、供給業者が統合されたシステム管理ツールを提供する共通フレームワークを提供する。システムステータスディスプレイ４６に緊密に結合されるのはＷＭＩサービスである。ＷＭＩにより、供給業者は、システムコンポーネントの管理および監視用のスクリプト可能なインターフェースを公開する。システムステータスディスプレイ４６とＷＭＩは共に、カスタマイズ可能かつ拡張可能な共通ユーザインターフェースおよび情報データベースを提供する。システムステータス特徴６０は、コンピュータの階層図および管理されたコンポーネント状態を提供するＭＭＣスナップインとして実施される。システムステータス特徴６０は、ＴＰＳドメインを定義する構成済みドメイン／組織ユニットトポロジーを読むために、アクティブディレクトリサービスインターフェース（ＡＤＳＩ：Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）を使用する。各ノードコンピュータ上のＷＭＩプロバイダは、構成および状態情報へのアクセスを提供する。状態情報はＷＭＩイベント通知により更新される。

システムディスプレイウィンドウは次の３つの部分に分割される。
・メニュー／ヘッダー−ウィンドウ上部に表示される共通のカスタマイズされた制御が、ウィンドウまたは項目の挙動を制御するために使用される。

・スコープペイン−コンソールウィンドウの左のペインは、インストールされたスナップインおよびそれらに含まれる項目の樹木図を表示するために使用される。
・リゾルトペイン−コンソールウィンドウの右のペインは、そのスコープペインで選択された項目に関する情報を表示する。表示モードは、大アイコン、小アイコン、リスト、詳細を含む（デフォルト表示）。管理されたコンポーネントは、リゾルトペインのディスプレイにＣｕｓｔｏｍ Ａｃｔｉｖｅ Ｘ制御も提供することができる。

システムイベントプロバイダ
ＳＥＰ ５２は、増補するＮＴログイベントの同期化されたプロバイダである。これは、処理済みのＮＴログイベントを制限するためにフィルタテーブル８４を使用し、ＯＰＣ−ＡＥ準拠のイベントを生成するために必要なデータと共に通過するそれらのイベントを増す。それは、構成済みのアクティブディレクトリ範囲内のすべてのノードと、ＳＲＰ ５６を使用して同期が取られる、それらのイベントの１つのレポジトリを維持する。ＳＥＰ ５２は、イベントフィルタファイル内で定義されたイベントのタイプおよび属性に従い、イベントの配信および状態の管理を担当する。

ＳＥＰ ５２はＷＭＩプロバイダとして実施される。ＷＭＩは、イベント通知、レポジトリの維持およびアクセスのための共通インターフェース、およびメソッドの輸出を可能にする。カスタムプロキシは必要とされず、インターフェースはスクリプト可能である。ＳＥＰ ５２は、そのレポジトリの内容を構成済みのアクティブディレクトリ範囲内のすべてのノードと同期化するために、ＳＲＰ ５６を利用する。これにより、ネットワーク帯域幅の消費量が低減され、接続管理事項および同期事項が低減される。

マルチキャストグループアドレスおよびポート、ならびにアクティブディレクトリ範囲は、同期レポジトリ標準構成ページから構成される。すべての他の標準構成ページと同様に、このオプションも、システムステータスディスプレイ４６によりコンピュータ構成コンテキストメニューに表示される。

デフォルトＳＥＰ ５２クライアント構成は、ＳＲＰクライアント構成レジストリキーに書き込まれる。このキーは、名前および範囲の値を含む。名前はＳＥＰサービスのユーザフレンドリーな名前であり、範囲はデフォルトで「ＴＰＳＤｏｍａｉｎ」であるが、これは、含んでいるアクティブディレクトリオブジェクト（ＴＰＳドメイン組織ユニット）を示す。

すべてのＮＴイベントがシステムイベント加入者に送信されるわけではない。イベントがクライアントまで通過すべきか否かを判定するため、ならびにＮＴイベントからＯＰＣイベントを作成するためのデータを増補するために、フィルタテーブルが使用される。このテーブルにエントリのないイベントは無視される。フィルタテーブルを作成するために構成ツールが使用される。

ＯＰＣイベントは、イベントのカテゴリ、イベントのソース、およびそのイベントが認知可能か否かのような、ＮＴイベントで取得可能な追加情報を必要とする。このフィルタテーブルは、ＯＰＣイベント形式へのＮＴイベントの変換に関する追加情報を含むことが好ましい。イベントのソースは、通常はコンピュータ名とコンポーネント名をドットで区切った組合せだが、コンピュータ名を省略するように構成することもできる。コンピュータ名は、イベントを生成するコンピュータの名前である。コンポーネント名は、イベントの複数の挿入ストリングのうちの１つである。これは、通常は第１の挿入ストリングだが、複数の挿入ストリングのどの挿入ストリングであるようにも構成可能である。

イベントは、標準イベントロギングメソッド（Ｗｉｎ３２またはＷＭＩ）を使用して、ＮＴイベントログファイルにログされる。ＳＥＰ ５２は、新しいイベントに関する＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅｎｔ（インスタンス作成イベント）通知に登録する。通知され、そのイベントが通過することになる場合、イベントのプロバイダが維持するサマリ記録が作成され、＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅｎｔがシステムイベントマルチキャストグループにマルチキャストされる。

ＳＥＰ ５２は、システムイベントフィルタ・スナップイン８６により定義されたフィルタテーブルを読む。このフィルタテーブルは、ＳＥＰレポジトリにロギングされるイベントを決定し、ＯＰＣ−ＡＥイベントの生成に必要となる追加データを定義する。Ｗｉｎｄｏｗｓイベントの重大度が所望のＯＰＣイベントの重大度に必ずしも直接的に翻訳されるわけではないので、システムイベントフィルタテーブル８４は、各イベントのタイプに１つの重大度を割り当てる。０という重大度が指定されている場合、元のＮＴイベントに割り当てられたイベントの重大度は事前に割り当てられたＯＰＣの重大度値に翻訳される。ＯＰＣイベントの重大度へのＮＴイベントの変換値を、表２７に示す。

イベントの２つの主要なクラスは、ＳＥＰ ５２によって取り扱われる。すなわち条件関連イベントと単純／追跡イベントである。条件関連イベントは、構成済み範囲内のすべてのノード上のＳＥＰ ５２内の同期レポジトリ内で維持される。単純または追跡イベントは、いかなる接続されたクライアントにでもリアルタイムに配信される。単純または追跡イベントに関しては、配信の保証はなく、レポジトリ状態は維持されず、イベントの回復は不可能である。

ＳＥＰ ５２は、すべての条件関連イベントのマップをソースおよび条件名の組合せにより維持する。新しい条件関連イベントが生成された場合、同じソースおよび条件名でロギングされたイベントは、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔ（インテンス修正イベント）にＡｃｔｉｖｅ＝ＦＡＬＳＥプロパティを書き込むことにより自動的に非活動化される。

条件状態変更により、対応する追跡イベントが生成される。ＳＥＰ ５２は、条件、状態、タイムスタンプ、およびユーザを特定する外部イベント通知を生成する。
同期を実行する場合、ＳＥＰ ５２は、同期化された表示内にある条件関連イベントの活動状態を、ローカルイベントマップに維持される状態で更新する。ローカルマップが同期化された表示に含まれる条件イベントを含まない場合、そのイベントはレポジトリで非活動化される。

条件イベントとそれらの関連付けられた通常状態復帰イベント（関連する活動状態の条件イベントを非活動化する）は柔軟に結合されているので、イベントロギングエンティティは、要求される通常状態復帰イベントをロギングしない場合があり、活動状態の条件関連イベントは正確に非活動化されない場合がある。これらのイベントをＳＥＳ（ＧＯＰＣ＿ＡＥ）条件データベースおよびＳＥＰレポジトリから作成することができるようにするために、それぞれの認知された活動状態のイベントは構成可能な期間だけ徐々に停止され（インストール中のデフォルト期間に設定される）、当該期間経過後に非活動化される。

単純イベントおよび追跡イベントはＳＥＰレポジトリでは保持されないが、いかなる接続されたクライアントにも外部イベントとして配信される。これらのイベントは、すべてのＳＥＰに対してＳＲＰ ＳｅｎｄＥｘｔｒｉｎｓｉｃＮｏｔｉｆｉｃａｔｉｏｎ（）メソッドにより配信される。単純イベントまたは追跡イベントの回復はない。これらのイベントは認知可能ではない。イベントディスプレイがこれらのイベントを表示するよう選択した場合、１つのノード上の１つのイベントの認知または削除という他の手段は、他のノードに影響を与えない。

外部追跡および単純イベントのタイプをサポートするために、新しいＷＭＩクラスが追加される。ＳＥＰは、ＳＲＰ ５６にこの新しいクラス（ＴＰＳ＿ＳｙｓＥｖｔ＿Ｅｘｔ）を登録する。ＳＲＰ ５６は、このクラスがＷＭＩ＿ＥｘｔｒｉｎｓｉｃＥｖｅｎｔ（外部イベント）クラス由来であることを知り、これらのイベントのいかなる同期も実行しない。ＳＲＰ ５６は通過モードのみで動作する。

ソースおよび条件名による条件関連イベントのマップは、ＳＥＰ５２により維持される。各ＳＥＰ ５２は、ローカルノードで生成中の条件関連イベントの活動状態を管理する。

ＳＥＰレポジトリで維持される条件イベントは、ＳＥＰ範囲内にあるすべてのノードに複製される。したがって、起動中、または中断した同期グループの再結合に起因する再同期中に、すべての条件関連イベントが回復されるはずである。単純イベントおよび追跡イベントは過渡的な単発イベントであり、回復することは出来ない。

ＳＥＰ ＴＰＳ＿ＳｙｓＥｖｔクラスは、ＡＣＫ（）メソッドを実施する。このメソッドはコメントパラメータを追加するように修正される。ＳＥＳにより実施されるＷＭＩクラス、ＴＰＳ＿ＳｙｓＥｖｔもまた、ＡｃｋＣｏｍｍｅｎｔストリングプロパティ、ＡｃｋｎｏｗｌｅｄｇｅＩＤストリングプロパティ、およびブーリアンアクティブプロパティを追加するように修正される。新しいＭｏｄｉｆｉｃａｔｉｏｎＳｏｕｃｅ（修正ソース）ストリングプロパティが、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔ（インテンス修正イベント）を生成中のＳＥＰによりセットされる。

イベントは、マルチキャストグループ内のいかなるノードでも認知可能である。この認知は、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔオブジェクトにパッケージされたシステムイベントマルチキャストグループのすべてのメンバーにマルチキャストされる。各ノードのＳＥＰ ５２は、認知のソースを特定して、そのローカルＣＣＡシステムイベントログへの情報メッセージをロギングする。

あるイベントが一度認知されると、そのイベントはシステムイベントリストから削除することができる。これにより、内部的に維持されたイベントリストからそのイベントが削除され、システムイベントマルチキャストグループにマルチキャストすべき＿ＩｎｓｔａｎｃｅＤｅｌｅｔｉｏｎＥｖｅｎｔ（インテンス削除イベント）が生成される。そのイベント削除要求のソースを示す情報メッセージが、ＣＣＡシステムイベントログファイルに書き込まれる。

ＷＭＩプロバイダオブジェクト
ＷＭＩプロバイダオブジェクトは、ＩＷｂｅｍＰｒｏｖｉｄｅｒＩｎｉｔインターフェースの「初期設定」メソッドと、ＩＷｂｅｍＳｅｒｖｉｃｅｓインターフェースのＣｒｅａｔｅＩｎｓｔａｎｃｅＥｎｕｍＡｓｙｎｃ（作成インスタンス列挙非同期）メソッドおよびＥｘｅｃＭｅｔｈｏｄＡｓｙｎｃ（実行方法非同期）メソッドと、ＩＷｂｅｍＥｖｅｎｔＰｒｏｖｅｒインターフェースのＰｒｏｖｉｄｅＥｖｅｎｔｓメソッドとを実施する。この初期設定メソッドは内部初期設定を実行する。ＣｒｅａｔｅＩｎｓｔａｎｃｅＥｎｕｍＡｓｙｎｃメソッドは、内部イベントリスト内のすべてのエントリに関するインスタンスを作成し、ＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋインターフェースを介してそのインスタンスをクライアントに送る。ＥｘｅｃＭｅｔｈｏｄＡｓｙｎｃメソッドにより２つのメソッド、ＡｃｋＥｖｅｎｔとＣｌｅａｒＥｖｅｎｔにアクセス可能である。これらは内部イベントリストを更新し、外部ノードに通知するためにＳＲＰクライアントオブジェクトを呼び出す。ＰｒｏｖｉｄｅＥｖｅｎｔｓメソッドは、イベントが発生した際に使用するために、クライアントのＩｗｂｅｍＯｂｊｅｃｔＳｉｎｋインターフェースを取っておく。その取っておいたＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋインターフェースを介してそのクライアントに通知するために、３つのコールバックメソッド、ＣｒｅａｔｅＩｎｓｔａｎｃｅＥｖｅｎｔ（作成インスタンスイベント）、ＭｏｄｉｆｙＩｎｓｔａｎｃｅＥｖｅｎｔ（修正インスタンスイベント）、およびＤｅｌｅｔｅＩｎｓｔａｎｃｅＥｖｅｎｔ（削除インスタンスイベント）が実施される。ＣｒｅａｔｅＩｎｓｔａｎｃｅＥｖｅｎｔメソッドは、あるイベントがローカルに作成される際にはＮＴイベントプロバイダオブジェクトにより呼び出され、あるイベントが遠隔で作成される際にはＳＲＰクライアントオブジェクトにより呼び出される。ＭｏｄｉｆｙＩｎｓｔａｎｃｅＥｖｅｎｔメソッドおよびＤｅｌｅｔｅＩｎｓｔａｎｃｅＥｖｅｎｔメソッドは、あるイベントが遠隔で認知または削除される際にＳＲＰクライアントにより呼び出される。

サーバ起動中、このサブシステムは、マルチストリングレジスタキーからフィルタテーブルへのディレクトリ経路を読む。これはフィルタテーブルをロードし、メモリにローカルマップを作成する。実行時に、これは、イベントが加入者に渡されるべきか否かを判定するためにＮＴイベントログＷＭＩクライアントにより呼び出されるメソッドを提供し、追加ＯＰＣ特有データを提供する。

ＮＴイベントクライアントオブジェクト
サーバ起動中、このサブシステムは、ＮＴイベントログプロバイダに登録し、ＮＴイベントファイルにイベントがロギングされた際に通知を要求する。インスタンス作成通知が受信されると、このサブシステムはイベントフィルタリングサブシステムを呼び出し、追加データにより１つのイベントを構築する。次いでサブシステムは、外部ノードに通知を送るためにＳＲＰクライアントオブジェクトを呼び出す。

ＳＲＰクライアントオブジェクト
サーバ起動中、ＳＲＰクライアントオブジェクトはＳＲＰ ５６に登録する。データの同期が即座に必要な場合、これはＳｙｎｃＷｉｔｈＳｏｕｃｅメッセージを受信する。内部イベントリストがデータの同期から外れているとＳＲＰ ５６が判断した場合にも、これは定期的にＳｙｎｃＷｉｔｈＳｏｕｒｃｅメッセージを受信する。ＳｙｎｃＷｉｔｈＳｏｕｒｃｅメッセージが受信された場合、これは、その外部ノード上のＳＥＰ ５２に接続するためにそのメッセージの「ソース」プロパティを使用し、イベントリストを要求する。次いでこの内部イベントリストが新しいリストに置き換えられる。イベントが遠隔ノードで作成された場合、ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎメッセージが受信される。これは、その新しいイベントを内部イベントリストに追加し、クライアントに通知を送ることをＷＭＩプロバイダオブジェクトに要求する。イベントが修正（認知）または作成された場合、このシナリオが適用される。イベントがローカルにロギングされる場合、ＮＴイベントクライアントオブジェクトは、インスタンス作成メッセージを外部ノードに送るためにこのオブジェクトを呼び出す。クライアントによってイベントが認知または作成される場合、ＷＭＩプロバイダオブジェクトは外部ノードにインスタンス修正または削除メッセージを送るためにこのサブシステムを呼び出す。ＬｏｓｔＭｓｇＥｒｒｏｒまたはＤｕｐｌｉｃａｔｅＭｓｇＥｒｒｏｒメッセージが受信された場合は、何の処置も取られない。

ＳＥＳ ４０はＳＥＰ ５２のＷＭＩクライアントである。ＳＥＰ ５２により書き込まれた各イベントは、ＳＥＳ ４０によりＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅｎｔとして受信される。追跡イベントは一時的なイベントであり、ＳＥＳ ４０により単純に無視される。条件イベントは、特定の監視ソースの状態を反映する。これらの条件は、ＳＥＳ ４０内部にある警報およびイベント条件データベースで維持される。ＳＥＰ ５２は、受信したＮＴイベントに、要求されたＳＥＳ情報をフィルタテーブルから取り出してポピュレートする。この情報は、イベントのクッキー、ソースストリング、イベントの重大度、イベントのカテゴリおよびタイプ、ならびにイベントがＡＣＫ可能か否か、および現在のＡＣＫされた状態を含む。

所与のソースに対して新しい条件関連イベントが受信されると、その新しい条件が以前の条件に取って代わらねばならない。条件関連イベントの受信に際し、ＳＥＰ ５２はそのソースの現在の条件を探し、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔを生成して、その現在の条件を非活動化する。これで、この新しい条件イベントが適用される。

同期レポジトリプロバイダ
ＳＲＰ ５６は、ＳＥＰ ５２およびＮＳＰ ５４の基礎的なコンポーネントである。ＳＥＰ ５２およびＮＳＰ ５４は、登録済みインスタンスクラスの複合表示を提供する。ＳＥＰ ５２およびＮＳＰ ５４は、ＳＲＰ ５６により実施されるコネクションレス型の信頼性のあるプロトコルにより、それぞれのレポジトリデータを取得する。

ＳＲＰ ５６は、分散型管理データの同期ＷＢＥＭレポジトリを維持するために、信頼性のあるインターネットプロトコル（ＩＰ）マルチキャストベースの技術を実施する、ＷＭＩ外部イベントプロバイダである。ＳＲＰ ５６は、動的インスタンスプロバイダまたはインスタンスクライアントが、分散型データの複合表示を収集するために複数の遠隔接続を行う必要性を解消する。ＳＲＰ ５６は、データ変更イベントの配信を保証するために、同期された表示の状態を維持する。コネクションレス型プロトコル（ＵＤＰ）が使用されるが、これは、接続されたクライアントおよびサーバに対するネットワーク／コンピュータ停止の影響を最小限に抑える。ＩＰマルチキャストを使用することにより、ネットワーク帯域幅に対する影響が低減され、構成は単純化される。

ＳＲＰ ５６は、標準ＷＭＩ外部イベントおよびメソッドプロバイダインターフェースを実施する。ＳＲＰ ５６に対して、ＩＷｂｅｍＳｅｒｖｉｃｅｓ：：ＥｘｅｃＭｅｔｈｏｄ［Ａｓｙｎｃ］（）メソッドを使用する同期プロバイダ（例えば、ＳＥＰ ５２またはＮＳＰ ５４）からすべてのメソッド呼び出しが行われる。ＳＲＰ ５６からの外部イベントデータに対する登録は、ＩＷｂｅｍＳｅｒｖｉｃｅｓ：：ＥｘｅｃＮｏｔｉｆｉｃａｔｉｏｎＱｕｅｒｙ［Ａｓｙｎｃ］（）のＳＲＰ実施態様への呼び出しによる。ＳＲＰ ５６は、外部イベント通知および接続状態更新を、ＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋ：：Ｉｎｄｉｃａｔｅ（）およびＩＷｂｅｍｂＯｂｊｅｃｔＳｉｎｋ：：ＳｅｔＳｔａｔｕｓ（）のクライアント実施態様に対するコールバックにより、ＳＥＰ ５２およびＮＳＰ ５４にそれぞれ提供する。標準ＷＭＩインターフェースしか使用されないので、（すべてのＷｉｎ２Ｋコンピュータに導入された）カスタムライブラリまたはプロキシファイルには、ＳＲＰ ５６を実施またはインストールすることが要求されない。

構成の複雑さを低減し、融通性を最適化するために、すべての登録済みクライアント（同期プロバイダ）に対して単一ＩＰマルチキャストアドレスが使用される。受信したマルチキャストはＷＢＥＭクラスおよびソースコンピュータのアクティブディレクトリ経路によりフィルタリングされ、次に適切な同期プロバイダに配信される。各クライアントはＷＢＥＭクラスによりＳＲＰ ５６に登録する。それぞれの登録されたクラスは、個別に構成可能なアクティブディレクトリ範囲を有する。

ＳＲＰ ５６は、同期制御メッセージとレポジトリ更新の両方を渡すためにＩＰマルチキャストを使用するが、これにより通知配信のオーバーヘッドが低減され、ネットワーク帯域幅が保たれる。同期中のノード間における伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）ストリーム接続を介してレポジトリ同期が行われる。同期にＴＣＰ／ＩＰストリームを使用することにより、複雑度マルチキャストトラフィック解釈が低減され、レポジトリデータの信頼性のあるポイントツーポイント配信が保証される。

同期プロバイダは、インスタンス通知がクライアントに配信される方法が標準のインスタンスプロバイダと異なる。ｗｉｎｍｇｍｔサービスのＩＷｂｅｍＯｂｊｅｃｔＳｉｎｋにインスタンス通知を直接配信する代わりに、同期プロバイダは、ＳＲＰ ５６に接続し、ＳＲＰ ＳｅｎｄＩｎｓｔａｎｃｅＮｏｔｉｆｉｃａｔｉｏｎ（）メソッドを使用してインスタンス通知を配信する。次いでＳＲＰはそのインスタンス通知をマルチキャストにより、構成済み同期グループのすべてのプロバイダに送る。ＳＲＰ ５６により受信されたインスタンス通知は、ｗｉｎｍｇｍｔサービスにより外部イベントを介して同期プロバイダに転送される。同期プロバイダはそのＳＲＰ外部イベントを受信し、その外部イベントからインスタンスイベントを抽出し、そのインスタンスイベントを必要に応じて内部データベースに適用し、次いでそのイベントを接続されたクライアントにｗｉｎｍｇｍｔにより転送する。

同期されたデータが、インスタンスの配列を含んだ外部イベントブジェクトにより同期プロバイダに配信される。このオブジェクトの配列は、現在同期した状態にある遠隔の同期プロバイダからＴＣＰ／ＩＰストリームにより同期中のノードに配信される。同期プロバイダＳＲＰクライアントは、この受信した配列と局所的に生成されたインスタンスとをマージし、遠隔の同期プロバイダに、ＳＲＰ ５６を介してインスタンス通知を送ることにより、その違いを通知する必要がある。各同期プロバイダは、同期データをローカルレポジトリデータとマージする最善の方法を決定する必要がある。

クライアントアプリケーションは、いかなる他のＷＢＥＭインスタンスプロバイダ用でもあるので、同期プロバイダ（ＳＲＰのクライアントとして登録済みのプロバイダ）にアクセスする。レポジトリの同期された性質は、同期プロバイダのクライアントに透過的である。

ＳＲＰ ５６は、指定された一群のコンピュータに対して登録設定を調整するＭＭＣプロパティページにより構成される。ＳＲＰ構成は、ＩＰマルチキャストおよびアクティブディレクトリ範囲のストリングの両方の構成を要求する。

デフォルトで、ＳＲＰ ５６は、ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｈｏｎｅｙｗｅｌｌ＼ＦＴＥレジストリキーにあるハートビートプロバイダ５８への構成されたＩＰマルチキャスト（ＩＰＭＣ）アドレスを使用する。これにより、ＬＡＮ診断メッセージ（ハートビート）による、ＩＰマルチキャストグループの健全性に関する肯定的な指示が提供される。ＳＲＰメッセージ用のＵＤＰ受信ポートは、固有である（ハートビートプロバイダ５８と共有されない）。マルチキャスト通信は、ルータによりしばしば制約を受ける。あるサイトがあるルータを介したデータの同期を要求した場合、マルチキャストメッセージがそのルータを通過するよう許可するために、ネットワーク構成ステップが必須となる場合がある。

アクティブディレクトリ範囲は、同期プロバイダごとに構成される（例えば、ＳＥＰ ５２またはＮＳＰ ５４）。それぞれのインストールされたクライアントは、サポートされるＷＭＩクラスの名前付きキーを、ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｈｏｎｅｙｗｅｌｌ＼ＳｙｓＭｇｍｔ＼ＳＲＰ＼Ｃｌｉｅｎｔｓキーに追加する。このキーに、クライアントは名前と範囲の値を追加する。名前の値は、構成インターフェース内に表示するためにユーザフレンドリーな名前を含んだＲＥＧ＿ＳＺ値である。範囲の値は、１つまたは複数のアクティブディレクトリ範囲のストリングを含んだＲＥＧ＿ＭＵＬＴＩ＿ＳＺ値である。

ＳＲＰ構成ページは、ユーザに、構成すべきインストール済みＳＲＰクライアントの選択を可能にするコンボボックスを提示する。このコンボボックスには、ＳＲＰ＼Ｃｌｉｅｎｔｓキーの基に列挙されたクライアントクラスごとに名前の値がポピュレートされる。クライアントプロバイダが一度選択されると、アクティブディレクトリツリーが、ユーザが更新の範囲を選択できるようにするためのチェックボックス項目と共に表示される。これは、現在のクライアント範囲の値と一致するようにチェックマークにより初期設定される。

インスタンス内容をＩＰマルチキャストにより渡すには、ＵＤＰ ＩＰマルチキャストパケットを介してＩＷｂｅｍＣｌａｓｓＯｂｊｅｃｔプロパティを読み取り、マルチキャストグループに整理し、受信側で再構成する必要がある。各通知オブジェクトが検査され、その内容がＳＲＰメモリのストリームオブジェクトに書き込まれる。インスタンスプロパティの数が最初にストリームに書き込まれ、次にすべてのインスタンスプロパティが名前（ＢＳＴＲ）／データ（ＶＡＲＩＡＮＴ）対の形式で書き込まれる。次いでこのストリームは、１つのＩＰマルチキャストＵＤＰデータパケットにパッケージされ送信される。受信されると、プロパティの数が抽出され、名前／データ対がストリームから読み出される。クラスインスタンスが作成され、受信された値がそれにポピュレートされ、次いで登録済みクライアント（同期プロバイダ）に配信するために外部イベントによりｗｉｎｍｇｍｔサービスに送信される。異型は参照データを含めることができない。値の安全な配列を含む異型は、まず異型タイプを書き込み、次にその安全な配列に含まれるインスタンスの数、次いですべての含まれる要素に関するその異型タイプとデータを書き込むことにより整理される。

応答ストームを回避するために、マルチキャスト応答は、送信前にリクエスター指定の最大時間まで任意に延期される。ローカル応答が送信される前に応答側ノードが別のノードから有効な応答を受信した場合、その送信は取り消される。

図４を参照すると、本発明によるＮＴ−ＡＥ通知およびＯＰＣ−ＡＥの通知の濾過を示す構成に、ノードコンピュータ３４が示されている。ＯＰＣ−ＡＥの通知は、ＳＲＰ ５６によりシステム２０の他のコンピューティングノードからマルチキャストリンク７０を介して受信される。ＳＥＰ ５２がこれらの通知を受信する権利を有するグループの加入者である場合、ＳＲＰ ５６は、ＷＭＩサービス３６を使用してこれらの通知をＳＥＰ ５２に渡す。ＳＥＰ ５２は、ＯＰＣ−ＡＥ通知を、ＷＭＩサービス３６を介してＳＥＳ ４０に渡す。ＳＥＳ ４０は、ＯＰＣ−ＡＥ通知を、ＯＰＣ−ＡＥクライアント８０のようなその加入者クライアントに渡す。ＯＰＣ−ＡＥクライアント８０（またはＳＥＳ ４０の他のＯＰＣクライアント）により生成されたＯＰＣ−ＡＥ通知が、ＳＥＳ ４０により受信され、ＷＭＩサービス３６およびＳＥＰ ５２を介してＳＲＰ ５６に渡される。ＳＲＰ ５６は次いで、これらのＯＰＣ−ＡＥ通知を適切な加入者グループに配信するようパッケージする。この配信は、そのローカルクライアントに対してはＳＥＰ ４０を介し、他のコンピューティングノードの遠隔クライアントに対してはマルチキャストリンク７０を介する。

ＷＭＩサービス３６は、ノードコンピュータ３４内で発生中のＮＴ−ＡＥの通知を含んでいるＮＴイベントプロバイダ８２を含む。ＮＴイベントプロバイダ８２は、それらのＮＴ−ＡＥ通知をＳＥＰ ５２に提供するためにＷＭＩサービス３６を使用する。上記の通り、ＮＴイベントはＮＴ形式であってＯＰＣ形式ではないので、すべてのＮＴ−ＡＥがＯＰＣクライアントに送られるわけではない。本発明によれば、ＮＴ−ＡＥ通知をフィルタリングし、それらをＯＰＣ−ＡＥ通知に変換するためにフィルタテーブル８４が提供される。

ＯＰＣ−ＡＥ通知に変換され、加入者クライアントに提供されるべきそれらのＮＴ−ＡＥ通知をユーザが定義できるように、フィルタ構成ツールであるシステムイベントフィルタ・スナップイン８６が提供される。ＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知に変換するために必須の上記の追加情報も、ＳＥＰ ５２が使用するよう提供され、好ましくはフィルタテーブル８４に含まれる。この追加情報は、イベントのタイプ（単純、追跡および条件）、イベントのカテゴリ、イベントのソース、イベントの重大度（１−１０００）、およびソース挿入ストリング、ならびにそのイベントが認知可能か否かなどの項目が含まれる。

ユーザによって選択されると、システムイベントフィルタ・スナップイン８６は、ノードコンピュータ３４にすべての登録済みメッセージテーブルを表示する。所望のイベントをロギングするために使用されるメッセージテーブルを選択する際、すべての含まれるメッセージがリゾルトペインに表示され、既存のフィルタテーブルファイルから追加の値が更新される。ファイルが存在しない場合、所望のイベントに関する新しいファイルが作成される。ユーザは、ＳＥＰ ５２によってロギングされるべきメッセージも選択し、ＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知に翻訳するために必要な追加情報を入力する。完了すると、更新されたフィルタテーブルが保存される。

第１の実施形態の論理設計シナリオ
ＣＡＳ ４８は、サーバのタイプに応じて次に示すサービスを提供する。次に、サポートされるサーバのリストを示す。

・ＨＣＩ管理サーバ
・ＨＣＩ管理状態サーバ
・非管理透過リダイレクタサーバ
・非管理ＯＰＣサーバ
ＣＡＳ ４８は、次に示すサービスをＨＣＩ管理サーバに提供する。

・構成済みサーバの自動検出および監視
・ノード起動時における、オプションによるサーバの自動スタート
・サーバの起動、シャットダウン、およびチェックポイントを開始するためのメソッドをＷＭＩクライアントに公開すること
・監視対象サーバ状態情報をＷＭＩクライアントに公開すること
ＣＡＳ ４８は、次に示すサービスを非管理サーバに提供する。

・非管理サーバの監視を開始、停止するために、ＷＭＩクライアントにメソッドを公開すること
・監視対象サーバ状態情報をＷＭＩクライアントに公開すること
コンポーネント構成および報告されたコンポーネント状態に対する変更が制御プロセスに影響を及ぼすので、ＣＡＳ ４８は、ＳＥＳ ４０に配信するようＳＥＰ ５２によって選択されたＷｉｎｄｏｗｓ（登録商標）アプリケーションイベントログにイベントをロギングする。ＳＥＳ ４０は、ＯＰＣ−ＡＥインターフェースを介して配信することのできるＷｉｎｄｏｗｓ（登録商標） ＯＲ ＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知に変換する。

次に示すシナリオは、ＣＡＳ ４８に対するイベントロギング要件と、ＳＥＰ ５２およびＳＥＳ ４０によって実行される後続処理とを記述する。
表１に示すシナリオは、コンポーネントメソッド呼び出しを行うＷＭＩクライアントを示す。シャットダウンメソッド呼び出しを使用したのは、クライアントがＨＣＩコンポーネント上のあるメソッドを呼び出した場合に実行されるステップを説明するためにすぎない。他のコンポーネントメソッド呼び出しも、同じ手順に従う。

ノードが起動され、ＣＡＳ ４８が開始され、ＨＣＩコンポーネントが実行中である。

表１
イベント イベントの記述
１ システム状態ディスプレイのユーザは、適切なコンポーネント上で右クリックし、 停止メニュー項目を選択する。
２ ＣＡＳ ４８は、その要求を受信し、ＨＣＩコンポーネント上のシャットダウンメ ソッドを開始する。
３ ＨＣＩコンポーネントは、シャットダウン動作を実行する。
４ ＣＡＳ ４８は、状態変更を検出し、すべての接続されたＷＭＩクライアントに状 態変更を通知するコンポーネント修正イベントを作成する。
５ ＣＡＳ ４８は、状態変更をアプリケーションイベントログに記録する。
６ ＳＥＰ ５２は、この新しいイベントログのエントリを検出し、未認知状態のＳＲ Ｐ ５６に条件イベントを追加する。

新しいＨＣＩ管理コンポーネントがそのノードに追加される。ＣＡＳ ４８は新しいコンポーネントを自動的に検出する。このノードが起動され、ＣＡＳ ４８が開始され、表２に示すように、ＨＣＩコンポーネント構成ページを使用して新しいＨＣＩ管理コンポーネントが追加された。

表２
イベント イベントの記述
１ ＣＡＳ ４８は、Ｗｉｎｄｏｗｓ（登録商標） ２０００から、コンポーネント情 報を含んでいるレジストリキーが修正されたことを示す更新を受信する。
２ ＣＡＳ ４８は、新しいＨＣＩ管理コンポーネントを検出し、監視スレッドを開始 する。
管理コンポーネントは、ＩｓＭａｎａｇｅｄ値をＹｅｓ／Ｔｒｕｅにセットしてお かなければならない。さもなければ、管理コンポーネントは無視される。例えば、 ＴＲＳはＮｏ／Ｆａｌｓｅにセットされる。
３ ＣＡＳ ４８は、すべての接続されたＷＭＩクライアントに新しいコンポーネント を通知するコンポーネント作成イベントを作成する。
４ 監視スレッドは、コンポーネント起動が状態の監視を開始するまで待機する。
５ ローカルアプリケーションイベントログに、新しいコンポーネントが作成されたこ とを示すエントリが書き込まれる。
６ ＳＥＰ ４０が、そのイベントを検出し、それを追跡イベントとしてシステムイベ ントレポジトリに追加する。

ＨＣＩ管理コンポーネントの構成が削除される。ＣＡＳ ４８は、その削除されたコンポーネントを自動的に検出する。ノードが起動され、ＣＡＳ ４８が開始される。表３に示すように、コンポーネントは停止され、ユーザはＨＣＩコンポーネント構成ページを使用して管理コンポーネントを削除する。

表３
イベント イベントの記述
１ ＣＡＳ ４８は、Ｗｉｎｄｏｗｓ（登録商標） ２０００から、コンポーネント情 報を含んでいるレジストリキーが修正されたことを示す更新を受信する。
２ ＣＡＳ ４８は、修正されたレジストリキーを介してＨＣＩコンポーネントの除去 を検出する。
３ ＣＡＳ ４８は、そのコンポーネントが削除されたことをＷＭＩ接続クライアントに通知するコンポーネント削除イベントを作成する。
４ ＣＡＳ ４８は、そのコンポーネントを監視するスレッドを停止する。
５ ＣＡＳ ４８は、削除中のコンポーネントに関するアプリケーションイベントログ に、そのコンポーネントが現在未認知状態であることを示すイベントを書き込む。
６ ＳＥＰ ５２は、この新しいイベントログのエントリを検出し、条件イベントをシ ステムイベントレポジトリに追加する。このイベントは「未認知」というＯＰＣサ ーバ状態に割り当てられており、次に示すことを目的としてＳＥＳ ４０により使 用される。
１）削除されたコンポーネントと同一ソースのいかなる顕著なイベントでもＡｕ ｔｏＡｃｋする。
２）削除されたコンポーネントと同一ソースの条件が通常状態に戻される。
７ ローカルアプリケーションイベントログ（イベント＃２）に、１つのコンポーネン トが削除されたことを示すエントリが書き込まれる。
８ ＳＥＰ ５２は、そのイベントを検出し、それを追跡イベントとしてシステムイベ ントレポジトリに追加する。

ＨＣＩ管理コンポーネントは状態を変更する。この状態変更は、ＣＡＳ ４８により検出され、接続されたＷＭＩクライアントに公開される。ノードが起動され、ＣＡＳ ４８が開始され、表４に示すように、ＨＣＩコンポーネントＡが実行中である。

表４
イベント イベントの記述
１ 管理コンポーネントＡが状態を変更する（例えば、ＬＣＮＰがＴＰＮサーバで機能 停止した場合、状態を警告に変更することになる）。
２ ＣＡＳ ４８は、コンポーネント状態変更を検出し、ＷＭＩコンポーネント修正イ ベントによりその情報を公開する。
３ システム状態ディスプレイ４６のようなすべての接続されたＷＭＩクライアントは 、状態変更を示すＷＭＩイベントを受信する。
４ コンポーネント状態変更が、アプリケーションイベントログに書き込まれる。
５ ＳＥＰ ５２は、この新しいイベントログのエントリを検出し、条件イベントを未 認知状態のシステムイベントレポジトリに追加する。
ＨＣＩ管理状態コンポーネントは、監視対象デバイスの状態変更を検出する。この状態変更はＣＡＳ ４８により検出され、接続されたＷＭＩクライアントに公開される。このノードが起動され、ＣＡＳ ４８が開始され、表５に示すように、ＨＣＩ状態コンポーネントＡが実行中である。

表５
イベント イベントの記述
１ 状態コンポーネントＡは実行中であり、監視対象デバイスが障害状態を報告する（ 例えば、ＨＢプロバイダがリンク障害を報告する）。
２ ＣＡＳ ４８が、デバイス状態変更を検出し、ＷＭＩコンポーネント修正イベント によりその情報を接続されたクライアントに公開する。
状態コンポーネントは、コンポーネント状態とデバイス状態の両方を報告する。
この場合、デバイスの状態だけが変更され、コンポーネント状態は未変更である。
３ システム状態ディスプレイ４６のようなすべての接続されたＷＭＩクライアントが 、状態変更を示すＷＭＩイベントを受信する。
４ このデバイス状態変更が、アプリケーションイベントログに書き込まれる。これら のイベントは、システムイベント用のフィルタテーブルには追加されない。これは 、複数のコンピュータからの複製イベントを防止するために行われる。
５ ＳＥＰ ５２は、この新しいイベントログのエントリを検出し、条件イベントを未 認知状態のシステムイベントレポジトリに追加する。

透過リダイレクタサーバ（ＴＲＳ）非管理コンポーネントは、ＣＡＳ ４８にその状態を監視するよう要求する。ノードが起動され、ＣＡＳ ４８が開始され、表６に示すように、ＴＲＳが起動中である。

表６
イベント イベントの記述
１ ＴＲＳは、ＷＭＩによりローカルＣＡＳ ４８に接続し、それ独自の名前およびＩ ＵｎＫｎｏｗｎポインタにより監視コンポーネントメソッドを呼び出す。
２ ＣＡＳ ４８は、そのコンポーネント名を一意とし、そのコンポーネントを監視す るために１つのスレッドを作成する。
一意の名前とする理由は、同一名／コンポーネントの複数のインスタンスがある 場合があるからである。
一意の名前はコンポーネントの名前である。
一意の名前は、新しいＴＲＳインスタンスが、既に停止したそれ以前のインスタ ンス内にあるのと同じ名前を取得しないようにするために、再起動およびＴＲＳ シャットダウン後にも続ける必要がある。これは、既存のイベントを調停する際 に混乱を起こすことになる。
３ ＣＡＳ ４８は、メソッド呼び出しによりＴＲＳに一意のコンポーネント名を戻す 。
コンポーネントの監視を停止するよう要求する際は、一意の名前が使用される。
４ ＣＡＳ ４８は、ＷＭＩ接続クライアントに新しく監視されているコンポーネント を通知するために、コンポーネント作成イベントを作成する。
５ ＣＡＳ ４８は、アプリケーションイベントログに、コンポーネントが監視を受け ていることを示すエントリを書き込む。
６ ＳＥＰ ５２は、その新しいイベントログのエントリを検出し、追跡イベントをシ ステムイベントレポジトリに追加する。

透過リダイレクタサーバ（ＴＲＳ）は、ＣＡＳ ４８に、その状態の監視を停止するよう要求する。ノードが起動され、ＣＡＳ ４８が開始され、表７に示すように、監視対象ＴＲＳがシャットダウンされる。

表７
イベント イベントの記述
１ ＴＲＳは、ＷＭＩによってローカルＣＡＳ ４８に接続し、監視コンポーネントメ ソッドにより戻された一意の名前により、未監視コンポーネントメソッドを呼び出 す。
２ ＣＡＳ ４８は、コンポーネント監視スレッドを停止する。
３ ＣＡＳ ４８は、削除中のコンポーネントに関するアプリケーションイベントログ に、そのコンポーネントが現在未知の状態にあることを示すイベントを書き込む。
４ ＳＥＰ ５２は、この新しいイベントログのエントリを検出し、システムイベント レポジトリに条件イベントを追加する。条件データベースのＯＰＣ Ａ＆Ｅイベン トを非活動化するために、このイベントはＳＥＳ ４０により使用される。
５ ＣＡＳ ４８は、ＷＭＩ接続クライアントに、このコンポーネントは最早監視され ていないということを通知するために、コンポーネント削除イベントを作成する。
６ ＣＡＳ ４８は、アプリケーションイベントログに、このコンポーネントは最早監 視されていないということを示すエントリを書き込む。
７ ＳＥＰ ５２は、この新しいイベントログのエントリを検出し、追跡イベントをシ ステムイベントレポジトリに追加する。

ハートビートプロバイダ５８は、ノードの健全性を示すためにハートビートメッセージを定期的にマルチキャストする。ノードが起動され、表８に示すように、ハートビートプロバイダ５８が起動される。

表８
イベント イベントの記述
１ ハートビートプロバイダ５８は、マルチキャストするＩｓＡｌｉｖｅメッセージを 開始する。
２ 同じマルチキャストアドレスを監視中の他のハートビートプロバイダ５８は、その ＩｓＡｌｉｖｅマルチキャストメッセージを受信し、そのノードを活動状態ノード のリストに追加する。
３ ＷＭＩインスタンス作成イベントがローカルＷＭＩハートビートプロバイダで発生 した場合、その新しいノードに対してＷＭＩクライアントの注意が喚起される。

このノードは、表９に示すように、機能停止またはシャットダウンする。

表９
イベント イベントの記述
１ ノードが機能停止し、ＩｓＡｌｉｖｅハートビートメッセージの送信を中止する。
２ マルチキャストアドレスを監視中の他のハートビートプロバイダ５８が、その機能 停止したノードに対する通信の障害を検出する。
３ ハートビートプロバイダ５８は、ノードに対する参照を削除することにより、ノー ドの機能停止状態を反映する。
４ ＷＭＩ削除インスタンスにより、その機能停止に対してＷＭＩクライアントの注意 が喚起される。
５ ハートビートプロバイダ５８は、アプリケーションイベントログにイベントをロギ ングする。
６ ＳＥＰ ５２は、イベントチェックフィルタテーブルを検出し、イベントを同期レ ポジトリに条件付きでロギングする。
注意：ＳＥＳノードは、ハートビートプロバイダ５８用のフィルタを有する唯一のノードである。これにより、ノード障害イベントの複数のコピーが防止される。

ＳＥＰ ５２は、ＮＴ−ＡＥの同期レポジトリである。ＮＴ−ＡＥは、システム、ＣＣＡアプリケーション、またはサードパーティのアプリケーションにより生成されたものであってよい。これは、すべてのノード上のシステムイベントの一貫した表示を維持するためにＳＲＰ ５６を利用する。これはまた、ＯＰＣ−ＡＥ通知となるＮＴ−ＡＥ通知を制御するためにフィルタテーブル８４を利用する。

フィルタテーブル８４は、ＳＲＰ ５６に追加されるべき、イベントの包含リストを提供する。いかなるＷｉｎｄｏｗ（登録商標） ２０００イベントでも組み込むことができる。表１０に示すように、ＳＥＳ ４０のために必要とされる、イベントのタイプ（単純、追跡、条件付き）、重大度（１−１０００）、およびソース挿入ストリングインデックスなどのような情報を示すために、すべてのイベントがカスタマイズされる。

表１０
イベント イベントの記述
１ ユーザは、ＳＥＰフィルタスナップイン８６を開始する。スナップイン８６は、す べての登録済みメッセージテーブルをコンピュータに表示する。
２ ユーザは、所望のイベントをロギングするために使用されるメッセージテーブルを 選択する。スナップイン８６は、すべての含んでいるメッセージをリゾルトペイン に表示し、既存のフィルタテーブルファイルからの追加の値を更新する。ファイル が存在しない場合は、変更が保存された際に作成される。
３ ユーザは、ＳＥＰ ５２によりロギングされるべきメッセージを選択し、イベント を翻訳するために必要とされる追加情報をＯＰＣイベントに入力する。
４ ユーザはフィルタテーブル８４を保存する。
５ フィルタテーブル８４が、イベントをロギングするために必要となるすべてのコン ピュータに配信される（手動で、またはＷｉｎ２Ｋオフラインフォルダにより）。
６ ユーザは、ＳＥＰ ５２サービスを停止し、再開する。

ＨＣＩネームサービスは、ＨＣＩ／ＯＰＣサーバ別名のデータベースを構築し、維持する。クライアントアプリケーションは、そのサーバをホストするノードのＣＬＳＩＤ、ＰｒｏｇＩＤ、および名前を見つけるために、ネームサービスを使用する。ネームサービスへのアクセスは、既に開発済みのＨＣＩクライアントアプリケーションに後方互換性を提供するために、ＧｅｔＣｏｍｐｏｎｅｎｔＩｎｆｏ（）と同様にＨＣＩツールキットＡＰＩに統合される。

すべての管理されたノード上で別名の同期データベースが維持される。各ノードが、同期データベース範囲を決定するマルチキャストグループに割り当てられる。ノードが起動され、Ｗｉｎｄｏｗｓ（登録商標）サービス制御マネージャ（ＳＣＭ）がＨＣＩネームサービスを開始する。ノードは正確に構成され、マルチキャストグループに割り当てられる。表１１に示すように、そのグループの他のノードは既に動作中である。

表１１
イベント イベントの記述
１ ネームサービスがＳＲＰ ５６に登録する。
２ ネームサービスは、同期ソースを要求するためにＳＲＰ ５６に要求を送信する。
３ 遠隔ノードのＳＲＰ ５６が、その要求に応答する。
４ ネームサービスは、遠隔のネームサービスプロバイダにＷＭＩ接続を行うことによ り、応答側ノードと同期を取る。ネームサービスは、ソースノードのネームサービ スのすべてのインスタンスを列挙し、ホストのファイルエントリを除いてローカル レポジトリを初期設定する。
５ ネームサービスは、アクティブディレクトリ内のノードＴＰＳＤｏｍａｉｎ関連を 、そのノードが最後に起動された際に記録されたものと比較する。アクティブディ レクトリが使用可能でない場合、最後に記録されたＴＰＳＤｏｍａｉｎが使用され る。
ＴＰＳＤｏｍａｉｎが記録されており、変更が検出された場合、ノードが別のＴＰ ＳＤｏｍａｉｎに移動した場合に何が起こるかを記述したシナリオにスキップする 。
ＴＰＳＤｏｍａｉｎは、ノードのアクティブディレクトリ識別名に含まれる。ノー ドの識別名は、ＵＮＣ形式でレジストリに登録される。
６ ネームサービスは、ローカルレジストリに局所的に登録されたコンポーネントを照 会し、名前の重複がないかチェックする。
１．ＮＯＴが見つかった場合、同期ネームサービスレポジトリにそのコンポーネント が追加される。
２．見つかり、すべての情報が同じ場合、さらなるアクションは要求されない。
３．見つかり、サーバがＬｏｃａｌ Ｏｎｌｙの場合、それが複製エントリに取って 代わり、同期は取らない。
４．見つかり、それがドメインコンポーネントである場合、複製コンポーネント別名 イベントがアプリケーションログに書き込まれる。この複製されたイベントは、 システム状態ディスプレイ４６に示されるように、システムイベントフィルタテ ーブル８４内に構成される。
７ ネームサービスは、ＨＣＩホストのファイルを読み込み、名前の重複がないかチ ェックする。
１．ＮＯＴが見つかった場合、ローカルネームサービスレポジトリにそのコンポーネ ントが追加される。
２．見つかり、すべての情報が同じ場合、さらなるアクションは要求されない。
３．見つかり、情報が同じでない場合、複製コンポーネント別名イベントがアプリケ ーションログに書き込まれる。この複製されたイベントは、システム状態ディス プレイ４６に示されるように、システムイベントフィルタテーブル８４内に構成 される。

次に示すシナリオは、ＳＥＳ ４０に対するＯＰＣクライアント接続に関する詳細は記述しない。その代わり、このシナリオは、ＷＭＩ対ＳＥＳ４０の対話の背景の提供を試みる。

ＳＥＳ ４０は、ＳＥＰ ５２インスタンス作成および修正イベントに加入する。ＳＥＰ ５２は、システムイベントのその同期レポジトリを、指定のアクティブディレクトリ範囲内にあるすべてのコンピュータと同期化した状態に保つためにＳＲＰ ５６を利用する同期レポジトリである。表１２に示すように、ＳＥＳ ４０は、ＯＰＣクライアントに配信するためにＳＥＰイベントをＧＯＰＣ−ＡＥオブジェクトに提出することを担当する。

表１２
イベント イベントの記述
１ ＳＥＳ ４０は、条件データベースを含むＧＯＰＣ−ＡＥオブジェクトの作成を含 めて、すべての要求された初期設定を開始し、実行する。
２ ＳＥＳ ４０は、ｗｉｎｍｇｍｔ（ＷＭＩ）サーバを介してＳＥＰ ５２に接続す る。
３ ＳＥＳ ４０は、インスタンス作成および修正イベントに登録する。
４ ＳＥＳ ４０は、すべての既存のイベントインスタンスを列挙し、ＯＰＣ ＡＥイ ンターフェースを介して条件データベースを更新する。

ＳＥＳ ４０は、ＳＥＰ ５２インスタンス作成および修正イベントに加入する。ＳＥＰ ５２は、システムイベントのその同期レポジトリを、指定のアクティブディレクトリ範囲内にあるすべてのコンピュータと同期化した状態に保つためにＳＲＰ ５６を利用する同期レポジトリである。この範囲は、ＵＮＣ形式のアクティブディレクトリ経路で設定されたレジストリにより定義される。ＴＰＳドメインへの経路は、ＴＰＳドメイン組織ユニット（ＯＵ）を有するすべてのコンピュータが同期化されることを示す。ドメインレベルへの経路は、ＴＰＳドメインＯＵにかかわらず、ドメイン内のすべてのＳＥＰを同期化する。この設定は、システムステータスディスプレイ４６またはローカル構成ユーティリティから開始することのできる構成ページにより構成される。ユーザは、システムステータスディスプレイ４６を開始する。表１３に示すように、レジストリ構成が実行される必要があるので、すべてのコンピュータはオンラインであるべきである。

表１３
イベント イベントの記述
１ ユーザは、システム状態ディスプレイ範囲ペイン内のＳＥＳ ＨＣＩ Ｃｏｍｐｏ ｎｅｎｔをホストするノード上で右クリックし、コンテキストメニューでＨＣＩ Ｃｏｍｐｏｎｅｎｔ Ｅｎｔｒｙを選択する。
２ ＨＣＩコンポーネント構成ページが表示される。
３ コンポーネントの別名を選択する。
４ ＨＣＩコンポーネント構成ページ内の複数のフィールドを回復する。
５ ユーザは、ＨＣＩコンポーネント特有情報の複数のフィールドを修正する（チェッ クポイントファイル位置、ＯＰＣメソッドアクセスセキュリティプロキシファイル ）。
６ ユーザは、ＤＳＳ特有構成ページを呼び出し、マルチキャスト範囲フィールドを修 正する。最上位の同期が「^＊」経路を範囲に適用し、その結果、ＩＰマルチキャス トグループ内のすべてのノードが同期化される。
７ ユーザは、Ａｐｐｌｙを選択する。
８ データが、そのコンポーネントをホストするノードのレジストリに書き込まれる。 プロキシファイルが、そのコンポーネントをホストするノード上で自動的に作成さ れる。

次に、第２の好ましい実施形態を、図２〜４に示すのと同じノードコンピュータ３４を追加の特徴と共に利用するシステム２０に関して説明する。

フィルタ構成ツール
システムイベントフィルタ・スナップイン８６は、システムステータスディスプレイ４６と、そのための、キーボードおよび／またはマウス（図示せず）のような、ＮＴ−ＡＥおよびその特性をユーザが入力するための入力装置とを含む。その特性は、ＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知に変換するための追加情報を含む。例えば、この特性は、イベントのタイプ（条件、単純、または追跡）、イベントのソース（テキストおよびＮＴイベントログ挿入ストリングにより示される）、イベントの重大度（規定の値またはロギングされた値）、イベントのカテゴリ（表２６に例示の値に注意のこと）、イベントの条件（表２６に例示の値に注意のこと）、イベントのサブ条件（イベントの条件に基づく）、およびイベントの属性（イベントのカテゴリにより定義される）を含むことができる。ユーザは、フィルタテーブル８４にＮＴイベントを入力するためにシステムイベントフィルタ・スナップイン８６を使用する。そのＮＴイベントは、そのためにその通知がＯＰＣ−ＡＥ通知への変換のために渡されるべきものである。

図６〜１０を参照すると、システムイベントフィルタ・スナップイン８６は、ユーザに対して、イベントのタイプ（図６）、イベントのカテゴリ（図７）、イベントの条件（図８）、イベントのサブ条件（図９）、およびイベントの属性（図１０）を割り当てるための一連の選択ボックスを、システムステータスディスプレイ４６上で示す。

システムイベントサーバ（ＳＥＳ）の論理設計
再び図４を参照すると、ＳＥＳ ４０は、ＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知として公開するＨＣＩ管理コンポーネントである。ＳＥＳ ４０は、システムイベントを収集するためにいかなるＯＰＣ−ＡＥクライアントでも使用することのできる、ＯＰＣ−ＡＥ準拠インターフェースを公開する。ＳＥＳ ４０は、規定のコンピュータのセットからイベントを収集するためにＳＥＰ ５２を利用する。ＳＥＰ ５２は、ロギングされた複数のＮＴ−ＡＥ通知を受信し、フィルタファイルに基づいてそれらの通知をフィルタリングする。そのフィルタを通過するＮＴ−ＡＥ通知に、ＯＰＣ−ＡＥ通知を生成するために必要とされる追加の質が補われる。ＳＥＰ ５２は、活動状態の条件関連イベントのマップを維持し、取って代わられた条件イベントの自動的な非活動化を提供する。ＳＥＰ ５２生成イベントが、ＯＰＣ−ＡＥ通知として配信されるためにＳＥＳ ４０に渡される。ＳＥＳ ４０は、イベントデータをＯＰＣ−ＡＥ通知としてパッケージし、条件関連ＯＰＣ−ＡＥの状態を追跡するために使用されるローカル条件データベースを維持することを担当する。

有効な条件状態を含めるよう、ローカル条件データベースを初期設定するために、ＳＥＰ ５２は、起動中に、ノード起動以来の、または最後のＳＥＰ ５２シャットダウン以来のロギングされたすべてのイベントをスキャンする。次いでＳＥＰ ５２は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ＮＴＥｖｅｎｔＬｏｇプロバイダからの変更通知の処理を開始する。

イベント増補
ＯＰＣ−ＡＥ通知を作成する際にＮＴログイベント情報を増補するために要求される追加データを定義するために、システムイベントフィルタ・スナップイン８６が使用される。システムイベントフィルタ・スナップイン８６はＯＰＣ−ＡＥタイプを構成し、そのイベントがＡＣＫ可能か否かにかかわらず、その項目が条件関連の場合はその条件がそのイベントに割り当てられる。イベントが条件関連イベントのタイプであると定義されている場合、そのイベントは単発イベント（ＩＮＡＣＴＩＶＥ）であるか、または対応する通常状態復帰イベント（ＡＣＴＩＶＥ）を公開する条件である場合がある。ＡＣＴＩＶＥと示されたイベントは、その条件を非活動化するよう定義された関連付けられたイベントを有する必要がある。

Ｗｉｎｄｏｗｓ（登録商標）イベントの重大度は必ずしも所望のＯＰＣ−ＡＥの重大度に直接翻訳されるわけではないので、ＯＰＣ−ＡＥの重大度が各イベントのタイプに割り当てられる。ＯＰＣ−ＡＥの重大度値を割り当てるために、システムイベントフィルタ・スナップイン８６が使用される。０という重大度が指定された場合、元のＮＴ−ＡＥに割り当てられたイベントの重大度は、事前に割り当てられたＯＰＣ−ＡＥの重大度値に翻訳される。ＳＥＳはサブ条件を利用しない。Ｃｏｎｄｉｔｉｏｎサブ条件は、条件名の複製である。

イベントの保守
ＳＥＳ ４０は、ＳＥＰ ５２生成イベントに加入する。ＳＥＰ ５２は、ＳＲＰ ５６によりすべてのノードにわたり同期化される、条件関連イベントの状態を保守することを担当する。すべての条件関連イベントおよびそれらの状態への変更は、認知を含めて、構成されたアクティブディレクトリ範囲内に含まれるすべてのＳＥＰに及ぶものである。既存の条件に対するすべての新しい条件および変更は、ＯＰＣＣｏｎｄｉｔｉｏｎＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎｓを生成する。含まれるＣｈａｎｇｅＭａｓｋは、変更済みの条件に対する値を反映する。条件が認知された場合、ＳＥＰ ５２は追跡イベントを生成する。

ＳＥＳ ４０により、ＳＥＰ ５２から、ＷＭＩ＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅｎｔｓ（インテンス作成イベント）として新しい条件関連イベントが受信される。活動状態にある認知および変更は、ＷＭＩ＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔｓ（インテンス修正イベント）に反映される。条件が認知され、かつクリアされた場合、ＷＭＩ＿ＩｎｓｔａｎｃｅＤｅｌｅｔｉｏｎＥｖｅｎｔ（インテンス削除イベント）が配信される。単純イベントおよび追跡イベントがＷＭＩ＿ＥｘｔｒｉｎｓｉｃＥｖｅｎｔｓとして配信され、いかなるレポジトリにも含まれない。

単純イベントおよび追跡イベントに関しては、同期（すべてのリスンするノードに対するマルチキャスト配信を超えて）も、状態の保全もない。これらのイベントは、それらの配信時に接続されたクライアントによってのみ受信される。条件関連イベントを保全するために、ＳＥＰ ＴＰＳ＿ＳｙｓＥｖｔクラスが使用される。単純イベントおよび追跡イベントを配信するために、ＴＰＳ＿ＳｙｓＥｖｔ＿Ｅｘｔクラスが使用される。

イベントの回復
すべての条件イベントは、ＳＥＰ ５２レポジトリで維持される。ＳＥＰ ５２レポジトリは、その構成された範囲内にあるすべてのノードにわたり同期化される。そのネットワーク接続を失うかまたはクラッシュするいかなるノードでも、その条件が訂正された場合は、複数の同期化した表示のうちの１つの表示で、それ自体の表示をリフレッシュする。条件イベントは、そのイベントのソースであるノードにより維持される。同期化中に現在のローカル状態と一致しないローカルノードをソースとするものであると示された条件イベントは、ＳＥＰ ５２により非活動化される。

単純イベントおよび追跡イベントは、同期化されず回復不可能である。ロギングノードにより、条件状態の維持が実行される。次いで状態がすべての他のノードと同期化される。ノードのいかなる組合せの損失でも、このイベント表示の有効性に影響を与えない。

条件タイムスタンプは、条件活動化時間に基づいており、回復リフレッシュにより変更されることはない。

ブラウジング
ＳＥＳ ４０は、階層ブラウジングをサポートする。構成済みＳＥＰ５２範囲内に含まれるアクティブディレクトリオブジェクトにより、エリアが定義される。階層エリア構文は、アクティブディレクトリ命名条件とは逆順であり、順序を入れ替える必要がある。エリア名の形式は、
＼＼ＲｏｏｔＡｒｅａ＼Ａｒｅａ１＼Ａｒｅａ２
である。ここで、ＲｏｏｔＡｒｅａ、Ａｒｅａ１、およびＡｒｅａ２は、アクティブディレクトリドメインまたは組織ユニットオブジェクトであり、Ａｒｅａ２はＡｒｅａ１により含まれ、Ａｒｅａ１はＲｏｏｔＡｒｅａにより含まれる。

ＳＥＳ ４０は、ＳＥＰ ５２の範囲内で定義されたアクティブディレクトリレベルから始めて、アクティブディレクトリツリー内を移動する。この構造の内部表現は、ブラウジングをサポートし、アクティブディレクトリ構成における変更の検出のために維持される。ＳＥＳ ４０ソースは、通常、ＳＥＰ ５２のアクティブディレクトリ範囲内で定義されたエリア内のコンピュータおよびコンポーネントである。１つのコンピュータをソースとするが、報告すべき特定エンティティを有しないイベントは、ロギングしているコンピュータの名前をそのソースとして使用する。そのコンピュータに常駐する特定エンティティに関するイベントは、ソース名の形式、ＣＯＭＰＵＴＥＲ．ＣＯＭＰＯＮＥＮＴ（例えば、ＣＯＭＰＵＴＥＲ１．ＰＫＳ＿ＳＥＲＶＥＲ＿０１）を使用する。含まれるコンピュータは、各エリアにソースとして追加される。他のソース（例えば、ソース名慣例付き管理コンポーネント、Ｓｏｕｒｃｅ．Ｃｏｍｐｏｎｅｎｔ）が、活動状態のイベントが受信された際に動的に追加される。

イネーブル／ディセーブル
１つのＳＥＳ上の複数のイベントのイネーブルまたはディセーブルは、他のＳＥＳが同じ範囲内にあるか異なる範囲内にあるかにかかわらず、それらのＳＥＳには影響を与えない。宛先変更マネージャ（ＲＤＭ）が使用される場合、ＲＤＭは、重複しているＳＥＳ接続上のエリアおよびソースをイネーブルまたはディセーブルし、同期化した表示を保全する。イネーブル／ディセーブルは、同一ＳＥＳに接続されたすべてのクライアントに及ぶ。

ＳＥＳサブシステム
ＳＥＳ ４０は、ＯＰＣ互換警報およびイベント（ＡＥ）インターフェースを提供するために、ＨＣＩ実行時を利用する。ＨＣＩ実行時およびＧＯＰＣ＿ＡＥオブジェクトは、すべてのＯＰＣクライアント通信および条件データベースの維持を実行する。デバイス特有サーバの機能は、ＳＥＳデバイス特有オブジェクト（ＤＤＳＯｂｊｅｃｔ）で実施される。このオブジェクトは、ＳＥＰ ５２からイベントを取り出し、ＳＥＰ ５２イベント通知をＧＯＰＣ＿ＡＥに転送する、イベント管理オブジェクトの単一インスタンスを作成する。さらに、単一オブジェクトは、サーバエリアおよび含まれるソースを定義するために使用されるアクティブディレクトリ構成の表示を維持する。

ＳＥＳ内のデータベース
次に示す参照マップが維持される。

表１４−ＳＥＳ内部マップ

階層エリアおよびソースマップ アクティブディレクトリコンテナ（エリア）と含まれ るイベントソースとを表すオブジェクトの階層マッピ ング。このマップは、エリア内複数エリアおよびエリ ア内複数ソースを戻すために使用される。アクティブ ディレクトリ階層内の変更を特定するために、アクテ ィブディレクトリの定期的スキャンを実行する際にも 使用される。
ＷＭＩイベントガイドへのＯＰ
Ｃイベントのクッキーのマップ
ＯＰＣクライアントが１つのイベントを認知する場合 にＷＭＩインスタンス署名を検索するために使用され る。

ＳＥＳ ４０動作を監視するために、次に示す性能カウンタが維持される。

表１５−ＳＥＳ性能カウンタ
カウンタ タイプ 記述
接続されたクライアント ＲＡＷＣＯＵＮＴ 現在のクライアント接続数（予約され ていないＤｓｓＯｂｊｅｃｔインスタ ンス）
ロギングされたイベント ＲＡＷＣＯＵＮＴ サーバ起動以来処理されたイベント数
秒当たりのロギングされ
たイベント ＣＯＵＮＴＥＲ 過去１秒間に処理されたイベント数（ 「ロギングされたイベント」から導出 ）
ロギングされた条件イベント ＲＡＷＣＯＵＮＴ サーバ起動以来処理されたＡＣＫ可能 なイベント数
秒当たりのロギングされた
条件イベント ＣＯＵＮＴＥＲ 過去１秒間に処理されたＡＣＫ可能な イベント数（「ロギングされたＡＣＫ 可能なイベント」から導出）
ロギングされた単純イベント ＲＡＷＣＯＵＮＴ 受信した単純イベント数
秒当たりのロギングされた
単純イベント ＣＯＵＮＴＥＲ 過去１秒間に処理された単純イベント 数（「ロギングされた単純イベント」 から導出）
ロギングされた追跡イベント ＲＡＷＣＯＵＮＴ 受信した追跡イベント数
秒当たりのロギングされた
追跡イベント ＣＯＵＮＴＥＲ 過去１秒間に処理された追跡イベント 数（「ロギングされた追跡イベント」 から導出）

システムイベントサーバ（ＳＥＳ）内のインターフェース
図５を参照すると、ＳＥＳ ４０は、ＯＰＣ−ＡＥクライアント８０に対して複数のインターフェース９０を公開する。インターフェース９０は、ＨＣＩ実行時コンポーネント９２により実現される。内部では、ＳＥＳ ４０が、標準ＨＣＩ実行時定義インターフェースを介してＨＣＩ実行時コンポーネント９２と通信する、ＤＳＳオブジェクト９４として示されるデバイス特有サーバオブジェクトを実施する。ＤＳＳオブジェクト９４は、すべてのサーバ特有実施態様を提供する。

システムイベントサーバＤＳＳオブジェクトは、
ＩＨｃｉＤｅｖｉｃｅＳｐｅｃｉｆｉｃ＿Ｃｏｍｍｏｎ、ＩＨｃｉＤｅｖｉｃｅＳｐｅｃｉｆｉｃ＿ＡＥ、ＩＨｃｉＤｅｖｉｃｅＳｐｅｃｉｆｉｃ＿Ｓｅｃｕｒｉｔｙ、ＩＨｃｉＤｅｖｉｃｅＳｐｅｃｉｆｉｃＣｏｕｎｔｅｒｓ、およびＩＨｃｉＤｅｖｉｃｅインターフェースを実施する。

（ＨＣＩ実行時を介して）クライアントにエリアおよびソースの可用性の変更を通知するために、ＨＣＩ実行時ＩＨｃｉＳｉｎｋ＿Ｃｏｍｍｏｎインターフェースが使用される。

クライアントに新しいイベントおよび修正されたイベントを通知するために、ＩＨｃｉＳｉｎｋ＿ＡＥ ＧＯＰＣ＿ＡＥインターフェースが使用される。ＧＯＰＣ＿ＡＥ／ＳＥＳ接続状態を確認するために、このインターフェースで定期的な（４秒）ハートビート通知が送られる。ＤＳＳ接続が有効でない場合（消失ハートビートまたはアクセスエラー）、ＳＥＳ ４０は、ＤＳＳ通信エラーを示すイベント（フィルタテーブルでＤＥＶＣＯＭＭＥＲＲＯＲ条件と示される）をロギングし、ＩＨｃｉＤｅｖｉｃｅ：：ＧｅｔＤｅｖｉｃｅＳｔａｔｕｓ（）によりＣＡＳ ４８が取り出した状態の問題を反映する。ＧＯＰＣ＿ＡＥ ＩＨｃｉＳｉｎｋ＿ＡＥインターフェース上のハートビートが一時停止され、したがってＧＯＰＣ＿ＡＥオブジェクトへの通信の障害が示される。接続が回復された場合、ＳＥＳ ４０は別のイベント（フィルタテーブル８４で非活動状態にあるＤＥＶＣＯＭＭＥＲＲＯＲ条件として示される）をロギングし、そのデバイス状態を更新する。このハートビートは、ＧＯＰＣ＿ＡＣに回復され、これにより、ＳＥＳ ＤＳＳオブジェクトリフレッシュ（）メソッドに対してＧＯＰＣ＿ＡＥにより呼び出しがトリガされる。ＳＥＳ ＤＳＳオブジェクトは、回復されたＳＥＰ接続からすべてのインスタンスを列挙し、各インスタンスをｂＲｅｆｒｅｓｈフラグセットと共にＧＯＰＣ＿ＡＥシンクインターフェースに書き込む。ＳＥＳ ＤＳＳオブジェクト９４は、ＧｅｔＤｅｖｉｃｅＳｔａｔｕｓ（）メソッドをコンポーネントＡｄｍｉｎサービス（ＣＡＳ）に公開する、任意選択のＩＨｃｉＤｅｖｉｃｅインターフェースを実施する。ＳＥＳ ４０は、イベント通知接続の状態を反映するために、このインターフェースを実施する。ＳＥＰ接続がまだ確立していないか、または現在切断中であることを示すために、障害のあるデバイス状態が戻される。同様に、ＳＥＰ ５２は、ＳＲＰに対するその接続内のエラーを、エラー通知によりＳＥＳ ４０まで反映する。ＧｅｔＤｅｖｉｃｅＳｔａｔｕｓ（）により戻されるデバイス情報フィールドは、基礎となる接続問題を記述するストリングを含む。

ＳＥＳ ＤＳＳオブジェクト９４は、ＤＳＳ性能カウンタをサポートするために、ＩＨｃｉＤｅｖｉｃｅＳｐｅｃｉｆｉｃＣｏｕｎｔｅｒｓインターフェースも実施する。
ＨｓｉＥｖｅｎｔＬｏｇＡＰＩを使用して、サーバイベントロギングが実行される。ＳＥＳ ４０に対するＨＣＩコンポーネント構成値が、ＩＴｐｓＲｅｇｉｓｔｒｙインターフェースを使用して取り出される。

第２の実施形態の論理設計シナリオ
管理コンポーネントは、状態をＦＡＩＬＥＤ状態に変更する。表１６に示すように、条件イベントは、ＯＰＣクライアントに対して生成する必要がある。

表１６−条件イベントが生成される−新しい活動状態警報
イベント イベントの記述
１ 管理コンポーネントがＦＡＩＬＥＤ状態に入る。
２ ＣＡＳ ４８は、その状態変更を検出し、Ｗｉｎｄｏｗ（登録商標）イベントをロ ギングする。
３ ＳＥＰ ５２サービスは、このイベントの通知を受け、そのフィルタテーブルを検 査する。
４ コンポーネント状態変更イベントが、フィルタテーブルで活動状態条件関連イベン トと示される。
５ ＴＰＳ＿ＳｙｓＥｖｔクラスインスタンスが作成され、フィルタテーブル情報がイ ベントオブジェクトに設定される。
６ ＳＥＰ ５２が、現在活動状態にある条件イベントに関するソース対条件イベント のそのマップをチェックし、何も見つからない。
７ ＳＥＰ ５２が、＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅｎｔを作成し、ＴＰ Ｓ＿ＳｙｓＥｖｔインスタンスを挿入する。＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎ ＥｖｅｎｔをＳＲＰ ５６に渡す。
８ ＳＲＰ ５６は、この＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅｎｔをすべての ＳＥＰ ５２に配信（マルチキャスト）する。
９ すべてのＳＥＰは、そのイベントを受信し、受信したイベントを接続されたクライ アントに通知する。
１０ ＳＥＳ ４０は、そのイベント通知を受信する。
１１ そのイベント情報は、ＯＰＣ−ＡＥイベント通知に変換され、１つまたは複数の 加入ＯＰＣ−ＡＥクライアントに送られる。

管理コンポーネントは、既にＷＡＲＮＩＮＧ状態に入っている。これにより、活動状態条件警報が生成された。次にこのコンポーネントはＦＡＩＬＥＤ状態に移行し、新しい活動状態条件を生成する。表１７に示すように、以前の条件は最早活動状態ではない。

表１７−条件イベントが生成される−活動状態警報が存在する
イベント イベントの記述
１ 管理コンポーネントが、ＷＡＲＮＩＮＧ状態からＦＡＩＬＥＤ状態に移行する。
２ ＣＡＳ ４８は、この状態変更を検出し、Ｗｉｎｄｏｗ（登録商標）イベントをロ ギングする。
３ ＳＥＰ ５２サービスは、このイベントの通知を受け、そのフィルタテーブルを検 査する。
４ コンポーネント状態変更イベントが、フィルタテーブルで活動状態条件関連イベン トと示される。
５ ＴＰＳ＿ＳｙｓＥｖｔクラスオブジェクトが作成され、フィルタテーブル情報が設 定される（ＥｖｅｎｔＢ）。
６ ＳＥＰ ５２は、現在活動状態にある条件イベントに関するソース対条件イベント のそのマップをチェックし、ＷＡＲＮＩＮＧ条件警報が見つかる（ＥｖｅｎｔＡ） 。
７ （ＥｖｅｎｔＡ）ＷＡＲＩＮＩＮＧ条件警報を含むＴＰＳ＿ＳｙｓＥｖｔオブジェ クト（ステップ６にある）がＩＮＡＣＴＩＶＥに設定される。
８ （ＥｖｅｎｔＡ）ＳＥＰ ５２は、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎ Ｅｖｅｎｔを作成し、その非活動化されたＷＡＲＮＩＮＧ条件イベントＴＰＳ＿Ｓ ｙｓＥｖｔオブジェクトを挿入する。
９ （ＥｖｅｎｔＡ）ＳＥＰ ５２は、修正イベントをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベントをすべてのＳＥＰに配信する。
１０ （ＥｖｅｎｔＡ）すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイ ベントを接続されたクライアント（ＳＥＳ）に通知する。
１１ （ＥｖｅｎｔＡ）ＳＥＳ ４０は、非活動化されたＷＡＲＮＩＮＧ条件イベント 通知を受信する。
１２ （ＥｖｅｎｔＡ）非活動化されたイベント情報がＯＰＣ−ＡＥイベント通知に変 換され、１つ以上の加入ＯＰＣクライアントに送られる。
１３ （ＥｖｅｎｔＢ）ＳＥＰ ５２は、＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅ ｎｔを作成し、新しいＦＡＩＬＥＤ条件イベントＴＰＳ＿ＳｙｓＥｖｔオブジェク トを挿入する。
１４ （ＥｖｅｎｔＢ）ＳＥＰ ５２は、＿ＩｎｓｔａｎｃｅＣｒｅａｔｉｏｎＥｖｅ ｎｔをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベントをすべてのＳＥＰ ５ ２に配信する。
１５ （ＥｖｅｎｔＢ）すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイベ ントを接続されたクライアント（ＳＥＳ）に通知する。
１６ （ＥｖｎｅｔＢ）ＳＥＳ ４０は、非活動化されたＷＡＲＮＩＮＧ条件イベント通 知を受信する。
１７ （ＥｖｅｎｔＢ）そのイベント情報は、ＯＰＣ−ＡＥイベント通知に変換され、１ つ以上の加入ＯＰＣクライアントに送られる。

障害のある管理コンポーネント（活動状態にあるイベントが存在する）が再開され、最終的にＩＤＬＥ状態に移行する。これは、表１８に示すように、システムイベントフィルタテーブルで通常状態復帰と示される。

表１８−条件イベントが生成され、未認知イベントで通常状態に戻される。
イベント イベントの記述
１ 管理コンポーネントは、ＩＤＬＥ状態に移行する。
２ ＣＡＳ ４８は、この状態変更を検出し、Ｗｉｎｄｏｗイベントをロギングする。
３ ＳＥＰ ５２サービスは、このイベントの通知を受け、そのフィルタテーブルを検 査する。
４ コンポーネント状態変更イベントが、フィルタテーブルで非活動状態の未認知条件 関連イベントと示される。
５ ＳＥＰ ５２は、現在活動状態にある条件イベントに関するソース対条件イベント のそのマップをチェックし、ＦＡＩＬＥＤ条件警報が見つかる。
６ ＦＡＩＬＥＤ条件警報を含むＴＰＳ＿ＳｙｓＥｖｔオブジェクト（ステップ５にあ る）がＩＮＡＣＴＩＶＥにセットされる。
７ ＳＥＰ ５２は、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔを作成 し、その非活動化されたＦＡＩＬＥＤ条件イベントＴＰＳ＿ＳｙｓＥｖｔオブジェ クトを挿入する。
８ ＳＥＰ ５２は、修正イベントをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベ ントをすべてのＳＥＰ ５２に配信する。
９ すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイベントを接続された クライアント（ＳＥＳ）に通知する。
１０ ＳＥＳ ４０は、非活動化されたＷＡＲＮＩＮＧ条件イベント通知を受信する。
１１ 非活動化されたイベント情報は、ＯＰＣ−ＡＥイベント通知に変換され、１つま たは複数の加入ＯＰＣクライアントに送られる。

イベントは、下のシステムステータスディスプレイ４６または別のＳＥＳ（ＳＥＰを介して）から認知するか、または上のＨＣＩ実行時インターフェースから認知することができる。このシナリオで、認知はＳＥＰ ５２にまであがってくる。認知が別のＳＥＳノード由来かシステム管理ディスプレイ由来かにかかわらず、動作は同じである。

表１９−条件イベントがＳＥＰから認知される−イベントは活動状態にある
イベント イベントの記述
１ ユーザは、システム状態ディスプレイ４６からのイベントをＡＣＫする。システム 状態ディスプレイ４６は、ＳＥＰ ５２上のＡＣＫメソッドを呼び出す。
２ ＳＥＰ ５２は、そのレポジトリ内にある参照されるＴＰＳ＿ＳｙｓＥｖｔオブジ ェクトを検索し、ＡＣＫされたプロパティをＴＲＵＥにセットする。Ｍｏｄｉｆｉ ｃａｔｉｏｎＳｏｕｒｃｅプロパティは、ローカルコンピュータ名にセットされる 。
３ ＳＥＰ ５２は、参照されるイベントオブジェクトに対して＿ＩｎｓｔａｎｃｅＭ ｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔを生成し、修正されたＴＰＳ＿ＳｙｓＥｖｔオ ブジェクトを挿入する。
４ ＳＥＰ ５２は、条件認知を追跡するために追跡イベントと解釈されるべきＮＴイ ベントをロギングする。
５ ＳＥＰ ５２は、そのイベントをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベ ントをすべてのＳＥＰ５２に配信する。
６ すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイベントを接続された クライアントに通知する。
７ ＳＥＳ ４０は、イベント修正通知を受信する。
８ 認知されたイベント情報は、ＯＰＣ−ＡＥイベント通知に変換され、１つまたは複 数の加入ＯＰＣクライアントに送られる。

表２０に示すように、ＯＰＣクライアントは、活動状態にある条件イベントを認知する。

表２０−条件イベントはＯＰＣクライアントから認知される−イベントは活動状態にある
イベント イベントの記述
１ ユーザは、ＯＰＣクライアントからのイベントを認知する。
２ ＳＥＳ ４０は、クッキーにより署名されたＷＭＩイベントを検索する。
３ ＳＥＳ ４０は、ステップ２で取り出されたイベント署名に対してＳＥＰ ＡＣＫ （）メソッドを呼び出す。
４ ＳＥＰ ５２は、指定されたイベントＡＣＫおよびＭｏｄｉｆｉｃａｉｔｏｎＳｏ ｕｒｃｅプロパティを修正する。
５ ＳＥＰ ５２は、＿ＩｎｓｔａｎｃｅＭｏｄｉｆｉｃａｔｉｏｎＥｖｅｎｔを生成 し、それに修正されたＴＰＳ＿ＳｙｓＥｖｔをポピュレートし、それをＳＲＰ ５ ６に送信する。
６ ＳＲＰ ５６は、その修正イベントをすべてのＳＥＰ ５２に送る。
７ ＳＥＰ ５２は、その変更通知を受信し、ローカルレポジトリを更新し、その変更 をＳＥＳ ４０に転送する。
８ ＳＥＳ ４０は、その変更通知を受信する。
９ ＡＣＫ状態が既に修正されているので、変更はなく、１つまたは複数のＯＰＣクラ イアントに対してイベントは生成されない。
注意：重複しているＳＥＳの観点からすると、ＡＣＫ状態は異なり、重複している サーバ上の１つまたは複数のＯＰＣクライアントおよびその重複しているサーバに 接続されたいかなるクライアントに対しても条件変更が生成される。

非活動状態にあるイベントが、ＳＥＰ ＷＭＩインターフェース（例えば、システムステータスディスプレイ４６）を介して認知される。表２１に示すように、非活動状態にある、認知されたイベントが、イベントレポジトリから除去される。

表２１−条件イベントがＳＥＰから認知される−イベントは非活動状態である
イベント イベントの記述
１ ユーザは、システム状態ディスプレイ４６からのイベントをＡＣＫする。システム 状態ディスプレイ４６は、ＳＥＰ ５２上のＡＣＫメソッドを呼び出す。
２ ＳＥＰ ５２は、参照されるＴＰＳ＿ＳｙｓＥｖｔオブジェクトを検索し、そのイ ベントが非活動状態であることを確認する。ＡＣＫされたプロパティがＴＲＵＥに セットされる。ＭｏｄｉｆｉｃａｔｉｏｎＳｏｕｒｃｅプロパティが、ローカルコ ンピュータ名にセットされる。
３ このイベントは、現在非活動状態であり、かつ認知されているので、ＳＥＰ ５２ は、＿ＩｎｓｔａｎｃｅＤｅｌｅｔｉｏｎＥｖｅｎｔを生成し、その修正されたＴ ＰＳ＿ＳｙｓＥｖｔオブジェクトを挿入する。
４ ＳＥＰ ５２は、条件認知を追跡するために追跡イベントと解釈されるべきＮＴイ ベントをロギングする。
５ ＳＥＰ ５２は、そのイベントをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベ ントをすべてのＳＥＰ５２に配信する。
６ すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイベントを接続された クライアント（ＳＥＳ）に通知する。ＴＰＳ＿ＳｙｓＥｖｔオブジェクトがＳＥＰ イベントレポジトリから除去される。
７ ＳＥＳ ４０は、イベント削除通知を受信する。
８ 認知されたイベント情報は、ＯＰＣ−ＡＥイベント通知に変換され、１つまたは複 数の加入ＯＰＣクライアントに送られる。

ＯＰＣクライアントは、非活動状態にある条件イベントを認知する。表２２に示すように、その非活動状態にある、認知されたイベントが、イベントレポジトリから除去される。

表２２−条件イベントはＯＰＣクライアントから認知される−イベントは非活動状態にる
イベント イベントの記述
１ ユーザは、ＯＰＣクライアントからのイベントを認知する。
２ ＳＥＳ ４０は、クッキーにより署名されたＷＭＩイベントを検索する。
３ ＳＥＳ ４０は、上記で取り出されたイベント署名を使用してＳＥＰ ＡＣＫ（） メソッドを呼び出す。
４ ＳＥＰ ５２は、参照されるＴＰＳ＿ＳｙｓＥｖｔオブジェクトを検索し、そのイ ベントが非活動状態であることを確認する。ＡＣＫされたプロパティがＴＲＵＥに セットされる。ＭｏｄｉｆｉｃａｔｉｏｎＳｏｕｒｃｅプロパティが、ローカルコ ンピュータ名にセットされる。
５ そのイベントは、現在非活動状態であり、かつ認知されているので、ＳＥＰ ５２ は、＿ＩｎｓｔａｎｃｅＤｅｌｅｔｉｏｎＥｖｅｎｔを生成し、その修正されたＴ ＰＳ＿ＳｙｓＥｖｔオブジェクトを挿入する。
６ ＳＥＰ ５２は、条件認知を追跡するために追跡イベントと解釈されるべきＮＴイ ベントをロギングする。
７ ＳＥＰ ５２は、そのイベントをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベ ントをすべてのＳＥＰ５２に配信する。
８ すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイベントを接続された クライアント（ＳＥＳ）に通知する。１つまたは複数のＳＥＳ ５２は、それら自 体のレポジトリからＴＰＳ＿ＳｙｓＥｖｔオブジェクトを除去する。
９ ＳＥＳ ４０は、イベント削除通知を受信する。
１０ 条件は既に削除されているので、１つまたは複数のＯＰＣクライアントに対して イベントは生成されない。
注意：重複しているＳＥＳの観点からすると、ＡＣＫ状態は異なり、重複している サーバ上の１つまたは複数のＯＰＣクライアントおよびその重複しているサーバに 接続されたいかなるクライアントに対しても条件変更が生成される。

ＦＡＩＬＥＤの管理コンポーネントが再開され、最終的にＩＤＬＥ状態に移行する。これは、表２３に示すように、システムイベントフィルタテーブルで通常状態復帰条件イベントと示される。

表２３−条件イベントが生成され、認知されたイベントで通常状態に戻される
イベント イベントの記述
１ 管理コンポーネントが、ＩＤＬＥ状態に移行する。
２ ＣＡＳ ４８は、この状態変更を検出し、Ｗｉｎｄｏｗ（登録商標）イベントをロ ギングする。
３ ＳＥＰ ５２サービスは、イベントの通知を受け、そのフィルタテーブルを検査す る。
４ コンポーネント状態変更イベントが、フィルタテーブルで非活動状態にある、未認 知可能条件関連イベント（通常状態に戻る）と示される。
５ ＳＥＰ ５２は、現在活動状態にある条件イベントに関するソース対条件イベント のそのマップをチェックし、ＦＡＩＬＥＤ条件警報が見つかる。
６ ＦＡＩＬＥＤ条件警報を含むＴＰＳ＿ＳｙｓＥｖｔオブジェクトがＩＮＡＣＴＩＶ Ｅにセットされる。
７ このイベントは、現在非活動状態であり、かつ認知されているので、ＳＥＰ ５２ は、＿ＩｎｓｔａｎｃｅＤｅｌｅｔｉｏｎＥｖｅｎｔを生成し、修正されたＴＰＳ ＿ＳｙｓＥｖｔオブジェクトを挿入する。
８ ＳＥＰ ５２は、条件認知を追跡するために追跡イベントと解釈されるべきＮＴイ ベントをロギングする。
９ ＳＥＰ ５２は、イベントをＳＲＰ ５６に発行し、ＳＲＰ ５６はそのイベント をすべてのＳＥＰ５２に配信する。
１０ すべてのＳＥＰ ５２は、そのイベントを受信し、受信したイベントを接続され たクライアント（ＳＥＳ）に通知する。１つまたは複数のＳＥＰは、それら自体 のレポジトリからＴＰＳ＿ＳｙｓＥｖｔオブジェクトを除去する。
１１ ＳＥＳ ４０は、イベント削除通知を受信する。
１２ 認知されたイベント情報は、ＯＰＣ−ＡＥイベント通知に変換され、１つまたは 複数の加入ＯＰＣクライアントに送られる。

表２４に示すように、ＯＰＣクライアントは、ＳＥＳのインスタンスを作成し、イベント通知に加入する。

表２４−ＯＰＣクライアントが、ＳＥＳイベントに加入する
イベント イベントの記述
１ ＯＰＣクライアントが、ＳＥＳ ４０のアウトオブプロセスインスタンスを作成す る。
２ ＳＥＳ ４０サーバオブジェクトが作成され、アウトオブプロセスクライアントに 対してインターフェースが整理される。
３ ＯＰＣクライアントは、インプロセスＩＯＰＣＥｖｅｎｔＳｉｎｋオブジェクトを 作成する。
４ ＯＰＣクライアントは、ＩＯＰＣＥｖｅｎｔＳｅｒｖｅｒ：：ＣｒｅａｔｅＥｖｅ ｎｔＳｕｂｓｃｒｉｐｔｉｏｎ（）の呼び出しから、ＩＣｏｎｎｅｃｔｉｏｎＰｏ ｉｎｔＣｏｎｔａｉｎｅｒインターフェースを得る。
５ ＯＰＣクライアントは、クライアントＩＯＰＣＥｖｅｎｔＳｉｎｋオブジェクトの ＩＵｎｋｏｗｎポインタを通過させるＳＥＳ ４０のＩｃｏｎｎｅｃｔｉｏｎＰｏ ｉｎｔＣｏｎｔｉｎｅｒインターフェース上でＡｄｖｉｓｅ（）を呼び出す。
６ このインターフェース上のＩＯＰＣＥｖｅｎｔＳｕｂｓｃｒｉｐｔｉｏｎＭｇｔ２ インターフェースに対するＯＰＣクライアントＱｌｓが、ＣｒｅａｔｅＥｖｅｎｔ Ｓｕｂｓｃｒｉｐｔｉｏｎ（）から戻る。
７ ＯＰＣクライアントは、コールバックインターフェース上のハートビートの賦活間 隔をセットするために、ＩＯＰＣＥｖｅｎｔＳｕｂｓｃｒｉｐｔｉｏｎＭｇｔ２： ：ＳｅｔＫｅｅｐＡｌｉｖｅ（）を呼び出す。
８ ＳＥＳ ４０は、ＩＯＰＣＥｖｅｎｔＳｉｎｋ：：ＯｎＥｖｅｎｔ（）メソッドを 使用してクライアントに新しいイベントを送信する。賦活が満了する間際になって もイベントがまったく生成されていない場合、１つの賦活が生成される。

ＯＰＣクライアントは、ＳＥＳ ４０のインスタンスを作成し、イベント通知に加入する。表２５に示されるように、コールバック接続が失われる。

表２５−ＯＰＣクライアントが、ＳＥＳへの接続を失う
イベント イベントの記述
１ 表２７「ＯＰＣクライアントがＳＥＳイベントに加入する」にあるように、ＯＰＣ クライアントがＳＥＳイベントに加入する。
２ ネットワークまたは他の接続が、接続されたＯＰＣクライアントに対するコールバ ック接続を変則的に切断する。
３ 特定の保持活動間隔が満了するまで、ＯＰＣクライアントはイベントを受信しない 。
４ ＯＰＣクライアントが、接続ポイントにＵｎａｄｖｉｓｅ（）する（問題が厳密に コールバックに関する事項である場合）。
５ Ｕｎａｄｖｉｓｅが成功した場合、クライアントは複数のイベントへの再加入を選 択することができる。
６ Ｕｎａｄｖｉｓｅが失敗した場合、クライアントは、そのＳＥＳ参照を解放し、再 度完全な再接続シナリオを実行する。
注意：多くの場合、これは、「いかなる」コールバック問題に対しても好ましい処 置である。ＳＥＳの新しいインスタンスを解放し、再インスタンス生成することに より、ＤＣＯＭは、そのキャッシュから古いインターフェースを確実にフラッシュ する。

頑強性および安全性
ＨＣＩ実行時は、ＯＰＣ−ＡＥコールバックに対してハートビートを実施する。クライアントは、そのコールバック接続が動作可能であることを確認するためにこのハートビートを使用する。ＳＥＳ ４０は、宛先変更マネージャ（ＲＤＭ）を使用して重複した動作をサポートする。ＳＥＳ ４０は、それ自体が重複した構成で動作中であることに気付いていない。重複しているＳＥＳ ４０サーバにアクセスようにＲＤＭを構成し、その構成がＳＥＳ ４０の２つのインスタンス間で確実に互換性を有するようにすることは、ユーザの責任である。１つのＳＥＳサーバまたはそれが実行中のノードが機能しなくなった場合、そのフェイルオーバータイムはＲＤＭに関して記録した通りである。イベントレポジトリの実際の状態は、すべてのノード上の同期化されたＳＥＰ ５２レポジトリで維持されるので、Ｄｉｒｅｃｔ ＳｔａｔｉｏｎｓからはＳＥＳは同じに見える。

システムイベントプロバイダに対するＷＭＩを介した接続は、共通モジュールＩｎｓｔＣｌｎｔ．ｄｌｌにより維持される。接続が失われたという通知、再接続の試行、および接続が回復されたという通知は、ＩｎｓｔＣｌｎｔ．ｄｌｌ内で実現されるスレッドにより処理される。何らかの理由でサーバが機能しなくなった場合、いかなるクライアントでもそれを参照しようとした時は、そのサーバは自動的に再開される。

システムイベントフィルタ・スナップイン
システムイベントフィルタ・スナップイン８６ツールは、ＯＰＣ警報およびイベントに関連付けられた付加的なイベントプロパティを定義するための機構を提供する、Ｍｉｃｒｏｓｏｆｔ社のＭａｎａｇｅｍｅｎｔ Ｃｏｎｓｏｌｅスナップインである。システムイベントフィルタ・スナップイン８６は、Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙに登録されたＷｉｎｄｏｗｓ（登録商標） ＮＴ Ｅｖｅｎｔカタログファイルを選択するための機構を提供する。イベントソースは、メッセージカタログに関連付けられたソースのリストから選択され、そのカタログに含まれるイベントのリストが表示される。ＯＰＣイベントとしてのＷｉｎｄｏｗｓ（登録商標） ＮＴ Ｅｖｅｎｔの構成は、構成「ウィザード」により実行される。

ＯＰＣ−ＡＥ属性が、構成ウィザードにより割り当てられるが、これは、次に示す表２６「イベントのタイプ、カテゴリ、および条件名」に準拠する。

表２６−イベントのタイプ、カテゴリ、および条件名
イベントの イベントのカテゴリ 条件名 記述
タイプ ／カテゴリＩＤ
関連条件 条件関連イベントは、活動状態 に割り当てることのできる認知 可能イベントである。活動状態 が１つのイベントに割り当てら れた場合、ソースが通常状態に 戻った際にロギングされる別の イベントを特定する必要がある 。
システム警報／ ＳＹＳＥＲＲＯＲ 特定のコンポーネント、ノード
０×３００３ 、またはネットワークに対して
分離不可能な、ＡＣＫ可能な、 非活動状態にあるシステムエラ ー。ソースは、その条件を出し たノードの名前である。
ＮＯＤＥＥＲＲＯＲ ＡＣＫ可能な、非活動状態にあ
るコンピュータのプラットフォ ーム（ノード）エラー。ソース はノード名である。
ＮＥＴＥＲＲＯＲ ＡＣＫ可能な、活動状態／非活
動状態にあるネットワークエラ ー。ソースは、その条件を出し たノードの名前で修飾された 「ネットワーク」またはネットワ ーク（セグメント）名である。
ＮＥＴＲＥＤＥＲＲＯＲ 重複した対の１つのリンクによ るＡＣＫ可能な、活動状態／非 活動状態にある問題。ソースは 、その条件を出したノードの名 前で修飾されたリンクの名であ る。
ＭＡＮＣＯＭＰＥＲＲＯＲ ＡＣＫ可能な、活動状態にある 管理コンポーネントエラー。ソ ースは、ノード名で修飾された コンポーネント名または別名で ある。コンポーネント名に対す る挿入ストリングは必須である 。非活動化するには、同じ条件 名で特定されたイベントをロギ ングし、ＡＣＫ可能でない、非 活動状態にセットする。
ＳＹＳＣＯＭＰＥＲＲＯＲ ＡＣＫ可能な、非活動状態にあ る汎用システムコンポーネント エラー。ソースは、ノード名で 修飾されたコンポーネント名で ある。コンポーネント名に対す る挿入ストリングは必須である 。
ＡＮＹ ＶＡＬＩＤ ＡＣＫ可能でない、非活動状態
ＣＯＮＤＩＴＩＯＮ ＮＡＭＥ にある、エラーなし／通常状態
ＳＥＴ ＴＯ ＮＯＴ 復帰条件。この条件は、ＯＰＣ
ＡＣＫＡＢＬＥ ＡＮＤ イベントとして直接は渡されな
ＩＮＡＣＴＩＶＥ いが、命名された条件イベント
を非活動状態に変更するために 使用される。ＳＥＰは、同じソ ースおよび条件名の活動状態に ある条件を求めてレポジトリを 検索する。見つかった場合、そ のイベントは非活動状態で更新 される。活動状態にある条件が 見つからなかった場合、ＯＰＣ イベントが生成される。
ＯＰＣ＿ＳＥＲＶＥＲ＿ ＡＣＫ可能な、活動状態にある
ＤＥＶＣＯＭＭＥＲＲＯＲ ＯＰＣサーバは、基礎となるデ
ＥＲＲＯＲ／０×３００４ バイスと通信することができな
い。ソースは、ノード名で修飾 されたサーバ名または別名であ る。対応する通信回復条件も指 定する必要がある。
単純 ＡＣＫ可能でない、非活動状態 にある単純イベントは、履歴は あるかも知れないが、イベント ビューワには表示されない単発 イベントである。
デバイス障害／０×１００１
システムメッセージ／０×１００３
追跡 ＡＣＫ可能でない、非活動状態 にある追跡イベントは、システ ムイベントレポジトリで保持さ れない単発イベントである。
プロセス変更／０×２００１ 対話ユーザまたは制御アプリケ ーションプログラムによるプロ セスパラメータの修正。これは 、ＳＥＰログ条件追跡イベント を含む。
システム変更／０×２００２ 構成変更以外のシステムの修正 、例えばオペレータのログオン またはログオフ
システム構成／０×２００３ システム構成の修正、例えばＴ ＰＳドメインへのノードの追加 （ＡＤ変更が検出された際にＳ ＥＳによりロギングされる）。

Ｗｉｎｄｏｗｓ（登録商標）またはＮＴイベントの重大度が必ずしも所望のＯＰＣイベントの重大度に直接的に翻訳されるわけでないので、ＯＰＣイベントの重大度を各イベントのタイプに割り当てる必要がある。表２７に、ＯＰＣの重大度の範囲とそれに相当するＣＣＡ／ＴＰＳ優先権（参照用）とを示す。フィルタテーブルで０という重大度が指定された場合、もとのＮＴイベントに割り当てられたイベントの重大度は、事前に割り当てられたＯＰＣの重大度値に翻訳される。

表２７−ＯＰＣイベント重大度の変換
割り当てられた重大度 変換 相当するＣＣＡ／ＴＰＳ優先権
０ ＮＴイベントがロギングされた際 Ｎ／Ａ
に割り当てられたイベントの重大度
を使用する（下記）
２００（ＯＰＣ範囲１−４００） 成功または情報 Ｉｎｆｏ（通常は表示されないが 、記録することができる）
５００（ＯＰＣ範囲４０１−６００） 警告 低
７００（ＯＰＣ範囲６０１−８００） エラー 高
９００（ＯＰＣ範囲８０１−１０００） 緊急または非常事態

システムイベントフィルタ内データベース
システムイベントフィルタは、ＦｉｌｔｅｒｓディレクトリのＸＭＬファイルに格納される。

以上、本発明者らは、本発明者らの発明に従い数点の実施形態を図示し説明したが、上記実施形態は、当業者には明らかな多数の変更を受けることが理解されよう。したがって、本発明者らは、図示し説明した詳細に限定することを欲せず、首記の特許請求の範囲内に含まれるすべての変更および修正を示すことを意図する。

本発明のイベントフィルタリングおよび通知デバイスを含むシステムのブロック図である。 本発明によるイベントフィルタリングおよび通知デバイスの様々な実行時システム管理コンポーネント間における通信経路を示すブロック図である。 本発明のイベントフィルタリングおよび通知デバイスにより使用される様々なコンピューティングノード間における通信リンクを示すブロック図である。 ＯＰＣイベント変換に対するシステムイベントを示すブロック図である。 システムイベントサーバインターフェースを示すブロック図である。 本発明のフィルタ構成ツールの選択ボックスである。 本発明のフィルタ構成ツールの選択ボックスである。 本発明のフィルタ構成ツールの選択ボックスである。 本発明のフィルタ構成ツールの選択ボックスである。 本発明のフィルタ構成ツールの選択ボックスである。

Claims (56)

1. ＯＰＣクライアントに対するＯＰＣ警報およびイベント（ＯＰＣ−ＡＥ）ならびにＮＴ警報およびイベント（ＮＴ−ＡＥ）の通知の方法において、
   ＮＴ−ＡＥのＮＴ−ＡＥ通知をＯＰＣ−ＡＥ通知に変換するステップと、
   前記ＯＰＣ−ＡＥ通知を前記ＯＰＣクライアントに提示するステップと
   を含む方法。
2. 前記ＮＴ−ＡＥをフィルタ基準に従いフィルタリングするステップ
   をさらに含む、請求項１に記載の方法。
3. 前記フィルタ基準はフィルタ構成ツールにより提供される、請求項２に記載の方法。
4. 前記フィルタ基準はシステムイベントフィルタ・スナップインにより提供される、請求項２に記載の方法。
5. 前記変換するステップは、前記ＯＰＣ−ＡＥ通知を提供するために前記ＮＴ−ＡＥ通知に追加情報を付加する、請求項１に記載の方法。
6. 前記追加情報は、前記ＮＴ−ＡＥ通知を作成したソースの名称を含む、請求項５に記載の方法。
7. 前記ソースの名称は、前記ＮＴ−ＡＥ通知を作成したコンピュータ名および前記ＮＴ−ＡＥの挿入ストリングを含む、請求項５に記載の方法。
8. 前記挿入ストリングは、前記ＮＴ−ＡＥを生成したコンポーネントを特定する、請求項７に記載の方法。
9. 前記追加情報は、イベントの重大度を含む、請求項５に記載の方法。
10. 前記イベントの重大度はＮＴ準拠の重大度であり、前記変換するステップは、前記ＮＴ準拠の重大度のＯＰＣ準拠の重大度への変換を提供する、請求項９に記載の方法。
11. 前記変換は、規定の重大度値に基づく、請求項１０に記載の方法。
12. 前記変換は、前記ＮＴ−ＡＥ通知のロギングされた重大度値に基づく、請求項１１に記載の方法。
13. 前記追加情報は、イベントのクッキー、ソースの名称、イベントの重大度、イベントのカテゴリ、イベントのタイプ、イベントの認知可能性、およびイベントの認知状態からなるグループから選択された１つまたは複数の項目である、請求項５に記載の方法。
14. 前記ＯＰＣクライアントは、前記ＮＴ−ＡＥ通知を作成したソースのローカルまたは遠隔にある、請求項１に記載の方法。
15. 前記提示するステップは、マルチキャストリンクを介して前記ＯＰＣ−ＡＥ通知を前記ＯＰＣクライアントに提示する、請求項１に記載の方法。
16. 前記ＮＴ−ＡＥは、条件イベント、単純イベント、または追跡イベントを含む、請求項１に記載の方法。
17. 前記条件イベントの少なくとも１つは、特定ソースの状態を反映する、請求項１６に記載の方法。
18. 前記ＯＰＣ−ＡＥ通知を、マルチキャストリンクを介して複数のノード間で同期を取るステップをさらに含む、請求項１に記載の方法。
19. 前記ＯＰＣ−ＡＥ通知は、ＯＰＣ−ＡＥインターフェースまたはＷＭＩインターフェースを介してアクセス可能である、請求項１に記載の方法。
20. ＯＰＣクライアントにＯＰＣ警報およびイベント（ＯＰＣ−ＡＥ）ならびにＮＴ警報およびイベント（ＮＴ−ＡＥ）を通知するためのデバイスにおいて、
    ＮＴ−ＡＥのＮＴ−ＡＥ通知を追加情報にリンクするシステムイベントプロバイダと、
    前記ＯＰＣクライアントに提示するために前記ＮＴ−ＡＥ通知と前記追加情報とをＯＰＣ−ＡＥ通知としてパッケージするシステムイベントサーバと
    を含むデバイス。
21. 前記ＮＴ−ＡＥ通知をフィルタ基準に従いフィルタリングするフィルタをさらに含む、請求項２０に記載のデバイス。
22. 前記フィルタ基準がフィルタ構成ツールにより提供される、請求項２１に記載のデバイス。
23. 前記フィルタ基準がシステムイベントフィルタ・スナップインにより提供される、請求項２１に記載のデバイス。
24. 前記追加情報は、前記ＮＴ−ＡＥ通知を作成したソースの名称を含む、請求項２０に記載のデバイス。
25. 前記ソースの名称は、前記ＮＴ−ＡＥを作成したコンピュータ名および前記ＮＴ−ＡＥの挿入ストリングを含み、前記ＮＴ−ＡＥが条件イベントである、請求項２４に記載のデバイス。
26. 前記挿入ストリングは、前記ＮＴ−ＡＥを生成したコンポーネントを特定する、請求項２５に記載のデバイス。
27. 前記追加情報は、イベントの重大度を含む、請求項２０に記載のデバイス。
28. 前記イベントの重大度はＮＴ準拠の重大度であり、前記システムイベントプロバイダが、前記ＮＴ準拠の重大度のＯＰＣ準拠の重大度への変換を提供する、請求項２７に記載のデバイス。
29. 前記変換は、規定の重大度値に基づく、請求項２８に記載のデバイス。
30. 前記変換は、前記ＮＴ−ＡＥ通知のロギングされた重大度値に基づく、請求項２８に記載のデバイス。
31. 前記追加情報が、イベントのクッキー、ソースの名称、イベントの重大度、イベントのカテゴリ、イベントのタイプ、イベントの認知可能性、およびイベントの認知状態からなるグループから選択された１つまたは複数の項目を含む、請求項２０に記載のデバイス。
32. 前記ＯＰＣクライアントが、前記ＮＴ−ＡＥ通知を作成したソースのローカルまたは遠隔にある、請求項２０に記載のデバイス。
33. マルチキャストリンクを介して前記ＯＰＣ−ＡＥ通知を前記ＯＰＣクライアントに提示する同期レポジトリプロバイダをさらに含む、請求項２０に記載のデバイス。
34. 前記イベントが、条件イベント、単純イベント、または追跡イベントである、請求項２０に記載のデバイス。
35. 前記条件イベントの少なくとも１つは、特定ソースの状態を反映する、請求項３４に記載のデバイス。
36. 前記ＯＰＣ−ＡＥ通知を、マルチキャストリンクを介して複数のノード間で同期を取るための同期レポジトリをさらに含む、請求項２０に記載のデバイス。
37. 前記ＯＰＣ−ＡＥ通知は、ＯＰＣ−ＡＥインターフェースまたはＷＭＩインターフェースを介してアクセス可能である、請求項２０に記載のデバイス。
38. 前記システムイベントサーバは、前記ＯＰＣ−ＡＥ通知を前記ＯＰＣクライアントに提供する、請求項２０に記載のデバイス。
39. 前記システムイベントプロバイダは、ＷＭＩインターフェースを介して前記システムイベントサーバと通信する、請求項２０に記載のデバイス。
40. 前記ＮＴ−ＡＥ通知を提供するＮＴイベントプロバイダと、
    前記フィルタ基準を満たすＮＴ−ＡＥ通知のみが前記システムイベントプロバイダによってＯＰＣ−ＡＥ通知にリンクされるように、フィルタ基準に従い前記ＮＴ−ＡＥ通知をフィルタリングするフィルタと
    をさらに含む、請求項２０に記載のデバイス。
41. 前記ＮＴ−ＡＥ通知の１つまたは複数は、ソースによって生成され、前記ソースの状態を反映する条件イベントであり、前記ソースの状態の変更により生成された前記複数の条件イベントのうちの後で発生する１つの条件イベントに合わせて、前記複数の条件イベントのうちの既に発生している１つの条件イベントの活動状態と非活動状態との間で状態を変更することをさらに含む、請求項２０に記載のデバイス。
42. 前記システムイベントプロバイダが、既に発生している条件イベントと後で発生する条件イベントのＮＴ−ＡＥ通知を、ＯＰＣクライアントに提示するためにＯＰＣ−ＡＥ通知にリンクする、請求項４１に記載のデバイス。
43. 前記ＮＴ−ＡＥの１つまたは複数は、ソースによって生成され、前記ソースの状態を反映する条件イベントであり、前記ソースの状態の変更により生成された前記複数の条件イベントのうちの後で発生する１つの条件イベントに合わせて、前記複数の条件イベントのうちの既に発生している１つの条件イベントの活動状態と非活動状態との間で状態を変更するステップをさらに含む、請求項１に記載の方法。
44. 前記変換するステップおよび提示するステップは、前記既に発生している条件イベントと後で発生する条件イベントのＮＴ−ＡＥ通知を、ＯＰＣクライアントに提示するためにＯＰＣ−ＡＥ通知に変換する、請求項４３に記載の方法。
45. ＯＰＣ警報およびイベントに変換するためにＮＴ警報およびイベント（ＮＴ−ＡＥ）をフィルタリングするフィルタをポピュレートする方法において、
    その通知が前記フィルタを通過すべきＮＴ−ＡＥを入力するステップと、
    前記入力されたＮＴ−ＡＥを、イベントのタイプ、イベントのソース、イベントの重大度、イベントのカテゴリ、イベントの条件、イベントのサブ条件、およびイベントの属性からなるグループから選択された１つまたは複数のイベント特性により構成するステップと
    を含む方法。
46. 前記イベントのタイプは、条件、単純、および追跡を含む、請求項４５に記載の方法。
47. 前記イベントのソースは、特定のＮＴ−ＡＥ通知を作成したコンピュータ名およびそれのＮＴ−ＡＥの挿入ストリングを含む、請求項４５に記載の方法。
48. 前記イベントの重大度は、規定の重大度値またはロギングされた重大度値を含む、請求項４５に記載の方法。
49. 前記イベントのカテゴリは、デバイスの状態を含む、請求項４５に記載の方法。
50. 前記イベントの属性は、特定のイベントのカテゴリに関して、特定のＮＴ−ＡＥの認知可能性および活動状態または非活動状態の状態を含む、請求項４５に記載の方法。
51. ＯＰＣ警報およびイベントに変換するためにＮＴ警報およびイベント（ＮＴ−ＡＥ）をフィルタリングするフィルタをポピュレートするコンフィギュレータにおいて、
    その通知が前記フィルタを通過すべきＮＴ−ＡＥの前記フィルタへの入力と、イベントのタイプ、イベントのソース、イベントの重大度、イベントのカテゴリ、イベントの条件、イベントのサブ条件、およびイベントの属性からなるグループから選択された１つまたは複数のイベント特性による、前記入力されたＮＴ−ＡＥの構成とを提供する構成デバイスを含むコンフィギュレータ。
52. 前記イベントのタイプは、条件、単純、および追跡を含む、請求項５１に記載のコンフィギュレータ。
53. 前記イベントのソースが、特定のＮＴ−ＡＥ通知を作成したコンピュータ名およびそのＮＴ−ＡＥの挿入ストリングを含む、請求項４９に記載のコンフィギュレータ。
54. 前記イベントの重大度は、規定の重大度値またはロギングされた重大度値を含む、請求項４９に記載のコンフィギュレータ。
55. 前記イベントのカテゴリは、デバイスの状態を含む、請求項４９に記載のコンフィギュレータ。
56. 前記イベントの属性は、特定のイベントのカテゴリに関して、特定のＮＴ−ＡＥの認知可能性および活動状態または非活動状態の状態を含む、請求項４９に記載のコンフィギュレータ。

Images