共用方式為

使用 DirSync 控件輪詢變更

  • 發行項

Active Directory 目錄同步處理 （DirSync） 控制項是 LDAP 伺服器延伸模組，可讓應用程式搜尋目錄分割區中自先前狀態以來已變更的物件。

透過ADSI使用 DirSync 控件，方法是在使用 IDirectorySearch 時指定ADS_SEARCHPREF_DIRSYNC搜尋喜好設定。 如需詳細資訊和程式代碼範例，請參閱 使用 ADS_SEARCHPREF_DIRSYNC 範例程序代碼。 您也可以使用LDAP API來執行 DirSync 搜尋。 下列說明 ADSI 實作，其中大部分也適用於直接使用 LDAP，但本主題結尾所討論除外。

當您執行 DirSync 搜尋時，您會傳入提供者特定的數據元素 （cookie），以識別先前 DirSync 搜尋時的目錄狀態。 在第一次搜尋中，您會傳入 Null Cookie，而搜尋會傳回符合篩選條件的所有物件。 搜尋也會傳回有效的 Cookie。 將 Cookie 儲存在您與 Active Directory 伺服器同步的相同記憶體中。 在後續的搜尋中，從記憶體取得 Cookie，並使用搜尋要求傳遞它。 搜尋結果現在只包含自 Cookie 所識別先前狀態以來已變更的物件和屬性。 搜尋也會傳回新的 Cookie 來儲存下一個搜尋。

下表列出客戶端搜尋要求可以指定的搜尋參數。

參數 描述
搜尋的基底 DirSync 搜尋的基底必須是目錄分割區的根目錄，可以是網域分割區、組態分割區或架構分割區。
範圍 DirSync 搜尋的範圍必須 ADS_SCOPE_SUBTREE，也就是分割區的整個子樹。 請注意，若要搜尋網域分割區，子樹會包含組態和架構分割區的內容，但不包含其內容。 若要輪詢較小範圍中的變更，請使用 USNChanged 技術，而不是 DirSync。
篩選器 您可以指定任何有效的搜尋篩選條件。 針對具有 Null Cookie 的初始搜尋，結果會包含符合篩選條件的所有物件。 對於具有有效 Cookie 的後續搜尋，搜尋結果只會包含符合篩選條件的對象數據，且自 Cookie 所指出的狀態之後已變更。 如需搜尋篩選的詳細資訊，請參閱 建立查詢篩選。
屬性 您可以指定要在發生變更時傳回的屬性清單。 針對每個物件，初始結果會包含對象上設定的所有要求屬性。 後續搜尋結果只包含已變更的指定屬性。 未變更的屬性不會包含在搜尋結果中。 在 ADSI 實作中，搜尋結果一律包含 每個物件的 objectGUID 和 instanceType 。 此外，指定的屬性清單可作為其他篩選條件：初始搜尋結果只包含至少設定其中一個指定屬性的物件;後續搜尋只會包含一或多個屬性已變更的物件（已新增或刪除的值）。

 

