Office 365 vs Exchange vs IMAP

Office365

Mai témánk ugyancsak sokakat érint, nagyon gyakran merül fel ügyfeleknél, hogy miért lenne érdemes a hagyományos küld/továbbít/válaszol típusú levelezőrendszerek helyett profi, vállalati szintű levelezést használni. Igyekszünk most a leggyakoribb kérdésekre választ adni és egyben segíteni a cégvezetőket a döntések meghozatalában, amikor felmerül bennük, hogy a néhány alapfunkción felül szeretnének végre 21. századi informatikai megoldást használni.

Office365

Először is kezdjük bevezetésként a különböző protokollok magyarázatával. Ha levelezésünket szolgáltatótól béreljük, mondjuk az internet előfizetéshez kapjuk vagy webtárhely szolgáltatás mellé, akkor azok jellemzően POP3 vagy IMAP protokollal érhetőek el. Ezen felül legtöbbször van lehetőségünk webes felületen is levelezni, ezt hívják webmail-nek. A POP3 protokoll úgy működik, hogy a levélszerverről letölti a leveleket a gépünkre és hacsak nem állítjuk be a levelezőprogramnak, hogy tartson a szerveren másolatot a levelekből (x napig, vagy amíg nem ürítjük ki őket a kukából), a letöltést követően törölni fogja őket a szerverről. Ez akkor jó, hogyha nagyon kis méretű a levélfiókunk a szerveren, mert a leveleket így nem ott tároljuk. Ebből a működésből eredően viszont egy halom problémát is kapunk a nyakunkba, úgy is mondhatjuk, hogy a POP3 előnyeinek a felsorolása itt véget is ért. Egyrészt esélyünk sincs a kimenő leveleinket egyszerre több helyen, több eszközön szinkronizálni, mert azok csak helyileg a gépen lesznek meg, másrészt a tárolás helyéből adódóan a leveleink adatvesztésnek vannak kitéve. Nagyon kevesen vannak, akik rendszeresen mentik az ilyen típusú levelezésüket, aki igen, az sem napi szinten, tehát egy vírustámadásból vagy hardver hibából eredő adatvesztést kockáztatnak minden pillanatban. Ezen problémák kiküszöbölésére találták ki az IMAP protokollt, ami szintén hoz létre másolatot a gépünkre a mappákból, de azok tartalmát meghagyja közben a szerveren is. Ebből kifolyólag kellő méretű levélfiókot igényel a szerveren, cserébe viszont másolatban legalább két helyen megvannak a leveleink és ha jól állítjuk be a levelező programot, akkor a kimenő levelek is feltöltődnek a szerverre, így például amikor szükségünk van bárhol a levélszerveren tárolt levelekre, akkor a webes felületen a levelezőprogramból elküldött leveleinket is látni fogjuk. Ugyanígy megoldható az is, hogy mondjuk az asztali gépen küldött leveleinket a következő pillanatban a telefonunkon beállított levelező kimenő mappájában is lássuk és fordítva. Ezzel ugyan sok problémánk megoldódott és kibővültek a lehetőségek, de önmagában az IMAP-pal csak a rövid bevezetőben említett funkciókat kaptuk meg.

Exchange Server 2016
Exchange Server 2016

Itt jön képbe az Exchange, ami a Microsoft levelezőrendszere és amivel jelentősen kibővülnek a lehetőségeink. Mielőtt belevágok az előnyeibe itt fontos megjegyezni, hogy nem csak ez a rendszer létezik természetesen a hagyományos IMAP alapú, jellemzően linuxos levelezőrendszerek után, hanem még nagyon sok másik, többek közt ott van a Google-féle GSuite vagy a szintén sokak által ismert Zimbra. A GSuite is nagyon népszerű, ennek a cikknek a témája mégis az Exchange lesz, mert egyrészt a legelterjedtebb és a legismertebb vállalati levelező megoldás, másrészt az Office csomagnak és a rengeteg egymásra épülő, csoportmunkát támogató szoftvernek köszönhetően ma a legkomplexebb megoldást nyújtja a vállalatok számára.

