Microsoft Teams -kalenterikutsut eivät reitity toivotusti sähköpostipalveluiden ollessa G Suitessa

Viankuvaus:

Kuvitellaan tilanne, jossa organisaatiossa (mapy.fi) on käytössä kaksi eri pilvipalvelua eri käyttötarkoituksiin. Esimerkiksi:

G Suite: Sähköposti, kalenteri
Office 365: Office-työpöytäohjelmat (Word, Excel, PowerPoint…), Microsoft Teams, Microsoft Intune

G Suitea ei haluta migratoida Office 365:een, vaan organisaatio haluaa jatkaa sen käyttämistä ensisijaisena sähköpostipalveluna. Koronavirustilanne on kuitenkin nostanut tarpeen paremmalle etätyöskentelylle ja yhteistyölle. Siihen tarkoitukseen halutaan käyttää Microsoft Teamsia. Organisaation käyttäjillä on tilit sekä G Suiten että Office 365:n puolella samoilla sähköpostiosoitteilla muotoa etunimi.sukunimi@mapy.fi.

Teamsin käytön aikana on havaittu kuitenkin mm. seuraavat ongelmat:

1) Oman organisaation sisäisille vastaanottajille lähetetyt Teams-kokouskutsut eivät mene perille heidän G Suitessa sijaitseviin sähköpostilaatikoihinsa

2) Organisaation ulkopuolisten kokousjärjestäjien lähettämät Teams-kokouskutsut eivät päädy Microsoft Teamsin kalenterinäkymään, vaikka ne päätyvät käyttäjän sähköpostilaatikkoon G Suitessa

Taustatietoa vian ymmärtämiseksi:

Miksi näin tapahtuu? Vikaa ymmärtäessä on tärkeää käsittää seuraavat asiat:

Microsoft Teams edellyttää Exchange Online -postilaatikon, jos käyttäjä haluaa luoda ja hallita Teams-kokouksia. Ilman Exchange Online -käyttöoikeutta käyttäjät eivät tule edes näkemään koko kalenteri-näkymää Microsoft Teams -sovelluksessa.
Tämä tarkoittaa sitä, että organisaation Teams-käyttäjillä tulee olemaan sähköpostilaatikko sekä Office 365:n että G Suiten puolella.
Koska organisaatio käyttää sähköpostipalveluinaan G Suitea, heidän nimipalveluidensa MX-tietueet osoittavat Googlen G Suiteen, eivätkä Microsoftin Office 365 -pilvipalveluun. Tämä tarkoittaa sitä, että kaikki organisaation ulkopuolelta sisäänpäin saapuva liikenne tulee reitittymään vain G Suiteen, eikä koskaan päädy Office 365:een. Sama pätee myös organisaation sisäiseen liikenteeseen, jos se lähetetään G Suiten postilaatikoista.
Office 365 ei kuitenkaan kunnioita julkisia MX-tietueita, jos organisaation toimialuenimi on lisättynä Office 365:een ensijaiseksi toimialueeksi. Tällöin se tulkitsee kyseiselle toimialueelle kohdistuvan sähköpostiliikenteen olevan tenantin sisäistä liikennettä, eikä edes yritä reitittää sitä julkisten MX-tietueiden perusteella.

Organisaation sisäisesti lähettämät Teams-kalenterikutsut eivät siis päädy vastaanottajien G Suite -postilaatikoihin, vaan ainoastaan kyseisten vastaanottajien Exchange Online -postilaatikoihin Office 365:n sisällä. Molemmilla postilaatikoilla on sama ensisijainen sähköpostiosoite.

Organisaation ulkopuolisten lähettämät Teams-kalenterikutsut eivät päädy Teamsin kalenterinäkymään, sillä lähettäjäorganisaation sähköpostipalvelin tarkistaa vastaanottavan organisaation nimipalveluista korkeimman prioriteetin MX-tietueen, joka osoittaa G Suiteen. Tästä syystä kalenterikutsu lähetetään vastaanottajan G Suitessa sijaitsevaan sähköpostilaatikkoon, eikä se tule koskaan päätymään Office 365:n puolelle, jossa sijaitsevan postilaatikon kalenteria Teams esittää kalenteri-näkymässään.

Ratkaisu:

Täydellistä ratkaisua ongelmaan ei koskaan tule olemaan, sillä emme voi ohittaa seuraavia faktoja:

