Exchange 2010 SP2 RU3、回復可能なアイテムのバージョン管理に驚きの変更

オリジナル記事の投稿日: 2012 年 6 月 1 日 (金曜日)

この数か月間、Recoverable Items フォルダー (削除済みアイテム収集機能と呼ばれることが多くありましたが、今後そのように呼ぶことはありません) のサイズが肥大するという報告が私たちの元に届いていました。この現象には主に 2 つの状況が関係していると考えられます。

1. 単一アイテムの回復と訴訟ホールドのバージョン管理
2. 予定表バージョンのログ記録

単一アイテムの回復と訴訟ホールド

単一アイテムの回復と訴訟ホールドでは、メールボックス内のデータの保存が有効になります。これがどういう機能かわからない場合は、私の以前の投稿「Single Item Recovery in Exchange 2010 (英語)」を参照してください。

メールボックス内のデータを保存するだけではありません。単一アイテムの回復と訴訟ホールドでは、バージョン管理も有効になります。基本的に、アイテムが変更されると、書き込み時コピー (COW) が実行され、そのアイテムの元のバージョンが保持されます。元のアイテムは Recoverable Items\Versions フォルダーに配置されます。このフォルダーはユーザーには公開されません。

Exchange 2010 で、メールボックス関連のデータにクライアントが接続およびアクセスする方法を変更すると、クライアント アクセス サーバーの Exchange System Objects (XSO) 層で書き込み時コピー操作が実行されます。

書き込み時コピーが実行されるタイミング

• メッセージと投稿 (IPM.Note* と IPM.Post*) については、書き込み時コピーは、件名、本文、添付ファイル、送信者/受信者、および送信/受信日時の変更をキャプチャします。
• それ以外のアイテムについては、アイテムに対するあらゆる変更をキャプチャします (フォルダー間の移動、開封/未開封状態の変更を除く)。
• 下書きは、自動保存されるたびにコピーが増えるため、書き込み時コピーの対象外です。

Recoverable Items フォルダーのサイズが肥大する原因

フォルダーのサイズが肥大するのは、書き込み時コピー操作が原因であると考えられます。Microsoft Outlook を使用する次の状況では、書き込み時コピーが過剰に実行されることがわかっています。

1. 予定を作成します。
2. その予定に Office ドキュメントを添付して保存します。
3. その後、その予定を開いて Office ドキュメントを参照する必要が生じ、ドキュメントを開きます。
4. Outlook は、この予定とドキュメントの自動保存をバックグラウンドで開始します (既定では 3 分おきに自動保存されます)。
5. 自動保存のたびに書き込み時コピーが実行されます。実際には、Office ドキュメントと予定の両方が自動保存されるため、書き込み時コピーは 2 回実行されます。添付ファイルが追加されると、その分、コピーも次々と作成されます。

ゾッとしますが、これは事実です。

添付ファイルはメッセージの一部なので、アイテムの各添付ファイルのコピーを作成することに意味はありません。基本的に、ファイルが添付されたアイテムを保存すると、Outlook では次の操作が実行されます。

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

書き込み時コピーは、SaveAttachment と SaveMessage の両方で発生します。コードを調べた結果、SaveAttachment の呼び出しで添付ファイルの保存後に、関連するメッセージに対して Flush メソッドが呼び出されていることがわかりました (クライアントはこのメソッドをサーバーとの状態の同期に使用します)。書き込み時コピーを実行する命令を出していたのは、この Flush の呼び出しでした。

その後、さらに詳しく調査した結果、書き込み時コピー ロジックが、Flush を呼び出すあらゆる状況で発生していることがわかりました。ついに原因を突き止めました。Flush がさまざまな状況で発生し、その結果、書き込み時コピーが数千回実行されていると考えられます。お客様の環境で発生している現象はこれです。

Exchange 2010 SP2 RU3 以上では、書き込み時コピーは Flush 操作と Save 操作を区別して、Save 操作の発生時にのみ実行されるようになりました。

予定表バージョンのログ記録

予定表バージョンのログ記録は、メールボックス内で発生する予定表の変更を書き込み時コピーによって保存するプロセスです。予定表バージョンのログ記録は Exchange 2010 で導入された機能で、予定表の信頼性に関する問題のトラブルシューティングと修復に役立ちます。

