Microsoft 365でのCloudM移行による日付破損の修正

CloudM Migrateは、Google Workspace、オンプレミスExchange、その他のプラットフォームからMicrosoft 365へメールボックスを移行する際に、頻繁に選択されるツールです。移行自体は通常スムーズに完了します。その後、誰かがOutlookを開いて異変に気づきます。数千通のすべてのメールが同じ受信日を表示しているのです。

何が起きたのでしょうか。アップロード時に、Exchange Onlineのトランスポートパイプラインは、移行された各メッセージを新着メールとして扱います。現在の処理タイムスタンプを持つ新しいReceivedヘッダーを付与し、それに応じてPR_MESSAGE_DELIVERY_TIMEプロパティを設定します。このプロパティは、Outlookデスクトップ、Outlook on the Web、Outlookモバイル、さらにはMicrosoft Copilotの機能がすべて日付表示の際に参照するものです。Google Workspace(WebクライアントがDate Headerを使って問題を隠せる)とは異なり、Microsoft 365はどこでも一貫して間違った日付を表示します。

実は、この一貫性こそがM365版のこの問題を非常に目立たせている理由です。「ブラウザでは問題ない」という逃げ道がありません。すべてのユーザーが、すべてのデバイスで、すべてのMicrosoft 365アプリケーションで移行日を目にします。IT部門は通常、CloudM移行完了から数時間以内に問題を発見しますが、その時点ではすでにサーバーレベルのメッセージメタデータに被害が刻み込まれています。

影響はM365エコシステム全体に波及します。Outlookデスクトップ、OWA、Outlookモバイル、Teamsのメール連携、Microsoft Search、すべてが移行タイムスタンプを表示します。ユーザーはアプリケーションを切り替えても不正確な日付から逃れることができません。たとえば、訴訟準備のために「2023年1月から3月に受信したメール」を検索する弁護士を想像してください。検索結果は空か、すべてが返ってくるかのどちらかです(移行がいつ行われたかによります)。これは軽微な不便ではなく、証拠開示の失敗になりかねません。

Microsoft Purview(旧コンプライアンスセンター)とeDiscovery Premiumは、破損した配信日でメッセージをインデックス化します。日付範囲に基づくコンテンツ検索は信頼できない結果を生成します。メッセージの経過日数に基づいて自動適用される保持ラベルは、間違った時系列で動作するため、一部のメッセージが早期に削除される一方、他のメッセージが無期限に保持されます。Outlookの自動アーカイブポリシーも、全体的にメッセージの経過日数を誤って計算します。規制対象のメール保持要件がある組織にとって、日付が修正されるまで続くコンプライアンスギャップが生じます。