疑難排解 Active Directory 複寫錯誤8614

本文提供疑難排解 Active Directory 複寫錯誤8614的步驟。

原始產品版本:   Windows Server 2012 R2
原始 KB 編號:   2020053

注意

家庭使用者: 本文僅適用于技術支援代理商和 IT 專業人員。 如果您正在尋找問題的說明,請 詢問 Microsoft 社區

徵狀

  1. DCDIAG 報告 Active Directory 複寫測試失敗,錯誤狀態碼8614: Active Directory 無法與此伺服器進行複製,因為最後一個與此伺服器進行複寫的時間超過 tombstone 存留期限。

    測試伺服器: <site name><destination dc name>
    開始測試:複製
    * Replications Check
    [Replications Check,<destination DC name] A recent replication attempt failed:
    From <source DC> to <destination DC>
    Naming Context: <directory partition DN path>
    The replication generated an error (8614): Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.
    The failure occurred at <date> <time>.
    The last success occurred at <date> <time>.
    3 failures have occurred since the last success.

  2. REPADMIN.EXE 報告上一個複寫嘗試失敗,狀態為8614。 通常表示8614狀態的 REPADMIN 命令包括但不限於:

    • REPADMIN /REPLSUM
    • REPADMIN /SHOWREPL
    • REPADMIN /SHOWREPS
    • REPADMIN /SYNCALL

    REPADMIN /SHOWREPS contoso-DC2 到 contoso-DC1 失敗及「 複製存取遭到拒絕 」的輸入複寫範例輸出如下所示:

    Default-First-Site-Name\CONTOSO-DC1
    DSA 選項: IS_GC
    網站選項: (無)
    DSA 物件 GUID:
    DSA invocationID:

    = = = = 內接鄰居 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

    DC=contoso,DC=com
    透過 RPC Default-First-Site-Name\CONTOSO-DC2
    DSA 物件 GUID:
    上次嘗試 @ <date> <time> failed,result 8614 (0x21a6) : Active Directory 無法與此伺服器進行同步處理,因為最後一個複寫與此伺服器的時間已超過 tombstone 存留期限。
    < # > 連續失敗 (s) 。
    上次成功 @ <date> <time> 。

  3. 具有5個狀態的 NTDS KCC、NTDS 一般或 Microsoft Windows ActiveDirectory_DomainService 事件會記錄在目錄服務事件記錄檔中。

    通常指出8524狀態的 Active Directory 事件包括但不限於下列專案:

    事件來源 識別碼 事件字串
    NTDS KCC 1925 嘗試為下列可寫入的目錄分割區建立複寫連結失敗。
  4. 在目錄服務事件記錄檔中可能會記錄 NTDS 複寫事件2042:

    事件類型:錯誤
    事件來源: NTDS 複寫
    事件類別:複寫
    事件 ID: 2042
    使用者: NT AUTHORITY\ANONYMOUS 登入
    電腦: <name of DC that logged event>

    描述:
    這是因為此機器上次與命名的來源機器進行複寫,所以過長。 與此來源之間的副本之間的時間已超過 tombstone 存留時間。 已停止使用此來源的複寫。

    無法繼續進行複寫的原因是,兩部機器的已刪除物件檢視現在可能會不同。 來源機器在此機器上仍有已刪除 (和垃圾收集) 的物件複本。 如果允許複寫,來源機器可能會傳回已經刪除的物件。

    上次成功複寫的時間: YYYY-MM-DD HH: MM: SS
    來源的呼叫識別碼: <32 character GUID for source DC>
    來源名稱: <fully qualified cname record of source DC>
    Tombstone 存留期 (天數) : <current TSL value. Default = 60 or 180 days>

    複寫作業失敗。

    使用者動作:

    決定兩部機器中的哪一部中斷連線樹系的連線,現在已過時。 您有三個選項:

    1. 降級或重新安裝已中斷連線的機器 () 。
    2. 使用 repadmin /removelingeringobjects 工具移除不一致的已刪除物件,然後繼續複寫。
    3. 繼續複寫。 可能會引入不一致的已刪除物件。 您可以使用下列登錄機碼繼續複寫。 當系統複製一次之後,建議您移除金鑰以復原保護。
  5. [Active Directory 網站和服務] 中的 [ 立即 複寫] 命令會傳回郵件 Active directory 無法與此伺服器進行同步處理,因為最後一次複寫與此伺服器的時間已超過 tombstone 存留期限

    以滑鼠右鍵按一下來源 DC 上的 connection 物件,然後選擇 [ 立即 複寫] [Active Directory 網站和服務] (DSSITE]。MSC) 會失敗,而且您收到的郵件 Active Directory 無法與此伺服器進行複寫,因為最後一個與此伺服器進行複寫的時間已超過 tombstone 存留期限

    螢幕上的錯誤訊息文字如下:

    對話方塊標題文字:立即複製
    對話方塊訊息文字:嘗試同步處理命名內容 <% directory 磁碟分割名稱% > (從網域控制站 <Source DC> 到網域控制站)時發生下列錯誤 <Destination DC> :

    Active Directory 無法與此伺服器進行複製,因為最後一個與此伺服器進行複寫的時間已超過 tombstone 存留時間。
    作業不會繼續

    對話方塊中的按鈕: OK