Voimme reitittää saapuvaa sähköpostiliikennettä MX-tietueiden perusteella vain yhteen palveluun kerrallaan
Office 365 ei kunnioita G Suiteen osoittavia julkisia MX-tietueita, jos se jakaa saman toimialuenimen

Olemme siis tilanteessa, jossa emme voi lähettää postia toisesta palvelusta toiseen samaa toimialuenimeä käyttäen. Eli Office 365:stä ei voida lähettää *@mapy.fi -osoitteista *@mapy.fi -osoitteisiin G Suitessa, tai toisin päin. Se ei tule toimimaan.

Ratkaisu tulee muodostumaan kahdesta tekijästä:

Alias-sähköpostiosoitteiden määrittämisestä käyttäjille eri toimialuenimeä käyttäen
Saapuvien viestien edelleenohjauksesta ensijaisesta osoittesta toisessa palvelussa sijaitsevaan alias-osoitteeseen

Mitä siis tarkoitan tällä? Käyttäjille tullaan määrittämään kaksi sähköpostiosoitetta per pilvipalvelu. Ensisijainen osoite tulee olemaan molemmissa palveluissa muotoa etunimi.sukunimi@mapy.fi. Toissijainen alias-sähköpostiosoite tulee olemaan eri toimialuenimellä. Käyttäjille voidaan lähettää sähköpostia kumpaa tahansa osoitetta käyttäen. Toissijainen alias-osoite on sellainen, johon käyttäjät eivät edes tule kiinnittämään huomiota. Siihen lähetetty sähköposti tulee kuitenkin päätymään heidän sähköpostilaatikkoonsa tavallisesti. Tämä mahdollistaa sen, ettei meidän ikinä tarvitse lähettää postia *@mapy.fi -osoitteista *@mapy.fi -osoitteisiin palveluiden välillä. Edelleenohjauksen lähettäjäosoite tulee aina olemaan *@mapy.fi, mutta vastaanottajaosoite ei.

Tarkoittaako tämä sitten sitä, että organisaatiolle tulee hankkia toinen toimialuenimi (domain-nimi) tätä käyttötarkoitusta varten? Onneksi ei. Sekä Office 365 että G Suite sisältävät oletustoimialuenimen, joka luodaan aina palvelun käyttöönoton yhteydessä:

Office 365: *@mapyfi.onmicrosoft.com
G Suite: *@mapy.fi.test-google-a.com

Tulemme siis toteuttamaan sähköpostin reitityksen palvelujen välillä seuraavasti:

# Viestien lähettäminen G Suitesta Office 365:een:
markus.pyharanta@mapy.fi --> markus.pyharanta@mapyfi.onmicrosoft.com

# Viestien lähettäminen Office 365:stä G Suiteen:
markus.pyharanta@mapy.fi --> markus.pyharanta@mapy.fi.test-google-a.com

Teams-kokouskutsun reitittäminen organisaation sisäiseltä käyttäjältä itselleni tulisi siis toimimaan seuraavasti:

Teams-kokouskutsun vastaanottaminen organisaation ulkopuoliselta käyttäjältä itselleni tulisi taas toimimaan näin:

Tarvittavat toimenpiteet:

1) Alias-sähköpostiosoitteiden määrittäminen
2) Nimipalvelumuutokset
3) Edelleenohjauksen käyttöönotto G Suitessa
4) Edelleenohjauksen käyttöönotto Office 365:ssä
5) Testaus

1) Alias-sähköpostiosoitteiden määrittäminen

G Suite:

G Suite luo jokaiselle käyttäjälle automaattisesti alias-sähköpostiosoitteen muotoa: *@mapy.fi.test-google-a.com. G Suiten osalta meidän ei siis käytännössä tarvitse tehdä mitään, mutta voimme varmistaa, että käyttäjillä on varmasti kyseinen alias seuraavasti:

1) Kirjaudutaan organisaation G Suite -hallintakeskukseen hallintatunnuksilla https://admin.google.com/

2) Navigoidaan: Käyttäjät > valitaan haluttu käyttäjä > Käyttäjätiedot > Sähköpostialiakset. Samassa yhteydessä, jossa voimme lisätä uuden aliaksen, näemme tilille jo valmiiksi määritetyt alias-osoitteet:

Kuten kuvasta huomaamme, käyttäjällä on jo valmiiksi alias-osoite markus.pyharanta@mapy.fi.test-google-a.com. Osoite on lisätty automaattisesti, kun lisensoitu käyttäjätili luotiin G Suiteen.

