Outlook에서 BitTitan MigrationWiz 마이그레이션 날짜 수정

BitTitan MigrationWiz는 원본 서버에서 각 이메일을 다운로드하여 대상 서버로 업로드합니다. 표준 마이그레이션 절차입니다. 하지만 업로드 과정에서 대상 메일 서버는 모든 메시지에 새로운 Received 헤더를 추가합니다. 이 헤더에는 원래 배달 날짜가 아닌 마이그레이션 타임스탬프가 기록됩니다.

Outlook이 왜 이것에 영향을 받을까요? Outlook은 각 이메일 헤더 체인에서 최상위 Received 헤더를 읽어 "받은 날짜" 열의 날짜를 결정하기 때문입니다. MigrationWiz의 헤더가 바로 맨 위에 위치합니다. 그래서 Outlook은 사서함의 모든 메시지에 대해 마이그레이션 날짜를 표시합니다. 받은 편지함, 보낸 편지함, 보관 폴더 모두 동일한 날짜가 찍힙니다.

완전히 깨진 상태입니다.

예를 들어 보겠습니다. 고객 커뮤니케이션 추적을 위해 시간순 이메일 기록에 의존하는 영업 이사의 4,237통의 이메일을 마이그레이션했습니다. 월요일에 Outlook을 열어보니 지난 6년간의 모든 이메일이 토요일 날짜를 표시합니다. 날짜별 정렬을 해도 하나의 거대한 블록만 보입니다. 지난 10월 이메일을 검색하면 아무것도 나오지 않습니다. (사실은 모든 것이 마이그레이션 날짜로 나옵니다.) 수신 날짜 기반으로 작동하는 Outlook 규칙은 오작동하거나 완전히 실패합니다.

MigrationWiz가 수백 개 사서함을 동시에 이전하는 기업 환경에서 이것은 한 사람의 문제가 아닙니다. 마이그레이션 후 첫 번째 영업일에 조직 전체의 위기가 됩니다. 달력과 연결된 이메일 스레드는 시간적 맥락을 잃고, 모든 메시지가 동일한 수신 타임스탬프를 공유하면 대화 보기도 신뢰할 수 없게 됩니다.

Outlook 데스크톱과 Windows용 Outlook 모두 IMAP INTERNALDATE와 최상위 Received 헤더에서 "받은 날짜" 열을 채웁니다. BitTitan 마이그레이션 후 날짜별 정렬을 하면 전체 사서함이 하루로 묶입니다. 3개월 전 이메일을 찾으려면 동일한 날짜를 가진 수천 통의 메시지를 스크롤해야 합니다.

검색도 깨집니다. 날짜 범위 필터가 인덱싱된 날짜를 기준으로 하기 때문에 잘못된 결과를 반환합니다. 인덱싱된 날짜는 원래 배달 날짜가 아닌 마이그레이션 날짜입니다. 그리고 대부분의 관리자가 놀라는 세부 사항이 있습니다. Outlook의 캐시 모드(로컬 .ost 파일)는 손상된 날짜를 저장하므로 오프라인 모드로 전환해도 도움이 되지 않습니다.

Redate.io는 마이그레이션 도구 시그니처 패턴 매칭을 통해 BitTitan이 주입한 메타데이터를 식별하고 서버 수준에서 수정하는 독자적인 보정 엔진을 사용합니다. 각 메시지는 메시지 내용, 첨부 파일 또는 폴더 구조를 변경하지 않고 정밀 메타데이터 보정을 거칩니다. 처리가 완료되면 원래 날짜가 Outlook 데스크톱, OWA, Outlook 모바일 및 기타 모든 연결된 클라이언트에 자동으로 표시됩니다.