本文提供在移除複寫檔案篩選之後，針對唯讀成員回報待辦專案的問題的解決方案。
原始 KB 編號： 4021676
徵兆
試想以下情況：
- 您正在執行 Windows Server 2019、Windows Server 2016 或 Windows Server 2012 R2。
- 系統使用分散式文件系統複寫 （DFSR），並包含唯讀複寫的資料夾。
- 不論從 DFSR 讀取/寫入到唯讀成員候選項目的複寫篩選為何，您都會預先設置數據。 因此，篩選集中的檔案現在存在於所有成員上。
- 初始複寫之後，您會移除複寫檔案篩選。
- 當 DFSR 成員偵測到篩選變更時，他們都會執行 DirWalkerTask 查閱內容。
- 在唯讀成員上，此程式會建立檔案物件的 UID，並遞增版本向量全域版本序號 （GVSN）。 不過，不會傳播本機變更。
- 讀取/寫入夥伴會為相同的檔案建立自己的UID，而唯讀成員會偵測名稱衝突。
- 根據標準衝突解決，會選取較新的本機版本檔案。 唯讀成員會報告 本機版本主宰 ，並細分讀取/寫入合作夥伴的更新。
- 只讀成員會遞增其 GVSN，並從讀取/寫入夥伴產生 UID 的墓碑。 不過，不會傳播兩個變更。
在此案例中，待辦專案會從唯讀成員回報給讀取/寫入夥伴，因為 DFSR 服務有兩個未復寫到其夥伴的本機變更。 當 DFSR 將檔案引入為新物件時，第一個報表專案適用於本機變更。 當 DFSR 從遺失衝突解決的讀取/寫入夥伴產生檔案版本的墓碑時，就會建立第二個專案。 它會藉由刪除該檔案版本來執行此動作。
注意
當同一個檔案在讀取/寫入成員上變更時，只讀成員會藉由將它回報為「遠端版本主宰」，然後提供自己的 UID 版本，重複使用其資料庫中的墓碑記錄。 此動作會產生衝突事件 4412。 此外，唯讀成員會清除其待辦專案。
原因
這是依照設計的行為。 如果移除篩選，且現有內容必須整合到 DFSR 中，只讀成員會將標準衝突解決機制套用至新的復寫內容。
解決方法
在大部分情況下，您可以放心地忽略在 DFSR 只讀成員中報告的待辦專案，以讀取/寫入夥伴方向。 這是因為唯讀成員不打算有真正的變更。
如果只有少數檔案受到影響，請考慮對讀取/寫入成員上的檔案進行一般變更。
一般而言，只讀成員需要初始同步處理，才能移除這類待辦專案。
其他相關資訊
當您使用 Windows PowerShell 腳本和 Get-DfsrBacklog Cmdlet 來建立多個 DFSR 設定的概觀時，您可能會想要考慮下列邏輯，將待辦項目輸出從只讀成員排除至其合作夥伴：
#variables for checking multiple DFSR setups, may be different in your existing script
$RGName="ReplicationGroupName"
$RFName="ReplicatedFolderName"
$SMem="SendingMember"
$RMem="ReceivingMember"
#new variable for the DFSR subcription for the RF, containing the value/attribute "ReadOnly"; obtained by Get-DfsrMembership
$DfsrSubscription=Get-DfsrMembership -Groupname $RGName -Computername $SMem | Where-object {$_.foldername -eq $RFName}
#now gather only the Backlog output, when the senders configuration for this RF is not Read-only
if ($DfsrSubscription.ReadOnly -eq 0)
{
Get-DfsrBacklog -Groupname $RGName -Foldername $RFName -SourceComputerName $SMem -DestinationComputerName $RMem -verbose
}
else
{
Write-Host "Backlog detection skipped because Sending Member ($SMem) is Read-only for this RF ($RFName)"
}
結果：您現在會看到下列報表專案， 而不是只讀成員的待辦項目輸出：
已略過待處理專案偵測，因為傳送成員 （SendingMember） 是此 RF 的唯讀 （ReplicatedFolderName）
注意
即使在初始待辦專案清除之後，只讀成員可能會在一段時間后再次顯示待處理更新。 如果這些更新是版本向量墓碑（也稱為 VersionVectorTombstones），您可以忽略它們。 這類更新不包含實際變更。 唯讀成員會在下列情況下產生版本向量標記更新：
- 偵測並標記過時的資料庫 GUID 時（GcTask：：GcStaleDbGuids）
- 當它向復寫夥伴發出訊號時，表示它正在運作並等待更新 （GcTask：：GcSendDbKeepAlive）
如需這些函式的詳細資訊，請參閱處理更新中版本向量墓碑的 UID。
這些泛型更新會增加唯讀成員上的版本序號（因此變更 GVSN 版本鏈結向量）。 不過，只讀成員絕不會與其復寫夥伴共用這些更新，因此在其他成員上使用全域版本向量來追蹤更新。 因此，待辦專案計數會顯示只讀成員與其複寫夥伴之間的可見差異。
為了防止這類更新產生令人困惑的數據，收集待辦項目數據的腳本應該排除唯讀成員。