此外，請注意：

  • 針對累加式搜尋，最佳做法是系結至先前搜尋中使用的相同域控制器（DC），也就是產生 Cookie 的 DC。 如果相同的 DC 無法使用，請等到其為 ，或系結至新的 DC 並執行完整同步處理。 使用 Cookie 將 DC 的 DNS 名稱儲存在次要記憶體中。

    您可以將一個 DC 所產生的 Cookie 傳遞至裝載相同目錄分割區複本的不同 DC。 用戶端不可能透過在另一個 DC 上使用來自某個 DC 的 Cookie 來遺漏變更。 不過，新 DC 的搜尋結果可能會包含舊 DC 的報告變更;在某些情況下，新的 DC 可能會傳回所有物件和屬性，如同完整同步處理一樣。 客戶端應該只讓其資料庫與任何指定的 DirSync 呼叫報告搜尋結果保持一致，也就是說，處理所有累加結果，就好像它們是最新狀態一樣。 您之前或甚至回到先前的狀態都看過變更並不重要，因為重複的累加同步處理會在一致性上趨同。

  • 另一個 DC 也可能拒絕從原始 DC 傳回的 Cookie。 搜尋會在伺服器上產生LDAP錯誤，例如 「0000203D： LdapErr： DSID-xxxxxxxxxx，批註：錯誤處理控件，數據 0“，用戶端應用程式可能會產生錯誤，例如 「System.DirectoryServices.Protocols.DirectoryOperationException：發生通訊協定錯誤」。。例如，當 Cookie 較舊，且執行不同 Windows 版本的 LDAP 伺服器處理時，Cookie 的內部內容預期會不同。 Cookie 是不透明的結構，且不保證在所有 Windows OS 版本之間在結構上一致。 如果遇到此錯誤，用戶端應用程式應該處理此案例，然後重試並執行完整同步處理。

  • 當物件重新命名或移動時，即使子對象的辨別名稱已變更，其子物件也未包含在搜尋結果中。 同樣地，當物件安全性描述元中修改可繼承的 ACE 時，即使子對象的安全性描述項已變更，物件的子物件也不會包含在搜尋結果中。

  • 使用 objectGUID 屬性來識別追蹤的物件。 不論對象在樹系中移動的位置為何，每個物件的 objectGUID 都會保持不變。

  • 請注意，DirSync 搜尋的搜尋結果指出搜尋時目錄分割複本上物件的狀態。 這表示如果其他 DC 的變更尚未復寫到目標 DC，將不會包含這些變更。 這也表示對象的屬性可能已經變更數次，因為先前的 DirSync 搜尋，但搜尋只會顯示最終狀態，而不是變更序列。

  • 在 ADSI 實作中，應用程式必須以不透明的方式處理 Cookie，而不會對其內部組織或值進行任何假設。

  • 請注意，用戶端會將 DC 的 Cookie、Cookie 長度和 DNS 名稱儲存在包含同步處理對象數據的相同記憶體中。 這可確保從備份還原記憶體時，Cookie 和其他參數會與對象數據保持同步。

  • 若要擷取針對 DirSync 控件建構的 parentGUID 屬性，也需要要求 name 屬性。

若要使用 DirSync 控件，呼叫端必須在受監視的數據分割根目錄上指派「目錄取得變更」許可權。 根據預設，此許可權會指派給域控制器上的 管理員 istrator 和 LocalSystem 帳戶。 呼叫端也必須具有 DS-Replication-Get-Changes 延伸控件訪問許可權。 如需針對必須在沒有此許可權之帳戶下執行之應用程式實作變更追蹤機制的詳細資訊，請參閱 使用 USNChanged 輪詢變更。 如需許可權的詳細資訊，請參閱 許可權。

ADS_SEARCHPREF_DIRSYNC搜尋結果會自動包含符合指定搜尋篩選條件的已刪除物件 （tombstones）。 不過，當對象處於即時時，符合物件的搜尋篩選條件，在刪除對象之後可能不符合該物件。 這是因為墓碑只會保留原始物件上存在的屬性子集。 例如，您通常會針對用戶物件使用下列篩選條件。

(&(objectClass=user)(objectCategory=person))

刪除物件時會移除 objectCategory 屬性，因此上述篩選條件與任何墓碑物件不符。 相反地， objectClass 屬性會保留在 tombstone 物件上，因此 “（objectClass=user）” 的篩選會符合已刪除的用戶物件。

您使用 DirSync 搜尋指定的屬性清單也會做為篩選;搜尋結果只包含自上一個 DirSync 搜尋之後，一或多個指定屬性已變更的物件。 如果屬性清單不包含在墓碑上保留的任何屬性，搜尋結果將不會包含墓碑。 若要處理此狀況，請指定 Null 屬性清單來要求所有屬性;或者，您可以要求 isDeleted 屬性，在所有墓碑上設定為 TRUE 。 Tombstone 屬性在 attributeSchema 定義的 searchFlags 屬性中設定0x8位。

如需詳細資訊，請參閱 擷取已刪除的物件。

DirSync 控件的LDAP實作

您也可以使用LDAP API搭配 LDAP_SERVER_DIRSYNC_OID 控件來執行 DirSync 搜尋。 如果您使用LDAP API，也請指定 LDAP_SERVER_EXTENDED_DN_OID 和 LDAP_SERVER_SHOW_DELETED_OID 控件。 LDAP_SERVER_EXTENDED_DN_OID控件會讓LDAP搜尋傳回延伸格式的辨別名稱，其中包含 使用者、群組和計算機等安全性主體物件的 objectGUID 和 objectSID 。 LDAP_SERVER_SHOW_DELETED_OID控件會導致搜尋結果包含已刪除對象的數據。 請注意，這些控件會自動包含在ADSI實作中。