公用資料夾複寫疑難排解 – 第 3 部分：疑難排解複本刪除及常見問題
英文原文已於 2011 年 11 月 28 日星期一發佈
英文原文張貼於美國部落格：2006 年 1 月 20 日
這是有關疑難排解公用資料夾複寫問題的第三篇部落格文章。在第一篇文章中，我們討論到疑難排解新變更的複寫。第二篇部落格文章 (可能為英文網頁)討論疑難排解現有資料的複寫。本系列中的這一篇文章將會討論疑難排解複本刪除及常見問題。若希望能有全面性的了解，請閱讀所有參考資料！
疑難排解複本刪除
您已將舊的伺服器從所有資料夾的複本清單中移除。不過，當您前往公用資料夾執行個體查看 ESM 中的舊儲存區時，還是看到那裡有一大堆資料夾。這是因為複本刪除程序有問題。在 Exchange 2003 SP2 版的 ESM 中，如果您嘗試刪除此狀態的公用儲存區，ESM 會顯示對話方塊表示：
「您無法刪除此公用資料夾儲存區，因為它含有資料夾複本。為避免資料遺失，請於公用資料夾儲存區上按一下滑鼠右鍵，並使用 [移動複本] 將複本移至其他伺服器。可能需要好幾個小時，才能將內容複寫至新的伺服器並移除本機複本。」
當您將儲存區從資料夾上的複本清單中移除時，該儲存區不會立刻刪除該資料，而是會送出特殊的 0x20 狀態要求給所有其他複本。這就叫做「複本刪除擱置狀態要求」(RDPSR)，在應用程式記錄檔中，無法與一般狀態要求分別。RDPSR 包含旗標，指出該複本正處於擱置刪除。當其他儲存區收到此 0x20 時，就會以名為「複本刪除擱置確認」(RDPA) 的特殊 0x10 來回應。RDPA 指出刪除該資料是可以的，但是如果其他儲存區已經有擱置刪除複本擁有的所有 CN，則只會傳送此 0x10。唯有當儲存區收到 0x10，指出有別人擁有該資料時，才會刪除該複本。
這表示如果您在公用資料夾執行個體清空之前刪除儲存區，可能會遺失資料。只有 2003 SP2 ESM 可以避免您這麼做，在舊版中，您必須手動檢查公用資料夾執行個體，看看刪除儲存區是否妥當。在您刪除公用儲存區之前，請務必要檢查公用資料夾執行個體，而當 2003 SP2 ESM 提出這個警告時，不應嘗試忽略它或加以解除，而是應該疑難排解複本刪除程序。
請注意，在 Exchange 2003 SP2 之前，從複本清單移除的伺服器只會傳送一次 RDPSR。如果沒有人回應，您就會看到資料夾無限期處於公用資料夾執行個體中，除非您將儲存區加回複本清單然後再次將其移除使其傳送新的 RDPSR。2003 SP2 變更了此行為，以致於儲存區每小時都會重試，直到收到某人的 RDPA 為止。
疑難排解
這和疑難排解回填程序幾乎一樣。
1. 擱置刪除複本有傳送 0x20 嗎？
除非當您移除複本時已經開啟記錄功能，否則您不會知道。幸好您可以直接加回複本，再度將其移除。然後在應用程式記錄檔中查看是否有 0x20。
2. 0x20 是否送達其他複本？
您現在應該了解應有的步驟。請檢查其他複本的應用程式記錄檔，看看它們是否收到 0x20。
3. 是否有任何其他複本以 0x10 回應？
這是您可能最後會專注的部分。如果複本收到了擱置刪除複本的 0x20，但沒有以 0x10 回應，則表示擱置刪除複本有其他複本所沒有的資料。由於您知道它剛從該複本收到 0x20，所以您也知道它已知道遺失了什麼資料。因此，您可預期每 24-48 小時就會看到該資料夾的回填要求。請查看應用程式記錄檔，並完全依照先前說明的一般回填程序，進行疑難排解。
4. 擱置刪除複本是否收到 0x10？
一旦任何其他複本有了所有資料之後，該複本就應該以 0x10 回應。當擱置刪除複本收到該 0x10 時，最後就會願意刪除該資料。但那並不表示這會立即發生。如果有用戶端在使用該複本，則在後來的線上維護之前，都不會將它刪除。如果您要加速此作業，可以卸載後再裝載儲存區，以中斷連接用戶端。
常見問題
您可能會發現伺服器傳送某種類型的複寫郵件至另一部伺服器，但是接收的伺服器從未將內送郵件記錄在應用程式記錄檔中。但是，郵件追蹤卻表示已在本機將其傳遞至該伺服器上的儲存區。此行為通常表示，可能是 複寫 狀態 表格有問題，或是 SMTP 虛擬伺服器上的權限問題。
我們先來討論比較簡單的部分。導致內送複寫郵件遭接收伺服器忽略的問題，是 複寫 狀態 (或 ReplState) 表格的問題。請注意，ReplState 表格的問題可能也會導致伺服器無法為某些資料夾發出回填要求 (0x8)，所以此資訊也適用於該情況。每個公用儲存區都會使用其 ReplState 表格，追蹤任何複寫資料夾的複寫狀態。該表格包含每個資料夾的好幾列，每個複本各一列。ReplState 表格中的列有可能與複本清單不同步，以致於有額外的列或遺失的列。有時候您可以做一些變更讓它再次同步，例如將伺服器從複本清單中移除、套用變更，然後立即將它加回去，但這不一定有效。幸好 ReplState 測試已新增至 isinteg。請參閱 KB889331 (適用於 Exchange 2003) 或 KB892485 (適用於 Exchange 2000)。只要您有更新的 isinteg.exe 及 store.exe，就可以使用 isinteg 更正 ReplState 表格的問題。如果您只執行 ReplState 測試，通常會非常快速，在大型公用儲存區上甚至不到一分鐘。執行了 isinteg 之後，可能仍然需要回去變更資料夾，讓 ReplState 表格與複本清單同步。兩者同步之後，伺服器應該就能夠處理內送複寫郵件，或是應該開始正常發出回填要求。
另一個會讓內送複寫郵件被忽略的常見問題，是 Exchange 2003 特定的問題。Exchange 2003 伺服器要求傳送伺服器要有接收 SMTP 虛擬伺服器的「傳送為」權限。也就是說，如果 ServerA 是 Exchange 2003，而 ServerB 將 PF 複寫郵件傳送至 ServerA，則 ServerB 必須要有 ServerA 的 SMTP 虛擬伺服器的「傳送為」權限。否則，ServerA 不會處理內送複寫郵件。此權限通常是透過 Exchange 網域伺服器群組授與。如果「傳送為」權限是問題所在，則來自特定伺服器的所有內送複寫郵件都會失敗。我發現要識別此問題，最簡單的方法就是在複寫郵件從一部伺服器傳送到另一部伺服器時，記錄網路追蹤。對話應該像下面這樣：
ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service...
ServerB: EHLO ServerB.microsoft.com
ServerA: 250-ServerA.microsoft.com Hello
250-TURN
250-SIZE
250-ETRN
250-PIPELINE
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-X-EXCH50
250 OK
此處的重點是 ServerA 必須通知 GSSAPI NTLM LOGIN 選項。如果您在 ServerA 對 EHLO 的回應中沒有看到這些選項，通常是因為 SMTP 虛擬伺服器上的 [整合式 Windows 驗證] 已取消選取。在 KB843106 的步驟 1 和 KB842273 的步驟 3 有提到這一點。只要這些驗證動詞出現，應該就會看到 ServerB 嘗試使用：
ServerB: X-EXPS GSSAPI
ServerA: 334 GSSAPI supported
ServerB: <一堆 base64 編碼資料>
ServerA: 334 <更多 base64 編碼內容>
ServerB: CRLF
ServerA: 235 2.7.0 Authentication successful.
如果驗證不成功，可能是有 Kerberos 問題，或是 ServerB 的電腦帳戶有問題。接下來，伺服器將會傳輸連結狀態資訊。之後，伺服器終究會抽出時間進行傳送電子郵件的業務：
ServerB: MAIL FROM:<ServerB-IS@microsoft.com>
ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Sender OK
ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER
ServerA: 250 2.1.5 ServerA-IS@microsoft.com
ServerB: XEXCH50 2404 2
ServerA: 354 Send binary data
這個對 XEXCH50 動詞的最後回應非常重要。如果回應是 "354 Send binary data" (354 傳送二進位資料)，則一切正常，至少就 SMTP 虛擬伺服器的權限而言沒問題。如果沒有通知 GSSAPI NTLM Login 選項，或是嘗試驗證失敗，就可預期 ServerA 會改為以 "504 Need to authenticate" (504 需要驗證) 回應。如果那些步驟成功，但 ServerA 仍表示 "504 Need to authenticate"，而不是 "354 Send binary data"，則 ServerB 沒有 ServerA 的 SMTP 虛擬伺服器之「傳送為」權限。發生這種情況的方式有好幾種。其中一種就是，當您在 ESM 中委派「Exchange 系統高權限管理員」之類的權限，該使用者或群組會繼承「傳送為」權限的拒絕。因此，使用 ESM 委派管理權限給電腦帳戶、Exchange 網域伺服器群組，或是含有 Exchange 伺服器的某些其他群組，將會中斷公用資料夾複寫。另一種可能是電腦帳戶不在 Exchange 網域伺服器群組中，這是它通常擁有「傳送為」權限的方式。您需要評估 SMTP 虛擬伺服器的權限，判斷為什麼傳送伺服器的電腦帳戶沒有適當的權限。如需 "504 Need to authenticate" 問題的詳細資訊，請參閱 KB843106 及 KB842273。
結論
您在閱讀本文件時，可能有注意到 Exchange 2003 的 SP2 包含數項隱藏的重要增強功能，可防止複寫問題，並有助於疑難排解這些問題。具有多個公用儲存區的環境可以真正看到 SP2 的重大好處，尤其是要在伺服器之間移動複本，以及新增和移除公用儲存區時。
希望這對您有幫助。感謝 Dave Whitney 檢查這所有內容！
這是翻譯後的部落格文章。英文原文請參閱 Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems