ADSI でのイベント トレーシング

Windows Server 2008 および Windows Vista は、Active Directory サービス インターフェイス (ADSI) でイベント トレーシングを導入しています。 ADSI LDAP プロバイダーの特定の領域には、その基本的な実装が複雑であったり、問題の診断を難しくする一連の手順が含まれていることがあります。 アプリケーション開発者のトラブルシューティングを支援するために、イベント トレーシングは次の領域に追加されています。

スキーマ解析とダウンロード

ADSI の IADs インターフェイスは、属性が正しくマーシャリングされるように、 LDAP スキーマをクライアントにキャッシュする必要があります (ADSI スキーマ モデルを参照)。 これを実現するために、ADSI は、ローカル ディスクに保存されているスキーマ (.sch) ファイルから、または LDAP サーバーからダウンロードして、各プロセス (および各 LDAP サーバー/ドメイン) のスキーマをメモリに読み込みます。 同じクライアント マシン上の異なるプロセスは、ディスク上のキャッシュされたスキーマを使用します (使用可能で該当する場合)。

ディスクまたはサーバーからスキーマを取得できない場合、ADSI はハードコーディングされた既定のスキーマを使用します。 この場合、この既定のスキーマに含まれていない属性はマーシャリングできず、ADSI はこれらの属性の取得中にエラーを返します。 スキーマの解析に問題や、スキーマをダウンロードするための権限が不十分であるなど、さまざまな要因でこのようなことが発生する場合があります。 多くの場合、特定の既定のスキーマが使用されている理由を判断するのは困難です。 この領域でイベント トレーシングを使用すると、問題をより迅速に診断して修正することができます。

パスワードの変更と設定

ChangePassword と SetPassword は、利用可能な構成に基づいて要求された操作を実行するために、複数のメカニズムを使用します (LDAP プロバイダーを使用したユーザー パスワードの設定と変更を参照)。 ChangePassword と SetPassword が失敗した場合、その理由を正確に特定するのが難しい場合があります。イベント トレーシングは、これらのメソッドの問題のトラブルシューティングに効果的です。

ADSI バインド キャッシュ

ADSI は、可能な限り LDAP 接続の再利用を内部的に試みます (接続キャッシュを参照)。 トラブルシューティングを行うときは、サーバーとの通信用に新しい接続が開かれたかどうか、または既存の接続が使用されたかどうかをトレースすると便利です。 また、接続キャッシュのライフサイクル (バインド キャッシュとも呼ばれます) とその作成またはクローズ、および接続の紹介が行われたかどうかをトレースする場合にも役立ちます。 サーバーレス バインドの場合、ADSI は DC ロケーターを呼び出して、ユーザーのコンテキストのドメインのサーバーを選択します。 その後 ADSI によって、後続の接続に対するドメインサーバー マッピングのキャッシュが保持されます。 イベント トレーシングによって DC の選択をトレースできるため、接続関連の問題のトラブルシューティングに役立ちます。

トレースの有効化とトレース セッションの開始

ADSI トレースを有効にするには、次のレジストリ キーを作成します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\ProcessName

ProcessName は、拡張子 ("Svchost.exe" など) を含む、トレースするプロセスのフルネームです。 さらに、PID という DWORD 型の省略可能な値をこのキーに入れることができます。 この値を設定し、特定のプロセスのみをトレースすることを強くお勧めします。 それ以外の場合は、ProcessName で指定されたアプリケーションのすべてのインスタンスがトレースされます。

その後、次のコマンドを実行します。

tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel

sessionname は単にトレース セッションにラベルを付けるための任意の識別子です (後でトレース セッションを停止するときに、このセッション名を参照する必要があります)。 ADSI 追跡プロバイダーの GUID は "7288c9f8-d63c-4932-a345-89d6b060174d" です。 filename は、イベントが書き込まれるログファイルを指定します。 traceFlags 値は次のいずれかを指定する必要があります。

これらのフラグは、以下の表に従って、どの ADSI メソッドがトレースされるかを決定します。