Először is kezdjük az összehasonlítást az IMAP és az Exchange rendszer között. Az IMAP lényegében egy szinkronizálási protokoll, az Exchange egy levelező rendszer, aminek szintén van egy ilyen protokollja, korábban ActiveSync-nek hívták, ma már egy továbbfejlesztett változata működik, a MAPI. Míg az IMAP esetében csak leveleket, mappákat szinkronizálunk a levélszerverrel, illetve címlistákat is lehetőségünk van, önmagában más funkciót nem lát el. További gyakori probléma az IMAP esetében, hogy nincs szabványosítás, tehát például egy adott linuxos levelezőrendszer Sent mappát nyit az elküldött elemeknek, egy másik sent itemsnek hívja, ahogy magyarul lehet elküldött, elküldött elemek, elküldött levelek is. Amikor például egy Thunderbird levelezőprogramot beállítunk alapbeállításokkal IMAP-pal, akkor a levélszerveren a sent mappába fogja rakni a kimenő leveleinket, amit mondjuk az Android-os telefonon nem fogunk a kimenő mappában látni, mert az pedig a sent items-be fog dolgozni és el fog térni a két kimenő mappa, így valamelyiket rá kell manuálisan venni, hogy oda dolgozzon, ahova a másik. Exchange esetében ilyen problémákba nem fogunk futni, mert ezek a dolgok szabványosítva vannak, amikor a levelezőprogram az Exchange által használt ActiveSync/MAPI protokollal szinkronizál az ugyanazt a kimenő, ugyanazt a levélszemét és ugyanazt a piszkozat mappát fogja használni. Az igazi előnye ennek a rendszernek mégsem ez, hanem az a rengeteg funkció, amit kínál. Lehetőség van például kategorizálni, színkódolni, megjelölni és feladatlistába tenni dolgokat, naptárbejegyzéseket létrehozni, amit aztán a mobileszközökre a megfelelő alkalmazásokba is képes szinkronizálni a rendszer. Össze lehet hívni értekezleteket, vagy meghívót küldeni, amit a másiknak igen/nem válasszal el kell fogadni, ha elfogadta beírja automatikusan a naptárba. A naptáraknál nagyon részletesen személyre lehet szabni, jogosultságokat lehet adni ki mit láthat, lehet létrehozni közös naptárakat és rengeteg ehhez kapcsolódó plusz funkció érhető el. Lehet csatolni megosztott postafiókokat, olyan levélcímekkel, amiket több felhasználó olvashat egyszerre, és ami nem szimplán másolatot küld minden levélről. Tehát ha a másik olvasta, ha válaszolt rá, minden látszik és a megosztott fiók nevében is van lehetőség levelet írni. Hatalmas előnye ezeknek a rendszereknek az adatbiztonság is, a szerveren beállított adatmegőrzési idő lejártáig a törölt elemekből is kiürített leveleket is van lehetőség visszaállítani, anélkül, hogy a rendszergazdának a mentéshez kéne nyúlnia. A mai Exchange rendszerek webes felülete pedig önmagában is kiválóan alkalmas munkára, asztali alkalmazás nélkül is szinte minden hasznos funkciót elérhetünk egyenesen a webről. Ma már online Office használatára is lehetőség van, ami azt jelenti, hogy a levélben kapott Office dokumentumokat akár írásra is meg tudjuk nyitni online, természetesen a legismertebb formátumokat, képeket, PDF-et, szövegeket ugyancsak meg tudjuk tekinteni a fájl letöltése nélkül is. Általánosságban elmondható, hogy rengeteg hasznos, a csoportmunkát és az informatikai rendszer hatékonyságát nagyban növelő funkciók egész sorával van tele, a billentyűzetem is elkopna, ha mindet részletesen fel kéne sorolnom. Sokan mindaddig nem tudják mennyi hasznos funkciót nem használnak ki nap, mint nap, amíg ki nem próbálják. Több helyen vezettünk úgy be ilyen levelezőrendszert, hogy a felhasználók egy része, volt ahol a többsége ellenségesen fogadta, illetve voltak olyan hangok, hogy nekem bőven elég az a néhány alapfunkció. Aztán gyakran ezek az emberek voltak, akik már az átállás ideje alatt elkezdték piros zászlóval jelölni a leveleket és a teendő listába tenni, színkódolni vagy éppen a nagyon hasznos kis „rajzszög” funkcióval rögzíteni a levelet a bejövő mappa tetejére. Aztán másnap már ők tették fel elsők közt az újdonságokra vonatkozó legtöbb kérdést és nagyon rövid idő alatt ismerték ki maguktól a rendszer újdonságait és ma már ők lennének a leghangosabbak, ha vissza akarnánk őket vezetni a régi fapados időkbe.

Hozzá kell azt is tenni, hogy egy Exchange rendszer ma nem olcsó. A terméklicencek önmagában is borsosak és nehezen megfizethetőek egy kisebb cégnek, nem beszélve arról, hogy igen komoly hardver kell alá és szükség van a telepítéséhez, üzemeltetéséhez és a meglévő levelező rendszerről történő átálláshoz is nem kevés szakértelemre. Természetesen ahány ügyfél annyi féle megtérülés és annyi féle költség számítás létezik, de egy alkalommal évekkel ezelőtt utána számoltunk és megdöbbentő eredményre jutottunk. Egy nagyobb rendszer esetében (kb. 250 e-mail fiók, 300-400GB összkapacitással) kértek ajánlatot a régi elavult rendszerük cseréjére. Az akkori legfrissebb Exchange-re megadtuk az árakat, amiben benne volt a terméklicenc díja mellett a szükséges hardver és a meglévő rendszerükről történő átállás munkadíja is. Mivel egy széles körben elterjedt rendszerről volt szó így számos fizetős szoftver elérhető volt az interneten, azok közül is egynek a demo verzióját ki is próbáltuk, kb. 100 ezer forintból megoldotta volna a meglévő levelezés migrálását fiókról fiókra egy új Exchange rendszerbe. A másik oldalon egy olyan ajánlat szerepelt az ügyfél előtt, ami linuxos levelezőre épített, licenc költségek nélkül és már induláskor is igen magas átállási munkadíj költségekkel. Összességében az ajánlat kedvezőbbnek tűnt viszont a szoftverlicencek ingyenessége miatt és a döntéshozók előtt is az a szempont lebegett, hogy a legtöbben úgyis csak az alapfeladatokat használják, néhány ember kedvéért nem vesznek drága rendszert. Végül az elhúzódó átállás miatt 20-25%-al magasabb lett a linuxos levelező ára, aminek később a fenntartása is jóval több munkával járt, mire 4-5 évre rá ismét megkeresett minket az ügyfél és megrendelte az Exchange-re átállást, amivel végeredményben jobban járt és évek óta nagy megelégedéssel használja. A legelső alkalommal viszont készült egy nagyon tanulságos számítás, ami úgy nézett ki, hogy dolgozónként napi 5 percet számoltunk, annyit veszít el a munkaidejéből a fapados rendszer használhatatlansága miatt vagy éppen egyes funkciók hiánya miatt. Elég volt csak napi 5 perccel számolnunk és az akkori minimálbérrel mégis az jött ki, hogy kb. 1 év alatt térül meg a szoftverlicenc ára. Mivel egy ilyen rendszer kb. 5-6 évig használható mire át kell térni a legújabb verzióra, így bőven van ideje megtérülni. Viszont ma már befektetni sem kell vagyonokat, mert itt a lehetőség még tovább fejlődni Office 365-tel.