Office 365:

Office 365 ei luo jokaiselle käyttäjälle automaattisesti alias-sähköpostiosoitetta muotoa *@mapyfi.onmicrosoft.com. Jos käyttäjä on luotu *@mapy.fi -osoitteella, aliasta ei automaattisesti luoda. Siksi se tulee lisätä manuaalisesti.

1) Kirjaudutaan organisaation Office 365 -hallintakeskukseen hallintatunnuksilla https://admin.microsoft.com/

2) Navigoidaan: Käyttäjät > Aktiiviset käyttäjät > valitaan haluttu käyttäjä > kohdassa “Tunnukset” valitaan Hallinnoi sähköpostitunnuksia > Lisää tunnus > etunimi.sukunimi@mapyfi.onmicrosoft.com > Tallenna muutokset

Sama voidaan vaihtoehtoisesti toteuttaa myös Exchange Onlinen -hallinnasta seuraavasti:

1) Kirjaudutaan organisaation Exchange Online -hallintakeskukseen hallintatunnuksilla https://outlook.office365.com/ecp/

2) Navigoidaan: Vastaanottajat > Postilaatikot > valitaan haluttu postilaatikko > Muokkaa > Sähköpostiosoite > Lisää > Sähköpostiosoitteen tyyppi: SMTP > Sähköpostiosoite: etunimi.sukunimi@mapyfi.onmicrosoft.com > OK > Tallenna.

Exchange Online -hallintakeskuksen näkymä sähköpostiosoitteista toimii siten, että ensijaisena osoitteena on se lihavoitu osoite, jossa teksti “SMTP” on isoin kirjaimin, eli:

SMTP markus.pyharanta@mapy.fi = ensisijainen SMTP-osoite
smtp markus.pyharanta@mapyfi.onmicrosoft.com = alias

Nyt, kun käyttäjillä on molemmissa palveluissa määritetty alias-osoitteet, voimme siirtyä seuraavaan vaiheeseen.

2) Nimipalvelumuutokset

Nimipalvelumuutokset ovat jo MX-tietueiden osalta kunnossa, eikä niihin tarvita muutoksia. Organisaatio on itse vastuussa oman mapy.fi -toimialuenimensä nimipalvelutietueista, mutta mapy.fi.test-google-a.com ja mapyfi.onmicrosoft.com -nimien tietueisiin ei voida vaikuttaa. MX-tietueet osoittavat nyt seuraavaa:

Toimialuenimi: mapy.fi

@ 10800 IN MX 1 ASPMX.L.GOOGLE.COM.
@ 10800 IN MX 5 ALT1.ASPMX.L.GOOGLE.COM.
@ 10800 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
@ 10800 IN MX 10 ALT3.ASPMX.L.GOOGLE.COM.
@ 10800 IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.

Toimialuenimi: mapy.fi.test-google-a.com

@ 86400 IN MX 5 GMAIL-SMTP-IN.L.GOOGLE.COM.

Toimialuenimi: mapyfi.onmicrosoft.com

@ 3600 IN MX 0 MAPYFI.MAIL.PROTECTION.OUTLOOK.COM.

Mitä siis tulee muuttaa? Koska organisaation on aiemmin käyttänyt sähköpostipalveluinaan vain G Suitea, ei Office 365 -palvelua ole todennäköisesti sallittu SPF-tietueessa sallituksi lähettäjäksi. Muokataan mapy.fi -toimialuenimen SPF-tietueeseen yksi mekanismi lisää:

include:spf.protection.outlook.com

Organisaation SPF-tietue näyttää tällä hetkellä siis seuraavalta:

@ 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Muutoksella pyritään välttämään sitä, että Office 365:stä *@mapy.fi -osoitteista lähetetyt Teams-kokouskutsut eivät tule päätymään vastaanottaja-organisaation sähköpostipalvelimella roskapostiin. Ilman muutosta Google olisi ainoa sallittu lähettäjä, jolloin SPF-tietueen “~all” -täytäntöönpanosääntö otettaisiin käyttöön, mikä johtaisi Soft Fail -tilanteeseen ja viestien merkitsemiseksi vastaanottajan päässä. Viestien lopullinen kohtalo riippuu kuitenkin kokonaan vastaanottavan palvelimen tavasta käsitellä SPF-tarkistuksia ja niiden tuloksia, mutta muutoksen myötä viestit eivät tule ainakaan SPF:n vuoksi päätymään roskapostiksi, kun ne lähtevät Office 365:stä.

