2010-luvun alun 365-buumi koostui teknisesti lähinnä sähköpostimigraatioista 365:een.
Lähdejärjestelminä oli usein joko omassa tai hostatussa konesalissa huriseva Exchange-toteutus tai erilaiset IMAP-pohjaiset sähköpostijärjestelmät.
Sähköpostimigraatioiden osuus 365-tekemisestä on ajan saatossa vähentynyt mm. siksi että moni organisaatio on jo sinne pilveen siirtynyt. Tilalle on tullut sitten sitä kuuluisaa ”Tenant-to-Tenant” -migraatiota eli esim. yritysostot ja fuusiot.
Kuitenkin maailmasta vielä löytyy migroitavia Exchangeja ja tämän kirjoituksen ajatus on antaa vinkkejä, kuinka valmistella vaikkapa sitä omaa ympäristöä hybrid-migraatiota varten. Osa alla olevista ovat asioita, jotka olisi hyvä olla kunnossa joka tapauksessa.
Tässä ei käydä läpi erilaisia virhetilanteita, joita itse migraatiossa voi tulla vastaan. Näistä löytyy melko kattavasti tietoa internetin ihmeellisestä maailmasta.
1. Exchange-versio ja CU-taso
Nyrkkisääntönä on, että kannattaa olla aina ajossa käytössä olevan Exchangen viimeisin CU-päivitystaso. Tämä toki ei ole välttämätöntä, mutta ainakin kannattaa tarkastaa mikä sen oman Exchangen taso on ja kurkata onko sen jälkeen mahdollisesti tullut päivityksiä, joissa on parannuksia hybridiin. Listaus CU-päivityksistä löytyy täältä.
Ja todettakoon vielä, että Exchange 2010 pohjaiset hybridit teknisesti toimivat kyllä, mutta mitään tukea ei niihin enää saa (ainakaan helposti). Kaikkia samoja ominaisuuksia yhteiselon kannalta Exchange 2010 hybridi ei tarjoa mitä myöhemmät Exchange versiot taasen antavat.
2. ”Turhien” osoitteiden siivous
Jos migraatio toteutetaan hybridillä, sähköpostilaatikoista pitää siivota ennen migraatiota pois sellaiset osoitteet, joita yrityksen 365:stä ei löydy. Yleensä nämä osoitteet ovat historian havinaa ja .local-osoitteita. Sellaisen sähköpostilaatikon migraatio yksinkertaisesti epäonnistuu, jossa on käytössä osoitteita, joita pilvessä ei ole.
3. Tunnus ja sähköpostiosoite samaksi
Tämä on ihan yleinen hyvä sääntö noudattaa 365-maailmassa, migraatiota tai ei.
Tunnuksella tässä tarkoitetaan AD-tunnuksen userPrincipalName (UPN). Kun AD:sta synkataan Azure AD Connectilla (AADConnect) tunnuksia pilveen, muodostuu pilven käyttäjätunnus tuon UPN:n perusteella, ellei synkkaan ole määritelty tunnuksen muodostuminen jonkin muun attribuutin perusteella. Yleisin tilanne on se, että UPN on AD:ssa keijo@ad.local ja sähköpostiosoite on muotoa keijo.kayttaja@firma.fi. Jos tunnus otettaisiin ihan noin vain käyttöön pilvessä, törmäisi käyttäjä työasemallaan mielenkiintoisiin ongelmiin. 365:ssä myös ohjeistukset käyttäjille on usein kerrottu muodossa ”anna sähköpostiosoitteesi” ja tämähän ei päde, jos käyttäjän tunnus (UPN) ei ole sama kuin sähköpostiosoite.
4. Sähköpostilaatikoiden väliset luvitukset
Tässä oikeastaan kaksi tärkeää kulmaa:
- Luvitukset ryhmien kautta –> Ryhmien tulee olla Mail-Enabled Security Grouppeja. Jos on käytetty normaaleita Global/Universal Security Grouppeja, oikeudet katoavat migraatiossa.
- Luvituksissa mukana olevien objektien (käyttäjät/ryhmä) tulee olla mukana AADConnect-synkassa jotta migraatio osaa luoda luvituksen 365:ssä samaksi kuin mitä se oli Exchangessa.
Ylivoimaisesti eniten itselleni on tullut vastaan tilanteita, joissa luvitukset on tehty tavallisilla AD:n Security Groupeilla. Exchange Online ei luvituksia osaa näillä ryhmillä tehdä.
5. Jakelulistojen jäsenien hallinta
Miten on toteutettu tällä hetkellä? Jos jäseniä päivittää listan omistaja oman Outlookinsa kautta, pitää jakelulistat pyöräyttää manuaalisesti pilveen. Jos jakelulistat synkataan AADConnectilla pilveen, niiden jäsenyyksiä voi hallita vain AD:n / Exchangen kautta. Omistaja(t) eivät enää pysty Outlookinsa kautta jäsenyyksiä päivittämään.
6. Onko käytössä Public Folderit?
Näiden migrointi ei ole koskaan mukavaa puuhaa. Vähintäänkin kannattaa harkita muita tapoja jatkossa tiedon käsittelyyn, kuten vaikkapa SharePoint Online / Teams. Eli en itse lähtisi suosittelemaan, että viedään 365:een 1:1 eli Public Folderiksi. Mieluummin vaikkapa jaetuiksi sähköpostilaatikoiksi. Todettakoon, että Microsoftilla ei ole tarjota valmista tapaa migroida Public Foldereita muuksi kuin Public Foldereiksi. Joten kolmannen osapuolen työkaluun voi joutua turvautumaan, jos kohteeksi halajaa SharePoint Onlinea / Teamsia. Toki Public Foldereista saa dataa ulos ilman työkaluja, jolloin tietoja voi itse ”käsin” viedä haluamaansa kohteeseen.
7. Integraatiot
Nämä on syytä kartoittaa ajoissa ja ymmärtää miten toimivat. Onko esim. käytössä sellaisia sovelluksia, jotka käyttävät sähköpostilaatikoita lähettämiseen/vastaanottamiseen. Luetaanko käyttäjien sähköpostilaatikoita Exchangen rajapinnan läpi suoraan. Esim. Microsoftin oma CRM-järjestelmä integroituu vahvasti Exchangen kanssa eikä selviä migraatiosta ilman toimenpiteitä. Integraatioksi lasketaan myös mahdolliset Outlook lisäpalikat, nämäkin voivat ottaa osumaa migraatiossa.
8. Testi- ja pilottimigraatiot
Näiden idea on saada kiinni mahdolliset ongelmat mm. integraatioiden kanssa. Tarpeeksi kattava pilottiporukka voi säästää monelta harmaalta hiukselta myöhemmin.
9. Työasemien Office-versiot
Sanomattakin selvää, että Office 2010 ja 2013 alkavat jo olla sellaisia, että pitäisi päivitellä uudempaan.
Migraation jälkeen (ja muutenkin) voi käyttäjän työasemalla tulla mielenkiintoisia ongelmia, jos käytettävä Office on liian vanha.
10. Hybridin elinkaari
Jos tiedossa on jo alkumetreiltä, että hybridin kanssa tullaan elämään vuosi(a) on koko hybridi syytä rakentaa niin että mahdollisimman moni asia toimii yhteiselossa pilven kanssa:
- Kalenterinäkyvyydet (free/busy) 365 <-> Exchange
- Lukeminen/lähettäminen resurssilaatikoista
- Esim. skenaario, jossa käyttäjä on jo migroitu pilveen mutta resurssilaatikko on vielä Exchangessa
Hybridistä on mahdollista rakentaa myös ns. ”kevyt versio” jonka idea on lähinnä hoitaa migraatiot pilveen. Tässä vaihtoehdossa ei ole mukana esim. kalenterinäkyvyyksiä 365 <-> Exchange
Migraatioita tehneillä on varmasti mielessään monia muitakin asioita, jotka pitää ottaa huomioon. Tässä nyt kuitenkin omani, jotka tuntuvat toistuvan melkein jokaisessa Hybrid-migraatiossa.
– Pilviguru Jasu Snell