Azt hiszem felhőről ma már mindenki hallott, nem kell a fogalmat magyarázzam. Az Office 365 a Microsoft felhőszolgáltatása, egy havidíjas alapon bérelhető Exchange, pontosabban jóval több annál. Ugyanis ahogy a nevéből is kitűnik egy nagy Office csomagot kapunk a pénzünkért, ami magában foglal egy Exchange levélfiókot is 50GB tárhellyel. Van belőle sok fajta licenc, olyan is ami lehetővé tesz nekünk az asztali gépre letelepített Office használatot és olyan is, ami csak online enged nekünk minden Microsoft technikát használni. Az 50GB-os Exchange levélfiókon és a webes Outlook felületen kívül még találkozhatunk a népszerű Office programok online (böngészőből futó) változataival, de a Word/Excel/Powerpoint mellett ma már több tucatnyi egyéb hasznos csoportmunka és vállalati kommunikációs szoftver is elérhető, ezek közül is kettőt emelnék ki, a Skype for Business-t (vagy újabb nevén Teams-et), illetve a szintén komoly erőforrásokat és licenc költségeket jelentő csoportmunka szoftvert, a Sharepoint-ot, aminek online változata szintén rendelkezésre áll. Ezen felül még ami nagyon fontos, hogy az adatok online tárolásához kapunk még 1TB OneDrive tárhelyet is. Egy ilyen komplett csomagnak a listaára pedig jelen pillanatban 4,2 EURO havonta, ami gyakorlatilag aprópénz ahhoz képest, amennyi funkciót és ami lehetőséget ad a dolgozóknak nap, mint nap. Úgy is felfoghatjuk, hogy egy átlagos magyar fizetéssel rendelkező dolgozónk kb. 1 órányi bérébe kerül havonta, amennyi segítséget ad az viszont nem havi egy órával fogja növelni az Ő hatékonyságát. Szinte napi rendszerességgel kapjuk meg azt is kérdésként, hogy megéri-e olyan Office 365 licencet venni, ami helyi Office telepítését és használatát adja, havidíjas alapon. Önmagában hogyha valaki csak az Office használata miatt veszi, akkor azt szoktuk mondani, hogy ne tegye. Kb. 60 ezer nettó körül lehet kapni a legkisebb, vállalati környezetben is használható csomagot, míg egy ilyen Office 365 csomag havidíja 15 EURO körül van, ami azt jelenti, hogy kb. 1 év alatt kifizetjük annak az Office licencnek az árát, ami egyébként 5-6 évig kiszolgál minket. Egyetlen kivétel van csak, amikor ilyen Office vásárlása jó alternatíva, amikor projekt munkára alkalmaz a cég valakit és néhány hónapra szükség van egy Office csomagra. Ezen kívül csak akkor érdemes valakinek ebben gondolkodnia, hogyha a mellette lévő szolgáltatásokat is tervezi használni, mint például a OneDrive tárhelyet, Sharepoint-ot, egyebeket.

Apps

Az átállás és az egyéb költségek kapcsán is elmondható, hogy egy hagyományos IMAP-os levelezőből történő átállás az Office 365 esetében a legegyszerűbb és a legrugalmasabb is. A webes admin felületen van lehetőség a korábbi szolgáltató IMAP szerveréről egyenesen átszinkronizálni a leveleket, a szerver elérési adatok megadását követően. Ahol ez bármi miatt nem lehetséges ott szükség van némi szakértelemre, és a korábban használt Outlook-ra vagy egyéb IMAP-os levelezőprogramra. A régi és az új levélfiókot egymás mellé beállítva apránként át lehet pakolni a levelezést, ami inkább időigényes és sok odafigyelést igénylő feladat, de egyáltalán nem bonyolult. Így hát bátran merem javasolni bárkinek, hogy nyugodtan vágjon bele akár saját Exchange rendszer építésébe, akár a levelezés Office 365-be migrálásába, mert nem csak hosszú távon, már igen hamar meg fog térülni. A hatékonyságot leginkább növelő megoldás, legyen szó Exchange-ről vagy a még több alkalmazást magába foglaló Office 365-ről.

