Windows 7, Windows Server 2008, Exchange Server 2010 – egy korszak vége

Microsoft támogatási időszak vége 2020 - end of support

Több népszerű Microsoft szoftver is a végnapjait éli, régóta a kiterjesztett támogatás idejét töltik ezek a rendszerek és közeleg a nap, amikor ez a korlátozott támogatás is végleg megszűnik. Sokan nem mérik fel ennek a súlyát és érzik át mekkora problémával néznek szembe attól a naptól kezdve. Mivel ez a nap már nincs messze így pár gondolattal segítünk áttekinteni a problémát és megoldásokat keresni rá.

Első körben pár gondolat arról miért is fontos a támogatási időszak. Gondolom senki számára nem mondok újat azzal, hogy minden szoftverben vannak hibák, ezek közül sok olyan is, ami az adataink biztonságát ássa alá. A gépen futó operációs rendszert hackerek vagy vírusok számára támadhatóvá teszik. Ezek azok a problémák, amiket a Windows Update, a frissítési szolgáltatás hivatott betömködni biztonsági frissítések útján. Olyan rendszerek, amik támogatottak a gyártó által azok rendszerint mire egy biztonsági probléma szélesebb körben kiderül már frissítések útján javításra is kerülnek. A Microsoft ebben egyébként világelső, ahogy az operációs rendszerek piacán is, az elmúlt évtizedek alatt megedződtek a rengeteg támadás alatt és mára a legbiztonságosabb rendszereket gyártják. Igaz ez mindaddig, amíg el nem jön a nap, amikor már nem támogatják tovább az adott rendszert. 2020. január 14-et tehát jól vésse be mindenki a naptárába, ugyanis ez a következő, a világ informatikáját nagyban meghatározó dátum. Ekkor jár le a még most is nagy népszerűségnek örvendő Windows 7, a szerverek piacán nagy sikert elérő Windows Server 2008 és R2-es változata, az SQL adatbázis szerver 2008-as verziója, és a máig népszerű és egyébként kellően modern Exchange 2010 levelezőrendszer támogatása is. Ettől a naptól kezdve nem csak szimpla hibajavításokat nem kapnak ezek a rendszerek, de biztonságiakat sem. Sokan legyintenek rá, de egy nagyon fontos dolgot nem árt tudni ezeknek a frissítéseknek a természetéről. Minden új verzió a régire alapoz, gyakran ugyanazon programkódok továbbfejlesztett változatait tartalmazza, a külső megjelenés ne tévesszen meg minket, a háttérben dolgozó program modulokban sok a közös nevező. Amikor egy ilyen közös hiba kerül a felszínre, ami mondjuk a 2008-as szerver verziótól kezdve jelen van minden Windows-ban, akkor amikor a 2012, 2016 vagy épp 2019-es szerverünkre a Microsoft kiadja a javítást éppen Ő maga lesz az, aki azzal a javítással felhívja a figyelmet a hibára, mivel ezeket hackerek előszeretettel fejtik vissza és nyomozzák le hol és milyen hibát foltoz. (Még mielőtt valaki szándékosságot kiáltana emögött vagy esetleg üzleti érdeket sejtene fontos hozzátenni, hogy amikor egy javítást publikálnak azt szigorú tesztek előznek meg, ahol az összes támogatott rendszerrel többféle környezetben vizsgálják meg a működését a javításnak. Ha egy ilyen hiba esetében a régi verzióhoz is kiadnának javítást azzal adott esetben tönkre is tehetnék azt, amivel szintén ugyanaz a vád érhetné őket, hogy rá akarnak venni minket a váltásra. Ez tehát egy természetes folyamat, ahogy a terméktámogatás lejárása is, ami 5+5 év szokott egyébként lenni, míg a nemzetközi törvények szoftverek esetében 7 évet írnak elő hivatalosan.)

Microsoft támogatási időszak vége 2020 - end of support

A biztonság tehát az egyik probléma, a másik, hogy innentől kezdve (és jellemzően már ezt megelőzően is) a hardver és szoftver gyártók is megvonják a támogatást ezektől a szoftverektől, sokan emlékezhetnek rá néhány éve az XP esetében hogyan vált mindennapossá, hogy egy adott szoftver nem volt hajlandó települni Windows XP-re, mert a gyártó már nem írta meg azt a változatot belőle, ami gond nélkül futna a régi rendszeren. Ugyanígy hardver gyártók sem írnak már meghajtóprogramokat az újonnan kijövő eszközeikhez, így például a régi rendszeren használhatatlan lehet egy frissen beszerzett nyomtató.

