W dobie popularności rozwiązań chmurowych coraz częściej będzie dochodziło do sytuacji, w której łączące się podmioty, posiadają infrastrukturę cloudową lub hybrydową, tj. część serwerów i aplikacji jest pod pełną kontrolą przedsiębiorstwa, a druga wykupiona jako usługa u providera. Rozwiązanie hybrydowe jest też stosowane jako forma zabezpieczenia, zachowania redundancji na wypadek awarii jednego ze środowisk.
Gdy mamy do czynienia z przejęciem lub fuzją firm, zachodzi konieczność połączenia ich infrastruktury IT. Po etapie planowania i podejmowania decyzji na poziomie biznesowym, dochodzi zwykle do przeniesienia środowiska jednej bądź obu z firm do wspólnego, ustandaryzowanego otoczenia.
Korzystając z doświadczeń po kilku wykonanych z sukcesem migracjach, w niniejszym artykule postaram się przedstawić najważniejsze rzeczy, na które trzeba zwrócić uwagę przy podobnych projektach.
Będę tu opisywał mechanizmy mające miejsce przy przejściu z jednej dzierżawy Office365, do drugiej – nowej, lub już użytkowanej przez inną firmę.
Na początek o sprawach, które pojawiają się przy każdej zmianie IT w firmie.
Ustalenia
Najważniejsza rzecz, o której goniąc za czasem i pieniądzem niektórzy zapominają – sukces projektu zależny jest od spełnienia oczekiwań klienta. Tyle, że tylko dokładnie spisane i zatwierdzone przez obie strony ustalenia mają szansę przełożyć się na udany efekt końcowy. Niedopatrzenia, ustalenia słowne, telefoniczne – prędzej, czy później staną się w najlepszym przypadku przyczyną niepotrzebnych nerwów i wyjaśnień, w gorszym scenariuszu mogą stanowić dla firm dodatkowe koszty, czy nawet uniemożliwić realizację projektu.
Łączenie dwóch bytów – kto tu rządzi?
Gdy firmy decydują się by ich oddzielne do tej pory środowiska zespolić, przychodzi czas na ustalenie wspólnych wytycznych konfiguracji. Bardzo istotne kwestie bezpieczeństwa mogą się znacznie różnić między organizacjami. Niektóre ustawienia Office365 są dokonywane na poziomie globalnym, więc dotyczą wszystkich skrzynek pocztowych, stron Sharepoint, OneDrive czy Skype Dla Firm, jak np. udostępnianie zewnętrzne, czy możliwość kontaktowania się z użytkownikami Skype spoza organizacji. Tutaj wymagane jest ustalenie wspólnej polityki, akceptowanej przez obie firmy.
Odrębną sprawną jest wybór administratorów, zajmujących się konkretnymi częściami usługi Office365, przy czym na chwilę obecną nie ma możliwości ograniczenia możliwości zmian tylko dla konkretnej grupy użytkowników, tak, żeby jeden dział IT zajmował się tylko swoimi. Być może z czasem się to zmieni. Jest natomiast możliwe ustalenie kto będzie odpowiadał tylko za użytkowników, kto za ustawienia globalne, można wybrać administratorów Sharepoint, a dla użytkowników Exchange przypisać role administracyjne.
Przed rozpoczęciem zaplanowanych prac – informacja dla użytkownika Sprawa, do której podchodzi się z rezerwą, to informacja dla pracowników o planowanych zmianach, czasie realizacji i instrukcji zachowania się w pierwszym dniu czy dniach nowego środowiska. Chodzi o to, aby do minimum ograniczyć niezadowolenie ludzi, wynikające najczęściej z niewiedzy i strachu przed zmianami. Odpowiednio wcześnie podjęte działania prewencyjne, takie jak szkolenia z użytkowania nowej aplikacji, sposobu logowania, zachowania się w dniu „1” (w pierwszym dniu po migracji) pozwolą na przekazanie niezbędnej wiedzy i rozchwianie wątpliwości, a także ukazują obszary, które powinny zostać objęte szczególną ochroną, np. podczas przekazywania informacji dowiadujemy się, że dział finansowy ma teraz audyt i musi mieć priorytetowy dostęp do całej swojej poczty elektronicznej. Nie rzadko światło dzienne ujrzy sprawa, która sprawi, że projekt musi zostać wstrzymany, np. przenosiny jednego z oddziału będące w toku. Przekazanie informacji odciąży dział IT, który w pierwszym dniu po dokonaniu migracji będzie i tak miał pełne ręce pracy.
Testy, testy, testy Wobec możliwości uruchomienia dowolnej ilości kont tymczasowych Office365, mamy ułatwioną sytuację, jeżeli chodzi o przygotowanie środowiska testowego. Każda etap migracji może i powinien zostać wcześniej sprawdzony w praktyce, aby upewnić się, że nie stoi nam nic na przeszkodzie. Będzie można w ten sposób również zweryfikować czas potrzebny na wykonanie poszczególnych czynności.
Migracja do Office365 – o czym pamiętać?
Przechodząc do sedna – o czym należy pamiętać przy migracji między dzierżawami Office365?
- Firma Microsoft nie udostępnia na chwilę obecną możliwości przeniesienia skrzynek pocztowych, danych OneDrive, Sharepoint i innych usług Office365 w sposób zautomatyzowany pomiędzy dzierżawami.
Nie ma możliwości połączenie się między serwerami Exchange Online i przesłania maili z jednego na drugi. Sharepoint Online podobnie – nie umożliwia przeniesienia stron do innej dzierżawy. Z pomocą przychodzą narzędzia firm trzecich: MigrationWiz firmy BitTitan, czy Quest Migration Manager Della, Sharegate – stworzony specjalnie dla Sharepointa, oraz inne.
Są to oczywiście narzędzia płatne, ale tylko one są w stanie przygotować i przeprowadzić migrację obu środowisk – źródłowego i docelowego bez przestoju w dostępie do usług
- Środowiska obu firm – dokumentacja
Zaplanowanie, przetestowanie i wybór narzędzi przeznaczonych do migracji między dzierżawami Office365 oraz czas potrzebny na to, zależny jest od posiadanego otoczenia informatycznego obu firm:
– czy posiadają jeden czy wiele lasów ActiveDirectory, – czy planują wcześniej migrację dwóch lub więcej AD do jednego, wspólnego, – czy posiadają dodatkowe serwery pocztowe, np. Exchange, Linux, relaye pocztowe, itd. – czy serwer Exchange działa w trybie hybrydowym, tzn. czy – w jaki sposób zarządzane są domeny pocztowe oraz czy firma ma pełny i swobodny dostęp do rekordów DNS. Należy udokumentować wszystkie elementy przepływu poczty, by móc wybrać optymalny sposób przełączenia usług.
- Backup konfiguracji
Office365 nie posiada opcji kopii danych. Mogłoby się wydawać, że przecież będziemy tylko przeprowadzać kopiowanie danych i konfiguracji do nowej dzierżawy, więc po co zapisywać konfigurację? Po pierwsze dlatego, że po wyłączeniu synchronizacji z Active Directory stracimy dostęp do kontaktów i grup. Jeżeli nową dzierżawę będziemy łączyć z innym AD, nie mając zapisanych ich parametrów (nazw, przekierowań, uprawnień) trzeba będzie odtworzyć je ręcznie. Na kolejnych etapach przenoszenia usług może się okazać, że któryś z obiektów blokuje np. usunięcie domeny i trzeba będzie go usunąć. Backup konfiguracji może nas uchronić od problemów. Co polecamy zachować? Większość z poniższej listy i tak trzeba będzie zapisać w celu przeniesienia ustawień do nowej dzierżawy – lista użytkowników Office365 (MSOLUsers) – lista skrzynek pocztowych Exchange użytkowników – lista skrzynek współdzielonych – Uprawnienia skrzynek – Ustawienia regionalne skrzynek – Przekierowanie poczty – Lista i parametry grup security i dystrybucyjnych – Lista i parametry kontaktów – Ustawienia OOF (Out Of Office) – Ustawienia ExchangeOnline(reguły transportowe, reguły DLP, ustawienia filtrów spamu, połączeń i malware) – inne ustawienia Office365 – role administracyjne, uprawnienia.
- Narzędzia firm trzecich kopiują dane, nie synchronizują ich!
Trzeba uczulić klientów na to, że wykorzystując aplikacje migrujące dane, w przypadku przeniesienia z jednej do drugiej dzierżawy Office365, jak też w wielu innych (proszę dokładanie zapoznać się zawsze z dokumentacją!) – zawartość skrzynek pocztowych, OneDrive, czy Sharepoint jest kopiowana z jednej lokalizacji do drugiej. Oznacza to, że element, który został skopiowany ze starej lokalizacji do nowej, np. e-mail – jeżeli po dokonanym przeniesieniu zostanie usunięty w starym środowisku – w nowym cały czas będzie widoczny. Narzędzia te posiadają zabezpieczenia w postaci znaków wodnych, by nie dublować elementów w kolejnych przejściach (można, a nawet trzeba zrobić kilka faz kopiowania) – raz przeniesiony obiekt, nie będzie po raz kolejny brany pod uwagę, chyba, że w projekcie migracyjnym danej aplikacji zaznaczymy, że chcemy to zrobić.
- Licencjonowanie
Aby dobrze policzyć licencje w Office365, trzeba pamiętać, że współdzielone skrzynki ich nie potrzebują, urządzenia łączące się z serwerem SMTP chmury, a nie korzystające ze skrzynek muszą mieć wykupione licencje EOP oraz, że można dowolnie łączyć plany w obrębie jednej dzierżawy. Licencji nie trzeba przypisywać od razu, a w ciągu 30 dni, np. od stworzenia skrzynki Exchange. Z ustaleniem licencji dla narzędzi migracyjnych może nie być łatwo, gdyż czasami pobierana jest ona w zależności od ilości danych, liczby site’ów Sharepoint, itd. Tutaj niezbędna będzie pomoc działu handlowego sprzedającego te aplikacje.
- Obiekty chmurowe
Przy łączeniu środowisk Office365 dwóch firm, trzeba zwrócić uwagę na skrzynki i grupy typu cloud – tworzone z poziomu chmury Microsoft. Gdy cała dzierżawa źródłowa opierała się na synchronizacji z Active Directory może wydawać się, że wystarczy oprzeć się na liście użytkowników i grup AD. Jednak – w szczególności gdy wielu administratorów ma dostęp do O365 – należy sprawdzić je także z poziomu chmury i odtworzyć w nowym środowisku. Po czym rozpoznać obiekty utworzone po stronie Office365? Można sprawdzić datę ich synchronizacji z AD. Chmurowe nigdy nie były synchronizowane z usługą katalogową, a więc parametr lastdirsynctime będą miały pusty ($null). W powershellu będą to komendy: get-msoluser -all |where {$_.lastdirsynctime -eq $null} get-msolgroup -all |where {$_.lastdirsynctime -eq $null} get-msolcontact -all |where {$_.lastdirsynctime -eq $null}
- Office365Groups – nie do zmigrowania!
Nowy typ obiektu, który pozwala samym użytkownikom zakładać grupy w usłudze Office365. Używa OneDrive, OneNote i Outlooka. Są to jednak obiekty ukryte tworzące całość tego specyficznego „wynalazku” Microsoftu. Wielu administratorów blokuje możliwość tworzenia OfficeGroups ze względu na brak możliwości nadzoru nad nimi. Komenda służąca do tego celu: Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -GroupCreationEnabled $false
Z racji na swoją specyfikę w chwili obecnej nie ma możliwości migracji OfficeGroups. Jeżeli w dzierżawie, z której będziemy przenosili dane istnieją takie grupy, trzeba poprosić użytkowników o zapisanie plików w nich istniejących i odtworzenie ich w nowym środowisku.
Aby sprawdzić istnienie grup Office365 wydajemy polecenie: Get-UnifiedGroup Po wykonaniu tej komendy otrzymamy listę grup Office365:
lub nic:
– wówczas oznacza to, że w naszej dzierżawie nie ma tego typu grup:
- ADConnect – problemy
Przy zmianie konfiguracji aplikacji służącej do synchronizacji danych z Active Directory do Office365 – w najnowszej odsłonie nazywa się ona ADConnect (dawniej Dirsync i AADSync) – może zdarzyć się, że mimo zapisania wprowadzonych przez nas zmian nie działają one, np. jeden z dodanych poprawnie konektorów nie uruchamia się w procesie synchronizacji. Radą na to na chwilę obecną jest odinstalowanie i ponowna instalacja ADConnect łącznie z wszystkimi jego składnikami i bazą danych. Po ponownej instalacji i konfiguracji wszystko powinno działać. Przy dużej ilości zmian trzeba się uzbroić w cierpliwość. Zapisywanie ich po stronie Office365 może zająć dużo czasu (do kilku godzin). Jeżeli nie widzimy błędów po stronie ADConnect, trzeba odczekać zanim zaczniemy szukać przyczyn braku synchronizacji. Na wszystkie pojawiające się błędy w konsoli należy niezwłocznie reagować – część z nich powoduje zatrzymanie procesu synchronizacji.
- ADConnect – wiele lasów ActiveDirectory
Aplikacja ADConnect umożliwia synchronizację wielu lasów AD do jednej dzierżawy. Zakładane jest, że konta użytkowników są unikalne – ich parametry nie powtarzają się w dwóch różnych domenach. Gdy jednak użytkownicy istnieją i tu i tu, można wybrać parametr, na podstawie którego będą oni identyfikowani. Jest też wspierany scenariusz z GalSync – kontakty w jednym lasie łączone są podczas synchronizacji z obiektami użytkownika w drugim, dzięki czemu można ustawiać uprawnienia i dostęp do grup w wielu lasach i jednej dzierżawie Office365.
- Federacje kilku domen
W tej chwili jest możliwa federacja wielu domen, czyli użytkownicy mogą się autentykować poprzez firmowe serwery ADFS do Office365 używając kilku domen.
- Przełączanie domen – przestój w dostarczaniu poczty
Aby przenieść organizację z jednej dzierżawy Office365 do drugiej, jednym z kroków jakie trzeba wykonać jest migracja domen pocztowych. Nie można podpiąć tej samej domeny do dwóch dzierżaw Office365. Konieczne jest najpierw usunięcie jej z istniejącej, następnie dodanie i weryfikacja w nowej. Będzie to możliwe, gdy pozbędziemy się wszelkich powiązań obiektów Office365 z daną domeną – skrzynki, grupy, kontakty – nie mogą mieć aliasów domeny przeznaczonej do usunięcia. Ten krok jest momentem krytycznym, gdyż przestaje wtedy spływać poczta do starej dzierżawy, a nie jest jeszcze dostarczana do nowej. Jeżeli nie wykorzystujemy dodatkowych serwerów, które mogą przejąć ruch pocztowy na czas przełączenia domen, np. w konfiguracji hybrydowej z lokalnym serwerem Exchange, lub serwerem Linux – nastąpi przestój w dostarczaniu maili, trwający tyle, co dodanie, weryfikacja i przełączenie rekordów MX na serwerach DNS. Trzeba o tym uprzedzić zainteresowanych i na etapie planowanie wziąć pod uwagę potrzebny na operację czas. Tym bardziej, że domen pocztowych może być w dzierżawie dużo, niejednokrotnie kilkaset, a jednocześnie można uzyskać kody weryfikacyjne tylko do 50 domen. Zdarzają się również przeszkody, np. w postaci uszkodzonych obiektów, z których nie można usunąć aliasów i trzeba je usunąć całkowicie.
- OneDrive dla Biznesu (OneDrive for Business – O4B)
W planach Office365 z OneDrive (np. Enterprise E1-E5), każdy użytkownik dostaje własną przestrzeń danych wydzieloną na serwerze Sharepoint organizacji. W chwili pisania tego artykułu jest to 1TB. Problem w tym, że domyślnie jest to miejsce tylko dla niego, dopóki nie udostępni plików komu innemu. Aby przenieść zawartość OneDrive użytkownika, należy dodać kontu, które będzie pobierało dane uprawnienia administratora. Można to zrobić skryptem Powershell dla wszystkich istniejących stron OneDrive. Druga sprawa związana z tą aplikacją Office365, to fakt, że przy przenoszeniu do nowej dzierżawy, trzeba konta O4B najpierw utworzyć – nie są one automatycznie zakładane po przypisaniu użytkownikowi licencji O365. Również tutaj przyjdzie z pomocą Powershell, jednak wymagane jest użycie skomplikowanego skryptu i wcześniej przygotowanej listy kont do utworzenia. Podczas podawania parametrów w narzędziach migracyjnych trzeba zwrócić uwagę, że po przepięciu domen z jednej dzierżawy Office365 do drugiej, zmieni się UPN (nazwa logowania) użytkownika, a wraz z nim link (URL) OneDrive. Z formy https://firma-my.sharepoint.com/personal/jan_kowalski_firma_onmicrosoft_com zmieni się np. na: https://firma-my.sharepoint.com/personal/jan_kowalski_firma_pl Z uwagi na ten proces, trzeba ustawić odpowiednie adresy źródłowe i docelowe w narzędziach migracyjnych.
- Sharepoint – osobny byt
Mimo, że zintegrowany z innymi usługami Office365, jest jednak osobnym środowiskiem, które rządzi się własnymi prawami. Posiada swój zestaw użytkowników, uprawnień i usług, o których trzeba pamiętać podczas migracji. Firma Microsoft i tutaj nie ma gotowego rozwiązania na przeniesienie konfiguracji, danych i struktury z jednej dzierżawy Office365 do drugiej, jednak istnieją płatne narzędzia firm trzecich, które w mniejszym lub większym stopniu to potrafią. Jaką jednak aplikacją nie będziemy dysponować, trzeba pamiętać, że nie jest ona w stanie oddać skomplikowania wszystkich funkcji serwera Sharepoint i zawsze ma jakieś ograniczenia. Trzeba sprawdzać w dokumentacji listę funkcjonalności i obiektów, które mogą zostać objęte migracją oraz przeprowadzić wcześniej testy, czy zakres działań aplikacji jest wystarczający. Nawet jednak wówczas, może przydać się specjalista Sharepoint, który rozwiąże pojawiające się problemy. Okazuje się bowiem, że w obrębie Office365 działają różne wersje tego serwera.
- Kontakty w pliku autoodpowiedzi Outlooka
Przy każdorazowym wysyłaniu wiadomości no nowej osoby, kontakt zapisywany jest na liście podpowiedzi Outlooka. Nie byłoby w tym nic złego, gdyby nie fakt, że w obrębie organizacji zawiera on odwołanie do serwera. Dlatego też po migracji, jeżeli plik autopodpowiedzi został przeniesiony, należy usunąć kontakty firmowe z jego listy. W innym przypadku pojawią się zwrotki o niedostarczeniu wiadomości.
- Stare adresy .onmicrosoft w kalendarzach
Po migracji może okazać się, że niektóre wpisy w kalendarzach również odwołują się do starego serwera – kontakty mailowe osób zaproszonych pojawiają się pod adresem w domenie .onmicrosoft.com. Do tej pory dało się to zauważyć tylko dla spotkań cyklicznych. Jedyną metodą na pozbycie się tego uciążliwego problemu jest usunięcie problematycznych wpisów i odtworzenie ich na nowo.
- Mało istotne?
Kolejna funkcjonalność nowej wersji Exchange budząca kontrowersje – Clutter (z jęz.ang. – nieład). Po polsku folder nazywa się „Mało istotne”. Z założenia mają do niego trafiać wiadomości, które nie będą dla użytkownika pilne. Z doświadczenia wiemy, że bezpieczniej tę funkcjonalność wyłączyć, by uniknąć częstych zapytań o sprawdzenie co stało się z ważnymi mailami.
Wyłączenie dla wszystkich skrzynek: Get-mailbox –resultsize unlimited|set-clutter -Enable:$false
- Lokalizacja skrzynek
W firmie wielojęzycznej istotne jest wzięcie pod uwagę w krokach migracyjnych kwestii języka przypisanego do konta użytkownika. Podczas przenoszenia go z jednej dzierżawy do drugiej należy również zadbać o te parametry. Aby nie czekać na pierwsze logowanie użytkownika i pobranie ustawień regionalnych jego systemu (czasem odmiennych od tych wymaganych), należy ustawić je wcześniej na skrzynce. Rzeczą, która potrafi sprawiać problemy, to brak lokalizacji u części użytkowników, mimo dobrze przypisanych ustawień regionalnych. Wówczas w skrzynce z przypisanym językiem polskim, mogą się pojawić np. angielskie nazwy folderów. Sposobem na rozwiązanie tego problemu, jest uruchomienie tej komendy (dla wszystkich skrzynek z językiem polskim): Get-Mailbox –resultsize unlimited | Set-MailboxRegionalConfiguration –LocalizeDefaultFolderName:$true –language pl-pl –DateFormat yyyy-MM-dd
- ImmutableId
To parametr konta AzureAD, z którym podczas migracji między dzierżawami trzeba się dobrze zapoznać. Jest to odpowiednik ObjectGuid z Active Directory Windows Server i służy do mapowania kont AD do AzureAD. Dzięki temu można przypisać konta stworzone wcześniej w Office365, niezsynchronizowane jeszcze przy użyciu ADConnect do ich odpowiedników w Active Directory.
- Usuwanie zsynchronizowanych kont
Jeszcze do tej pory można znaleźć instrukcje nakazujące przenieść obiekt AD do innej jednostki organizacyjnej (OU), która jest wyfiltrowana w ADConnect, aby nie został zsynchronizowany – w celu usunięcia go z Office365. Teraz nie jest to już konieczne – można usuwać konta z ustawionym parametrem immutableid. Konto zostanie ponownie utworzone po ponownej synchronizacji z AD (jeżeli jest ciągle włączona). Jeżeli nie będzie chciało zadziałać, można użyć parametru –force komendy Remove-MsolUser, czyli: Remove-MSolUser –userprincipalname jan.kowalski@firma.pl -force
Podsumowanie: W artykule tym przybliżyłem sprawy, na które trzeba zwrócić uwagę planując migrację z jednej dzierżawy Office365 do drugiej. Nie wyczerpuje on tematu, ponieważ każdy z przedstawionych po krótce punktów można rozwinąć w zależności od środowiska IT i danej sytuacji. Sama usługa Office365 znajduje się w ciągłym rozwoju i przedstawione rozwiązania mogą wkrótce zostać zastąpione innymi.
Oferta Support Online zawiera m.in. kompleksowe usługi chmurowe. Na popularności zyskuje teraz hasło „chmura dla firm”. Co się pod nim kryje oraz jakie niesie korzyści? Tego dowiesz się z naszej oferty – CHMURA PRYWATNA. Zapraszamy do współpracy – zakładka KONTAKT.
Źródło: https://azure.microsoft.com/pl-pl/documentation/articles/active-directory-aadconnect-topologies/ https://support.office.com/en-us/article/Use-PowerShell-to-manage-Office-365-Groups-Admin-help-aeb669aa-1770-4537-9de2-a82ac11b0540 http://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_manage/disable-clutter-in-office-365-administration/f65ca8f4-7094-4629-8165-482c29d009ea?auth=1
Maciej Ochal
Administrator i Trener Microsoft w Support Online