Végezetül említenék még egy levelezéssel kapcsolatos rémálmot, amit az Office 365 megold nekünk. Az pedig a spamszűrés. Jellemzően a kisebb szolgáltatók vagy akiktől csatolt szolgáltatásként kapjuk a levélfiókunkat azok nem fognak nekünk profi szűrő megoldásokat adni. Magyarul elönt minket a spam, ami sokaknak ismerős lehet. Ez saját levelezőszervernél is komoly fejtörést jelent, akár egy saját Exchange esetében is, mert azt a tudást, ami alapján hatékonyan fel lehet a jelenség ellen lépni bizony licencelni kell, valakinek fizetni kell érte, hogy segítsen kiszűrni nekünk a kéretlen leveleket. Nyilván egy nagy szolgáltató esetében ez könnyebben megy, mert nagyobb mintából tud dolgozni, amikor 1 perc alatt a sokadik ügyfele kapná ugyanazt a spam levelet, akkor el tudja kezdeni blokkolni, egy ilyen esetben nekünk viszont az összes címünk spam-et kap egy saját rendszeren. Az eddigi tapasztalat alapján nyugodtan ki merem jelenteni, hogy a levélszemét szűrését a nagyok közül is az Office 365 oldja meg a legprofibban, ha nekem kéne döntenem, hogy céges levelezésként mit vezessek be már önmagában ezért kifizetném, amit elkérnek érte. Itt pedig visszautalnék a korábbi gondolatmenetre is, hogyha egy másik szolgáltatást használok, amiben elöntenek a spam-ek és naponta csak pár percet foglalkozok ezek törölgetésével, akkor az hosszabb távon mennyi erőforrásomat fogja lekötni? Lehet így nézve már nem is kérnek olyan sokat érte?

Azok számára pedig, akik karbantartási szerződésben gondolkoznak van egy külön jó hírem. Az Office 365 már elérhető nálunk olyan formában is, amikor az átalánydíjas karbantartás keretében a havidíjba beépítve mi biztosítjuk a licenceket. Így nem kell külön bonyolítani a licencek könyvelését, a fizetését, a különböző változásokat lekövetni. Egyszerűen csak használni kell a jelenleg elérhető legjobb és leghatékonyabb vállalati megoldást.

Problémamentes átállás Exchange 2010-ről 2016-ra

2018. nyarán kaptunk felkérést nagyvállalati ügyfelünktől, akivel korábban már több nagyobb projekten sikeresen dolgoztunk együtt. Korábban teljeskörű IT auditot végeztünk náluk, ezt követően a szerver rendszerük korszerűsítését és rendberakását, a korábbi Windows Server-es problémáik megoldását is sikerrel elvégeztük. A munka kezdetét egy alapos tervezés, majd az új Dell PowerEdge szerver és a szükséges szoftverlicencek beszerzése követte. Miután ezzel megvoltunk következhetett a tényleges átállás dátumának kitűzése és az előkészületek. Mivel Exchange átállásról, postafiókok migrálásáról volt szó, amivel korábban már számos tapasztalattal rendelkeztünk, így pontosan tisztában voltunk vele, hogy milyen sebességű adatmozgással lehet számolni. Ügyfelünk telephelyén gyakorlatilag a hét minden napján zajlik valamilyen termelő tevékenység, így nagyon fontos volt az átállást a legapróbb részletekig megtervezni, hogy minél kisebb leállással, szolgáltatás kieséssel járjon az egész folyamat. Köszönhetően a korábban szerzett tapasztalatainknak és az alapos tervezésnek ez jobban nem is sikerülhetett volna, de ne szaladjunk ennyire előre…

Exchange Server 2016

Mivel a tervezési folyamat kezdetekor igen jelentős mennyiségű adatról volt szó, ami akár egy teljes hétvégés átállást is igénybe vehetett volna, ismerve az Exchange fiók migráció tempóját (a rendszert úgy tervezték, hogy olyan lassan csorgassa az adatokat, hogy közben az Exchange lassulás nélkül ki tudja szolgálni a kéréseket, tehát használat közben lehessen átállni), ugyanakkor azzal számoltunk, hogy legjobb esetben is péntek estétől hétfő reggelig mindennek át kellene érnie, hogy ne legyenek fennakadások az átállás során. Ezért az előkészítést azzal kezdtük, hogy kiexportáltuk Powershell-ből a meglévő e-mail fiókokat, majd átnézettük a listát az ügyféllel, aki megjelölte nekünk az archiválható fiókokat. Amint ez elkészült csináltunk egy teljes mentést a régi Exchange rendszerről és a levéladatbázisokról (mind a háromról), majd lejjebb vettük az adatmegőrzési időt, hogy az átállás tervezett dátumáig végleg törlésre kerüljenek az adatok. Ezután szintén Powershell-ből a törölni kívánt fiókok tartalmát kiexportáltuk PST fájlokba, majd töröltük (illetve letiltottuk, törlésre megjelöltük) a sikeresen exportált fiókokat. Ezzel a közel 500GB-os levéladatbázisokat 300GB körülre le tudtuk szorítani. Itt alkalmaztunk még egy korábban jól bevált trükköt, minden fiókhoz 1-től 5-ig kértünk egy prioritási számot, hogyha hétfő reggelre bármi miatt nem tud lefutni minden tudjuk kik azok, akiknek feltétlen működnie kell. Az 1-es prioritási csoportba kerültek azok, akiknek hétvégén is el kell tudni érni távolról a levélfiókjukat, a 2-esbe és a többibe pedig fontossági sorrendben bekerült mindenki más.