3) Edelleenohjauksen käyttöönotto G Suitessa

Edelleenohjaus laitetaan G Suitesta päälle ylläpitäjien toimesta. Edelleenohjaus on toteutettavissa monella tapaa. Itse käytän tässä yhteydessä niin sanottua User-Level Routing:ia. Etuna on se, että tapa on toteutettavissa suoraan yhdestä paikasta kaikille käyttäjille, eikä käyttäjien postilaatikkojen asetuksia tule muuttaa käyttäjäkohtaisesti erikseen.

Tulemme siis osoittamaan käyttäjien G Suiten etunimi.sukunimi@mapy.fi -osoitteet Office 365:n etunimi.sukunimi@mapyfi.onmicrosoft.com -osoitteisiin ja määrittämään kaiken saapuvan liikenteen edelleenohjattavaksi sinne automaattisesti.

1) Kirjaudutaan organisaation G Suite -hallintakeskukseen hallintatunnuksilla https://admin.google.com/

2) Navigoidaan: Sovellukset > G Suite > Gmail > Lisäasetukset > Kohdassa “Reititys” > Vastaanottajan osoitekartta > Muokkaa

3) Annetaan osoitekartalle kuvaus, esimerkiksi “Edelleenlähetetään käyttäjien sähköpostit *@mapyfi.onmicrosoft.com -osoitteisiin Office 365:een”

4) Määritetään kohdassa 1. “Viestit, joita koskee” arvoksi: Kaikki saapuvat viestit

5) Määritetään kohdassa 2. “Reititysasetukset” täppä ruutuun “Reititä myös alkuperäiseen kohteeseen“. Tämä on tärkeä valinta muistaa ottaa käyttöön, sillä muuten kaikki MX-tietueiden perusteella G Suiteen reititetty saapuva sähköpostiliikenne ohjataan pelkästään Office 365:een, eikä viesteistä jää kopioita vastaanottajan G Suite -sähköpostilaatikkoon, jota organisaatiossa ensisijaisesti käytetään!

6) Määritetään kohdassa 3. osoitekartta, jossa *@mapy.fi -osoitteet osoitetaan *@mapyfi.onmicrosoft.com -osoitteisiin. Painetaan Lisää ja syötetään kunkin G Suite -käyttäjän osoitteet pilkulla erotettuna seuraavasti:

<ensisijainen osoite>, <Office 365:n toissijainen alias-osoite>

Eli käytännössä esimerkiksi:

markus.pyharanta@mapy.fi, markus.pyharanta@mapyfi.onmicrosoft.com

Asetusten tulisi siis näyttää seuraavalta:

7) Valitaan Asetuksen lisääminen > Tallenna

Kun muutokset on tallennettu, tulisi asetuksen yhteenvedon osoitemääritysten lukumäärän vastata organisaation käyttäjälukumäärän kanssa.

Muuta ei G Suiten puolella tarvitse enää tehdä. Edelleenohjaus on nyt käyttöönotettu. Tulee tosin huomioida, että asetus ei välttämättä tule välittömästi voimaan, eli kannattaa odottaa jonkin aikaa ennen testausta.

4) Edelleenohjauksen käyttöönotto office 365:ssä

Edelleenohjaus laitetaan Office 365:stä päälle ylläpitäjien toimesta. Jos muutos halutaan tehdä graafisen käyttöliittymän kautta, on edelleenohjaus työläämpää kuin G Suitessa, sillä jokainen ulkoinen osoite tulee ensin luoda Exchange Onlinessa sähköpostin yhteystiedoksi (mail contact), ennen kuin se voidaan valita edelleenohjauksen kohdeosoitteeksi. Kuvaan lopussa vielä, miten edelleenohjaus voidaan toteuttaa PowerShellissä järkevämmin.

1) Kirjaudutaan organisaation Exchange Online -hallintakeskukseen hallintatunnuksilla https://outlook.office365.com/ecp/

2) Navigoidaan: Vastaanottajat > Yhteystiedot > Uusi > Sähköpostiyhteystieto

3) Määritetään yhteystiedon tiedot seuraavasti:

Näyttönimi: Markus Pyhäranta G Suite (secondary alias)
Sähköpostitunnus: markus.pyharanta
Ulkoinen sähköpostiosoite: markus.pyharanta@mapy.fi.test-google-a.com

