次の方法で共有


USNChanged を使用した変更のポーリング

DirSync コントロールは強力で効率的ですが、次の 2 つの重要な制限があります。

  • 高い特権を持つアプリケーションの場合のみ: DirSync コントロールを使用するには、doメイン コントローラーに対するStandard Edition_SYNC_AGENT_NAME特権を持つアカウントでアプリケーションを実行する必要があります。 非常に高い特権を持つアカウントはほとんどないため、DirSync コントロールを使用するアプリケーションを通常のユーザーが実行することはできません。
  • サブツリースコープなし: DirSync コントロールは、名前付けコンテキスト内で発生するすべての変更を返します。 名前付けコンテキストの小さなサブツリーで発生する変更にのみ関心があるアプリケーションは、多くの無関係な変更を処理する必要があります。これは、アプリケーションと doメイン コントローラーの両方にとって非効率的です。

Active Directory からの変更は、DirSync コントロールの制限を 回避する uSNChanged 属性のクエリを実行して取得することもできます。 この代替方法は、属性が変更されたときにすべての属性を送信する必要があり、特定の障害シナリオを正しく処理するためにアプリケーション開発者からのより多くの作業を必要とするため、すべての点で DirSync コントロールよりも優れているわけではありません。 現時点では、特定の変更追跡アプリケーションを記述する最適な方法です。

doメイン コントローラーは、オブジェクトを変更するときに、そのオブジェクトの uSNChanged 属性を、そのオブジェクトの uSNChanged 属性の前の値より大きい値に設定し、そのオブジェクトに保持されている他のすべてのオブジェクトの uSNChanged 属性の現在の値より大きい値メインコントローラーに設定します。 その結果、アプリケーションは、最大の uSNChanged 値を持つオブジェクトを見つけることによって、doメイン コントローラーで最後に変更されたオブジェクトを見つけることができます。 doメイン コントローラーで最後に変更された 2 番目のオブジェクトは、2 番目に大きい uSNChanged 値になります。

uSNChanged 属性はレプリケートされないため、2 つの異なる do メイン コントローラーでオブジェクトの uSNChanged 属性を読み取ると、通常は異なる値が提供されます。

たとえば、 uSNChanged 属性を使用して、サブツリー S の変更を追跡できます。まず、サブツリー S の "完全同期" を実行します。S 内の任意のオブジェクトの最大 の uSNChanged 値が U であるとします。uSNChanged 値が U より大きいサブツリー S 内のすべてのオブジェクトに対して定期的に クエリを実行します。このクエリは、完全同期以降に変更されたすべてのオブジェクトを返します。これらの変更されたオブジェクトの中で最大 の uSNChanged に設定すると、もう一度ポーリングする準備が整います。