Az előkészítő munka egyik fontos eleme volt az is, hogy az Outlook kliensek verzióját ellenőrizzük, erre az új Exchange-re való problémamentes kapcsolódás miatt volt szükség. Mivel az ügyfél számára korábban telepítettünk egy WSUS rendszert, így a 2010-es és 2013-as Office rendszerekre és az Outlook-ra kiadott és még nem telepített frissítéseket rövid határidővel telepítettük a gépre és az átállás előtt gondoskodtunk róla, hogy minden gépen olyan verziójú kliens legyen fent, amely képes lesz gond nélkül dolgozni az Exchange 2016-al.

Időközben telepítésre került az új szerver, majd az Exchange 2016 virtuális gépe, a Windows Server 2016 Standard a legújabb frissítésekkel, végül a gépre előkészítettük a kezdéshez az összes szükséges telepítőt. .NET csomagot, különböző szükséges filterek és egyéb Microsoft összetevők telepítőit és természetesen a legújabb Exchange 2016 telepítőt is. Ezután a gép megkapta a telepítéshez szükséges szerepköröket és adminisztrációs eszközöket, konzolokat, így tényleg minden készen állt az Exchange telepítő indítására.

Egyetlen nappal az indulás előtt ismét teljes mentés készült az Exchange 2010-ről, majd következett a Microsoft által is javasolt eljárás, a régi szerver frissítése. Megkapta az Exchange Server is a legújabb update rollup-ot, majd a Windows is a frissítéseit. Ezután következett egy gyors ellenőrzés, minden Exchange összetevő problémamentesen üzemelt, így megkezdhette a régi rendszer az utolsó munkanapját, hogy aztán pénteken a munkaidő végeztével indulhasson az utolsó teljes mentés készítése egy külön kazettára, majd a tartományvezérlő soron kívüli mentése, ezután pedig az átállás.

Telepítettük az Exchange 2016-ot, beállítottuk rajta az alapvető küldési – és fogadási összetevőket, és amikor a gép már készen állt a munkára a tűzfalas csapat fél órán belül átállított mindent nekünk a tűzfalon, így innentől már a 2016-os szerver látta el a fő levelezési feladatot, a régi 2010 pedig mailbox szerverként üzemelt tovább, tárolva a régi levélfiókokat. Beállítottuk itt is a 3 levéladatbázist a szükséges korlátokkal, majd megkezdtük a tényleges adatmigrálást. Itt került elő ismét a bekért táblázat, az 1-es prioritási értékkel rendelkezők levélfiókjai így sikerrel elkezdték a másolást péntek este, hogy szombat reggelre már az új szerverről érjék el a leveleiket. Ismerve az Exchange trükkjeit és hogyan lehet gyorsítani a migrálási folyamatot végeztünk pár módosítást a konfiguráción, ami a másolási sebességet nem emelte meg (arra nem ad lehetőséget a Microsoft), de az egyidejűleg másolható elemek számát és az egyszerre elindítható migrálási szálak számát megemelte, ami végső soron a másolási tempó drasztikus növekedésével is járt. A végeredmény olyan jól sikerült, hogy péntek éjfél körül már a 2-es prioritási értékkel rendelkezők fiókjai kerültek elindításra, és mivel ilyenkor nekünk az ügyfél rendszere, az átállás sikeressége jelenti a legfőbb prioritást, így a munkát végző rendszergazda alvás idejét is a migrációs folyamathoz igazítjuk, az előző néhány óra statisztikája alapján pont annyi migrálási szálat indítottunk el, amennyi még egymást nem akadályozza, ideálisan fut le, de a rendszergazdának is ad kb. 8 óra alvás időt, amíg a szerverek másolnak. 🙂 Nagyjából a becslés stimmelt is, így fordulhatott az elő, hogy a 3-as prioritásúak is lementek reggelre, és a szombati reggeli elfogyasztását követően már a 4-es prioritásúakkal folytathattuk, hogy aztán az 5-ösökkel zárva a sort már szombat kora délutánra lefusson a folyamat legkritikusabb része.