4) Painetaan Tallenna ja muokataan vielä sen jälkeen juuri äsken lisättyä yhteystietoa.

5) Laitetaan täppä valintaan “Piilota osoiteluettelosta“, sillä emme halua näitä edelleenohjausosoitteita näkymään Outlookin osoitteistossa.

Sama toimenpide tulee tehdä jokaisen käyttäjän *@mapy.fi.test-google-a.com -osoitteiden lisäämiseksi. Sähköpostiyhteystietojen lisäämisen jälkeen voimme siirtyä edelleenohjauksen määrittämiseen.

6) Navigoidaan samassa Exchange Online -hallintakeskuksessa: Vastaanottajat > Postilaatikot > valitaan haluttu postilaatikko > Muokkaa > Postilaatikon ominaisuudet > kohdassa “Postinkulku” > Muokkaa tietoja

7) Laitetaan täppä valintaan “Ota edelleenohjaus käyttöön”

8) Määritetään vastaanottajaksi juuri luotu sähköpostin yhteystieto “Markus Pyhäranta G Suite (secondary alias)”

9) Laitetaan täppä valintaan “Toimita viesti sekä edelleenlähetysosoitteeseen että postilaatikkoon“. Tämä siksi, että haluamme viestien ja kalenterimerkintöjen näkyvän myös käyttäjän Office 365:n sähköpostilaatikossa ja sen kalenterissa.

10) Painetaan OK > Tallenna.

Edelleenohjaus on nyt luotu, ja se tulee voimaan pienellä viiveellä. Sama toimenpide edelleenohjauksen määrittämiseksi tulee tehdä jokaisen organisaation käyttäjän sähköpostilaatikolle erikseen.

Vaihtoehtoinen ja parempi tapa:

Sama muutos voidaan tehdä myös PowerShellissä, jolloin sähköpostiyhteystietoa ei tarvitse luoda. Jos Exchange Onlineen yhdistäminen PowerShellissä ei ole tuttua, kannattaa vilkaista esimerkiksi: https://markuspyharanta.com/2019/11/03/office-365-exchange-online-palveluun-yhdistaminen-powershellilla-mfa-tunnistautumisen-kanssa/

# Otetaan yhteys Exchange Onlineen
Connect-EXOPSSession

# Otetaan edelleenohjaus käyttöön ja säilytetään myös sähköpostiviestien paikalliset kopiot
Set-Mailbox -Identity markus.pyharanta@mapy.fi -DeliverToMailboxAndForward $true -ForwardingSMTPAddress markus.pyharanta@mapy.fi.test-google-a.com

Jos edelleenohjaus määritetään -ForwardingSMTPAddress -parametrin kanssa, ei yhteystietoa tarvitse lisätä etukäteen. Jos taas käytettäisiin parametria -ForwardingAddress, yhteystieto pitäisi ensin lisätä tenanttiin.

5) Testaus

Edelleenohjaus on nyt määritetty molempien palveluiden päässä, ja viestit tulevat reitittymään seuraavasti:

# Viestien lähettäminen G Suitesta Office 365:een: 
markus.pyharanta@mapy.fi --> markus.pyharanta@mapyfi.onmicrosoft.com 

# Viestien lähettäminen Office 365:stä G Suiteen: 
markus.pyharanta@mapy.fi --> markus.pyharanta@mapy.fi.test-google-a.com

Testasin ratkaisua kolmella eri käyttäjällä, joista kaksi oli saman mapy.fi -organisaation sisäisiä käyttäjiä ja yksi oli organisaation ulkopuolinen käyttäjä. Kuvasin havaintoni Excel-taulukkoon. Ensimmäinen taulukko esittää, mihin kaikkiin omiin postilaatikoihini ja kalentereihin Teams-kokouskutsu/-kalenterimerkintä päätyi. Toinen taulukko taas esittää, mihin kaikkiin postilaatikoihin ja kalentereihin Teams-kokouskutsu/-kalenterimerkintä päätyi kokouskutsun toisella osapuolella.

Sekä G Suiten että Office 365:n kalenterit ovat riippuvaisia samassa palvelusta toimivasta sähköpostilaatikosta. Siksi kalenterimerkintä tulee lähtökohtaisesti olemaan myös sähköpostilaatikossa, vaikkei sen saapuneet-kansioon päätyisikään erillistä kokouskutsua.

Mainitsin tämän artikkelin alussa organisaation Teams-käytössä havaitut kaksi ongelmaa: