OutlookでのBitTitan移行による日付破損の修正

BitTitan MigrationWizは、移行元サーバーから各メールをダウンロードし、移行先にアップロードする標準的な移行手順を実行します。しかし、このアップロード時に、移行先のメールサーバーがすべてのメッセージに新しいReceivedヘッダーを付与します。このヘッダーには、元の配信日ではなく移行のタイムスタンプが記録されます。

なぜOutlookがこの影響を受けるのでしょうか。Outlookは「受信日時」列に表示する日付を、各メールのヘッダーチェーン内の最上部にあるReceivedヘッダーから読み取ります。MigrationWizのヘッダーがまさにその最上部に位置するため、Outlookはメールボックス内のすべてのメッセージに移行日を表示します。受信トレイ、送信済みアイテム、アーカイブフォルダ、すべてが同じ日付です。

これは完全に壊れた状態です。

たとえば、クライアントとのやり取りを時系列で管理している営業部長の4,237通のメールを移行したとします。月曜にOutlookを開くと、過去6年分のすべてのメールが土曜日の日付を示しています。日付でソート? 巨大な1つのブロックです。去年の10月のメールを検索? 何もヒットしません(実際にはすべてがヒットしますが、移行日の日付で)。受信日に基づくOutlookルールは誤動作するか、完全に機能しなくなります。

MigrationWizが数百のメールボックスを同時に移行する企業環境では、これは一人の問題ではありません。移行後最初の営業日に組織全体の危機となります。カレンダーに関連するメールスレッドは時間的なコンテキストを失い、すべてのメッセージが同一の受信タイムスタンプを共有すると、スレッドビューも信頼できなくなります。

OutlookデスクトップとOutlook for Windowsは、どちらもIMAP INTERNALDATEと最上部のReceivedヘッダーから「受信日時」列を表示します。BitTitan移行後、日付でソートするとメールボックス全体が1日にまとまります。3か月前のメールを見つけるには、同じ日付の数千件のメッセージをスクロールする必要があります。

検索も壊れます。日付範囲フィルタは、インデックスされた日付が元の配信ではなく移行を反映しているため、不正確な結果を返します。そして、多くの管理者が驚く点があります。Outlookのキャッシュモード(ローカルの.ostファイル)にも破損した日付が保存されるため、オフラインモードに切り替えても解決しません。

Redate.ioは、移行ツールのシグネチャに対するパターンマッチングを備えた独自の補正エンジンを使用し、BitTitanが挿入したメタデータをサーバーレベルで特定・修正します。各メッセージは、メッセージ本文、添付ファイル、フォルダ構造を変更することなく、日付メタデータのみが対象となります。処理完了後、元の日付がOutlookデスクトップ、OWA、Outlookモバイル、およびその他の接続クライアントに自動的に表示されます。