traceFlags 引数の適切なビットを組み合わせることで、フラグを組み合わせることができます。 たとえば、DEBUG_SCHEMA と DEBUG_BINDCACHE フラグを指定する場合、適切なtraceFlags 値は 0x00000009 となります。

最後に、traceLevel フラグの値は次のいずれかである必要があります。

TRACE_LEVEL_INFORMATION はトレース プロセスに全てのイベントを記録し、TRACE_LEVEL_ERROR はトレース プロセスにエラー イベントのみを記録します。

トレースを終了するには、次のコマンドを実行します。

tracelog.exe -stop sessionname

前の例では、sessionname はトレース セクションを開始したコマンドで与えられたものと同じ名前です。

解説

コンピューター上のすべてのプロセスをトレースするよりも、特定の PID を指定して特定のプロセスだけをトレースする方が効果的です。 同じコンピューター上の複数のアプリケーションをトレースする必要がある場合は、パフォーマンスに影響を与える可能性があります。コードのパフォーマンス指向セクションには、かなりのデバッグ出力があります。 また、管理者は、複数のプロセスをトレースするときにログ ファイルのアクセス許可を適切に設定するように注意する必要があります。そうでない場合、すべてのユーザーがトレース ログを読み取ることができ、他のユーザーは安全な情報を含むプロセスをトレースできてしまう可能性があります。

たとえば、管理者がアプリケーション "Test.exe" のトレースを設定し、プロセスの複数のインスタンスをトレースする PID をレジストリに指定していないとします。 次に、別のユーザーがアプリケーション "Secure.exe" をトレースします。 トレース ログ ファイルが適切に制限されていない場合、ユーザーは "Secure.exe" の名前を "Test.exe" に変更するだけでトレースされます。 一般に、トラブルシューティング中に特定のプロセスのみをトレースし、トラブルシューティングが完了したらすぐにトレース レジストリ キーを削除することをお勧めします。

イベント トレーシングを有効にすると追加のログ ファイルが生成されるため、管理者はログ ファイルのサイズを慎重に監視する必要があります。ローカル コンピューターのディスク領域が不足すると、サービス拒否が発生する可能性があります。

シナリオの例

シナリオ 1: 管理者は、ユーザー アカウントのパスワードを設定するアプリケーションで予期しないエラーが発生するため、次の手順に沿ってイベント トレーシングを使用して問題を解決します。

1. 問題を再現するスクリプトを記述し、レジストリ キーを作成します

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe

2. traceFlags を 0x2 (DEBUG_CHANGEPASSWD)、traceLevel を 0x4 (TRACE_LEVEL_INFORMATION) に設定し、次のコマンドでトレース セッションを開始します

   tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4

3. テスト スクリプトで cscript.exe を実行して問題を再現し、トレース セッションを終了します

   tracelog.exe -stop scripttrace

4. レジストリ キーを削除します

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe

5. ETW ツールの Tracerpt.exe を実行して、ログからトレース情報を解析します

   tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4

シナリオ 2: 管理者は、すでに実行されている w3wp.exe という名前の ASP アプリケーションのスキーマ解析とダウンロード操作をトレースしたいと考えています。 これを行うために、管理者は次の手順を実行します。

1. レジストリ キーを作成します

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe

   そのキー内に、PID という名前の DWORD 型の値を作成し、ローカル コンピューターで現在実行されている w3wp.exe のインスタンスのプロセス ID に設定します。

2. そして、トレース セッションを作成し、traceFlags を 0x1 (DEBUG_SCHEMA) に、traceLevel を 0x4 (TRACE_LEVEL_INFORMATION) に設定します

   tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\w3wp.etl -flag 0x1 -level 0x4

3. トラブルシューティングが必要な操作を再現します。

4. トレース セッションを終了します。

   tracelog.exe -stop w3wptrace

5. レジストリ キーを削除します HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe

6. ETW ツールの tracerpt.exe を実行して、ログからトレース情報を解析します

   tracerpt.exe .\w3wp.etl -o -report