原因

Active Directory 網域控制站支援多主複本,其中任何容納可寫入分割區的網域控制站都可以建立、修改或刪除物件或屬性 (value) 。 物件/屬性刪除的知識會持續存在於邏輯刪除存留期天數。 (查看 有關 Windows Server Active Directory 樹系中的延遲物件的資訊

Active Directory 需要從所有分割區擁有端對端的複寫,才能將所有目錄磁碟分割的所有原始刪除,都複寫到所有分割區。 無法在滾動 TSL 中輸入目錄分割區。天數會產生延遲物件。 (延遲物件是指至少已由至少一個 DC 刪除但不正確地存在於目的 Dc 上的物件,但該物件在無法輸入所有唯一刪除之暫態知識的目的 Dc 上。 )

錯誤8614是在執行 Windows Server 2003 或更新版本的網域控制站中新增的邏輯範例,用來隔離延遲物件的散佈,並識別導致不一致的目錄磁碟分割的長期複寫失敗。 錯誤8614及 NTDS 複寫事件2042的根本原因包括下列各項:

  1. 記錄8614錯誤的目的地 DC 無法從一或多個來源 Dc 輸入目錄磁碟分割以進行 tombstone 存留天數。

  2. 目標 DC 上的系統時間已移動或已跳過,邏輯刪除週期是自上次成功複寫以來的未來一或多個天數。 這為複寫引擎提供的 外觀 ,目的 DC 無法輸入重複的目錄磁碟分割以進行 tombstone 存留時間(天數)。

    當目的地 DC 順利輸入時,可能會發生時間跳躍時,會發生 錯誤 的系統時間 TSL 或以後的天數,然後會嘗試從上次從 TSL 中複製的來源或過去數天內的來源,進行輸入的複製。

    從目前的時間到日期/時間邏輯刪除存留期或過去的天數,已成功輸入重複輸入,然後嘗試在未來的時間 TSL 或數天之後進行輸入重複。

本質上,複寫錯誤狀態8614的原因和解決步驟,會均等地套用到 NTDS 複寫事件2042的原因和解決方法。

解決方案

注意

有兩個行動計畫可復原已記錄錯誤狀態8614或 NTDS 複寫事件2042的 Active Directory 網域控制站。 您既可以強制降級網域控制站,也可以使用下列的行動計畫: 檢查必要的修正程式、查看是否有必要的修正程式、檢查是否有延遲物件,以及移除其(如果有的話),請移除任何複寫隔離、解決複寫失敗,然後將 DC 放回服務。 強制降級這類 Dc 會變得更輕鬆及更快,但也可能導致來源更新遺失 (也就是說,強制降級的網域控制站上的資料遺失) 。 您可以遵循下列步驟,從這種狀況順利恢復 Active Directory。 選取適用于您案例的最佳解決方案,但不要假設強制降級是唯一可行的解決方案,尤其是在 Active Directory 以外的地方,尤其是在此情況下,複製失敗很容易解決。

  1. 檢查 tombstone 存留時間的非預設值。

    根據預設,邏輯刪除壽命會根據樹系中部署的 Windows 版本,使用60或180天。 Microsoft 支援定期查看 Dc 的失敗的輸入複寫時間。 您也可以將 tombstone 存留時間設定為一小段時間,例如2天。 如果是這種情況,則未輸入的 Dc (如5天)將會失敗, 所有的 dc 都必須以滾動 TSL 天數 測試進行複製。

    用於 repadmin /showattr 查看是否已設定 TombstoneLifetime 屬性的非預設值。

    repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<forest root domain>,DC=<top level domain>"
    

    如果輸出中未顯示此屬性 showattr ,則使用內部預設值。

  2. 檢查是否有失敗之輸入複寫的 Dc,TSL 天數

    repadmin /showrepl * /csv使用「驗證成功複寫至網域控制站」區段中所指定的方式,執行分析。 在 [最後複寫成功] 欄上,將 Excel 中的 replsum 輸出排序從最新的日期和時間順序。

  3. 檢查 Windows Server 2003 RTM 網域控制站。

    如果在 Windows Server 2003 RTM 網域控制站上發生8614錯誤,請安裝最新的 Windows Server 2003 service pack。

  4. 檢查時間跳躍。

    若要判斷是否發生時間 跳躍 ,請檢查事件及診斷記錄 (repadmin /showreps ,dcdiag 記錄) 在目的地 dc 上,記錄下列專案的8614錯誤:

    • Predate 作業系統發行的日期戳記 (windows Server 2003 的日期戳記,以 Windows Server 2008 發行的作業系統)
    • Predate 在樹系中安裝作業系統的日期戳記
    • 未來的日期戳記
    • 在指定的日期範圍內沒有記錄事件

    Microsoft 支援小組在實際執行的網域控制站上看到系統時間,在過去和未來的時間、天、周數、年數甚至數十年中,會錯誤地跳入。

    如果找不到系統時間,您應該更正它,然後嘗試判斷時間的跳過原因及可執行檔動作,以避免持續的錯誤時間與更正錯誤的時間。 可能的調查區域包括下列各項:

    • 樹系根 PDC 是使用外部時間來源設定嗎?
    • 線上、網路上是否可使用參考時間來源,以及是否可在 DNS 中解析?
    • 是由 Microsoft 或協力廠商的時間服務執行,還是以無錯誤的狀態運作?
    • 是否設定為使用 NT5DS 階層至源時間的 DC 角色電腦?
    • 設定 Windows 時間服務時,如何將 Windows 時間服務設定 為適當的時間位移,是否會說明時間復原保護?
    • 系統時鐘在 BIOS 中是否有良好的電池和準確的時間?
    • 虛擬主機和來賓電腦是否根據主控廠商的建議設定為來源時間?

    本文 說明如何設定 Windows 時間服務以符合大的時間偏移 檔步驟,以協助防止網域控制站接聽不正確時間範例。 MaxPosPhaseCorrectionMaxNegPhaseCorrection 的詳細資訊,可在 Windows 時間服務中取得。

  5. 檢查並移除延遲物件(如果有的話)。

    8614錯誤複寫隔離的點是檢查延遲物件,如果有的話,請在每個以本機保留的磁碟分割中,將其設定為在目的地 DC 登錄中的 [允許以其他方式與損毀] 夥伴進行的 複寫,即使您認為樹系中的所有目的 dc 都是以嚴格的複寫一致性執行。

    延遲物件的移除超出本文的範圍。 如需詳細資訊,請參閱下列來源:

    Repadmin 語法如下所示:

    語法 線上說明 (Windows Server 2008 和更新版本)
    c:\>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/advisory_mode] c:\>repadmin /help:removelingeringobject
  6. 評估在目的地 Dc 上設定嚴格複寫。

    嚴格模式複寫可防止在已使用垃圾收集建立、刪除和回收故意刪除之物件的目的地 Dc 上 reanimated 延遲物件。

    嚴格複寫的登錄機碼如下: \

    • 路徑: HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters
    • 設定:嚴格複寫一致性 <-不區分大小寫>
    • 類型: reg_dword
    • 值: 0 |1

    在單一或多個 Dc 上啟用及停用嚴格複寫的 Repadmin 語法如下:

    語法 線上說明 (Windows Server 2008 和更新版本) 在單一 DC 上啟用 在樹系中的所有 Dc 上啟用 在樹系中的所有 Gc 上啟用
    repadmin /regkey <DSA_LIST> <{+|-}key> [value [/reg_sz]] Repadmin /help:regkey repadmin /regkey <fully qualified computer name> +strict repadmin /regkey * +strict repadmin /regkey gc: +strict
  7. 在 8614 DC 上,設定 允許以分歧及 損毀的夥伴進行複寫至1。

    移除任何延遲物件後,請停用以時間為基礎的複寫隔離:

    Registry 方法

    • 登錄路徑: HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters
    • 登錄設定:允許具有分歧及損毀夥伴的複寫 <-不區分大小寫》
    • 登錄值: 0 = 禁止,1 = 允許

    Repadmin 方法

    語法 線上說明 (Windows Server 2008 和更新版本) 在單一 DC 上啟用 在樹系中的所有 Dc 上啟用 在樹系中的所有 Gc 上啟用
    repadmin /regkey <DSA_LIST> <{+|-}key> [value [/reg_sz]] Repadmin /help:regkey repadmin /regkey dc01.contoso.com +allowDivergent repadmin /regkey * +allowDivergent repadmin /regkey GC: +allowDivergent
  8. 解決 AD 複寫失敗(如果有的話)。

    當在目的地 DC 上記錄8614錯誤狀態時,會遮罩先前 TSL 中所記錄的前幾天的複製錯誤。

    [!注意] 目的地 DC 會報告8614錯誤,這表示在目的地 DC 上的複寫錯誤。 相反地,複寫失敗的來源可能與網路或 DNS 名稱解析有關,或者可能是具有 jet 資料庫、拓撲或來源 DC 或目的地 DC 上的複寫引擎的驗證問題。

    複習過去的目錄服務事件和診斷輸出 (dcdiag、repadmin 記錄從源 DC 所產生的) 、目的地 DC,以及過去的替代複寫夥伴,以識別阻礙目的地 DC 與來源 DC 間複寫的範圍和失敗狀態。

  9. Delete 允許具有分歧及 損毀夥伴的複寫,或將登錄中 具有分歧及 損毀夥伴的複寫設定為0。

  10. 監視 Active Directory 複寫每日繼續進行。

    使用 Active Directory monitoring application 監視 Active Directory 樹系中的端對端複寫。 一個成本低但有效的選項是先執行 repadmin /showrepl * /csv ,然後再剖析 Excel 中的結果。 (請參閱 方法2:使用命令列監視 複寫在 Windows Server Active Directory 樹系中的延遲物件的相關資訊。 )

    找出接近50% 的複寫失敗,以及90% 的 tombstone 存留時間,並將它們放在手錶清單中的 Dc。 在 TSL 的50% 中,進行強大的推入以解決複寫錯誤。 在90% 時,必要時請考慮使用 dcpromo /forceremoval 導致複寫錯誤的命令) dc,強制 (強制降級。

    另外,在目的地 dc 上記錄的複寫錯誤可能是由於來源 DC、目的地 DC 或基礎網路上的問題所造成。 因此,在您採取預防性動作之前,請盡力判斷原因及其錯誤的所在位置。

參考

修正 (事件 IDs 1388、1988、2042) 的複寫延遲物件問題