Извършване на миграция на клиент в Microsoft 365 (наричана още миграция от клиент на клиент или миграция от клиент на клиент на Office 365) не е просто преместване на пощенски кутии от едно място на друго: то включва прехвърляне на самоличности, поща, файлове, Teams, автоматизации, устройства и политики за сигурност, без да се спира бизнесът или да се губи информация.
Този тип проекти обикновено се появяват при сливания и придобивания., отделяния, промени в домейни или консолидации на няколко исторически наематели и комбинира оригинални елементи като CTUDM, възможности за кръстосано ползване на Entra ID, миграции на Exchange/SharePoint/OneDrive… В много случаи инструментите на трети страни и специализираните партньори помагат всичко да бъде по-управляемо.
Какво представлява мигрирането на клиент на Microsoft 365 и в какви случаи се извършва?
а Миграция между клиенти на Microsoft 365 Това е процесът на преместване на потребители, пощенски кутии на Exchange Online, сайтове и файлове на SharePoint и OneDrive, екипи на Teams, автоматизации на Power Platform, устройства, управлявани от Intune, и настройки за сигурност/съответствие от един клиент на друг.
Причина номер едно за този вид миграция е MAD етапи (сливания, придобивания и продажби), където е необходимо да се интегрират или разделят компании, които вече използват Microsoft 365, въпреки че се появяват и поради ребрандиране, промяна на домейн, консолидиране на стари наематели или промяна на партньор/лицензиране.
Сред най-често срещаните сценарии откриваме:
- Сливания и придобивания, при които е желателна единна корпоративна среда.
- Отделяне или отделяне на част от бизнеса.
- Глобална промяна на имейл домейна.
- Обединяване на регионалните наематели в корпоративен и реорганизации в мултинационални групи, които преминават от модел за всяка държава към глобален модел.
Във всички тези случаи ключовият въпрос не е само „как да мигрирам“, а какво се мигрира такова, какво се оставя в източника, какво се изгражда от нулата в целевия клиент и в какъв ред се изпълняват промените, за да не се задържат критични процеси или чувствителни потребители.
Зад всеки миграция от наемател на наемател Съществува и правен компонент и компонент за съответствие: защита на личните данни, правно съхранение, одит, секторни изисквания и суверенитет на данните, които трябва да бъдат прегледани, преди да се предприеме и едно действие.
Методология, управление на проекта и фаза на оценка
Разликата между гладка миграция и бедствие често се крие в методология. Работете на вълни, с представителен пилот, UAT с ясен бизнес и показатели. С мониторингов комитет, който се среща редовно, за да взема решения и да приоритизира.
Интересно е комбинирайте гъвкави практики с планиране на етапиоткриване и оценка, проектиране на архитектурата, конфигуриране на съвместно съществуване, техническа имплементация чрез натоварвания (поща, файлове, Teams, Power Platform, Intune), миграция на домейни и фаза на стабилизиране.
El първоначална оценка отговори три основни въпроса:
- Какво има в момента (инвентар).
- Какво блокира миграцията (притежания, ограничения на услугите, разпоредби).
- Кои критични зависимости свързват потребители, приложения и данни в рамките на и между наемателите?
В частта на сътрудничество и архиви Препоръчително е да се направи инвентаризация на обемите и моделите на използване в OneDrive по потребител, сайтове на SharePoint (класически, модерни, комуникационни, свързани с групи/екипи) и екипи на Microsoft Teams с техните канали, раздели, записи и използване на Stream в SharePoint.
В областта на устройства и приложения Политиките и автопарковете трябва да бъдат картографирани в Intune, приложения, които използват Graph/EWS/SMTP OAuth спрямо клиента, среди и решения на Power Platform и всички външни интеграции, които зависят от конкретни самоличности или пощенски кутии.
Съвместно съществуване: идентичност, календари и имейл между наематели
Добре обмислено съвместно съществуване Това позволява на организацията да продължи да работи нормално, докато данните се прехвърлят във фонов режим. Това предотвратява прекъсвания на имейла или календара.
В идентичността, Въвеждането на идентификатор е ключовата част. Конфигурират се политики за достъп между клиенти, синхронизацията между клиенти е активирана, ако искате да автоматизирате създаването и актуализирането на B2B потребители, а форматът и псевдонимът на UPN в целевата среда се определят предварително.
За календари, Exchange Online ви позволява да конфигурирате организационни взаимоотношения между наемателите, така че потребителите да могат да виждат състоянието „Свободен/Зает“ на своите колеги, дори ако те все още са разпръснати, като се регулира нивото на детайлност и се потвърждава, че ръководството, продажбите и поддръжката могат да продължат да планират безпрепятствено.
В пощата най-разумното нещо, което можете да направите, е MX записът да сочи към произхода По време на фазата на съвместно съществуване, трябва само да го преместите към целевия клиент, след като критичните пощенски кутии бъдат мигрирани и тествани. Междувременно можете да използвате конектори и правила за транспорт, за да маршрутизирате трафика, ако е необходимо.
CTUDM, лицензи и правни аспекти на миграцията
В момента стандартният подход за имейл и OneDrive е използването на Плъгин за миграция на потребителски данни между наематели (CTUDM), което позволява нативни миграции между клиенти на Exchange Online и OneDrive с поддръжка на Microsoft и високи възможности за проследяване.
CTUDM е лицензиран за всеки мигриран потребител. Предназначен е за еднократна употреба на обект. Затова е препоръчително да се планира кои потребители действително ще бъдат мигрирани, кога и в коя вълна. Целта е да се избегне закупуването на допълнителни лицензи или изчерпването им в последния момент.
От правна и нормативна гледна точка, това е задължително Прегледайте споразуменията за обработка на данни, партньорските споразумения, политиките за защита на данните, законовите условия за съхранение на данни и регулаторните изисквания. които влияят на преноса на данни между наематели и региони.
там ръчни или хибридни алтернативи (PST, IMAP, инструменти на трети страни без CTUDM, експортиране към междинни файлове). Те обикновено са свързани с по-голям оперативен риск, по-малко официална поддръжка и повече работа по наблюдение. Най-добре е да се запазят за специфични случаи.
Миграция на Exchange Online между наематели
Когато FastTrack е интегриран или се използва CTUDMПроцесът на преместване на пощенски кутии между клиенти на Exchange Online следва сравнително ясна последователност: подготовка на доверителни отношения, проверка на домейни, гарантиране, че потребителят съществува в местоназначението и създаване на партиди за миграция.
FastTrack, когато е наличен, предлага 24/7 поддръжка на английски език за бизнес клиенти. Предоставя насоки за планиране, помощ при подготовката на наемателите и услуги за миграция, включително стартиране и наблюдение на събития за миграция с отчети за състоянието.
Що се отнася до това, което наистина се движи вътре Обмен онлайнОбикновено се мигрират имейл съобщения, правила от страна на сървъра, контакти и календари, задачи, свързани архивирани пощенски кутии, възстановими елементи, стаи, пощенски кутии на ресурси и имейли, защитени или криптирани от технологиите на Microsoft, при условие че няма заключващи механизми за криптиране в източника.
От друга страна, Има елементи, които не са включени в стандартната миграция. Говорим за публични папки, съобщения, които надвишават ограничения за размер, решения за архивиране на трети страни, повредени елементи, клиентски правила, съобщения в Teams, пощенски кутии в режим на задържане или с повече от определен брой помощни файлове на Outlook, профили в Outlook, разрешения за Entra ID или настройки „Изпращане като“ и „Изпращане от името на“.
Преди да преместите пощенска кутия, препоръчително е да изчистите проблемното криптиране.както и преглед на правни задържания и временно спиране. Също така, уверете се, че списъците за разпространение и външните контакти съществуват в местоназначението. И че пощенските кутии, които ще бъдат мигрирани, са активни и лицензирани.
Мигриране на OneDrive и SharePoint Online между клиенти
Преместване на лични и корпоративни файлове Това включва разбиране на ограниченията за съхранение, квотите за SharePoint и OneDrive, както и ограниченията за размера и броя на елементите на сайт или акаунт. Има ограничения, като например 5 TB или 1 милион елемента на OneDrive или сайт, които не можем да игнорираме.
В SharePoint
Миграцията от клиент на клиент може да включва сайтове, свързани с групи на Microsoft 365 (включително тези, свързани с Teams), модерни и класически сайтове, сайтове за комуникация, структури на папки, документи, разрешения на потребителско и групово ниво, споделени връзки, история на собствеността, версии и основни метаданни, като например дати на създаване/модификация и автори.
Има обаче важни изключения. Сайтове с повече от 5 TB или с повече от един милион елемента, повредени или недостъпни документи, пътища с дължина над 400 знака, наследени работни потоци на SharePoint, приложения и компоненти като Power Apps или автоматизации, които се намират „върху“ съдържанието.
В OneDrive
Моделът е подобен. Прехвърлят се документи, папки, разрешения, споделени връзки, версии и основни метаданни. Изключват се обаче законово спрени акаунти, съдържание, надвишаващо ограниченията, прекомерно дълги пътища или повредени файлове, до които системата няма достъп.
FastTrack или вградените инструменти на Microsoft за SharePoint/OneDrive Те предлагат помощ при планирането, установяването на доверителни взаимоотношения между наемателите, планирането на събития за миграция, наблюдението на напредъка и генерирането на отчети – винаги в рамките на ограниченията на услугите на платформата.
Инструменти на трети страни и автоматизирани решения
Въпреки че Microsoft предлага солиден набор от вградени възможности, много организации допълват този подход с решения на трети страни. Особено когато търсят много подробни отчети, по-лесни за ползване интерфейси или специфични функционалности.
Инструменти като SysTools Office 365 към Office 365 Те ви позволяват да изберете Microsoft 365 като източник и местоназначение, да маркирате кои данни да мигрирате (имейл, контакти, календари, документи), да прилагате филтри по дата, да активирате опции за мигриране на документи и да управлявате потребителските назначения с помощта на CSV файлове.
Този тип автоматизирани инструменти Обикновено изискват да регистрирате приложение в Azure, да предоставите разрешения, да генерирате идентификатор на приложение и да валидирате разрешенията както за изходния, така и за целевия клиент. Това им позволява да действат от името на администраторите и да извършват групова миграция.
Други решения, като например Миграция на ядрото към Office 365 Те се фокусират върху преместването на пощенски кутии между наематели, изброяване на всички пощенски кутии в изходния наемател и съпоставянето им с тези в целевия наемател. Това ви позволява да мигрирате потребителски пощенски кутии, публични папки или архивни пощенски кутии и да прилагате филтри, преди да стартирате миграцията.
Тези инструменти обикновено предлагат ventajasНякои от тези функции включват: миграция на множество проекти, поддръжка на домейн акаунти, делта миграция (само за нови промени), приоритизиране на акаунти и генериране на подробни CSV отчети за одит и последващи действия.
Microsoft 365 DSC и репликация на конфигурацията между клиенти
Освен простото преместване на данни, ние трябва репликиране на конфигурацията на наемателя. От политиките за сигурност и правилата за достъп, това обуславя всичко до параметрите на Exchange и конфигурацията на SharePoint, Teams и др. Тук влиза в действие конфигурацията на желаното състояние (DSC) на Microsoft 365.
DSC е базиран на декларативни PowerShell скриптове които описват желаното състояние на конфигурацията. Локален мениджър на конфигурации периодично преглежда средата. Ако открие отклонения, той прилага необходимите промени, използвайки специфични ресурси, включени в PowerShell модулите.
за Използвайте DSC безопасно Обикновено приложение, регистрирано в Azure AD, се създава с разрешения за съответните API, удостоверяване чрез сертификат (PFX) и използване на едно и също приложение както в изходния, така и в целевия клиент, за да се минимизират рисковете за сигурността.
Първоначалното внедряване на конфигурации с помощта на DSC Може да отнеме значително време. Todp зависи от обема на включените натоварвания и броя на конфигурационни параметри за репликиране. Затова е препоръчително първо да се тества в тестови среди, които репликират производствената среда.
Настройка на домейн, DNS и преместване на MX записи
Един от най-деликатните моменти на проекта Това е преместването на основния пощенски домейн: премахването му от изходния клиент, добавянето му към местоназначението, настройването на MX, SPF, DKIM и DMARC и гарантирането, че пощата не се губи по пътя.
В предварителна фаза Трябва да направите това:
- Проверете домейна в целевия клиент.
- Добавяне на TXT записи към DNS.
- Уверете се, че домейнът се използва само в един клиент (в противен случай проверката ще бъде неуспешна).
- Обърнете внимание на TTL на MX, за да знаете колко време ще отнеме разпространението на промените.
Преди да можете да освободите домейна на изходния клиент Необходимо е да се премахне от всички обекти, които го използват: първични и вторични имейл адреси, групи, пощенски кутии на ресурси, политики и др., в противен случай платформата няма да позволи освобождаването му.
По време на процеса на рязане е обичайно да спиране на потока от входяща поща Насочване на MX записа към временна стойност или междинна услуга. Трябва да изчакате опашката на източника да се изчисти. След това завършете всички чакащи миграции и накрая регистрирайте домейна в целевия клиент с новите му, правилни записи.
След движението Изпращането и получаването, подписването на DKIM, DMARC отчетите и доставката до и от външни домейни се валидират, като политиката на DMARC се коригира от консервативна (p=няма) към по-строги конфигурации (карантина или отхвърляне), когато всичко е стабилно.
Как трябва да изглежда една добре планирана миграция между клиенти в Microsoft 365? Трябва да се комбинира честна оценка, стабилен дизайн за съвместно съществуване, интелигентно използване на CTUDM и възможности за кръстосано ползване, подкрепа от инструменти и/или партньори, когато е уместно, поетапно внедряване със строги тестове и засилена сигурност и управление в целевия клиент. Целта е промяната да бъде едва забележима в ежедневния опит на потребителите. Всичко това обаче ще се превърне в по-голям контрол, повишена надеждност и по-малко изненади в средносрочен план.