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

BitTitan MigrationWiz는 마이그레이션 중 EWS 또는 IMAP을 사용하여 Microsoft 365 테넌트에 메시지를 업로드합니다. 각 업로드 시 Microsoft 365의 메일 인프라는 원래 날짜가 아닌 마이그레이션 타임스탬프가 포함된 새로운 Received 헤더를 메시지에 추가합니다. 이 헤더는 헤더 체인의 맨 위에 위치하며 전체 M365 생태계의 기준 날짜가 됩니다.

Microsoft 365는 이것을 메시지의 INTERNALDATE(Exchange 용어로 PR_MESSAGE_DELIVERY_TIME 속성)로 저장합니다. M365 사서함에 연결된 모든 클라이언트가 이 값을 읽습니다. Outlook 데스크톱, 웹용 Outlook, Outlook 모바일, 서드파티 IMAP 클라이언트 모두 마이그레이션 날짜를 표시합니다. 8년치 이메일 기록이 있는 사서함이 갑자기 모든 것이 3월의 어느 화요일에 도착한 것처럼 보입니다.

거듭 말하지만, 이것은 드문 예외 사례가 아닙니다. 원본 플랫폼에 관계없이 M365로의 모든 BitTitan 마이그레이션에서 발생합니다. 온프레미스 Exchange, Google Workspace, Zimbra, GroupWise 어디에서든 대상 서버의 동작은 동일합니다. Microsoft 365가 업로드 날짜를 적용하고, 그 날짜가 최종 기준이 됩니다.

결과적으로 IT 팀은 마이그레이션 다음 날 아침 티켓에 파묻힙니다. 사용자는 날짜별로 이메일을 찾을 수 없습니다. 시간순 이메일 기록을 참고하던 임원진은 하룻밤 사이에 수개월 또는 수년간의 맥락을 잃게 됩니다.

모든 M365 애플리케이션이 손상된 날짜를 읽습니다. 웹용 Outlook, Outlook 데스크톱, Mac용 Outlook, Outlook 모바일 모두 잘못된 수신 날짜를 표시합니다. 이메일 타임라인을 참조하는 Microsoft Copilot 및 AI 기능도 동일한 손상된 메타데이터에 의존하기 때문에 부정확한 결과를 생성합니다.

규정 준수 측면에서 진정한 문제가 발생합니다. 소송 보류, 보존 정책, 보안 및 규정 준수 센터의 eDiscovery 검색 모두 날짜를 기준으로 필터링합니다. 모든 이메일이 마이그레이션 타임스탬프를 가지고 있으면 날짜 기반 쿼리는 무용지물입니다. 법적 사안을 위해 2023년 3분기의 모든 이메일을 요청받은 관리자는 아무것도 돌려받지 못하거나 전체 사서함을 돌려받게 됩니다. 이것은 사소한 불편이 아니라 규정 준수 실패입니다.

Redate.io는 메시지별 검증이 포함된 안전한 저수준 메시지 처리를 통해 이 문제를 해결합니다. 각 이메일은 개별적으로 처리되며, 서버 수준에서 원래 날짜가 복원되어 연결된 모든 클라이언트와 규정 준수 도구에 자동으로 수정 사항이 전파됩니다. 재마이그레이션 불필요, 수동 개입 불필요, 데이터 손실 없음.