Oprava dat migrace CloudM v Microsoft 365
Proč migrace CloudM poškozuje data v Microsoft 365
CloudM Migrate je oblíbený nástroj pro organizace přesouvající schránky z Google Workspace, on-premises Exchange nebo jiných platforem do Microsoft 365. Samotná migrace obvykle proběhne hladce. Pak někdo otevře Outlook a všimne si něčeho alarmujícího: každý jednotlivý e-mail - tisíce jich - zobrazuje stejné datum přijetí.
Co se stalo? Během nahrávání transportní pipeline Exchange Online zachází s každou migrovanou zprávou jako s novým doručením. Orazítkuje ji novou hlavičkou Received s aktuálním časovým razítkem zpracování a nastaví odpovídajícím způsobem vlastnost PR_MESSAGE_DELIVERY_TIME. Tuto vlastnost čte Outlook desktop, Outlook na webu, Outlook mobilní i funkce Microsoft Copilot při zobrazování dat. Na rozdíl od Google Workspace (kde webový klient může problém maskovat) Microsoft 365 zobrazuje špatné datum konzistentně všude.
Právě tato konzistence činí M365 verzi tohoto problému tak viditelnou. Neexistuje žádný únikový ventil typu "v prohlížeči to funguje". Každý uživatel, na každém zařízení, v každé aplikaci Microsoft 365 vidí datum migrace. IT týmy typicky objeví problém během hodin od dokončení migrace CloudM, ale v tu chvíli je poškození již uloženo v metadatech zpráv na úrovni serveru.
Jak špatná data narušují prostředí Microsoft 365
Dopad se šíří celým ekosystémem M365. Outlook desktop, OWA, Outlook mobilní, integrace e-mailu v Teams, Microsoft Search - vše zobrazuje časové razítko migrace. Uživatelé nemohou uniknout nesprávným datům přepnutím aplikace. Představte si advokáta, který hledá "e-maily přijaté mezi lednem a březnem 2023" v rámci přípravy na soudní spor. Vyhledávání nevrátí nic, nebo vrátí úplně všechno, podle toho, kdy migrace proběhla. To není drobná nepříjemnost - je to potenciální selhání při zjišťování důkazů.
Microsoft Purview (dříve Centrum dodržování předpisů) a eDiscovery Premium indexují zprávy podle poškozeného data doručení. Vyhledávání obsahu založená na datových rozsazích produkují nespolehlivé výsledky. Štítky uchovávání aplikované automaticky na základě stáří zprávy pracují se špatnou časovou osou, což znamená, že některé zprávy jsou smazány příliš brzy, zatímco jiné jsou uchovávány na neurčito. Zásady automatické archivace v Outlooku špatně vypočítávají stáří zpráv plošně. Pro jakoukoli organizaci podléhající regulačním požadavkům na uchovávání e-mailů to vytváří mezeru v dodržování předpisů, která přetrvává, dokud nejsou data opravena.
Často kladené otázky
Nabízí CloudM nějakou možnost, jak zabránit poškození dat během migrace do M365?
CloudM zachovává původní hlavičku Date v těle zprávy, ale transportní pipeline Exchange Online přidá vlastní hlavičku Received během zpracování zprávy. Toto chování na straně serveru nemůže žádný migrační nástroj obejít. Jedinou cestou ke správným datům je korekce po migraci.
Mohou administrátorské nástroje Microsoft 365 data opravit nativně?
Ne. Microsoft 365 neposkytuje žádný vestavěný mechanismus pro úpravu času doručení nebo hlaviček Received u existujících zpráv. PowerShell, Exchange Admin Center ani Purview touto schopností nedisponují. Redate.io bylo vytvořeno specificky pro řešení tohoto problému prostřednictvím korekčního enginu založeného na porovnávání vzorů.
Je oprava v Microsoft 365 trvalá?
Ano. Jakmile Redate.io aplikuje opravu, původní zpráva je přesunuta do vyhrazené záložní složky a opravená zpráva nese správná datová metadata. Microsoft 365 od tohoto okamžiku indexuje opravené datum napříč všemi klienty a nástroji pro dodržování předpisů.
Kolik schránek může Redate.io zpracovat v tenantu Microsoft 365?
Redate.io může zpracovat schránky v celém tenantu M365 prostřednictvím registrace aplikace Azure AD se souhlasem administrátora. Neexistuje žádný limit na počet schránek. Administrátoři spravují celý korekční proces z jednoho řídicího panelu a zpracování běží na pozadí bez rušení uživatelů.