Windows Server 2016 támogatás vége 2027-ben – mit kell tenniük a vállalkozásoknak?

Windows Server 2016-ról Windows Server 2025-re: frissítés, migráció, Active Directory, Terminal Server és üzleti alkalmazások

Sok vállalkozás informatikai infrastruktúrájában még mindig stabilan működik Windows Server 2016.

Lehet rajta:

Active Directory;
DNS és DHCP;
fájlszerver;
nyomtatási szolgáltatás;
SQL adatbázis;
könyvelőprogram;
ügyviteli rendszer;
Remote Desktop Services;
Terminal Server;
dokumentumkezelő rendszer;
vagy más, üzletileg kritikus alkalmazás.

A probléma az, hogy egy jól működő szerver könnyen azt az érzetet kelti:

„Ha nincs vele probléma, minek hozzányúlni?”

2027-ben azonban ez már nem kizárólag technológiai kérdés lesz.

A Windows Server 2016 életciklusa eléri azt a pontot, ahol a vállalkozásoknak el kell dönteniük:

hogyan viszik tovább a szerveres infrastruktúrát egy támogatott platformra.

A legtöbb esetben nem egyszerűen egy Windows-verzió frissítéséről beszélünk.

A valódi feladat:

a teljes szerverkörnyezet kontrollált migrációja úgy, hogy közben az Active Directory, a jogosultságok, az üzleti alkalmazások és a felhasználók munkája is működőképes maradjon.

Mikor ér véget a Windows Server 2016 támogatása?

A Microsoft jelenlegi életciklus-információi szerint a Windows Server 2016 kiterjesztett támogatása:

2027. január 12-én ér véget.

A fő támogatási szakasz már 2022 januárjában lezárult.

A támogatási életciklus végével a rendszer normál életciklus szerint már nem kapja tovább azokat a biztonsági és minőségi frissítéseket, amelyek egy vállalati szerverkörnyezet hosszú távú biztonságához szükségesek.

Ez nem azt jelenti, hogy:

2027. január 13-án a szerver kikapcsol.

Valószínűleg továbbra is elindul.

Az Active Directory működhet.

A hálózati meghajtó megnyílhat.

Az ügyviteli program elindulhat.

Éppen ezért veszélyes félreérteni a támogatás végét.

A „még működik” nem ugyanaz, mint a „támogatott”

Egy vállalati infrastruktúrában három különböző fogalomról beszélünk:

Működik

Biztonságos

Támogatott

Ezek nem ugyanazt jelentik.

Egy tízéves szerveroperációs rendszer technikailag hosszú ideig képes ellátni a feladatát.

A kérdés inkább az, hogy:

kap-e biztonsági javításokat;
támogatják-e rajta az üzleti alkalmazásokat;
együttműködik-e az új kliensrendszerekkel;
kompatibilis-e az újabb hitelesítési követelményekkel;
elfogadható-e audit és compliance szempontból;
mennyire nehéz helyreállítani egy meghibásodás után;
meddig érhető el hozzá megfelelő gyártói támogatás.

Egy vállalkozás szempontjából a probléma tehát nem az, hogy a Windows Server 2016 egyik napról a másikra használhatatlanná válik.

A probléma az, hogy egyre nagyobb üzleti és informatikai kockázatot jelent egy támogatáson kívüli platformra építeni a működést.

Miért nem érdemes 2027 januárjáig várni?

Egy szervermigráció ritkán csak annyiból áll, hogy:

behelyezzük a Windows Server 2025 telepítőt és megnyomjuk a „Next” gombot.

Előtte fel kell mérni például:

milyen fizikai vagy virtuális szerverek vannak;
milyen Windows Server verziók futnak;
milyen szerepkörök működnek rajtuk;
melyik gép domain controller;
milyen alkalmazások használják az Active Directoryt;
milyen megosztások vannak;
milyen NTFS jogosultságok léteznek;
milyen szolgáltatásfiókok működnek;
van-e SQL Server;
van-e Terminal Server;
milyen nyomtatók vannak kiosztva;
milyen Group Policy-k működnek;
milyen régi SMB vagy NTLM függőségek vannak;
van-e megfelelő biztonsági mentés;
ténylegesen visszaállítható-e a rendszer.

Ezek felmérése, tesztelése és migrációja időt igényel.

Ha a vállalkozás csak 2027 januárjában kezd ezzel foglalkozni, akkor már nem stratégiai migrációt végez.

Hanem határidő alatt próbál kockázatot csökkenteni.

Windows Server 2016-ról közvetlenül Windows Server 2025-re?

Technikailag ez ma már bizonyos környezetekben lehetséges.

A Microsoft jelenlegi upgrade-mátrixa szerint nem fürtözött Windows Server 2016 rendszerről támogatott közvetlen in-place upgrade útvonal létezik Windows Server 2025-re.

Ez fontos változás a korábbi Windows Server generációkhoz képest.

De ettől még:

a támogatott upgrade path nem jelenti automatikusan azt, hogy az in-place upgrade a legjobb migrációs stratégia.

Vállalati környezetben két alapvető megközelítés merül fel.

1. In-place upgrade

Ebben az esetben a meglévő szerver operációs rendszerét frissítjük.

Például:

Windows Server 2016

↓

Windows Server 2025

A Microsoft in-place upgrade eljárása képes megtartani a konfiguráció, a telepített szerepkörök és az adatok jelentős részét.

Ez bizonyos egyszerűbb szervereknél teljesen indokolható megoldás lehet.

Előnye:

kevesebb újrakonfigurálás;
rövidebb migráció;
a meglévő kiszolgálóstruktúra megmaradhat.

Hátránya:

a korábbi rendszer öröksége is továbbmegy;
régi illesztőprogramok és komponensek maradhatnak;
alkalmazáskompatibilitási problémák jelentkezhetnek;
visszaállítása nehezebb lehet;
kritikus infrastruktúrán nagyobb változási kockázatot jelenthet.

Ezért egy in-place upgrade előtt különösen fontos a:

teljes mentés;
kompatibilitásvizsgálat;
gyártói dokumentáció;
tesztkörnyezet;
rollback terv;
karbantartási ablak.

2. Új szerver építése és migráció

A másik megközelítés:

Windows Server 2016

↓

új Windows Server 2025

↓

szerepkörök és adatok migrációja

Ez sok vállalati környezetben tisztább megoldást eredményezhet.

Ilyenkor lehetőség van:

új VM létrehozására;
új operációs rendszer telepítésére;
szerepkörök kontrollált átvitelére;
régi konfigurációk felülvizsgálatára;
jogosultságok tisztítására;
elavult komponensek megszüntetésére;
biztonsági baseline kialakítására.

Egy évek óta működő szerverben gyakran rengeteg történelmi konfiguráció halmozódik fel.

Régi szoftver.

Elfelejtett szolgáltatás.

Nem használt megosztás.

Régi lokális felhasználó.

Megmaradt tűzfalszabály.

Elavult GPO.

A migráció jó alkalom arra, hogy ezeket ne vigyük automatikusan tovább.

Active Directory migráció: itt kell a legnagyobb fegyelem

Ha a Windows Server 2016 domain controllerként működik, a migráció már nem egyszerű operációs rendszer frissítés.

Az Active Directory a vállalati identitásrendszer központja.

Rajta keresztül történhet:

felhasználói hitelesítés;
számítógépek domain tagsága;
Group Policy alkalmazása;
fájlszerver-jogosultság;
nyomtatás;
RDP jogosultság;
szolgáltatásfiókok kezelése;
DNS;
számos üzleti alkalmazás hitelesítése.

Ha az AD hibásan működik, annak hatása a teljes vállalkozásra kiterjedhet.

Ezért egy domain controller migrációt külön projektként kell kezelni.

Hogyan néz ki egy tipikus Active Directory migráció?

Egy általános, leegyszerűsített folyamat:

Meglévő Windows Server 2016 DC

↓

AD állapotfelmérés

↓

DNS és replikáció ellenőrzése

↓

új Windows Server 2025 telepítése

↓