uSNChanged 同期アプリケーションを実装する 機微には、次のようなもの があります。

  • uSNChanged フィルターをバインドするには、rootD Standard Edition の highestCommittedUSN 属性を使用します つまり、完全同期を開始する前に、関連する doメイン コントローラーの highestCommittedUSN を読み取ります。 次に、(ページングされた結果を使用して) 完全同期クエリを実行して、データベースを初期化します。 これが完了したら、完全同期クエリの前に読み取られた highestCommittedUSN 値を格納し、次の同期に uSNChanged 属性の下限として使用します。 後で増分同期を実行するには、highestCommittedUSN rootD Standard Edition 属性を再読み込みします。 次に、前の同期から保存された uSNChanged 属性値の下限より大きい uSNChanged のページ結果を使用して、関連するオブジェクトのクエリを実行します。 この情報を使用してデータベースを更新します。 完了したら、増分同期クエリの前に読み取られた最高のCommittedUSN 値から uSNChanged 属性の下限を更新します。 アプリケーションが doメイン コントローラーのコンテンツと同期しているのと同じストレージに、uSNChanged 属性値の下限を常に格納します。

    この手順に従って、取得したオブジェクトの uSNChanged 値に基づく のではなく、アプリケーションに適用できるセットの外にある更新された オブジェクトをサーバーで再検討することを回避します。

  • uSNChanged はレプリケートされていない属性であるため、アプリケーションを実行するたびに同じ doメイン コントローラーにバインドする必要があります。 その do にバインドできない場合メインコントローラーは、その操作が可能になるまで待機するか、新しい doメイン コントローラーと連携して、その doメイン コントローラーと完全同期を実行する必要があります。 アプリケーションが doメイン コントローラーに関連する場合、その doメイン コントローラーの DNS 名が安定したストレージに記録されます。これは、doメイン コントローラーのコンテンツと同じストレージです。 次に、格納されている DNS 名を使用して、後続の同期のために同じ doメイン コントローラーにバインドします。

  • アプリケーションは、現在関連付けされている doメイン コントローラーがバックアップから復元されたことを検出する必要があります。これは不整合を引き起こす可能性があるためです。 アプリケーションが doメイン コントローラーに関連する場合、その doメイン コントローラーの "呼び出し ID" が安定ストレージにキャッシュされます。つまり、doメイン コントローラーのコンテンツと同じストレージが維持されます。 doメイン コントローラーの "呼び出し ID" は、doメイン コントローラーのサービス オブジェクトの invocationID 属性に格納されている GUID です。 doメイン コントローラーのサービス オブジェクトの識別名を取得するには、rootD Standard Edition の dsServiceName 属性を読み取ります。

    アプリケーションの安定ストレージがバックアップから復元されると、doメイン コントローラー名、呼び出し ID、および uSNChanged 属性値の下限が doメイン コントローラーのコンテンツと同期されたデータと共に格納されるため、整合性の問題がないことに注意してください。

  • 大規模な結果セットを同時に取得する可能性を回避するために、完全同期と増分同期の両方でサーバーにクエリを実行するときにページングを使用します。 詳細については、「その他の検索オプションの指定」を参照してください。

  • インデックスベースのクエリを実行して、ページングされた結果を使用するときにサーバーに大きな中間結果を強制的に格納しないようにします。 詳細については、「インデックス付き属性」を参照してください。

  • 一般に、検索結果のサーバー側の並べ替えを使用しないでください。そのため、サーバーは大きな中間結果を格納して並べ替える必要があります。 これは、完全同期と増分同期の両方に適用されます。 詳細については、「その他の検索オプションの指定」を参照してください。

  • 親条件を適切に処理しません。 アプリケーションは、親を認識する前にオブジェクトを認識できます。 アプリケーションによっては、これは問題になる場合とそうでない場合があります。 アプリケーションは常に、ディレクトリから親の現在の状態を読み取ることができます。

  • 移動または削除されたオブジェクトを処理するには、追跡対象 の各オブジェクトの objectGUID 属性を格納します。 オブジェクトの objectGUID 属性はメインフォレスト全体の移動場所に関係なく変更されません。

  • 移動されたオブジェクトを処理するには、定期的な完全同期を実行するか、検索範囲を広げて、クライアント側で関心のない変更を除外します。

  • 削除されたオブジェクトを処理するには、増分同期を実行するときに、定期的な完全同期を実行するか、削除されたオブジェクトを個別に検索します。 削除されたオブジェクトを照会する場合は、削除されたオブジェクトの objectGUID を取得して、データベースから削除するオブジェクトを決定します。 詳細については、「削除されたオブジェクトの取得」を参照してください

  • 検索結果には、呼び出し元が読み取るアクセス許可を持つオブジェクトと属性のみが含まれることに注意してください (さまざまなオブジェクトのセキュリティ記述子と DACL に基づく)。 詳細については、「クエリに対するセキュリティの影響」を参照してください

詳細と、USNChanged 同期アプリケーションの基本を示すコード例については、「USNChanged を使用して変更を取得するコード例」を参照してください