已給予複寫屬性時發生錯誤 8606 不足,無法建立物件Replication error 8606 Insufficient attributes were given to create an object

適用於:Windows Server 2016、Windows Server 2012 R2、Windows Server 2012Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

此文章涵蓋,包括症狀、根本原因,以及如何進行解析 Active Directory 複寫錯誤 8606:不足屬性已提供給建立物件。症狀造成解析度更多資訊This article covers symptoms, root causes, and how to resolve Active Directory replication error 8606: Insufficient attributes were given to create an object. Symptoms Causes Resolution More information
症狀 DCDIAG 報告的 Active Directory 複寫測試失敗,錯誤 8606:「不足屬性已提供給建立物件」。 Starting test: Replications [Replications Check, <Destination DC>] A recent replication attempt failed: From <source DC> to <destination DC> Naming Context: <directory partition DN path> The replication generated an error (8606): Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected The failure occurred at <date> <time> The last success occurred at <date> <time> 所觸發連入複寫複製現在Active Directory 網站和服務] 嵌入式管理單元 DSSITE.MSC],它會產生下列錯誤:「不足屬性已提供給建立物件」。連接物件來源俠上按一下滑鼠右鍵,然後選取現在複製失敗,並它產生下列錯誤:「存取。」錯誤訊息文字螢幕上顯示如下: 對話方塊的標題文字: 立即複寫 對話的訊息文字: 下列錯誤同步命名操作時發生<directory 磁碟分割 DNS 名稱>的網域控制站<來源俠>網域控制站<目標 DC>: 不足屬性已提供給建立物件。此物件不可能是因為它可能已經和已經回收。 將不會繼續這項操作。 REPADMIN 命令通常引用 8606 狀態,包括但不是限於: REPADMIN /ADD REPADMIN /REPLSUM REPADMIN /SHOWREPL REPADMIN /SYNCALL 其中一項下列事件已發生之後,很快就會登入事件 1988 年: 森林中的第一個 Windows Server 2008 R2 網域控制站部署。 任何更新屬性部分設定由。 NTDS 複寫事件 1988 年能登入嘗試輸入複寫 Active Directory 網域控制站的 Directory 服務事件登入: 事件類型:錯誤 事件來源:NTDS 複寫 事件分類:複寫 263: 1988 年 的使用者:NT AUTHORITYANONYMOUS 登入 電腦:<名稱的登入的「目的「DC 複寫嘗試中的事件 DC> 描述: 本機網域控制站嘗試複製物件下列下列來源網域控制站的。此物件不存在本機網域控制站,因為它可能已經和已經回收。 來源網域控制站 <完整的來源 DC 的指引 CNAME> 物件: <上來源 DC 動態物件 DN 路徑> 物件 GUID: <物件來源網域控制站複本 Active Directory 物件的 GUID> Symptoms The DCDIAG reports that the Active Directory Replications test failed with error 8606: "Insufficient attributes were given to create an object." Starting test: Replications [Replications Check, <Destination DC>] A recent replication attempt failed: From <source DC> to <destination DC> Naming Context: <directory partition DN path> The replication generated an error (8606): Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected The failure occurred at <date> <time> The last success occurred at <date> <time> Incoming replication that is triggered by the Replicate now command in the Active Directory Sites and Services snap-in DSSITE.MSC is unsuccessful, and it generates the following error: "Insufficient attributes were given to create an object." And, right-clicking on a connection object from a source DC and then selecting Replicate now is unsuccessful, and it generates the following error: "Access is denied." The on-screen error message text reads as follows: Dialog title text: Replicate Now Dialog message text: The following error occurred during the attempt to synchronize naming context <DNS name of directory partition> from domain controller <source DC> to domain controller <destination DC>: Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected. This operation will not continue. REPADMIN commands that commonly cite the 8606 status include but are not limited to: REPADMIN /ADD REPADMIN /REPLSUM REPADMIN /SHOWREPL REPADMIN /SYNCALL Event 1988 is logged shortly after one of the following events occurs: The first Windows Server 2008 R2 domain controller in the forest is deployed. Any update to the partial attribute set is made. NTDS Replication Event 1988 may be logged in the Directory Service event log of domain controllers that are trying to inbound-replicate Active Directory: Event Type: Error Event Source: NTDS Replication Event Category: Replication Event ID: 1988 User: NT AUTHORITYANONYMOUS LOGON Computer: <name of DC that logged event, that is the "destination" DC in the replication attempt> Description: The local domain controller has attempted to replicate the following object from the following source domain controller. This object is not present on the local domain controller because it may have been deleted and already garbage collected. Source domain controller <fully qualified GUIDED CNAME of source DC> Object: <DN path of live object on source DC> Object GUID: <object GUID of object on source DCs copy of Active Directory>
會導致 8606 錯誤登入的來源網域控制站物件傳送更新時(而不是原始的物件建立)的已已經建立、刪除及回收從複本 Active directory 目的地網域控制站在執行設定目標網域控制站嚴格複寫一致性http://technet.microsoft.com/library/cc816938(WS.10).aspx 如果目的地網域控制站已設定為使用鬆散複寫一致性,物件想改為「而重新引發」上的 Active Directory 上目的地網域控制站的複本。特定的變化都可能造成 8606 錯誤以」更多資訊」一節所述。不過,錯誤會造成下列其中一個動作: 其移除會需要當下管理操作永久延遲物件。 ,將會自動修正當來源網域控制站清除其下一步回收暫時性延遲物件。部分屬性設定介紹的第一個 Windows Server 2008 R2 網域控制站現有的樹系的更新中的已知此條件的原因。 還原歧的標記期間到期日,或取消刪除物件。 疑難排解 8606 錯誤時記住下列: 問題物件封鎖複寫即使 8606 錯誤登入目的地網域控制站,位於來源網域控制站。 Causes The 8606 error is logged when a source domain controller sends an update to an object (instead of an originating object create) that was already created, deleted, and reclaimed by garbage collection from the copy of Active Directory on a destination domain controller and the destination domain controller was configured to run in strict replication consistencyhttp://technet.microsoft.com/library/cc816938(WS.10).aspx. If the destination domain controller was configured to use loose replication consistency, the object would instead be "reanimated" on the copy of Active Directory on the destination domain controller. Specific variations that can cause the 8606 error are documented in the "More Information" section. However, the error is caused by one of the following: A permanently lingering object whose removal will require administrative intervention. A transient lingering object that will correct itself when the source domain controller performs its next garbage-collection cleanup. The introduction of the first Windows Server 2008 R2 domain controller in an existing forest and updates to the partial attribute set are known causes of this condition. An object that was undeleted or restored at the cusp of tombstone lifetime expiration. Remember the following when you troubleshoot 8606 errors: Even though the 8606 error is logged on the destination domain controller, the problem object that is blocking replication resides on the source domain controller. 此外,來源網域控制站或轉移複寫合作夥伴來源網域控制站潛在<?Comment JTH: Ask Arren. 2012-02-22T15:14:00Z Id='0?>未不輸入複寫刪除的標記生活天數過去了解。<?CommentEnd Id='0' ?> Lingering 物件可能會在下列下存在: 做為「動態「物件、CNF 或衝突受損物件「動態「物件,或 CNF 或刪除的物件的容器來源網域控制站中的衝突受損物件。 包括應用程式的磁碟分割任何 directory 磁碟分割中以外架構磁碟分割。架構磁碟分割不支援刪除。 的任何物件課程(使用者、電腦、群組,以及 DNS 記錄種最常見)。延遲物件最常唯讀網域磁碟分割上 Gc 與寫入網域中找到,可能也會出現在設定磁碟分割。 記住搜尋潛在延遲物件物件 GUID 與 DN 路徑,使其主機磁碟分割與家長容器無論找到物件。搜尋 objectguid 資訊,也會尋找不使用刪除的物件 LDAP 控制刪除的物件的容器中的物件。 NTDS 複寫 1988 年事件辨識僅封鎖傳入複寫嚴格模式目的地網域控制站來源網域控制站在目前物件。其他延遲物件更新是「後方」已 1988 年事件中所參照的物件複寫佇列中有可能。 的來源網域控制站延遲物件防止或封鎖嚴格模式目的網域控制站的輸入複寫」告訴您一個好「變更背後的延遲物件複寫佇列中有。 網域控制站排列從他們刪除的物件的容器(回收精靈會執行每個 12 小時的最後一次上次開始每個網域控制站),造成錯誤 8606 目的地網域控制站物件 delete 物件的方式而無法受到下一步回收清理執行中移除。在這個課程延遲物件是暫時性的應該移除本身不會超過 12 小時的時間在問題的 [開始] 畫面。 問題的延遲物件是可能已原本是由系統管理員或應用程式。這因數到您的解析度計劃中,並注意重新引發物件,尤其是刻意已的安全性原則。 Additionally, the source domain controller or a transitive replication partner of the source domain controller potentially <?Comment JTH: Ask Arren. 2012-02-22T15:14:00Z Id='0?>did not inbound-replicate knowledge of a deleted tombstone life number of days in the past.<?CommentEnd Id='0' ?> Lingering objects may exist under the following circumstances: As "live" objects, as CNF or conflict-mangled objects "live" objects, or as CNF or conflict-mangled objects in the deleted objects container of the source domain controller. In any directory partition including application partitions except the schema partition. The schema partition does not support deletes. In any object class (users, computers, groups, and DNS records are most common). Lingering objects are most frequently found in read-only domain partitions on GCs and in writable domains and may also be found in the configuration partition. Remember to search for potentially lingering objects by object GUID vs. DN path so that objects can be found regardless of their host partition and parent container. Searching by objectguid will also locate objects that are in the deleted objects container without using the deleted objects LDAP control. The NTDS Replication 1988 event identifies only the current object on the source domain controller that is blocking incoming replication by a strict mode destination domain controller. Additional lingering object updates are likely in the replication queue "behind" the object that is referenced in the 1988 event. The presence of lingering objects on a source domain controller prevents or blocks strict mode destination domain controllers from inbound-replicating "good" changes that exist behind the lingering object in the replication queue. Because of the way that domain controllers individually delete objects from their deleted object containers (the garbage-collection daemon runs every 12 hours from the last time each domain controller last started), the objects that are causing 8606 errors on destination domain controllers could be subject to removal in the next garbage-collection cleanup execution. Lingering objects in this class are transient and should remove themselves in no more than 12 hours from problem start. The lingering object in question is likely one that was intentionally deleted by an administrator or application. Factor this into your resolution plan, and beware of reanimating objects, especially security principals that were intentionally deleted.
解析度 找出目前值樹系的TombStoneLifeTime屬性設定: c:>repadmin /showattr . "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD> /atts:tombstonelifetime 看到知識庫文章中的 [標記期間並複寫刪除] 區段910205http://support.microsoft.com/default.aspx?scid=kb;EN-US;910205 篩選登入 8606 錯誤每個目的地網域控制站,NTDS 複寫事件 1988 年 Directory 服務事件登入。 中繼資料收集為每個唯一已 1988 NTDS 複寫事件中引用的物件。 已登入 cites 新物件目的地網域控制站每個 1988 年事件,請從填入表: Resolution Identify the current value for the forest-wide TombStoneLifeTime attribute setting: c:>repadmin /showattr . "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD> /atts:tombstonelifetime See the "Tombstone lifetime and replication of deletions" section in Knowledge Base article 910205http://support.microsoft.com/default.aspx?scid=kb;EN-US;910205. For each destination domain controller that is logging the 8606 error, filter the Directory Service event log on NTDS Replication event 1988. Collect metadata for each unique object that is cited in the NTDS Replication event 1988. From each 1988 event that is logged on the destination domain controller that cites a new object, populate the following table:
物件 DN 路徑Object DN path GUID 物件Object GUID 來源俠Source DC 磁碟分割主機Host partition 動態或刪除嗎?Live or deleted? LastKnownParentLastKnownParent IsDeleted 值。IsDeleted value
可以直接從登入 1988 年事件或 8606 複寫狀態的登入的目的地網域控制站 Directory 服務事件登 NTDS 複寫 1988 年活動中的欄位讀取值擴展到 5 參考下表 1 欄。 日期加上戳記為LastKnownParentIsDeleted欄可藉由執行「repadmin /showobjmeta」,以及參考 objectguid 資訊引用 NTDS 複寫 1988 年事件中的物件。若要這樣做,請使用下列語法: c:>repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>" 的日期戳記LastKnownParent辨識已物件的日期。適用於日期戳記IsDeleted可將您的位置告知您在上次刪除或重新引發物件。上次修改是否刪除或重新引發物件的版本號碼會告訴您。IsDeleted 1 值代表初始 delete。奇大於 1 指出下列至少一個刪除重新引發值。例如,IsDeleted 2 值代表物件刪除(第 1 版),然後稍後未刪除或重新引發(版 2)。稍後甚至編號值適用於IsDeleted代表稍後 reanimations 或物件的復原。 選取適當的動作,根據物件中繼資料中 1988 年事件引用。 錯誤 8606 / NTDS 複寫事件 1988 年事件最常造成長期︰ 複寫失敗,無法輸入複寫網域控制站的森林中的所有原始刪除知識。這會導致上一或多個來源網域控制站延遲物件。 檢視,建立一個步驟中表中列出的物件的中繼資料。 如果 1988 年事件中的物件是 ((動態來源網域控制站)(刪除超過標記期間到期目的地網域控制站),但),查看移除延遲物件和<?Comment JTH: Arren 2012-02-23T06:31:00Z Id='1?>]。」< 嗎?CommentEnd Id = '1'?> 系統管理員必須手動移除此條件中的物件。 Columns 1 through 5 of this table can be populated by reading values directly from fields in the NTDS Replication 1988 events that are logged in the Directory Service event logs of the destination domain controllers that are logging either the 1988 event or the 8606 replication status. The date stamps for LastKnownParent and IsDeleted columns can be determined by running "repadmin /showobjmeta" and referencing the objectguid of the object that is cited in the NTDS replication 1988 event. To do this, use the following syntax: c:>repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>" The date stamp for LastKnownParent identifies the date on which the object was deleted. The date stamp for IsDeleted tells you when the object was last deleted or reanimated. The version number tells you whether the last modification deleted or reanimated the object. An IsDeleted value of 1 represents an initial delete. Odd-numbered values greater than 1 indicate a reanimation following at least one deletion. For example, an IsDeleted value of 2 represents an object that was deleted (version 1) and then later undeleted or reanimated (version 2). Later even-numbered values for IsDeleted represent later reanimations or undeletes of the object. Select the appropriate action based on the object metadata cited in the 1988 event. Error 8606 / NTDS Replication event 1988 event is most frequently caused by long-term replication failures that are preventing domain controllers from inbound-replicating knowledge of all originating deletes in the forest. This results in lingering objects on one or more source domain controllers. Review the metadata for object that is listed in the table that was created in the previous step. If the object in the 1988 event is either ((live on the source domain controller) but (deleted on the destination domain controller for longer than tombstone lifetime expiration)), see Removing lingering objectsand <?Comment JTH: Arren 2012-02-23T06:31:00Z Id='1?>"."<?CommentEnd Id='1' ?> Objects in this condition must be manually removed by an administrator. 刪除的物件可能已遭提前清除從刪除的物件的容器系統時間向前跳時間目的地網域控制站如果。檢視檢查時間跳一節。 如果已 1988 年事件中引用物件存在於刪除的物件的容器來源網域控制站且其 delete 日期歧的標記期間到期時間的方式,物件回收一或多個目的地網域控制站在正確和將回收在下一個回收間隔來源網域控制站(亦即延遲物件的暫時性),您可以選擇。等待下一步回收集合執行 delete 物件,或是手動觸發來源網域控制站回收。查看以手動方式開始回收。介紹的第一個 Windows Server 2008 R2 網域控制站或任何變更部分屬性設定,可能會造成此條件。 如果 repadmin /showobjmeta 輸出已 1988 年事件中引用物件的LastKnownParent的值 1,這表示,已物件,IsDeleted值 2 或一些其他甚至編號值,該日期戳記IsDeleted歧標記期間的尚餘天數的日期戳記不同的是LastKnownParent然後物件是刪除,然後取消刪除日授權還原時它來源網域控制站還是即時但已經回收目的地網域控制站錯誤 8606 日事件 1988 年登入。查看Reanimations 在歧 TSL 到期時間的。 Deleted objects may have been prematurely purged from the deleted objects container if system time jumped forward in time on the destination domain controller. Review the Check for time jumps section. If the object that is cited in the 1988 event exists in the deleted objects container of the source domain controller and its delete date is right at the cusp of tombstone lifetime expiration in such a way that the object was reclaimed by garbage collection by one or more destination domain controllers and will be reclaimed by garbage collection at the next garbage-collection interval on source domain controllers (that is, the lingering objects are transient), you have a choice. Either wait for the next garbage collection execution to delete the object, or manually trigger garbage collection on the source domain controller. See Manually starting garbage collection. The introduction of the first Windows Server 2008 R2 domain controller, or any change in the partial attribute set, can cause this condition. If repadmin /showobjmeta output for the object that is cited in the 1988 event has a LastKnownParent value of 1, this indicates that the object was deleted, and an IsDeleted value that of 2 or some other even-numbered value, and that date stamp for IsDeleted is at the cusp of the tombstone lifetime number of days different from the date stamp for LastKnownParent, then the object was deleted and then undeleted/auth-restored while it was still live on the source domain controller but already reclaimed by garbage collection by destination domain controllers logging error 8606/Event 1988. See Reanimations at the cusp of TSL expiration.
移除延遲物件 中 REPADMIN.EXE 可以從下列 directory 磁碟分割中移除延遲物件: REPADMIN /REMOVELINGERINGOBJECTS REPADMIN /REHOST REPADMIN /REMOVELINGERINGOBJCTS 可用來在 Windows Server 2003 來源網域控制站寫入和唯讀 directory 磁碟分割中移除延遲物件。語法如下: c:>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE] 位置: <Dest_DSA_LIST>是執行 Windows Server 2003 或更新版本的網域控制站的名稱,以及包含(例如 NTDS 複寫 1988 年事件中已描述來源網域控制站)延遲物件。 <來源 DSA GUID>執行 Windows Server 2003 或更新版本的網域控制站的名稱,包含延遲物件的 directory 磁碟分割複本寫入裝載的網域控制站<Dest_DSA_LIST>網路連接。 <NC> DN 路徑懷疑包含延遲物件,例如已 1988 年比賽中指定的磁碟分割 directory 磁碟分割。 REPADMIN//REHOST 可以用來在該主機中移除延遲物件網域控制站唯讀的網域 directory 正在執行 Windows 2000 SP4 或更新版本的網域控制站的磁碟分割複本。語法如下: c:>repadmin /rehost DSA <Naming Context> <Good Source DSA Address> 位置: DSA 為網域控制站的正在執行 Windows 2000 SP4 或更新版本,且裝載唯讀網域 directory 磁碟分割的本地網域名稱。例如在 root.contoso.com GC 可以重新裝載 child.contoso.com 其唯讀複本,但無法重新裝載 root.contoso.com。 <命名操作>DN 唯讀網域 directory 磁碟分割,首先位於的路徑。 <告訴您一個好來源 DSA 位址>的網域控制站是執行 Windows 2000 SP4 或更新版本,該主機寫入複本名稱<命名操作>。網域控制站必須網路-用於 DSA 電腦。 來 repadmin 未移除延遲物件已 1988 年事件中回報,評估是否 USN 間距] 中建立來源網域控制站物件是否原始網域控制站不存在於高達 dateness 來源網域控制站的物件向量如 Microsoft 知識庫文章中所述948071http://support.microsoft.com/default.aspx?scid=kb;EN-US;948071 也可以使用移除 Lingering 物件repldiag.exehttp://activedirectoryutils.codeplex.com/releases/view/13664。這項工具會自動執行 repadmin /removelingeringobjects 處理程序。 Removing lingering objects Two commands in REPADMIN.EXE can remove lingering objects from the following directory partitions: REPADMIN /REMOVELINGERINGOBJECTS REPADMIN /REHOST REPADMIN /REMOVELINGERINGOBJCTS can be used to remove lingering objects from writable and read-only directory partitions on Windows Server 2003 source domain controllers. The syntax is as follows: c:>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE] Where: <Dest_DSA_LIST> is the name of a domain controller that is running Windows Server 2003 or a later version and that contains lingering objects (such as the source domain controller that is cited in the NTDS Replication 1988 event). <Source DSA GUID> is the name of a domain controller that is running Windows Server 2003 or a later version and that hosts a writable copy of the directory partition that contains lingering objects to which the domain controller in <Dest_DSA_LIST> has network connectivity. <NC> is the DN path of the directory partition that is suspected of containing lingering objects, such as the partition that is specified in a 1988 event. REPADMIN /REHOST can be used to remove lingering-objects domain controllers that host a read-only copy of a domain directory partition from domain controllers that are running Windows 2000 SP4 or a later version. The syntax is as follows: c:>repadmin /rehost DSA <Naming Context> <Good Source DSA Address> Where: DSA is the name of a domain controller that is running Windows 2000 SP4 or a later version and that hosts a read-only domain directory partition for a nonlocal domain. For example, a GC in root.contoso.com can rehost its read-only copy of child.contoso.com but cannot rehost root.contoso.com. <Naming Context> is the DN path of a read-only domain directory partition that is residing in a global catalog. <Good Source DSA Address> is the name of a domain controller that is running Windows 2000 SP4 or a later version and that hosts a writable copy of <Naming Context>. The domain controller must be network-available to the DSA computer. If the lingering object that is reported in the 1988 event is not removed by repadmin, evaluate whether the object on the source domain controller was created in USN gap, or whether the objects originating domain controller does not exist in the source domain controller's up-to dateness vector as documented in Microsoft Knowledge Base article 948071http://support.microsoft.com/default.aspx?scid=kb;EN-US;948071. Lingering objects can also be removed by using repldiag.exehttp://activedirectoryutils.codeplex.com/releases/view/13664. This tool automates the repadmin /removelingeringobjects process.
每天監視 Active Directory 複寫健康 如果錯誤 8606 / 事件 1988 年網域控制站的無法在最後一個標記期間天數複寫 Active Directory 變更,請務必在接下來日常監視 Active Directory 複寫健康所造成。使用專屬的監視應用程式,或檢視的輸出執行一個便宜但有效選項可監視複寫健康「repadmin /showrepl * /csv」試算表應用程式,例如 Microsoft Excel 中的命令。(看到「方法 2:使用命令列監視器複寫「Microsoft 知識庫文章中910205http://support.microsoft.com/kb/910205)。 ,已經不輸入複寫以 50%的標記期間的尚餘天數網域控制站應該放在收到優先順序管理員注意進行操作︰ 複寫觀賞清單。不能順利複寫的網域控制站應該會推動-降級如果它們已不複寫 90%標記期間 (TSL) 中。 藉由目的地網域控制站、來源網域控制站或網路的 DNS 基礎結構,可能因為目的地網域控制站顯示︰ 複寫失敗。 Monitoring Active Directory replication health daily If error 8606 / Event 1988 was caused by the domain controller's failing to replicate Active Directory changes in the last tombstone lifetime number of days, make sure that Active Directory replication health is being monitored on a day-to-day basis going forward. Replication health may be monitored by using a dedicated monitoring application or by viewing the output from the one inexpensive but effective option to run "repadmin /showrepl * /csv" command in a spreadsheet application such as Microsoft Excel. (See "Method 2: Monitor replication by using a command-line" in Microsoft Knowledge Base article 910205http://support.microsoft.com/kb/910205). Domain controllers that have not inbound-replicated in 50 percent of tombstone lifetime number of days should be put in a watch list that receive priority admin attention to make replication operational. Domain controllers that cannot be made to successfully replicate should be force-demoted if they have not replicated within 90 percent of tombstone lifetime (TSL). Replication failures that appear on a destination domain controller may be caused by the destination domain controller, by the source domain controller, or by the underlying network and DNS infrastructure.
檢查時間跳 若要判斷是否時間跳躍發生,請檢查日期戳記事件和診斷登 (事件檢視器 repadmin /showreps,netlogon 登,dcdiag 報告) 登錯誤 8606 日 NTDS 複寫 1988 年事件下列目的網域控制站在: 日期毒手作業系統(例如,從 CY 2003 的作業系統,在 CY 2008 年推出日期戳記)發行的戳記 日期毒手中的作業系統安裝的戳記您的樹系 未來日期戳記 有不在特定的日期範圍事件 Microsoft 支援服務團隊已經看過不正確跳小時、日期、星期、年來和甚至數以萬計的過去與未來年 production 網域控制站系統時間。如果系統時間找不正確,您應該更正它,然後再試判斷時間為何跳和項目可以避免往後與只修正不正確的時間不正確的時間來完成。可能問題来詢問如下: 的樹系根 PDC 使用外部的時間來源的設定嗎? 的參考 online 的時間來源,在網路上可以使用和 dns 解析嗎? 是 Microsoft 或第三方時間服務執行和錯誤免費狀態? 的網域控制站角色電腦設定為使用 NT5DS 階層來源時間? 是 Microsoft 知識庫文章中所述時間復原保護884776http://support.microsoft.com/default.aspx?scid=kb;EN-US;884776的地方? 系統時鐘擁有告訴您一個好電池和正確的時間在 BIOS 網域控制站 virtual 主機電腦上嗎? 的 virtual 主機和客體電腦設定為裝載製造商建議依據來源時間? Microsoft 知識庫文章884776http://support.microsoft.com/default.aspx?scid=kb;EN-US;884776文件步驟,以協助保護從「聆聽」的網域控制站範例不正確的時間。MaxPosPhaseCorrection 及 MaxNegPhaseCorrection 的相關資訊可在W32Time 部落格http://blogs.msdn.com/b/w32time/張貼設定服務時間:PhaseCorrection 最大的 [位置日負]http://blogs.msdn.com/b/w32time/archive/2008/02/28/configuring-the-time-service-max-pos-neg-phasecorrection.aspx。Microsoft 知識庫文章961027http://support.microsoft.com/default.aspx?scid=kb;EN-US;961027告訴您一些很有幫助精確的更新,當您在原則設定以時間為基礎的設定。 使用檢查延遲物件」repadmin /removelingeringobjects /advisorymode,」並視需要移除。 [允許複寫 Divergent 與損壞合作夥伴」所需的放寬。 Check for time jumps To determine whether a time jump occurred, check date stamps in Event and diagnostic logs (Event Viewer, repadmin /showreps, netlogon logs, dcdiag reports) on destination domain controllers that are logging error 8606/NTDS Replication 1988 events for the following: Date stamps that predate the release of an operating system (for example, date stamps from CY 2003 for an OS released in CY 2008) Date stamps that predate the installation of the operating system in your forest Date stamps in the future Having no events that are logged in a given date range Microsoft Support teams have seen system time on production domain controllers incorrectly jump hours, days, weeks, years, and even tens of years in the past and future. If system time was found to be inaccurate, you should correct it and then try to determine why time jumped and what can be done to prevent inaccurate time going forward vs. just correcting the bad time. Possible questions to ask include the following: Was the forest root PDC configured by using an external time source? Are reference online time sources available on the network and resolvable in DNS? Was the Microsoft or third-party time service running and in an error-free state? Are domain controller role computers configured to use NT5DS hierarchy to source time? Was time rollback protection that is described in Microsoft Knowledge Base article 884776http://support.microsoft.com/default.aspx?scid=kb;EN-US;884776 in place? Do system clocks have good batteries and accurate time in the BIOS on domain controllers on virtual host computers? Are virtual host and guest computers configured to source time according to the hosting manufacturer's recommendations? Microsoft Knowledge Base article 884776http://support.microsoft.com/default.aspx?scid=kb;EN-US;884776 documents steps to help protect domain controllers from "listening" to invalid time samples. More information about MaxPosPhaseCorrection and MaxNegPhaseCorrection is available in the W32Time Bloghttp://blogs.msdn.com/b/w32time/ post Configuring the Time Service: Max[Pos/Neg]PhaseCorrectionhttp://blogs.msdn.com/b/w32time/archive/2008/02/28/configuring-the-time-service-max-pos-neg-phasecorrection.aspx. Microsoft Knowledge Base article 961027http://support.microsoft.com/default.aspx?scid=kb;EN-US;961027 describes some helpful precision updates when you are configuring time-based settings in policy. Check for lingering objects by using "repadmin /removelingeringobjects /advisorymode," and then remove them as required. Relax "Allow replication with Divergent and corrupt partner" as required.
手動起始回收 手動觸發程序回收特定網域控制站,有多種方法: 執行「repadmin /setattr」」」」doGarbageCollection 新增 1] 執行 LDIFDE /s<伺服器>/i /f dogarbage.ldif dogarbage.ldif 包含文字的位置: dn: changetype: modify replace: DoGarbageCollection dogarbagecollection: 1 - 最終」-」字元需要.ldif 檔案的項目。 Manually starting garbage collection Several options exist to manually trigger garbage collection on a specific domain controller: Run "repadmin /setattr "" "" doGarbageCollection add 1" Run LDIFDE /s <server> /i /f dogarbage.ldif where dogarbage.ldif contains the text: dn: changetype: modify replace: DoGarbageCollection dogarbagecollection: 1 - The final "-" character is a required element of the .ldif file.
Reanimations 歧在 TSL 到期時間的 存在,repadmin 這個條件 /showobject]<GUID = 物件 guid 1988 事件中的物件>」應該物件」中找不到「目的地網域控制站但動態來源網域控制站的報告,而且刪除或 nondeleted 的物件。 鍵欄位 repadmin 的評論 /showobjmeta 來源網域控制站應該報告下列成立: LastKnownParent的值為 1,其日期戳記位於歧過去 TSL 天。它日期戳記表示物件 delete 日期。 IsDeleted 2 的版本號碼(或是其他甚至編號值),其中第 1 版定義原始刪除而 2 版本還原/重新更動。日期戳記「isDeleted = 2「上次變更日期之後,應該LastKnownParent數天來大約等於 TSL。 評估是否有問題的物件應維持作用中的物件或刪除的物件。如果LastKnownParent問題的值為 1 或其他人刪除物件。如果這不是意外刪除,應用程式很應該刪除從任何已物件複本動態來源網域控制站的物件。 選項物件應該存在上所有的複本,如果是,如下所示: 讓鬆散複寫嚴格模式目的地網域控制站不具有物件。 推動降級已回收的網域控制站收集物件。 Delete 物件,再重新建立。 Reanimations at the cusp of TSL expiration For this condition to exist, repadmin /showobject "<GUID=object guid for object in 1988 event>" should report that the object is "not found" on the destination domain controller but is live on the source domain controller and is either a deleted or a nondeleted object. A review of key fields from repadmin /showobjmeta on the source domain controller should report that the following are true: LastKnownParent has a value of 1, and its date stamp is at the cusp of TSL days in the past. Its date stamp indicates the delete date of the object. IsDeleted has a version number of 2 (or another even-numbered value), where version 1 defined the original deletion and version 2 is the restore/reanimation. The date stamp for "isDeleted=2" should be after the last change date for LastKnownParent by a number of days approximately equal to TSL. Evaluate whether the object in question should remain a live object or a deleted object. If LastKnownParent has a value of 1, something or someone deleted the object. If this was not an accidental deletion, chances are good that the object should be deleted from any source domain controllers that have a live copy of the object. If the object should exist on all replicas, the options are as follows: Enable loose replication on strict mode destination domain controllers that do not have the object. Force-demote the domain controllers that have already garbage collected the object. Delete the object and then re-create it.
其他資訊 造成延遲物件的 More information Causes of Lingering Objects
原因 1:來源網域控制站傳送更新己目的地網域控制站回收因為來源網域控制站離線或 TSL 複寫失敗的物件經歷的尚餘天數。 CONTOSO.COM 網域中包含兩種網域控制站在相同的網域。標記期間等於 60 天。嚴格複寫是在兩個網域控制站支援。DC2 體驗主機板失敗。同時,DC1 將原始刪除過時安全性群組每天後的 90 天。它離線 90 天之後,DC2 接收取代主機板、力量,並再來自 ACL 的變更所有使用者帳號之前它輸入複寫的原始從 DC1。DC1 登 8606 更新安全性群組清除 DC1 上 DC2 已離線第一次 30 天的錯誤。 Cause 1: The source domain controller sends updates to objects that have already been reclaimed by garbage collection on the destination domain controller because the source domain controller either was offline or has failed replication for TSL elapsed number of days. The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime equals 60 days. Strict replication is enabled on both domain controllers. DC2 experiences a motherboard failure. Meanwhile, DC1 makes originating deletes for stale security groups daily over the next 90 days. After it is offline for 90 days, DC2 receives a replacement motherboard, powers up, and then originates an ACL change on all user accounts before it inbound-replicates knowledge of originating deletes from DC1. DC1 logs 8606 errors for updates security groups that are purged on DC1 for the first 30 days that DC2 was offline.
原因 2:來源 DC 傳送更新己回收嚴格模式目的地俠在歧 TSL 到期時間的物件。 CONTOSO.COM 網域中包含兩種網域控制站在相同的網域。 Cause 2: The Source DC sends updates to objects at the cusp of TSL expiration that have already been reclaimed by garbage collection by a strict mode destination DC. The CONTOSO.COM domain contains two domain controllers in the same domain. 標記期間等於 60 天。Tombstone lifetime equals 60 days. 嚴格複寫是在兩個網域控制站支援。Strict replication is enabled on both domain controllers. DC1 和 DC2 複寫每 24 小時。DC1 and DC2 replicate every 24 hours. DC1 每天來自刪除。DC1 originates deletes daily. DC1 是就地升級到nextref_server_includes >。DC1 is in-place upgraded to nextref_server_includes>. 這加上所有的設定和寫入網域磁碟分割中的物件戳記新的屬性。This stamps new attributes on all objects in the configuration and writable domain partitions. 這包含目前正在刪除的物件的容器,其中一些已 60 天前,現在的標記到期歧正在物件。This includes objects that are currently in the deleted objects container, some of which were deleted 60 days ago and are now at the cusp of tombstone expiration. 部分物件回收所 DC2 收回刪除 TSL 天前之前複寫排程開啟 DC2。DC2 reclaims some objects by garbage collection that were deleted TSL days ago before the replication schedule opens with DC2. 錯誤 8606 登之前 DC1 回收封鎖物件回收。Error 8606 is logged until DC1 reclaims the blocking objects by garbage collection. 部分屬性設定的任何更新,可能會造成暫時,將會清除本身之後來源網域控制站收集廢棄刪除的物件,歧 TSL 到期時間的延遲物件 (例如,除了的第一個nextref_server_includes > 現有的樹系的網域控制站)。Any updates to the partial attribute set can cause temporary lingering objects that will clear themselves up after source domain controllers garbage-collect deleted objects at the cusp of TSL expiration (for example, the addition of the first nextref_server_includes> domain controller to an existing forest).
原因 3:時間跳躍目的網域控制站提前加快刪除的物件回收目的地網域控制站。 CONTOSO.COM 網域中包含兩種網域控制站在相同的網域。標記期間等於 60 天。嚴格複寫是在兩個網域控制站支援。DC1 和 DC2 複寫每 24 小時。DC1 每天來自刪除。使用 DC1(但不是 DC2)參考資料的時間來源回復到行事曆年 2039 年。這會造成 DC2 也採用行事曆年 2039 年系統時間。這會造成 DC1 提前 delete 的刪除的物件容器從今天刪除的物件。同時,DC2 來自對使用者、電腦及群組動態上 DC2 但刪除屬性,並立即提前回收 DC1 上。DC1 將會登錯誤 8606 時它接下來輸入複寫分批刪除物件的變更。 Cause 3: A time jump on a destination domain controller prematurely speeds up the garbage collection of deleted objects on a destination domain controller. The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime equals 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. The reference time source that is used by DC1 (but not DC2) rolls forward to calendar year 2039. This causes DC2 to also adopt a system time in calendar year 2039. This causes DC1 to prematurely delete objects that are deleted today from its deleted objects container. Meanwhile, DC2 originates changes to attributes on users, computers, and groups that are live on DC2 but deleted and now prematurely garbage collected on DC1. DC1 will log error 8606 when it next inbound-replicates changes for the premature deleted objects.
4 的原因︰ 物件重新引發的 TSL 到期歧在 CONTOSO.COM 網域中包含兩種網域控制站在相同的網域。標記期間等於 60 天。嚴格複寫是在兩個網域控制站支援。DC1 和 DC2 複寫每 24 小時。DC1 每天來自刪除。不小心被刪除組織單位,其中包含使用者、電腦,以及群組。系統狀態備份所做的 TSL 歧,在過去是在 DC2 驗證還原。備份包含即時 DC2 上,但已刪除或回收 DC1 上的物件。 Cause 4: An object is reanimated at the cusp of TSL expiration The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime equals 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. An OU that contains users, computers, and groups is accidentally deleted. A system state backup that is made at the cusp of TSL in the past is auth-restored on DC2. The backup contains objects that are live on DC2 but already deleted and reclaimed by garbage collection on DC1.
原因 5: 觸發 USN 泡泡 8606 的登入 假設您建立物件,它會不輸出複寫因為目的地網域控制站」認為」它在這種方式 USN 泡泡泡泡因為有物件。現在,泡泡關閉後,變更 [開始],複製再試一次後,變更建立該物件來源網域控制站的及會顯示為目的網域控制站的延遲物件。目的地控制器登 8606 事件。 Cause 5: A USN bubble is triggered the logging of the 8606 Suppose you create an object in a USN bubble in such a way that it does not outbound-replicate because the destination domain controller "thinks" it has the object because of the bubble. Now, after the bubble closes, and after changes start to replicate again, a change is created for that object on the source domain controller and is displayed as a lingering object to the destination domain controller. The destination controller logs the 8606 event.
端點需求複寫來自刪除了解 Active Directory 網域控制站支援多主機複寫任何網域控制站(寫入磁碟分割)可以在位置來自建立,變更物件的 delete 或屬性(值)。原始的網域控制站的任何網域控制站的 TSL 的尚餘天數原始 delete 傳入複製知識保存的物件日屬性刪除知識。(請查看 Microsoft 知識庫文章216996http://support.microsoft.com/default.aspx?scid=kb;EN-US;216993910205http://support.microsoft.com/default.aspx?scid=kb;EN-US;910205) Active Directory 需要的所有的磁碟分割持有間接至所有磁碟分割位置複製所有 directory 磁碟分割中的所有原始刪除端點-複寫。輸入複寫 directory 磁碟分割中循環 TSL 數天導致延遲物件。延遲物件是的物件的刻意已於至少網域控制站,但不正確存在的目的網域控制站的不輸入複寫的所有唯一刪除暫時性知識。 Requirements for end-to-end replicate knowledge of originating deletes Active Directory domain controllers support multi-master replication where any domain controller (holding a writable partition) can originate a create, change, or delete of an object or attribute (value). Knowledge of object/attribute deletes are persisted by the originating domain controller and any domain controller that has incoming replicated knowledge of an originating delete for TSL number of days. (See Microsoft Knowledge Base articles 216996http://support.microsoft.com/default.aspx?scid=kb;EN-US;216993 and 910205http://support.microsoft.com/default.aspx?scid=kb;EN-US;910205) Active Directory requires end-to-end replication from all partition holders to transitively replicate all originating deletes for all directory partitions to all partition holders. Failure to inbound-replicate a directory partition in a rolling TSL numbers of days results in lingering objects. A lingering object is an object that was intentionally deleted by at least one domain controller but that incorrectly exists on destination domain controllers that did not inbound-replicate the transient knowledge of all unique deletions.
疑難排解 Active Directory 操作失敗的錯誤 8606:「不足屬性已給予建立物件] http://support.microsoft.com/kb/2028495 Troubleshooting Active Directory operations that fail with error 8606: "Insufficient attributes were given to create an object" http://support.microsoft.com/kb/2028495