domainhez csatlakoztatás

↓

új domain controller létrehozása

↓

AD és DNS replikáció ellenőrzése

↓

FSMO szerepkörök átvitele

↓

bejelentkezés és GPO tesztelése

↓

régi DC kontrollált kivezetése

Ez nem univerzális recept.

De jól mutatja, hogy egy Active Directory migráció célja nem az, hogy „frissítsük a Windows-t”.

A cél az, hogy:

az identitási infrastruktúra új platformra kerüljön anélkül, hogy a domain működése megszakadna.

Migráció előtt az Active Directory állapotát is ellenőrizni kell

Egy új szerver nem fogja automatikusan kijavítani a régi AD problémáit.

Ha a környezetben már jelen van:

hibás DNS;
replikációs probléma;
elhagyott domain controller objektum;
hibás SYSVOL;
régi Group Policy;
túlzott adminjogosultság;
gyenge szolgáltatásfiók;
örökölt NTLM használat;
régi LDAP függőség,

akkor ezeket nem célszerű vakon továbbvinni.

A migráció előtt ezért indokolt:

AD health check

és

security assessment

végrehajtása.

Active Directory hardening: a migráció biztonsági projekt is

Egy Windows Server 2025-re történő migráció jó alkalom arra, hogy ne csak az operációs rendszer legyen frissebb.

Az Active Directory biztonsági modelljét is érdemes felülvizsgálni.

Ide tartozhat például:

Domain Admins tagság felülvizsgálata;
külön adminisztrátori fiókok;
privilegizált hozzáférések szétválasztása;
Windows LAPS;
szolgáltatásfiókok felülvizsgálata;
gMSA használata, ahol lehetséges;
NTLM használat felmérése;
Kerberos beállítások;
LDAP signing;
SMB signing;
Group Policy jogosultságok;
auditálás;
eseménynaplózás;
domain controller hálózati védelme;
AD backup;
forest recovery terv.

A SARABEL Informatika ehhez külön, nyilvánosan elérhető technikai útmutatót is készített:

Windows Server Active Directory Hardening Guide

Az útmutató Windows Server 2025 és 2022 környezetekhez készült, és többek között lefedi:

az AD threat model kialakítását;
domain controller hardeninget;
privilegizált hozzáféréseket;
Windows LAPS-t;
Kerberos és NTLM kérdéseket;
LDAP signingot;
GPO governance-t;
auditingot és monitoringot;
AD CS kockázatokat;
backup- és forest recovery tervezést.

Fontos alapelv:

a hardeninget nem érdemes vakon registry- és GPO-beállítások tömeges bekapcsolásával kezdeni.

Először mérni kell.

Utána tesztelni.

Majd kontrolláltan élesíteni.

Mit jelent ez Terminal Server esetén?

Sok Windows Server 2016 rendszer valójában azért kritikus, mert a dolgozók azon keresztül végzik a napi munkát.

Tipikus környezet:

Felhasználói PC

↓

RDP

↓

Windows Server 2016 RDS / Terminal Server

↓

ügyviteli alkalmazás

↓

SQL / fájlszerver / Active Directory

Ha itt szervermigráció történik, nemcsak a Windows kompatibilitását kell vizsgálni.

Meg kell nézni például:

támogatja-e az alkalmazás a Windows Server 2025-öt;
támogatott-e többfelhasználós környezetben;
működnek-e a nyomtatók;
működik-e a smart card;
működik-e USB token;
működik-e elektronikus aláírás;
megfelelő-e az RDS licencelés;
működnek-e a felhasználói profilok;
helyesen csatolódnak-e hálózati meghajtók;
működnek-e a GPO-k.

Ez különösen fontos ügyvédi, könyvelői és más olyan környezetben, ahol speciális alkalmazások és hardverkulcsok működnek együtt.

Erről részletesebben a Elektronikus aláírás vállalkozásoknak: Netlock Mokka, eSzignó, Bit4id és minden, amit tudni érdemes című cikkünkben írtunk.

Üzleti alkalmazás kompatibilitása fontosabb lehet, mint maga a Windows