予定表バージョンのログ記録は、予定表アイテムが変更されるたびにログを作成するように設計されています。これらのログは会議の履歴となります。Get-CalendarDiagnosticLog コマンドレットを使用して履歴を確認し、問題を引き起こす原因となったクライアントの操作を探すことができます。予定表バージョンのログ記録のもう 1 つの用途は、予定表修復アシスタントです。これは、特定の予定表アイテムの履歴を調べて不整合を見つけるときにログを使用します。

予定表バージョンのログ記録は、Exchange 2010 のメールボックスで既定で有効になります。この機能の有効/無効は、CalendarVersionStoreDisabled プロパティによって切り替えることができます。ここで 1 つ重要な点があります。プロパティ名は CalendarVersionStoreDisabled です。したがって、既定値 $false は、予定表バージョンのログ記録を既定で有効にするという意味です。予定表アイテムのコピーを格納する処理は、メールボックスの構成に応じて異なります。

1. 単一アイテムの回復または訴訟ホールドがメールボックスで有効になっていない場合、予定表アイテムのストリップ版が Recoverable Items フォルダーのルートに 120 日間保存されます。このストリップ版 (本文と第 1 レベルまたは非埋め込み型メッセージ タイプの添付ファイルを削除したもの) は書き込み時コピーによって作成されます。
2. 単一アイテムの回復または訴訟ホールドがメールボックスで有効になっている場合、予定表アイテムの完全なコピーが Recoverable Items\Deletions または Recoverable Items\Versions フォルダーに保存されます。Recoverable Items\Deletions または Recoverable Items\Versions フォルダー内の予定表アイテムに対して物理的な削除操作が実行されると、常に、書き込み時コピー インフラストラクチャによってストリップ版が作成されます。このストリップ版は Recoverable Items フォルダーのルートに 120 日間保存されます。ただし、Recoverable Items\Deletions または Recoverable Items\Versions フォルダー内のアイテムの保存期間が 134 日 (120 日 + 14 日) を越えると、ストリップ版は作成されません。これは保存期間を変更した場合、メールボックス フォルダー アシスタントが実行されていない場合、訴訟ホールドが無効になっている場合などに発生することがあります。

書き込み時コピー ロジックが Flush 操作と Save 操作を区別しない場合に発生する前述の問題に起因して、予定表バージョンのログ記録で、Recoverable Items フォルダーのクォータが大量に消費されることがあります (警告のしきい値は 20 GB、ハード クォータは 30 GB です)。

書き込み時コピーの問題には SP2 RU3 で対処していますが、予定表バージョンのログ記録によって Recoverable Items フォルダーのクォータがすべて消費される可能性があるという問題については、SP2 RU2 でアーキテクチャを変更するという形で対処しています。その結果、予定表バージョンのログ記録は、現在、書き込み時コピーを開始する前に Recoverable Items フォルダーのサイズを考慮するようになっています。

フォルダーのサイズが RecoverableItemsWarningQuota を越えると、メールボックスに対する予定表バージョンのログ記録は無効になります。RecoverableItemsWarningQuota の適切な値はメールボックスの設定によって異なります。

1. メールボックスの UseDatabaseQuotaDefaults が $true に設定されている場合は、メールボックス データベースの RecoverableItemsWarningQuotaが使用されます。
2. メールボックスの UseDatabaseQuotaDefaults が $false に設定されている場合は、メールボックスの RecoverableItemsWarningQuota が使用されます。

予定表バージョンのログ記録が無効になると、クライアント アクセス サーバーのアプリケーション イベント ログに次のイベントが生成されます。

イベント ID: 5003
ソース: MSExchange 中間層ストレージ
タスク カテゴリ: CopyOnWrite
レベル: 情報
説明: ユーザーのメールボックス <legacyExchangeDN> が削除済みアイテム収集機能の警告のしきい値を越えました。メールボックスに対する予定表のログ管理は無効になりました。

以上で、すべての説明が終わりというわけではありません。この展開の初期ステージについて詳しい説明は行いませんが、予定表バージョンのログ記録をさらに改良して、この機能が展開に与える悪影響を最小限に抑えることができるように鋭意努力中です。さらに多くの情報を共有できるようになれば、このブログで紹介します。

Ross Smith IV
主席プログラム マネージャー
Exchange カスタマー エクスペリエンス

これはローカライズされたブログ投稿です。原文の記事は、Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3 をご覧ください。