A következő cikk egy Microsoft által nem támogatott átállás menetét írja le. Fontos hangsúlyozni, hogy abban az esetben, ha valami rosszul sül el a gyártó nem ad támogatást és minden fórumon kihangsúlyozzák, hogy Exchange alatt a Windows frissítése nem támogatott. Egyáltalán. Ugyanakkor vannak olyan esetek, nekünk jelenleg két ilyen rendszer is fut, ahol szinte indokolatlanul sok extra munkával jár egy friss telepítés, Exchange konfiguráció, majd teljes migrálás. Ezért megpróbáltunk egy nem támogatott frissítést helyben. Akadtak nehézségek, amiket viszont sikerült orvosolni, az Exchange él és virul, immár egy Windows Server 2016 alatt.
Mindenki tehát saját felelősségére kezdjen ebbe a frissítésbe. Mivel mi virtuális gépekkel dolgoztunk, így a napi mentés sikeres lefutása után, egy snapshot készítésével vágtunk a feladatba. Ezek meglétét mindenkinek erősen ajánlom!
Ezt követően a Windows frissítése a normál útján indult, Windows Server 2016 telepítő be, Windows alatt indít, fájlok és beállítások megtartása, figyelmeztetés megerősítése, majd kb. 1 óra várakozás. A rendszer ez alatt 2x újraindult és a végén a bejelentkező képernyő fogadott.
(Az esetünkben egy Exchange 2016 futott a Windows Server 2012 R2 alatt, fontos hangsúlyozni, hogy ezt kizárólag Windows Server 2016-ra érdemes frissíteni, ugyanis a 2019-es vagy 2022-es Windows és az Exchange 2016 hivatalosan sem támogatott! Minden ilyen frissítés előtt érdemes megnézni a hivatalos kompatibilitási mátrixot.)
A frissítés utáni első bejelentkezés alkalmával egészen biztató volt, ami fogadott. Az Exchange szolgáltatások mindegyike elindult, az OWA-ba sikerült pillanatok alatt bejelentkezni, láttam a leveleket, első ránézésre minden jó volt. Aztán jött egy kis feketeleves. Nem sikerült levelet küldeni még házon belül sem. Az Exchange Powershell nem indult el, csak figyelmeztetéseket kaptam. Szerettem volna megnézni az Exchange Tools segítségével a levélvárólistát, de az MMC konzol összeomlott. A naplókból kiderült, a Powershell-Proxy\web.config-ban található system.management.wsmanagement.config résszel van valami gondja és a .NET telepítés sincs rendben.
Ezzel megkezdődött a renoválás. Első körben a .NET 4.8 került újratelepítésre a rendszeren, ezt követte a KB3206632 jelű frissítés, ami a fórumtémákból és az Exchange telepítő üzenetéből is kiderült, hogy nélkülözhetetlen Windows Server 2016 alatt az Exchange megfelelő futásához. A .NET és a frissítés telepítése után ugyanakkor még nem javult meg a rendszer, így következhetett az Exchange javító telepítése.
Exchange 2016 telepítő ISO be, majd a következő paranccsal útjára indult, hogy aztán kb. 2 órányi futás után helyreálljon az Exchange: D:\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms
Bár a telepítő nem kéri külön, én a gépet még azért újraindítottam. Exchange Powershell ezután helyreállt, az Exchange Tools is újra működni kezdett, a teszt levél kiment külső címre, külső címről vissza is jött (a frissítés ideje alatt a tűzfalon csak egyetlen szerver IP címét engedtem be az SMTP-re, ha netán vissza kell álljak a korábbi snapshot-ra ne vesszen el levél), majd a válasz tesztüzenet is beérkezett. Újra működött Exchange-en belül is a levélküldés. Gondoltam nincs más hátra, akkor engedjük rá a legújabb, 2023. márciusi biztonsági csomagot az Exchange-re.
Az SU csomag telepítése után viszont az Exchange Transport szolgáltatás nem volt hajlandó elindulni, amint elindult le is állt. A napló alapján a gondot a Content filter agent okozta, annak is a DLL fájl verziója vélhetően nem megfelelő. Ezt az SU csomag frissítette a fájldátum alapján. Nem tudom a fenti frissítéstől függetlenül is belefutottam volna-e ebbe, mindenesetre mivel 3rd party megoldást használnak ezen a rendszeren a szűrésre, és a Content filter amellett, hogy engedélyezett, nem konfigurált, így az eltávolítás mellett döntöttem. Egyes fórumok a KB4013429 számú frissítést említik a probléma forrásaként, én ezt nem találtam meg a gépen, vélhetően egy újabb már felülírta. Ezért én az Exchange scripts mappájában lévő Uninstall-AntiSpamAgents.ps1 Powershell script-et futtattam és eltávolítottam a Content filter agent-et, ami után a Transport szolgáltatás már nem csak elindult, de ismét működni is kezdett. Az Exchange küld és fogad, minden funkció megfelelően működik rajta és a gépen is minden a legfrissebb jelenleg. A Windows Server 2012 R2-t pedig ezzel egy újabb gépen nyugdíjaztuk és megspóroltunk egy több napos munkával járó, komplikált átállást.