Természetesen ez idő alatt számos konfigurációs feladat is elvégzésre került, többek közt a nyilvános mappák migrálásának előkészítése, az egyéb, kézzel konfigurált küldési összetevők script-elt export/importja, az új Exchange-en a levéltanúsítványok beállítása és a virtuális könyvtárak helyes beállítása, ami a mobileszközök és a távoli elérés számára fontos lépés. Így szombat késő estére az utolsó simítások is elkészülhettek, végül a távoli elérés, a webes levelező és minden fontos szolgáltatás tesztelésre került, majd a régi Exchange 2010 lebontása és eltávolítása a rendszerből szintén megtörtént. Teljes lett tehát az átállás, alig több, mint 24 óra alatt átálltunk közel 150db levélfiókkal, 300GB-nyi adattal.

A munka zárásaként vasárnap délelőtt a helyi IT csapattal közösen végig teszteltünk mindent. Néhány mobileszköz újrakonfigurálására még szükség volt, de alapjában véve a szolgáltatások rendben működtek. Hétfő reggel aztán eljött az éles teszt ideje, ahol az Outlook-ok sikerrel kapcsolódtak az új Exchange szerverre és néhány mobil átállításán és az új webes felületet leszámítva észre sem vették a felhasználók a váltást, pedig nem kevés és nem egyszerű munkák előzték meg az előtte lévő 2 napban az átállást. Természetesen a hétfői napon is személyesen jelen voltunk, hogy bármilyen felmerülő probléma esetén azonnal segíteni tudjunk a helyszínen. Szerencsére nem kellett, így egy remekül sikerült munkát zárhattunk és újabb tapasztalatokat szerezhettünk, ügyfelünk pedig újfent elégedett lehetett az elvégzett munkánkkal.

Exchange Server migrálás linuxos levelezőről

Az alábbi sikertörténet valójában két jól sikerült munkát foglal össze. Korábban több alkalommal vittünk már véghez olyan jellegű migrálást, amikor nem volt a cégnek korábban saját levelező rendszere, csak (jobb esetben) Outlook-ba beállított levelezés, (rosszabb esetben) Thunderbird vagy valami egyéb levelezőprogram, esetenként webmail. Ilyenkor általában a meglévő levelező programba a régi fiók mellé csatoltuk mindig az új fiókot és IMAP segítségével kézzel mozgattuk át a korábbi leveleket. Jobb esetben Outlook PST-ből tudtunk közvetlenül importálni egy frissen felépített Exchange rendszerbe.

Exchange Server 2016

A címben szereplő történetben ez nem így történt. Egy picit nehezebb változatát kellett elvégezni a levelezés átpakolásánál, amikor ügyfelünknél igényként felmerült a közös naptárak, értekezletek összehívása, csoportmunka funkciók, teendőlista és egy jól működő, felhasználóbarát adatszinkron (ActiveSync) igénye, így a meglévő linuxos levelezőrendszert egy minden tekintetében modernebb és barátságosabb Exchange levelezőrendszerre cseréltük. A gépek többségén Outlook levelezők voltak IMAP-pal beállítva, a lehetőség tehát itt is adott lett volna, hogy mappánként tegyük át a leveleket, azonban ez a 160-170GB körüli és 30-35 fiók közötti levelezőrendszer esetében nem lett volna járható út. A feladatra 1 hétvégénk volt, hétfőn már a kliensek átállításával kellett kezdeni, hogy a munka ne álljon le a cégnél.

Elsőként feltelepítettük az új szerver gépet, amelyen helyet kapott először egy Active Directory címtár (amellyel korábban szintén nem rendelkeztek) és egy másik virtuális gépen helyet kapott az Exchange rendszer is. Miután a felhasználókat Powershell-ből felvittük, kialakításra kerültek az időközben szintén Excel táblákba felvitt postafiókok is. Az Exchange-et bekonfiguráltuk az IMAP használatához, majd egy kimondottan a migrálás céljára létrehozott felhasználó számára hozzáférési jogot adtunk az új postafiókokra, így egyetlen név/jelszó segítségével lehetőség nyílt a migrálást elvégezni. A közös csatorna, az IMAP tehát megvolt a szerverek közt, már csak a script-eket kellett előállítani. Mivel a linuxos felhasználói fiókok listája és azok jelszavai rendelkezésre álltak, így már az imapsync telepítését követően a forrás szerveren, a linuxon kezdtük el a scripteket kialakítani. A migrálási táblázatból mentett szövegfájl tartalmazta a felhasználónév/jelszavakat, illetve a minden joggal felruházott migráló felhasználó hozzáférését, ami az Exchange oldalról biztosította a jogokat. Az adminisztrátor és néhány korábbi dolgozó levelezésével élesben teszteltük a script-eket még a hétvégét megelőzően, hogy aztán a péntek délután beköszöntével élesben is elindulhasson a script az összes felhasználó fiókján.

Természetesen nem ment ennyire simán minden, már a próba migrálások alkalmával is számos problémával kellett megküzdeni, köztük a Citrix Xen hálózatkezelési bugjával is, ami az amúgy sem túl acélos hálózati kapcsolatot folyton 10MBit-re vette le. Az éles migrálás alatt is jelentkeztek problémák, főleg az átviteli sebességekkel és az ezzel járó időtúllépési hibákkal. Egyes imapsync folyamatok a nagyobb postafiókok esetén rendre leakadtak, így volt fiók, amelyen többször is el kellett indítani a script-et, hogy végül minden átmenjen. A migrálási folyamat minden egyes száláról közben a script jelentést küldött a rendszergazdai fiókba, így folyamatosan nyomon tudtuk követni a folyamatot. Vasárnapra végül az utolsó levél is megérkezett az Exchange-be. Hozzá kell tenni, hogy ez idő alatt aki már ismerte az Exchange webes elérését, esetleg be tudta magának állítani a telefonját az új szerverre az egész idő alatt már tudott küldeni és fogadni is az új szerverről/re.

