Windows Server 2022 kończy wsparcie podstawowe 13 października 2026, ale poprawki bezpieczeństwa będą wychodzić do 2031 roku. Nie musisz więc migrować z dnia na dzień. Warto natomiast sprawdzić, które usługi stoją na tym systemie, czy ich dostawcy wspierają nowsze wersje Windows Server i kto odbierze ewentualną zmianę.
Czy Windows Server 2022 nadal będzie dostawał poprawki bezpieczeństwa?
Tak. Po 13 października 2026 system przechodzi do Extended Support i dostaje miesięczne aktualizacje bezpieczeństwa do 14 października 2031, bez dodatkowej opłaty. Zmienia się zakres wsparcia: w okresie podstawowym Microsoft przyjmuje także zgłoszenia zmian funkcji i poprawek niezwiązanych z bezpieczeństwem, a w rozszerzonym takie poprawki wymagają osobnej, płatnej umowy.
Źródła: Microsoft, KB5120242; Microsoft, Fixed Lifecycle Policy.
Jeśli aplikacja działa, a jej dostawca wspiera Windows Server 2022, możesz zaplanować dalsze utrzymanie i wyznaczyć datę kolejnego przeglądu. Jeśli aplikacja wymaga nowszego środowiska, decyduje termin dostawcy, a nie Microsoftu.
Czy trzeba od razu migrować do nowszego Windows Server?
Nie. Decyzję podejmuj osobno dla każdej usługi, po sprawdzeniu, co na niej działa. Zestaw ze sobą wersję Windows Server, wersję aplikacji, silnik bazy danych i agent backupu, bo każdy z nich ma własny cykl wsparcia. Typowe pułapki to aplikacja napisana pod starszą wersję .NET, wersja bazy bez wsparcia na nowszym systemie i agent backupu, który nie obsługuje nowego Windowsa.
W rejestrze zapisz link do dokumentu dostawcy, datę sprawdzenia i osobę odpowiedzialną. Ogólne „wspieramy Windows Server" nie wystarcza. Potrzebujesz dokumentu albo maila od dostawcy, który wprost wymienia Twoją kombinację: wersję aplikacji, bazy i systemu. Jeśli go nie ma, poproś o niego w zgłoszeniu do producenta.
Dla nowych wdrożeń naturalnym celem jest Windows Server 2025. Zanim wpiszesz go do planu, sprawdź, czy dostawca aplikacji go wspiera i czy ścieżka aktualizacji z Twojej wersji jest opisana w dokumentacji Microsoftu.
Co zmienia wirtualizacja?
Przeniesienie maszyny wirtualnej na nowy host nie zmienia systemu w środku: Windows i aplikacje działają jak wcześniej. Zmiana platformy i zmiana wersji systemu to dwie osobne zmiany. Testuj je osobno i dla każdej ustal kryteria odbioru, wtedy wiesz, która z nich spowodowała problem.
Przy przenosinach na inny hypervisor, na przykład z VMware na Proxmox VE, zaplanuj dodatkowo trzy rzeczy. Po pierwsze, sterowniki VirtIO dla dysku i sieci w systemie gościa; bez nich zostają emulowane kontrolery o niższej wydajności. Po drugie, możliwość ponownej aktywacji systemu po zmianie wirtualnego sprzętu. Po trzecie, licencjonowanie Windows Server względem rdzeni nowego hosta.
Karta decyzji dla jednej usługi
Zamiast zaczynać od listy wszystkich serwerów, wybierz jedną usługę ważną dla firmy, na przykład system magazynowy, i wypełnij dla niej poniższą kartę. Przykłady w ostatniej kolumnie są hipotetyczne.
| Pole | Co wpisać | Przykład: system magazynowy |
|---|---|---|
| Usługa i właściciel | Nazwę procesu i osobę, która potwierdzi jego poprawne działanie. Kontakt do administratora nie zastępuje odbioru przez użytkownika biznesowego. | Wydania towaru; kierownik magazynu. |
| Składniki | System i edycję, aplikację, bazę, agent backupu, platformę uruchomieniową. Wersje odczytaj z konsol administracyjnych, nie z nazw maszyn. | Windows Server 2022 Standard, aplikacja WMS, baza SQL, agent backupu, host wirtualizacji. |
| Wsparcie | Datę i rodzaj końca wsparcia dla każdego składnika. Oddziel koniec poprawek bezpieczeństwa od końca wsparcia podstawowego. | System: 13.10.2026 (podstawowe), 14.10.2031 (bezpieczeństwo). Pozostałe składniki wg dokumentów dostawców. |
| Zależności | Usługi potrzebne przy logowaniu, wymianie danych i zadaniach cyklicznych. Potwierdź je z właścicielem aplikacji i w jej konfiguracji. | Logowanie przez domenę, eksport do systemu księgowego, nocne zadanie inwentaryzacji. |
| Odbiór | Konkretne operacje kontrolne, oczekiwany wynik i osobę zatwierdzającą. Test ma obejmować realny przepływ pracy. | Przyjęcie dokumentu i przekazanie go do księgowości; zgodność liczby rekordów i sum kontrolnych raportu. |
| Decyzja | Dalsze utrzymanie z datą przeglądu, próba modernizacji albo projekt migracji. Przy każdej opcji zapisz przyczynę i termin kolejnego działania. | Utrzymanie do przeglądu w I kwartale; „do sprawdzenia" tylko z właścicielem i terminem odpowiedzi. |
Karta jest kompletna, gdy pozwala wskazać najbliższy istotny termin, przygotować test i podjąć decyzję. Brak deklaracji dostawcy to zadanie do wykonania przed zmianą na produkcji.
Jak ustalić, czy jest jeszcze czas na przygotowanie zmiany?
Porównaj czas do najbliższego istotnego terminu z czasem potrzebnym na analizę, testy, uzgodnienie przerwy i wykonanie prac. Wszystkie składowe licz w tej samej jednostce, na przykład w dniach kalendarzowych, i uwzględnij dostępność osób potrzebnych do odbioru.
Hipotetyczny przykład: dostawca aplikacji wyznaczył termin zmiany za 90 dni. Analiza i testy zajmą 30 dni, uzgodnienie okna serwisowego 20 dni, a rezerwa na poprawki to 15 dni. Zapas wynosi 90 − 30 − 20 − 15 = 25 dni. To liczba dla tych założeń, nie ogólna norma czasu migracji.
Jeśli wynik jest ujemny, trzeba zmienić plan: przyspieszyć przygotowania, zawęzić zakres jednego etapu albo uzgodnić z dostawcą rozwiązanie przejściowe. Nie przesuwaj terminu dostawcy w arkuszu tylko po to, żeby wynik wyglądał lepiej.
Aktualizacja in-place czy przeniesienie usługi na nową instancję?
Microsoft opisuje dwie metody. Aktualizacja in-place zachowuje istniejące środowisko, ale wymaga zgodnej ścieżki, odpowiednich ról i okna serwisowego. Migracja polega na przygotowaniu osobnej instancji i przeniesieniu ról lub danych według procedury właściwej dla danej roli.
Źródło: Microsoft, planowanie aktualizacji Windows Server.
Wybór metody zacznij od macierzy ról Microsoftu, potem sprawdź wymagania dostawcy aplikacji. Kontroler domeny wymaga osobnego podejścia: dokumentacja oznacza in-place jako niezalecany i wskazuje czystą instalację z migracją. Klaster ma własną procedurę, Cluster OS Rolling Upgrade, więc nie przenoś na niego kroków opisanych dla pojedynczego serwera.
Źródło: Microsoft, aktualizacja i migracja ról.
Przed zmianą zrób pełny backup i próbę odtworzenia. Zmierz czas od rozpoczęcia przywracania do zakończenia testów usługi i porównaj go z przerwą akceptowaną przez biznes. Jeśli próba trwa dłużej niż okno, popraw plan powrotu jeszcze przed pracami na produkcji. Uruchomienie systemu po restore to dopiero połowa: usługa musi przejść test odbioru.
Źródło: Microsoft, wykonanie aktualizacji in-place.
Czy wszystkie wersje Windows Server mają ten sam termin?
Nie. Wsparcie rozszerzone Windows Server 2016 kończy się 12 stycznia 2027, czyli prawie pięć lat wcześniej niż dla wersji 2022. Wspólny wpis „Windows Server: wsparcie" w rejestrze może więc ukryć usługę, którą trzeba ruszyć jako pierwszą.
Dla Windows Server 2016 Microsoft oferuje płatne Extended Security Updates przez Azure Arc. Traktuj je jako rozwiązanie przejściowe dla usług, które nie zdążą przejść zmiany, a nie jako plan docelowy.
Źródło: Microsoft, koniec wsparcia Windows Server 2016.
Zacznij od jednej usługi. Jeśli nie ma właściciela albo testu odbioru, uzupełnij to najpierw: bez tego nie da się ani rozmawiać z dostawcą, ani rzetelnie wycenić projektu.
Dokumentacja i źródła
Microsoft, komunikat o zmianie wsparcia Windows Server 2022 (KB5120242)
Microsoft, Fixed Lifecycle Policy
Microsoft, planowanie aktualizacji Windows Server
Microsoft, aktualizacja i migracja ról i funkcji
Microsoft, wykonanie aktualizacji in-place
Microsoft, koniec wsparcia Windows Server 2016
Ustalmy kolejność prac w infrastrukturze
Planujesz modernizację serwerów i chcesz ustalić zależności oraz kolejność zmian? Sprawdź usługi infrastruktury IT Symbit i opisz usługę, którą chcesz objąć projektem.
Porozmawiajmy o modernizacji