Az első és második részben már a mélyére ástunk, hogy milyen részletekre kell odafigyelni levelezésünk migrálása esetén. A sor végtelen, íme még néhány érdekes részlet:

SPF rekord:

Trükkös, mert az Office 365 csak azt jelzi ki, hogy mire van NEKI szüksége. De vajon mire van szüksége az ügyfélnek? Tapasztalt migrációs szakemberekként tudjuk, hogy az átállás előkészítése során nem írjuk felül a meglévő SPF rekord, ha egyáltalán van, hanem csak kiegészítjük az O365 igényekkel. Még fontosabb kérdés ez, ha nem volt eddig SPF rekord. Ugyanis a SPAM elleni védekezésben részt vevő SPF rekord úgy működik, hogy nagyobb baj, ha van SPF rekord és NINCS benne a meglévő levelező szerver IP címe, mintha egyáltalán nincs SPF rekordunk. Kínos pillanatokat szerezhet magának az az úgynevezett szakember, aki az átállás előkészítése során legyártja az SPF rekordot, amiben csak az O365 által igényelt rekord érték van benne, és az átállás pillanatáig az ügyfél kiküldött levelei „érthetetlen” módon Levélszemétbe érkeznek.

SRV rekordok:

Azt mondanám, 10-ből 9x nem sikerül ezt senkinek beállítani, így sokan meg sem próbálják. A szerencse a szerencsétlenségben, hogy nem kritikusan fontos dolog ez, és sokan (kezdetben) nem is használják a Skype for Business-t. Azért ne vegyük fél vállról, mert pl. ha elengedjük a kezét az ügyfélnek migráció után, és később liszensz upgrade keretében elkezdenék használni a Skype for Businesst, akkor nem fogják érteni, miért nem működik rendesen.

E-mail migráció

A fenti leírás elsősorban az E-mail migrációs projekt folyamat DNS rekord kezelésével kapcsolatos témakört részletezi, más folyamat lépéseket nem. Maga az E-mail migráció az ügyfél igényeitől és az alkalmazott migrációs megoldástól függően változik mind a lépéseket, mind azok sorrendjét illetően. IMAP migráció esetén a folyamat elején hozzuk létre a Tenantot, készítjük el szerkezetkészre, melynek része a DNS rekord kezelés is, majd végzünk IMAP migrációt, utána pedig foglalkozunk a munkaállomásokkal, úgy mint telepítés, e-mail profil beállítás, kiegészítő kliens oldali PST migráció, stb. Exchange migrációnál nem készítjük el szerkezetkészre a Tenantot, mivel maga a tartalom migrációja készíti el postafiókokat, hanem utólag, a delta szinkron szétkapcsolását követően fejezzük be a Tenantban az Exchange Online objektumok létrehozását, módosítását, stb. Azonban a DNS rekordok kezelése mindkét típusú migrációs folyamat esetén egyforma.