Ez az egyik legfontosabb pont.

Lehet, hogy:

a Windows Server 2016 → Windows Server 2025 upgrade technikailag támogatott.

De ettől még az adott üzleti alkalmazás gyártója nem feltétlenül támogatja ugyanazt.

Például vizsgálni kell:

SQL Server verziót;
.NET függőséget;
Java verziót;
ODBC drivert;
middleware-t;
nyomtatási komponenst;
licenckiszolgálót;
USB drivert;
tanúsítványkezelést;
régi SMB használatot;
adatbázis-klienst.

Ezért migráció előtt az egyik legfontosabb feladat:

alkalmazásleltár és kompatibilitási mátrix készítése.

A migráció egyik legnagyobb rejtett kockázata: a régi üzleti szoftver

A Windows Server 2016 gyakran azért marad sokáig üzemben, mert egy régi szoftverhez „senki nem mer hozzányúlni”.

Ez tipikus helyzet.

A rendszer:

évek óta működik;
az eredeti telepítő már alig dokumentált;
a gyártó megváltozott;
nincs naprakész dokumentáció;
a licencelés nem egyértelmű;
az adatbázis régi;
a program egy adott Windows-verzióhoz kötődik.

Ilyen esetben a migráció előtt nem a Windows Server telepítővel kell kezdeni.

Hanem azzal, hogy dokumentáljuk:

mi fut valójában a szerveren.

Készítsünk szerverleltárt

Egy megfelelő felmérésben szerepelhet:

Terület	Mit kell dokumentálni?
Operációs rendszer	verzió, edition, build
Szerver szerepkör	DC, DNS, DHCP, file, RDS, SQL stb.
IP konfiguráció	IP, gateway, DNS
Active Directory	domain, FSMO, GC
Megosztások	share és NTFS jogosultság
Alkalmazások	verzió, gyártó, támogatottság
Adatbázis	SQL verzió, instance, méret
Szolgáltatások	service accountok
GPO	kapcsolódó házirendek
RDS	licencek, profilok, sessionök
Backup	mit és hová mentünk
Monitoring	milyen szolgáltatásokat figyelünk
Integráció	SMTP, API, LDAP, SMB, ODBC stb.

Ez önmagában sok későbbi problémát előzhet meg.

A dokumentált infrastruktúra jelentőségéről a Mi az IT üzemeltetés, és miért létfontosságú minden vállalkozás számára? című útmutatónkban is írtunk.

Virtualizált Windows Server 2016 migráció

Ha a szerver virtuális gépként fut például:

Hyper-V;
VMware;
Proxmox;

környezetben, a migráció tervezése sok esetben rugalmasabb lehet.

Létrehozható például egy új:

Windows Server 2025 VM

amelyre fokozatosan migrálhatók a szolgáltatások.

A virtualizáció egyik fontos előnye ilyenkor:

nem feltétlenül kell a régi szervert azonnal megszüntetni.

A régi rendszer egy ideig kontrolláltan együtt élhet az új környezettel.

Ez jelentősen csökkentheti a migrációs kockázatot.

Snapshot nem ugyanaz, mint backup

Virtualizáció esetén gyakori hiba:

„Van snapshotunk, tehát van mentésünk.”

Ez nem megfelelő megközelítés.

A snapshot elsősorban rövid távú állapotkezelési eszköz.

Nem helyettesít:

független biztonsági mentést;
hosszú távú megőrzést;
offline backupot;
másodlagos helyszínt;
helyreállítási tesztet.

Különösen kritikus ez Active Directory migráció előtt.

Egy rosszul végrehajtott migrációból csak akkor lehet biztonságosan visszatérni, ha előre megtervezett recovery stratégia áll rendelkezésre.

Backup migráció előtt: nem opcionális

Mielőtt bármilyen szervermigráció megkezdődik, meg kell válaszolni:

Ha minden rosszul sül el, miből állítjuk vissza?

Legalább ezekre szükség lehet:

VM backup;
rendszermentés;
fájlszintű backup;
adatbázismentés;
Active Directory System State;
konfigurációexport;
alkalmazásadatok;
GPO backup;
licencinformáció;
dokumentált restore folyamat.