Hétfőn aztán megtörtént a gépek Windows-os tartományba való beléptetése is, majd az Outlook-ok beállításra kerültek az Exchange használatára. Már a kliensek beállításakor azt tapasztaltuk, hogy a gyakorlottabb felhasználók már az átállás alatt elkezdték használni az új rendszer nyújtotta lehetőségeket, értekezlet összehívásokat, közös naptárakat, egyebeket. A néhány Thunderbird felhasználó számára volt kicsit keserűbb az indulás, nekik végül egy ingyenes bővítmény segítségével sikerült Exchange üzemmódban beállítani a levelezést, amit nem sokkal később a bővítmény fizetőssé válásával az IMAP váltott fel, természetesen így csökkent funkcionalitással. Az átállás viszont teljes győzelemmel zárult, a régi linuxos levelező kiürült, a hétfői induláskor a küldés/fogadás már gőzerővel az új rendszerről futott, ahogyan a régi levelek is mind elérhetőek voltak az új szerveren.

Ekkor még nem tudtuk, hogy ez a munka egy remek főpróbája volt egy fél évvel későbbi nagy migrálásnak, ahol ugyanez volt a feladat, csak nagyban. 500GB levelezés és 200 körüli fiókszám. Mivel itt korábban már az Active Directory rendelkezésre állt így picit módosultak a folyamatok, de alapvetően ugyanaz zajlott. Telepítettük az Exchange Servert (ez esetben már a 2016-ot, ami nem sokkal ezelőtt jelent meg RTM változatban) és beállítottuk. Amikor minden teszt sikeres volt Excelben összeraktuk a migrálási táblát. Mivel nagyon nagy mennyiségű adatról volt szó, és a korábbi tapasztalat az volt, hogy az imapsync sebessége messze elmarad a tényleges hálózati átviteli sebességektől (jellemzően 2-3MB/sec sebességgel csorogtak az adatok a másik helyen), így a projektbe egy plusz csavart is bele kellett vinni. Mivel nem voltunk biztosak abban, hogy a péntek délután-hétfő reggel intervallumban mindent át tudunk másolni, továbbá több dolgozónak is szüksége volt a hétvégén a levelezésére, így kénytelenek voltunk felállítani egy prioritási listát. A tervezés ezen fázisa a helyi informatikával együttműködve történt. A migrálandó fiókokat tartalmazó Excel táblába létrehoztunk egy új oszlopot, prioritás. Nullás prioritás értéket kaptak azok, akiknek hétvégén szüksége van a postafiókjára, ez 2-3 felhasználót érintett. 1-est azok, akiknek hétvégén nem, de hétfőn feltétlen szükség van a levelezésére, ők voltak jellemzően a nagyobb vezetők. 2-est a kisebb vezetők kaptak, akik szintén magas prioritásúak voltak, majd következtek a kevésbé fontos felhasználók és a már nem használt, de még fontos archív leveleket tartalmazó fiókok. Ez utóbbiakat próba migrálásként már csütörtök-péntek folyamán átpakoltuk tesztelve a rendszert és a scripteket. Az 5-6-os (5 – nem fontos, 6 – archív) prioritást kapott dolgozók fiókjai voltak azok, akiknél belefér az is, hogyha a hétfői napon még nem férnek hozzá a leveleikhez. A táblázatba egy script segítségével lekérdezett levélfiók méretek is felvezetésre kerültek, így néhány Excel függvény használatával már láttuk is, hogy az adott prioritású felhasználók összesen hány GB levelezést hoznak át magukkal. Számoltunk vele, hogy IMAP-pal lassú lesz a migrálás, így a prioritásos migrálás bevezetése mellett is volt B terv, szükség is volt rá.

Péntek délutánig átmozgattuk a próbamigrálásra kijelölt fiókokat, amivel a munka néhány százaléka készült el, egyben teszteltünk mindent. Az átviteli adatok itt is adtak okot az aggodalomra, habár az előző munka során a hálózati problémákból eredő időtúllépések itt elmaradtak. Eljött a munkaidő vége, hazament mindenki, kezdődött az éles folyamat. Első körben mentek a 0-ás prioritásúak. Éjfél körül át is értek, ezzel az első és legfontosabb lépés teljesült, ők már szombat reggel tudtak dolgozni az új levelezőrendszerrel. Aztán éjfél után indultak az 1-es prioritásúak, akikből már jóval több volt, és jellemzően nagy postafiókok, így a teljes állomány kb. 25-30%-át ők adták. Szombat reggelre aztán már látszott, hogy ezzel a tempóval kb. 5-6 nap lenne a teljes migrálás, így először be kellett vetni a B, majd a C tervet is, legvégül a menet közben született D tervet is.

