哇 COW！Exchange 2010 SP2 RU3 中 Recoverable Items 版本設定的變更

英文原文已於 2012 年 6 月 1 日星期五發佈

過去幾個月來，我們收到關於可復原的項目資料夾 (俗稱「垃圾桶」，雖然我們已正名了) 容量暴增的回報。造成檔案大小暴增的原因主要有兩個：

1. 「單項復原」和訴訟暫止的版本設定
2. 行事曆版本記錄

單項復原和訴訟暫止

「單項復原」和「訴訟暫止」可讓資料保存在信箱內部。若您不熟悉這些功能，我之前有篇文章 Exchange 2010 中的單項復原 (可能為英文網頁) 內有詳細說明，歡迎參考。

除了將資料保存在信箱內部外，「單項復原」和「訴訟暫止」也啟用了版本設定。實質上就是說，當有項目變更時，系統就會執行一次「寫入時複製」(copy-on-write，簡稱 COW) 以保存該物件的原始版本。原始項目會置於 Recoverable Items\Versions 資料夾中。此資料夾使用者是看不到的。

由於 Exchange 2010 在用戶端連線與存取信箱相關資料的方式上有一點改變，此 COW 活動會出現在用戶端存取伺服器上的 Exchange 系統物件 (XSO) 層。

什麼情況下會觸發 COW？

• 對於訊息與貼文 (IPM.Note* 和 IPM.Post*)，COW 會捕捉主題、本文、附加檔案、寄件人/收件人以及寄送/收到日期的變更。
• 對於其他類型的項目，COW 會捕捉一切對該項目所做的變更，但資料夾之間的移動以及讀取/未讀取狀態的變更除外。
• 草稿自動儲存時會被 COW 排除在外，以避免產生過多的複本。

Recoverable Items 資料夾容量暴增的可能原因為何？

COW 的行為可能就是罪魁禍首。我們的調查結果發現，在下列使用 Microsoft Outlook 的案例中，會造成過度 COW 的主因：

1. 您在行事曆中建立了一筆約會。
2. 您附加了一份 Office 文件到該約會並加以儲存
3. 稍後，您想要打開這筆約會，以對照那份 Office 文件內寫的某些內容。於是您開啟了文件。
4. Outlook 會在幕後開始自動儲存這份開啟的約會，以及相對應的開啟文件 (Outlook 預設每隔 3 分鐘就會自動儲存一次)。
5. 每筆自動儲存事件只會觸發一次 COW。但由於此自動儲存需同時儲存 Office 文件和約會兩者，因而就產生兩筆 COW 事件了。若還有更多的附加檔案，則每個後續的檔案都會再額外產生一個隨之而來的 COW 版本。

這下可好了。

既然附加檔案算是訊息的一部分，為每個項目的每個附加檔案分別建立複本實在沒什麼道理。當您儲存一封有附加檔案的項目時，Outlook 實際上是執行了下列動作：

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

COW 則是發生在 SaveAttachment 和 SaveMessage 的階段。深入研究程式碼後，我們發現呼叫 SaveAttachment 儲存附加檔案後，最終將會在與它相關的信件上呼叫 Flush 方法 (用戶端與伺服器狀態同步的一種方法)。而不斷通報 COW 程式碼發生作用的，就是這個 Flush 方法。

經過進一步的分析，我們發現只要有「任何」Flush 呼叫，都會觸發 COW 的運作邏輯。這真是個重大的發現，因為在許多種情況下，都可能會啟動到 Flush，進而導致出現上千筆 COW 活動，也就是過去幾位客戶在他們的環境下遭遇的情況。

隨著 Exchange 2010 SP2 RU3 和更新版本的推出，COW 現在已能分辨 Flush 和 Save 作業的差異，也只有在發生 Save 作業時才會觸發了。

行事曆版本記錄

