Na co powinniśmy zwrócić uwagę, zanim uruchomimy proces migracji? Posiadanie odpowiednich serwerów, czy też odpowiednio wydajnych zasobów dyskowych jest ważne w przypadku wdrożenia Exchange on-premises, w przypadku wdrożenia Office 365 lokalne serwery nie są aż tak ważne (tylko w zakresie integracji posiadanego Active Directory z katalogiem użytkowników w Office 365). W obu przypadkach wąskim gardłem mogą stać się łącza sieci rozległej czy też internetowe, zwłaszcza przy rozszerzaniu funkcjonalności udostępnianej pracownikom. Przecież system Exchange to nie tylko serwer poczty elektronicznej ale scentralizowane zarządzanie kalendarzami, kontakty, wspólna książka adresowa, delegowanie zadań.
Kolejne kroki, które należy wykonać przygotowując Active Directory czy też istniejącą infrastrukturę serwerów do wdrożenia Exchange 2013 stosunkowo dokładnie opisuje dokumentacja produktu – zwłaszcza rozdział dokumentacji produktowej Planning and Deployment oraz narzędzię Exchange Server Deployment Assistant. W ciekawy sposób zagadnienia, na które musimy zwrócić uwagę ujął Krzysiek Kubicki na naszej konferencji preMTS 2013 – niestety nadal nie najlepiej opisane są zalecane konfiguracje sprzętowe dla Exchange 2013 na serwerach firmowych. Co warto policzyć, zanim zaplanujemy infrastrukturę sprzętową oraz rozłożenie fizyczne serwerów oraz jakie narzędzia będą pomocne szczegółowo opisuje Prabhat Nigam na blogu MSExchangeGuru http://msexchangeguru.com/2013/07/30/exchange-2013-planning-and-design-guide/. W skrócie – przede wszystkim możemy wykorzystać kalkulatory do policzenia ilości serwerów i dysków potrzebnych dla serwerów Exchange – Exchange 2013 Server Role Calculator (warto zauważyć, że zalecane wartości RAM są dwa razy większe niż w przypadku Exchange 2010, może nam przydać się również Exchange Client Network Bandwidth Calculator. Zwłaszcza przy zmianie architektury lub struktury połączeń (centralizacja serwerów Exchange lub migracja do Office365). używając kalkulatorów warto również wiedzieć, ile maili i jakiej wielkości pracownicy generują w skali dnia czy miesiąca – te wielkości są nam potrzebne do wyliczeń.
Przy wdrażaniu Office 365 nie musimy zastanawiać się nad kwestiami skalowalności ani wydajności systemu – za to odpowiedzialny jest zespół Microsoftu nadzorujący centra danych Office 365, jest również dostępny zestaw dokumentów i narzędzi, wspomagających administratora/wdrożeniowca podczas migracji systemu pocztowego do chmury – najlepszym miejscem do rozpoczęcia przygotowań jest Office 365 deployment guide. Ciekawym narzędziem jest również OnRamp (wcześniejsza nazwa Office 365 Readiness Tool). Bardzo często używanym narzędziem, potrzebnym w przygotowaniu lokalnej domeny Active Directory do integracji z chmurą jest również IdFix (DirSync Error Remediation Tool) - narzędzie do wykrywania i naprawiania problemów z atrybutami obiektów AD, które mogą sprawić problemy przy synchronizacji lokalnej lasu z usługą Office 365. Migrując z alternatywnych platform, takich jak Lotus Notes przydatnym narzędziem będzie również Online Notes Inspector (MONTI), który można pobrać lokalnie z tego miejsca - MONTI oraz dokumentacja.
Jednak wszystkie powyższe źródła niewiele powiedzą nam o przykrych niespodziankach, na które możemy natknąć się po stronie działających komputerów klientów naszej organizacji. Microsoft zakłada, że korzystamy z platform aktualnie wspieranych i umożliwiających obsługę Exchange 2013/Office365. Niestety wiele firm nadal wykorzystuje w swoim środowisku zarówno Outlooka 2003 jak i stacje robocze Windows XP, a nawet Windows Vista. Office 2013, dostarczany w ramach planów korporacyjnych E3 i E4 oraz planów dla większych organizacji SMB mogą być instalowane na komputerach z systemem Windows 7 lub nowszym, co automatycznie eliminuje prawie połowę rynku komputerów klienckich – mimo, że zegar tyka i za nieco ponad trzy miesiące definitywnie zakońćzy się wsparcie dla Windows XP, nadal co najmniej 30% rynku używa tego systemu. Oznacza to, że wykorzystanie wszystkich funkcjonalności Office365, bądź też Exchange 2013 nie w każdej firmie może być możliwe. Nawet Office 2007, wspierany przez Exchange 2013 nie wszystkie funkcjonalności pozwala nam wykorzystać tak samo skutecznie. jak dobrze widać na przykładzie obsługi kalendarza, o czym pisałem kilka miesięcy temu na tym blogu. Alternatywą pozostaje wykorzystanie przeglądarki internetowej – Outlook Web App posiada pełną funkcjonalność kliencką Exchange 2013, jednak znowu Microsoft w wydanym pod koniec listopada Cummulative Update 3 pokazał, że nie do końca zwraca uwagę na ograniczenia wbudowanego w Windows XP Internet Explorera 8, o czym świadczy artykuł KB 2871314.
Przygotowując migrację systemu pocztowego do Exchange 2013, niezależnie od tego, czy mamy zamiar wdrażać system lokalnie (on-premises) czy w chmurze (Office 365), należy przede wszystkim skupić się na analizie środowiska. Ale wbrew pozorom największe wyzwania czekają nas nie po stronie środowiska serwerowego, tylko stacji roboczych. Często okazuje się, że niezależnie od wielkości firmy nie do końca orientujemy się, jakie wersje systemu operacyjnego (w tym Service Packów), a także pakietów Microsoft Office mają zainstalowane stacje robocze. Część firm używa dedykowanego oprogramowania do zarządzania stacjami roboczymi (np. SCCM lub LanDesk), jednak możemy również użyć bezpłatnego oprogramowania, dostarczanego przez Microsoft – Microsoft Assesment and Planning Toolkit (MAP). Oprogramowanie to, od niedawna dostępne w wersji 9.0, zaktualizowane pod kątem najnowszych produktów, szybko zinwentaryzuje stacje robocze, oraz przygotuje raporty z informacjami, opisującymi stan przygotowania środowiska do konkretnych wersji systemu operacyjnego, pakietu Office czy też usługi Office365.
Korzystając z takich narzędzi stosunkowo prosto możemy sprawdzić jakie niespodzianki mogą nas spotkać w trakcie migracji. Oczywiście nie rozwiążemy w ten sposób wszystkich problemów, ale przynajmniej będziemy mieli rozeznanie, jaka część naszego środowiska nie jest gotowa współpracy z Exchange 2013 czy też Office 365.