End-of-support

Nagy vonalakban vázoltuk tehát, hogy miért probléma a támogatás lejárata, most essen szó az érintett szoftverekről és arról melyiknél milyen lehetőségeink vannak továbblépni és megoldani a problémát. Elsőként a sokakat érintő Windows 7 cseréről essen szó. Talán ez a problémakör a legegyszerűbb, még ha a legtöbb felhasználót érintő is. Azoknak, akik korábban már a meglévő Windows 10 licencüket frissítették egyszer az akció keretében Windows 10-el, de később valami miatt visszaálltak a 7-esre jó hírem van, azzal a kulccsal, amit egyszer már aktiváltak Windows 10-el legálisan lehetőség van frissíteni. Csak egy Windows 10 telepítőt kell futtatni a gépen a megfelelő módon és a telepített programok és az adatok meghagyásával rá lehet frissíteni. Akinek van megvásárolt Windows 7-es licence az is tehet egy próbát, legfeljebb az aktiválásnál gondjai adódnak, de szerencsére nekik is akad olyan megoldás, ami nem drága, a 3 hónapnál régebbi használt gépekre ugyanis az erre jogosult viszonteladóknál lehetőség van ún. refurbished Windows licence vásárlására, ami egy korábbi meglévő Windows licence „felújítása” újabb verzióval és kb. negyede áron elérhető, a Home változat esetében nettó 10 ezer forint környékén, a Professional picit több. A frissítés minden esetben helyben elvégezhető, természetesen ezt megelőzően a Windows 10 telepítője meg fogja vizsgálni a gépet, hogy minden előfeltételnek megfelel-e és ellenőrzi a telepített programjaink kompatibilitását is, ha olyat talál, ami nem kompatibilis a Windows 10-el azt jelzi nekünk és a frissítést követően el is fogja azt távolítani. A frissítés természetesen nem kockázatmentes és ha szükséges egy mentést nem árt csinálni előtte a gépről, ha nem vagyunk biztosak a dolgunkban forduljunk szakemberhez.

A második legtöbb felhasználót érintő váltás a Windows Server 2008 vagy 2008 R2 cseréje lesz. Ez már mindenképpen komoly szakértelmet kíván, így senkinek nem javasoljuk, hogy cégénél nem megfelelő tudás birtokában nekilásson! Itt nem lehet biztos receptet adni, ahány cég annyi féle környezet és annyi migrációs útvonal lehetséges. Itt is van lehetőség helyben történő frissítésre, de nem minden esetben, vannak szerepkörök, amiket nem lehet helyben frissíteni. A legtöbb esetben sajnos egy ilyen váltás együtt jár egy új szerver beszerzésével (mivel azok a gépek, amikre Windows Server 2008-at telepítettek jellemzően túl vannak már a működésbiztonsági élettartamukon), amivel viszont a váltás is könnyebbé válik. Ennek a legjellemzőbb módja ugyanis egy új gép telepítése új operációs rendszerrel, ma már jellemzően Server 2016 vagy 2019 verzióval, majd a szerepkörök egyenkénti átvétele előre jól tervezett módon. Mindenképpen kérje ki szakember véleményét, egy jól tervezett átállás mindig sokkal fájdalommentesebb és kisebb kockázattal jár, mint amikor egy elkerülhető problémát kell utólag megszüntetni. Külön gondot jelenthet a váltásnál a licencelés is, a 2008-as változat óta számtalan változatot szüntetett meg és hozott be újat is a Microsoft. Ráadásul az elmúlt 10 évben radikálisan más irányt vett az informatika, míg 2008-ban még csak gyerekcipőben járt, ma már alapvető dolog a virtualizáció, azóta mindenre létezik már felhős megoldás, tehát nem csak a migráció megfelelő módját nehéz megtalálni, hanem a legalkalmasabb célt is.