「行事曆版本記錄」是當發生在信箱內部的行事曆變更要透過 COW 儲存時，所進行的程序。「行事曆版本記錄」是 Exchange 2010 推出的新功能，目的是為了協助診斷和修復行事曆的可靠性問題。

行事曆版本記錄的設計，會在每次有行事曆項目被更動時，自動建立一份記錄。這些記錄全部組合在一起，就構成了完整的會議歷史。您可以使用 Get-CalendarDiagnosticLog Cmdlet 查閱此歷史記錄，並依此判定哪些客戶曾採取了破壞性的舉動。「行事曆版本記錄」的第二項用途，是它可以讓行事曆修復小幫手在偵測某行事曆項目不一致的情形時，拿來當做判定的依據。

在 Exchange 2010 的信箱上預設啟用「行事曆版本記錄」。您也可以從 CalendarVersionStoreDisabled 屬性停用或加以啟用。請注意，它的屬性名稱是 CalendarVersionStoreDisabled，所以如果將預設值設成 $false 代表「行事曆版本記錄」預設為啟用。依信箱設定之不同，隨後儲存行事曆項目複本的程序可能會有所不同：

1. 如果信箱未啟用「單項復原」或「訴訟暫止」，縮減版的行事曆項目會保存在 Recoverable Items 資料夾的根目錄下 120 天。此縮減版 (已移除本文和重要性非第一級或非內嵌訊息類型的附加檔案) 是由 COW 所建立。
2. 如果信箱已啟用「單項復原」或「訴訟暫止」，Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中則會保存完整版的行事曆項目。每當有 Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中的行事曆項目受到實際刪除的動作時，就會經由 COW 的基礎架構建立一個縮減的版本。此縮減版會置於 Recoverable Items 資料夾的根目錄中 120 天。不會建立縮減版的唯一情況，是當 Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中某項目的保存時間已超過 134 天 (120 + 14) 時。如果您變更了保留時限，如果很久未執行「信箱資料夾助理」，或如果「訴訟暫止」已停用等，就有可能會發生此情況。

由於上述有關 COW 運作邏輯未分辨 Flush 和 Save 作業的問題，「行事曆版本記錄」在某些情況下，有可能佔用掉 Recoverable Items 資料夾容量配額的一大塊空間 (如果您還記得的話，警告臨界值是 20GB，固定配額是 30GB)。

雖然 SP2 RU3 已解決 COW 的問題，但為了化解「行事曆版本記錄」可能佔用掉 Recoverable Items 資料夾全部配額的疑慮，在 SP2 RU2 中我們引進了一項架構上的變更，藉此「行事曆版本記錄」如今在啟動 COW 之前，會先將 Recoverable Items 資料夾的大小列入考量。

如果該資料夾大小超過 RecoverableItemsWarningQuota，信箱就會停用「行事曆版本記錄」。其所參考的 RecoverableItemsWarningQuota 值會依信箱設定而異：

1. 如信箱的 UseDatabaseQuotaDefaults 設為 $true，就會參考該信箱資料庫的 RecoverableItemsWarningQuota。
2. 若信箱的 UseDatabaseQuotaDefaults 設為 $false，則會參考該信箱的 RecoverableItemsWarningQuota。

當「行事曆版本記錄」停用時，用戶端存取伺服器上的應用程式事件記錄中就會產生下列事件：

Event ID: 5003
Source: MSExchange Mid-Tier Storage
Task Category: CopyOnWrite
Level: Information
Description: User mailbox <legacyExchangeDN> has exceeded the dumpster warning quota. Calendar logging has been disabled for the mailbox.

我們想做的事還不只如此。此開發目前尚屬早期階段，我不打算討論詳情，但我可以說我們正在努力進一步改善「行事曆版本記錄」，以使本功能對您部署的負面影響降到最低。待時機成熟，我便會透過本部落格向大家報告更多消息。

Ross Smith IV
首席專案經理
Exchange 客戶經驗部

這是翻譯後的部落格文章。英文原文請參閱 Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3