dirsync 查詢顯示對似乎不存在的 AD 對象的更改
AdamSync 定期崩潰。在故障排除中，我們發現當它遇到它認為是空的 DN 時會拋出異常。我使用儲存在 ADLDS 配置中的 dirsync cookie 重放了查詢。轉儲返回的值，我發現以下對象：
CN=SCCM Site Server\0ADEL:0b9efaf1-24cc-46a1-92ff-f6aa74254d3e,CN=Deleted Objects,DC=appd,DC=appstate,DC=edu description objectguid 0b9efaf1-24cc-46a1-92ff-f6aa74254d3e instancetype 4 isrecycled TRUE據我們所知，該對像不再存在。我們使用我們的任何工具都找不到它：使用者和電腦、LDP、ADSI 編輯、AD 管理中心、AD Explorer、PowerShell 查詢（全部使用已刪除/回收的過濾器、擴展和標誌）。我們認為，自 dirsync 查詢中指定的日期以來，它可能已命中其墓碑並由垃圾收集器處理。如果是這樣，是否會繼續返回屬性更改記錄？無限期？如果它沒有被垃圾收集器處理，為什麼我們找不到它？
由於該值而導致的 AdamSync 崩潰似乎是次要影響或完全不同的問題。
如果您執行 DirSync LDAP 查詢而不指定要返回的任何屬性，則它會返回任何已更改的對象。如果您啟用了 Active Directory 資源回收筒，則當對象轉換為回收狀態時（如原始問題中列出的屬性所示），狀態更改將導致 DirSync 發送帶有 isRecycled = True 對象的條目。
在與一位 MS Premier 工程師合作後，我們發現 AdamSync 在返回 DirSync 結果後對對象進行了第二次請求。如果用於執行 AdamSync 執行檔的帳戶僅配置了“複製目錄更改”權限，則 AdamSync 無法讀取返回的對象，因為沒有讀取回收對象的權限。這導致第二次查找的 DN 為 NULL，從而導致 AdamSync 因未處理的異常而崩潰。
存在兩種解決方案：禁用 AD 資源回收筒或修改 AdamSync LDAP 查詢以排除 isRecycled = TRUE 的對象：
(&(<ldap_filter>)(!(IsRecycled=TRUE))請注意，“TRUE”必須大寫。
MS Premier 表示 AdamSync 處於“原樣”狀態，未處理的異常不太可能被修補。