De önmagában a sikeres backup job sem bizonyíték arra, hogy a rendszer helyreállítható.

A helyes kérdés:

teszteltük-e már a visszaállítást?

Active Directory esetén a helyreállítás külön kategória

Egy domain controller backupja különösen érzékeny terület.

Egy vállalati AD-környezethez nemcsak mentés kell.

Hanem:

forest recovery terv.

Ebben szerepelhet:

melyik DC-ről történik helyreállítás;
hol található a System State backup;
ki fér hozzá;
hol van a DSRM hitelesítő adat;
hogyan épül vissza a DNS;
hogyan kerülnek vissza a további DC-k;
hogyan validáljuk a replikációt.

A Windows Server Active Directory Hardening Guide külön fejezetben foglalkozik az AD backup- és forest recovery-readiness kérdéseivel is.

A migráció után monitoring kell

Egy migráció nem ér véget akkor, amikor az új szerver elindul.

Az első napokban és hetekben különösen fontos figyelni:

CPU;
memória;
háttértár;
szolgáltatások;
event log;
AD replikáció;
DNS;
RDP;
SQL;
backup;
hálózat;
válaszidők.

A folyamatos felügyeletről részletesen a Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben írtunk.

Mit ne csináljunk?

1. Ne várjunk 2027 januárjáig

A migráció megtervezése nem azonos a migráció végrehajtásával.

Minél előbb történik felmérés, annál több idő marad a problémák kezelésére.

2. Ne frissítsünk vakon

Az, hogy egy upgrade útvonal támogatott, nem garantálja az üzleti alkalmazások kompatibilitását.

3. Ne dolgozzunk restore terv nélkül

Backup nélkül migrálni felesleges üzleti kockázat.

4. Ne vigyük át automatikusan az összes régi konfigurációt

A migráció alkalom a takarításra is.

5. Ne csak a szervert nézzük

A teljes környezetet kell vizsgálni:

szerver + kliens + hálózat + alkalmazás + adatbázis + jogosultság + backup + felhasználó

Mikor érdemes elkezdeni?

Ha a vállalkozásnál jelenleg Windows Server 2016 működik, a felmérést érdemes már 2026-ban elvégezni.

Egy kisebb környezet migrációja lehet viszonylag gyors.

Egy komplexebb infrastruktúrában azonban lehet:

több domain controller;
több RDS szerver;
SQL;
fájlszerver;
speciális program;
több telephely;
VPN;
NAS;
külső integráció;
50–100 vagy több felhasználó.

Ilyenkor hónapokkal előre kell tervezni.

Egy lehetséges migrációs ütemterv

1. Felmérés

szerverleltár;
szerepkörök;
alkalmazások;
függőségek;
licencek;
backup;
hálózat.

2. Kompatibilitás

Windows Server 2025 támogatás;
alkalmazások;
SQL;
RDS;
nyomtatók;
tokenek;
driverek.

3. Tervezés

in-place vagy side-by-side;
új VM-ek;
IP és DNS;
migrációs sorrend;
kiesési ablak.

4. Mentés

teljes backup;
adatbázis;
AD;
konfiguráció;
restore teszt.

5. Pilot

új szerver;
tesztfelhasználó;
tesztalkalmazás;
hitelesítés;
RDP;
nyomtatás.

6. Migráció

szerepkörök átvitele;
adatok;
alkalmazások;
jogosultságok.

7. Validáció

AD;
DNS;
GPO;
fájlhozzáférés;
SQL;
RDS;
backup;
monitoring.

8. Régi szerver kivezetése

Csak akkor, amikor már bizonyítottan nincs rá szükség.

Mi történik, ha nem migrálunk?

Rövid távon lehet, hogy semmi.

Ez teszi alattomossá a helyzetet.

A szerver tovább működhet.

De az idő előrehaladtával növekedhet:

a biztonsági kockázat;
az alkalmazáskompatibilitási probléma;
az auditkockázat;
a gyártói támogatás hiánya;
a meghibásodás utáni helyreállítás nehézsége;
a technológiai adósság.

