Microsoft 365에서 CloudM Migrate 마이그레이션 날짜 수정

CloudM Migrate는 Google Workspace, 온프레미스 Exchange 또는 기타 플랫폼에서 Microsoft 365로 사서함을 이전할 때 즐겨 사용되는 도구입니다. 마이그레이션 자체는 대개 순조롭게 진행됩니다. 그런데 누군가 Outlook을 열고 놀라운 사실을 발견합니다. 수천 통의 이메일 모두가 동일한 수신 날짜를 표시합니다.

무슨 일이 일어난 걸까요? 업로드 중에 Exchange Online의 전송 파이프라인은 마이그레이션된 각 메시지를 새로운 배달로 처리합니다. 현재 처리 타임스탬프가 포함된 새 Received 헤더를 추가하고 PR_MESSAGE_DELIVERY_TIME 속성을 그에 맞게 설정합니다. 이 속성이 바로 Outlook 데스크톱, 웹용 Outlook, Outlook 모바일, 심지어 Microsoft의 Copilot 기능이 날짜를 표시할 때 참조하는 값입니다. 웹 클라이언트가 문제를 감출 수 있는 Google Workspace와 달리, Microsoft 365는 모든 곳에서 일관되게 잘못된 날짜를 표시합니다.

사실 이 일관성 때문에 M365 버전의 이 문제가 더 눈에 띕니다. "브라우저에서는 정상이에요"라는 도피구가 없습니다. 모든 사용자가, 모든 기기에서, 모든 Microsoft 365 애플리케이션에서 마이그레이션 날짜를 봅니다. IT 팀은 대개 CloudM 마이그레이션 완료 후 몇 시간 이내에 문제를 발견하지만, 그때는 이미 서버 수준의 메시지 메타데이터에 손상이 내재된 상태입니다.

영향은 전체 M365 생태계로 확산됩니다. Outlook 데스크톱, OWA, Outlook 모바일, Teams 이메일 통합, Microsoft Search 모두 마이그레이션 타임스탬프를 표시합니다. 사용자가 애플리케이션을 전환해도 잘못된 날짜를 피할 수 없습니다. 예를 들어 변호사가 소송 준비를 위해 "2023년 1월에서 3월 사이에 수신된 이메일"을 검색한다고 상상해 보세요. 검색은 마이그레이션 시점에 따라 아무것도 반환하지 않거나 모든 것을 반환합니다. 이것은 사소한 불편이 아니라 잠재적인 증거 수집 실패입니다.

Microsoft Purview(이전 규정 준수 센터)와 eDiscovery Premium은 손상된 배달 날짜로 메시지를 인덱싱합니다. 날짜 범위 기반 콘텐츠 검색이 신뢰할 수 없는 결과를 생성합니다. 메시지 수명을 기반으로 자동 적용되는 보존 레이블이 잘못된 타임라인에서 작동하여 일부 메시지는 너무 일찍 삭제되고 다른 메시지는 무기한 보존됩니다. Outlook의 자동 보관 정책도 전반적으로 메시지 수명을 잘못 계산합니다. 규제 이메일 보존 요구 사항의 적용을 받는 모든 조직에게 이것은 날짜가 수정될 때까지 지속되는 규정 준수 격차를 만듭니다.