A B terv az volt, hogy lassú migrálás esetén a script egy apró módosításával kizárjuk a migrálásból a nagyobb méretű leveleket, azokat egy második körös migrálással pakoljuk át. A módszer működött, a nagyobb méretű csatolmányokkal rendelkező levelek ott maradtak a régi rendszeren, a script pedig lépett tovább és egyre gyorsabban pakolta át a fiókokat. A tempó azonban még így is nagyon kevés volt, becslés szerint jó esetben a 3-as prioritású fiókok végéig jutott volna csak el a script hétfő reggelre. Így eljött a C terv ideje. Ez előtte a másik helyen már kipróbálásra került, ott a hálózati sávszélesség problémája miatt kevésbé, itt szerencsére jobban működött. A két Exchange közötti migrálás adta az alapötletet, ott ugyanis beállítható a rendszerben, hogy egyszerre hány migrálási folyamatot végezzen a gép. Mivel ott a sávszélességet alapból korlátozza a rendszer (hogy közben használni is lehessen akár a levelezést), így nagy mennyiségű levélnél muszáj hozzányúlni, hogy belátható időn belül végezni tudjunk. Az imapsync esetében is működött, a fiókok adatait tartalmazó szövegfájlt több részre, több fájlra bontottuk szét és egyszerre több scriptet futtattunk. A 2 script ugyan nem jelentett 2-szeres sebességet, de kb. másfelet igen, így sokat gyorsult a folyamat. Sajnos nem eleget, így szombat estére eljött a D verzió ideje, a script-ekbe beépítettük, hogy a régebbieket ne pakolja át, csak az x időnél újabb leveleket. Ekkor már a 2-es prioritású fiókokig minden készen volt, szombat este egy újabb script az 1-2 prioritású fiókokból kihagyott nagyobb leveleket is átpakolta, így odáig teljesen meg voltunk. A 3-as prioritástól kezdődően már csak az újabb és kis méretű leveleket szedtük át. Így végül hétfő reggelre már a script-ek az 5-ös prioritással bíró fiókok utolsó leveleit pakolták át, a munkaidő kezdete környékén futtathattuk újra őket az összes fiókon, már kizárások nélkül, ami végül a 3-5 prioritású fiókokon másnap reggelre végzett csak. A jó szervezésnek köszönhetően nem hiányolt senki semmit abban az egy napban, amikor még picit hiányos levelezéssel futott a rendszer.

Itt mivel nagyrészt webes felületet engedélyezett a dolgozóknak a vezetőség, így a hétfő reggel nyugodtabban telt. A hétvége folyamán beállítottunk egy csoportházirendet, ami a felhasználók asztalára ikonként kiteszi a webes felület URL-jét, illetve ezen kívül a kedvencekbe, a start menübe is helyez el linkeket. Bár az ügyfelet felkészítettük rá lélekben, hogy hétfőn még várható leállás, minden bizonnyal nem lesz teljesen készen minden, a jó szervezésnek köszönhetően fennakadásmentesen rajtolhatott az új rendszer, aminek az extra funkcióit sokan el is kezdték még aznap használni.

Aztán kicsivel később többen jelentkeztek, hogy szükségük lenne a korábban beállított levelezőklienseikből (Outlook, Thunderbird), másoknál a webmailből az automatikus kiegészítés elemeire, illetve többen használtak névjegyeket is. Mivel senki nem tudta pontosan, hogy ki hogyan levelezik a régi rendszeren így ezeket az igényeket csak egyenként tudtuk kezelni és bár számítottunk rá és készültünk előre, nem ment simán. A régi webes levelezőt használó felhasználók adatait a Roundcube webes levelezőjük tartalmazta, annak az exportjával nem mentünk sokra. A PostgreSQL adatbázishoz hozzáférve viszont egy szerkesztő progival ki tudtuk nyerni ömlesztve az automatikus kiegészítések és címjegyzék adatait. Egy másik fájlba pedig kinyertük, hogy melyik felhasználóhoz milyen azonosító tartozik. Így volt két fájl, benne ömlesztve az adatokkal. Olyan formába kellett hozni, ami importálható, ha lehet tömegesen az Exchange-be. Kb. 1 órás munkával írtunk rá egy programot, ami szabvány XML-es formába külön-külön fájlokba elmenti felhasználónként az adatokat. Ezt a formátumot aztán egy másik, netről letölthető program már tudta olvasni és konvertálni nekünk PST-be. Amikor készen állt a rengeteg apró felhasznalonev.pst fájlunk, készült rá egy Powershell script, ami szépen betolta mindet az Exchange-be. Ezzel a webmail-esek gondja megoldódott. Az asztali levelező kliensekből érkező adatokat aztán egyesével át kellett alakítani PST-be és importálni azok számára, aki ezt kérte. Nehézkes és fáradtságos munkával, de aztán végül minden megérkezett az Exchange rendszerbe.

FlashCom Powered System

Ennek már másfél éve, az Exchange azóta is néhány apróbb hibát leszámítva közel 100%-os rendelkezésre állással üzemel és teszi a dolgát.

Facebook