Egy idő után pedig már nem tervezett migrációról beszélünk.

Hanem kényszerhelyzetről.

A váratlan rendszerleállások hátteréről részletesen a Miért áll le váratlanul egy cég informatikai rendszere? A leggyakoribb okok és hogyan előzhetők meg című cikkünkben írtunk.

A Windows Server 2025 önmagában nem old meg mindent

Fontos ezt is tisztázni.

Egy újabb operációs rendszer nem teszi automatikusan:

biztonságossá az Active Directoryt;
helyessé a jogosultságokat;
naprakésszé az alkalmazásokat;
megfelelővé a backupot;
működőképessé a recovery tervet;
biztonságossá az adminisztrációt.

A platformfrissítést ezért érdemes összekötni:

infrastruktúra-felméréssel;
Active Directory auditálással;
hardeninggel;
jogosultság-felülvizsgálattal;
backup-tervezéssel;
monitoringgal;
dokumentációval.

GYIK – Windows Server 2016 támogatás vége

Mikor ér véget a Windows Server 2016 támogatása?

A Microsoft jelenlegi életciklus-információi szerint 2027. január 12-én.

2027 után leáll a Windows Server 2016?

Nem.

A rendszer technikailag tovább működhet, de normál támogatási életcikluson kívülre kerül.

Muszáj Windows Server 2025-re váltani?

Nem feltétlenül minden esetben ugyanaz a célverzió.

A megfelelő platformot az alkalmazások, licencek, infrastruktúra és támogatási követelmények alapján kell meghatározni.

Hosszú távú új környezet építésénél azonban a Windows Server 2025 jelenleg logikus vizsgálandó célplatform.

Frissíthető közvetlenül Windows Server 2016 Windows Server 2025-re?

A Microsoft jelenlegi dokumentációja szerint támogatott közvetlen in-place upgrade útvonal létezik nem fürtözött Windows Server 2016 rendszerről Windows Server 2025-re.

Ez azonban nem jelenti azt, hogy minden szervernél ez a legjobb megoldás.

Domain Controllert is lehet in-place frissíteni?

Bizonyos upgrade forgatókönyvek technikailag támogatottak lehetnek, de üzletileg kritikus Active Directory környezetben gyakran biztonságosabb és tisztább egy új domain controller felépítése és a szerepkörök kontrollált migrációja.

Mi lesz a Terminal Serverrel?

Külön kompatibilitási vizsgálat szükséges.

A Windows Server, RDS, CAL-ok, alkalmazások, profilok, nyomtatók és perifériák együttműködését tesztelni kell.

Kell backup a migráció előtt?

Igen.

Kritikus környezetben nemcsak backup, hanem tesztelt helyreállítási eljárás szükséges.

Mikor érdemes elkezdeni?

A felmérést 2026-ban célszerű elvégezni.

Így marad idő kompatibilitási problémák, régi alkalmazások és infrastruktúrahibák kezelésére.

Összegzés

A Windows Server 2016 támogatásának vége nem egyszerű Windows-frissítés.

Egy vállalkozás számára ez lehetőség arra, hogy felülvizsgálja a teljes szerveres infrastruktúrát.

A kérdés nem csak az:

„Hogyan frissítsük Windows Server 2016-ról Windows Server 2025-re?”

Hanem az is:

milyen rendszereink vannak;
melyik üzletileg kritikus;
milyen régi alkalmazásoktól függünk;
megfelelő-e az Active Directory;
megfelelőek-e a jogosultságok;
van-e tesztelt backup;
hogyan állítanánk helyre a rendszert;
megfelelő-e a monitoring;
dokumentált-e az infrastruktúra.

A legjobb migráció nem az, amelyik a leggyorsabban befejeződik.

Hanem az, amelyik után:

az új környezet támogatott, dokumentált, biztonságosabb és visszaállítható.

Ha egy Windows Server 2016 rendszer ma stabilan működik, az jó kiindulópont.

De nem indok arra, hogy a migráció tervezését 2027-re halasszuk.