Az SQL Server 2008 támogatásának lejárata elsősorban a szakalkalmazások készítőit, a szoftverfejlesztőket érintik, adminisztrátori szempontból egy esetleges átállás, verzióváltás nem egy nagy kaland. A kérdés itt az, hogy az adott alkalmazás alkalmas-e újabb verziójú SQL Server-en való futtatásra vagy sem, esetleg alkalmas egy újabb verzióra való frissítést követően. Itt tehát első körben a szoftver készítőjével kell felvenni a kapcsolatot, ha támogatottak az újabb verziók, akkor a megfelelő licencek beszerzését követően lehetőség van telepíteni az új változatot és át lehet pakolni a meglévő adatbázist is rá. Sok szoftverfejlesztő cég szívesen segít is ezek kivitelezésében, van ki külön díjazás ellenében, van aki a szoftver támogatás keretében ingyen is.

Végezetül jöjjön a szintén sokakat érintő, de talán a legtöbb kérdést felvető átállás, az Exchange Server 2010 cseréje. Számos ilyenben volt részünk az évek alatt, ahogy Windows Server verzió cserékben is, így tapasztalatból mondhatom nem könnyű. A cél meghatározása és a kivitelezés sem. A cél meghatározásához ajánlom olvasóink figyelmébe korábbi cikkünket a témában, Office 365 vs Exchange vs IMAP címen. Itt összehasonlításra kerül a hagyományos IMAP alapú levelezés, a saját Exchange és az Office 365 is. Akik már rendelkeznek Exchange 2010-el vélhetően nem akarnak visszalépni a múlt századba, így a célirány vagy a saját Exchange vagy az Office 365 lesz. A saját Exchange jellemzően azon cégek iránya lesz, akik vagy nem akarnak felhőben tárolni, mert ilyenből is akad nem is kevés, vagy azok, akik jellemzően kicsik és így felhasználóra leosztva nagyon költséges lenne számukra egy saját Exchange üzemeltetése, mind licencköltség, mind hardverigény és a későbbi üzemeltetés terén is. Ha valaki ugyancsak saját Exchange kialakítása mellett dönt, akkor egy technikailag nagyon bonyolult kivitelezésű vállalkozásba fog, de az Office 365-be való migrálás se sokkal egyszerűbb művelet, ezek esetében ugyanis nincs lehetőség helyben történő frissítésre. Amennyiben ilyesmibe vágna bele, úgy ne késlekedjen felvenni velünk a kapcsolatot, számos tapasztalattal és referenciával rendelkezünk már ezen a téren is:

Windows Server 2003 end-of-support migrálás elsők közt az országban

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

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

Természetesen minden ilyen projektünkről nem készült cikk, ezek mellett viszont számos más izgalmas átállásban volt részünk, a felsorolt szoftverek mindegyikével, kérés esetén szívesen megadjuk a szóban forgó referenciákat is.

A felsorolt szoftverek cseréjével és az átállásra való felkészüléssel, tervezéssel pedig ne késlekedjen túl sokat. Az SQL Server terméktámogatásából már szó szerint csak napok vannak hátra, a többi szoftver cseréjére való felkészülés és az alkalmas időpont megválasztása miatt pedig a hátralévő fél év is lehet nagyon rövid idő. Ami miatt pedig sokan most veszik elő az átállás témáját az abból fakad, hogy a cégek előszeretettel választják a nyári időszakot az átállással járó IT feladatok elvégzésére, amikor a legtöbben szabadságukat töltik és kevésbé érintik a leállások a munkamenetet, illetve alacsonyabb kockázattal járnak. A gondos tervezés, az előzetes felmérések, a beszerzések pedig mind időt igényelnek, így itt az ideje belevágni. Átállásra fel!

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.

Vicc – Egyszer volt egy fiatal férfi…

Egyszer volt egy fiatal férfi, aki a világ legnagyobb írója szeretett volna lenni. Amikor megkérdezték, mit ért ezen, azt válaszolta:
– olyan dolgokat akarok írni, amit az egész világ olvasni fog,
– olyat, amire az emberek valódi érzelmekkel reagálnak,
– olyat, amelytől sikítani, sírni, a fájdalomtól és dühtől ordítani fognak.
Kívánsága teljesült, most a Microsoftnál dolgozik, hibaüzeneteket ír.

Facebook