Windows Server 2016 traci wsparcie w styczniu 2027
Data jest tylko jedna. Wsparcie rozszerzone dla Windows Server 2016 kończy się 12 stycznia 2027 roku. Wsparcie podstawowe skończyło się już 11 stycznia 2022 roku, więc od tamtej pory system dostawał wyłącznie poprawki bezpieczeństwa. Po styczniu 2027 nie będzie dostawał nawet ich.
Ten kalendarz nie jest niespodzianką. Wersje Windows Server z kanału długoterminowego mają z góry ustalone dziesięć lat życia: pięć lat wsparcia podstawowego i pięć lat rozszerzonego. Data była znana od premiery. Rzadko kto zapisuje ją jednak w firmowym kalendarzu.
Największa pułapka polega na tym, że 13 stycznia 2027 roku serwer wstanie normalnie. Nic nie zgaśnie, nic nie wyświetli ostrzeżenia na ekranie logowania, aplikacje będą działać tak samo jak dzień wcześniej. Zmieni się jedna rzecz i to niewidocznie. Kolejna wykryta luka w tym systemie już nie zostanie załatana.
Warto od razu spojrzeć dalej niż na jedną wersję. Windows Server 2019 ma wsparcie rozszerzone do 9 stycznia 2029 roku. Windows Server 2022 wychodzi ze wsparcia podstawowego 13 października 2026 roku, a rozszerzone ma do 14 października 2031 roku. Jeżeli właśnie kupujecie nowy serwer, to ma bezpośredni wpływ na wybór wersji systemu.
Serwer bez poprawek to problem całej firmy
Microsoft opisuje skutek wprost. Koniec wsparcia oznacza koniec poprawek i biuletynów bezpieczeństwa, a to może rodzić problemy z bezpieczeństwem i zgodnością oraz narażać aplikacje biznesowe. To zdanie z dokumentacji producenta, nie interpretacja dostawcy usług.
W praktyce zaczyna się od pytań, na które ktoś musi odpowiedzieć na piśmie. Audyt pyta, czy używane systemy mają wsparcie producenta. Przy odnawianiu polisy od ryzyk cybernetycznych trzeba wypełnić kwestionariusz, w którym to samo pytanie zwykle się pojawia. Duzi klienci pytają o to w ankietach dla dostawców. Odpowiedź przecząca rzadko kończy sprawę od razu, ale zawsze otwiera rozmowę o warunkach.
Jest jeszcze warstwa, o której łatwo zapomnieć. Producenci oprogramowania biznesowego wpisują w swoje wymagania, na jakich systemach wspierają produkt. Kiedy system wypada z tej listy, zgłoszenie do ich pomocy technicznej kończy się prośbą o aktualizację. Awaria, która normalnie zajęłaby jeden dzień, zamienia się w projekt na kwartał.
I rzecz najbardziej praktyczna. Im dłużej system stoi bez poprawek, tym trudniej go potem ruszyć. Rośnie liczba rzeczy, które trzeba zrobić w jednym oknie serwisowym: system, sterowniki, aplikacja, baza danych, czasem sprzęt. Migracja robiona pod presją incydentu wygląda zupełnie inaczej niż zaplanowana z półrocznym wyprzedzeniem.
Zacznij od spisu, nie od decyzji
Zanim ktokolwiek zacznie wybierać między aktualizacją a chmurą, trzeba wiedzieć, o ilu maszynach mówimy. W wielu firmach pierwsza odpowiedź brzmi dwa albo trzy, a po przejrzeniu wirtualizatora wychodzi osiem. Serwery z 2016 rzadko stoją na widoku. Częściej są to maszyny, których nikt nie rusza, bo działa na nich jedna aplikacja i wszyscy się boją. Spis powinien odpowiadać na kilka pytań przy każdej maszynie:
- jaka dokładnie wersja i edycja systemu jest zainstalowana
- jakie role pełni ta maszyna, na przykład kontroler domeny, serwer plików i wydruku, serwer aplikacji, baza danych
- która aplikacja albo który proces w firmie na niej stoi i kto z tego korzysta
- czy to maszyna fizyczna, czy wirtualna, i na jakim wirtualizatorze pracuje
- jaki jest stan licencji i czy firma ma aktywne Software Assurance albo odpowiednią subskrypcję
- kto po stronie producenta oprogramowania odpowiada za aplikację, która na niej działa
Osobno warto sprawdzić urządzenia, które formalnie nie są serwerami. Systemy kontroli dostępu, rejestratory monitoringu wizyjnego, sterowniki maszyn produkcyjnych i urządzenia dostarczane z gotowym oprogramowaniem często mają w środku Windows Server. Nie każde z nich da się zaktualizować, ale trzeba wiedzieć, że tam są, i zaplanować dla nich osobne zabezpieczenie.
Licząc serwery, policz też bazy danych. Tam kalendarz jest jeszcze ciaśniejszy. Wsparcie rozszerzone dla SQL Server 2016 skończyło się 14 lipca 2026 roku, czyli ta linia jest już za nami. SQL Server 2017 dojdzie do niej 12 października 2027 roku, a SQL Server 2019 dopiero 8 stycznia 2030 roku. Wersje instancji warto wypisać razem z systemami, bo baza i system pod nią bardzo często idą do wymiany w jednym projekcie.
Droga pierwsza, czyli aktualizacja w miejscu
Najprostsza w opisie i najczęściej wybierana. Instalujemy nowszy system na tej samej maszynie, zachowując role, ustawienia i dane. Z Windows Server 2016 można w ten sposób przejść bezpośrednio na wersję 2019, 2022 albo 2025. Microsoft określa przy tym, jak daleko wolno przeskoczyć. Jeżeli celem jest wersja 2025, można przejść nawet cztery wersje naraz. Jeżeli celem jest 2022 albo starsza, limit to dwie wersje. W klastrze reguła jest ostrzejsza, tam aktualizacja idzie po jednej wersji.
Co przy tym boli. Nie każda rola przechodzi aktualizację w miejscu, więc trzeba to sprawdzić dla konkretnej konfiguracji, a nie założyć. Kontroler domeny ma własne zasady i własną kolejność. Nie da się przy okazji zmienić instalacji Server Core na wersję z pulpitem ani odwrotnie. Jeżeli maszyna korzysta z NIC Teaming, trzeba to wyłączyć przed aktualizacją i włączyć po niej. Systemu uruchamianego z pliku VHD nie zaktualizujesz w ten sposób w ogóle.
Jest jeszcze koszt, o którym klienci dowiadują się na końcu. Każda aktualizacja Windows Server wymaga osobnej licencji. To nie jest darmowa zamiana starszej wersji na nowszą, jak przy systemie na komputerze pracownika.
Zostaje cicha wada tej drogi. Aktualizacja w miejscu przenosi na nowy system wszystko, co narosło przez dziesięć lat. Stare wyjątki w zaporze, konta serwisowe, których nikt nie pamięta, ustawienia dodane na jedno popołudnie w 2018 roku. Bywa, że właśnie one powodują później awarie, których nikt nie umie powiązać z aktualizacją. Kopia zapasowa przed startem i sprawdzony plan powrotu nie są tu dodatkiem, tylko warunkiem.
Droga druga, czyli nowy serwer i przeniesienie ról
Stawiamy czystą instalację nowego systemu, a potem przenosimy role, dane i uprawnienia. Więcej pracy niż aktualizacja w miejscu, ale efektem jest maszyna bez historii. To zwykle jedyna droga, gdy sprzęt i tak dochodzi do końca życia, gdy producent aplikacji nie wspiera jej na nowszym systemie w tej samej instalacji albo gdy któraś z ról nie przechodzi aktualizacji.
Ta droga daje jeszcze jedną rzecz, której aktualizacja w miejscu nie da. Stary serwer stoi obok i działa aż do przełączenia, więc plan powrotu jest naturalny. Wracasz na to, co nadal chodzi. Przy aktualizacji w miejscu powrót zawsze oznacza odtworzenie z kopii, czyli dłuższą przerwę i więcej nerwów.
Co przy tym boli. Trzeba mieć gdzie postawić drugą maszynę, choćby jako maszynę wirtualną na czas migracji. Trzeba przejść przez rzeczy, o których najłatwiej zapomnieć: wpisy DNS, certyfikaty, udziały i uprawnienia, zadania cykliczne, konta serwisowe, integracje z innymi systemami, drukarki. Trzeba też ustalić z producentem aplikacji, jak wygląda przeniesienie licencji i instalacji na nową maszynę.
Największym kosztem nie jest tu sprzęt. Jest nim czas na spokojne przełączenie i na testy przed nim. Migracja ról zrobiona w jedną noc bez testów to ta sama praca, tylko z gorszym zakończeniem.
Droga trzecia, czyli przeniesienie do chmury
Trzecia możliwość to przeniesienie serwera do chmury, w praktyce najczęściej do Azure albo Google Cloud. Maszyna dalej jest maszyną, tylko stoi u dostawcy chmury. Przy okazji zmienia się model kosztów. Zamiast jednego zakupu sprzętu na kilka lat pojawia się rachunek co miesiąc, a decyzja o rozbudowie przestaje wymagać zamówienia.
W tym konkretnym scenariuszu jedna rzecz przemawia wyraźnie na korzyść Azure. Poprawki z programu Extended Security Updates są dla maszyn wirtualnych w Azure bezpłatne, a poza Azure trzeba je kupić. Jeżeli firma i tak rozważa chmurę, koniec wsparcia jest dobrym momentem na tę rozmowę.
Co przy tym boli. Nie każda aplikacja lubi chmurę. Systemy, które rozmawiają z urządzeniami w biurze albo na produkcji, potrzebują dobrego łącza i przewidywalnego czasu odpowiedzi, a czasem po prostu muszą zostać na miejscu. Licencjonowanie w chmurze liczy się inaczej niż na własnym sprzęcie i warto to policzyć przed migracją, nie po pierwszym rachunku.
Jest też pułapka, w którą łatwo wpaść. Przeniesienie starego systemu do chmury samo z siebie go nie odmładza. Windows Server 2016 uruchomiony w chmurze to nadal Windows Server 2016 i nadal wychodzi ze wsparcia w styczniu 2027 roku. Dlatego najczęściej sensowny jest podział. Część maszyn idzie do chmury, część zostaje na miejscu na nowszym systemie, a decyzja przy każdej z nich wynika z tego, co na niej działa, a nie z jednej reguły dla całej firmy.
ESU to bilet na trzy lata, nie rozwiązanie
Jeżeli terminu nie da się dowieźć, zostaje program Extended Security Updates. Microsoft nazywa go opcją ostatniej szansy i pomostem na czas migracji, a nie rozwiązaniem docelowym. Program obejmuje poprawki luk ocenionych jako krytyczne i ważne, maksymalnie przez trzy lata od końca wsparcia rozszerzonego.
Warto wiedzieć, czego ESU nie daje. Nie ma nowych funkcji, nie ma poprawek niezwiązanych z bezpieczeństwem, nie ma zmian na życzenie. Nie ma też zwykłego wsparcia technicznego. Program obejmuje same poprawki, a pomoc dotyczy w zasadzie tylko ich wdrożenia i skutków, nie ogólnych problemów z systemem. Cyklu życia produktu ESU nie przedłuża, tylko odracza jeden konkretny skutek.
Do tego dochodzą warunki, które zaskakują przy pierwszej wycenie. Poza Azure poprawki trzeba kupić, a warunkiem jest aktywne Software Assurance albo odpowiednia subskrypcja. Kolejnych lat nie da się kupić na przeskok, drugi rok wymaga pierwszego. Kto podłącza się później, dopłaca za miesiące, które już minęły. A po trzecim roku poprawki po prostu się kończą i problem wraca dokładnie w tym samym miejscu.
Praktyczny wniosek jest prosty. ESU ma sens jako świadomie kupiony czas na dokończenie migracji, która już się zaczęła i ma datę końca. Jako sposób na przesunięcie tematu o rok jest tylko droższą wersją zwlekania.
Co zrobić, zanim zrobi się późno
Do stycznia 2027 roku zostało niespełna pół roku, a przy bazach danych część terminów już minęła. To wciąż wystarczy, żeby zrobić migrację spokojnie i w oknach serwisowych, które sami wybierzecie. Ale tylko wtedy, gdy spis powstanie teraz, a nie w kolejnym kwartale.
Kolejność, która się sprawdza:
- zrób spis maszyn i wersji systemów, razem z instancjami SQL Server
- przy każdej maszynie zapisz, co na niej działa i kto z tego korzysta
- wybierz drogę osobno dla każdej maszyny, bo jedna reguła dla wszystkich prawie nigdy nie wychodzi
- dogadaj z producentami aplikacji, na jakich systemach wspierają swój produkt
- zaplanuj okna serwisowe i sposób powrotu, zanim cokolwiek ruszysz
- dopiero na końcu ustal, czy potrzebujesz ESU i na jak długo
Jeżeli nie wiecie, od czego zacząć, najprostszym pierwszym krokiem jest przegląd tego, co realnie stoi w serwerowni, i uczciwa lista terminów przy każdej maszynie. Zwykle po dwóch rozmowach widać, które serwery są pilne, a które spokojnie doczekają następnego roku. Chętnie taki przegląd zrobimy razem z waszym zespołem.