10 kwietnia 2026 — Windows Server Update Services (WSUS) został wycofany z wsparcia. Jeśli Twoja firma polega na WSUS do zarządzania patchami dla 50+ serwerów Windows, teraz stoisz przed kluczową decyzją: co robić dalej? W tym artykule pokażę Ci alternatywy dla WSUS, jak zbudować efektywną politykę patch management i jak zautomatyzować wdrażanie patche bez WSUS. Instrukcja dotyczy firm z infrastrukturą 10–1000 serwerów.
Dlaczego patch management serwerów jest krytyczny?
Serwery Windows obsługują Twoją infrastrukturę IT — Active Directory, Exchange, SQL Server, aplikacje biznesowe. Jedno nieupatchone okno bezpieczeństwa może oznaczać breach, ransomware, lub utratę danych. A jednak 78% firm wdrażało patche z opóźnieniem > 30 dni.
Fakty:
- 80% breachów to znane CVE — czyli były patche dostępne, ale IT ich nie wdrożyło.
- Średni czas do patch = 39 dni — to za długo na Security patch (powinno być 7–14 dni).
- Audytorzy (SOC 2, ISO 27001, NIS2) wymagają raportów — musisz udowodnić że wszystkie serwery są patchowane.
- Compliance fines mogą sięgać mln PLN — za niezałatanie znanej podatności.
Bez automatyzacji patch management = chaos. Z automatyzacją (Endpoint Central) = peace of mind.
WSUS EOL — co zamiast tego?
WSUS (Windows Server Update Services) pozwala na pobranie patche raz z Microsoft Update, potem dystrybucja w sieci firmowej. Od kwietnia 2026 — brak wsparcia, brak bezpieczeństwa patche.
Trzy alternatywy:
1. Microsoft Update for Business
- Darmowy (wbudowany w Windows Server)
- Bezpośrednia komunikacja z Microsoft Update
- Brak bufora testowania — patche idą natychmiast
- Limit kontroli IT (nie można odroczyć patche dla Quality)
- Dla firm < 50 serwerów lub bez compliance wymagań
2. Intune (Azure Mobile Device Management)
- Cloud-native, pełna integracja z Microsoft 365
- Możliwość opóźniania patche per device, per group
- Raportowanie compliance do Azure AD
- Koszt: ok. 6–10 USD/device/miesiąc (licencja Microsoft)
- Najlepszy wybór dla firm już w Microsoft 365
3. Endpoint Central (ManageEngine)
- On-premise lub cloud, pełna kontrola nad patchami
- Buffor testowania: pre-production → production
- Harmonogramy zaawansowane (np. deploy co drugi wtorek)
- Raportowanie compliance dla SOC 2, ISO, NIS2
- Koszt: ok. 80–150 PLN/device/rok
- Najlepszy dla firm wartościujących bezpieczeństwo i kontrolę
Polityki patchowania — pre-production vs production
Każdy patch nosi ryzyko — może złamać aplikację, zmienić API, albo sam zawierać bug. Dlatego musisz pracować w dwóch fazach: testowanie, potem deploy.
Faza 1: Pre-Production (testowanie)
Seria serwerów testowych, identyczne jak production: Windows Server 2019/2022, SQL Server, aplikacje biznesowe.
- Harmonogram: Druga wtorek każdego miesiąca (Patch Tuesday Microsoft) → patche trafiają na pre-prod
- Testowanie: 2–3 tygodnie — sprawdzasz czy aplikacje działają
- Dokumentacja: „Patch KB5035607 — ok, brak problemów" vs „Patch KB5035608 — blokuje komunikację z SQL Server XYZ — odroczamy"
- Security patches: testowanie 1 tydzień max (są krytyczne)
- Quality patches: mogą czekać 30–60 dni (mniej ryzyka, mniej pospiechu)
Faza 2: Production (deployment)
Po zatwierdzeniu w pre-prod — deploy do production.
- Harmonogram: Trzecia wtorek miesiąca lub ustalone okno (np. drugie wtorki w nocy 02:00–06:00)
- Grupy serwerów: Deploy faliami — najpierw mniej krytyczne, potem krytyczne:
- Seria A: serwery development, test (ryzyko najniższe)
- Seria B: serwery aplikacyjne (ryzyko średnie)
- Seria C: Domain Controllers, SQL Server, krytyczne (ryzyko maksimum — deploy w ostatniej fali)
- Timeout: Jeśli patch powoduje reboot > 10 minut — czekaj, sprawdzaj, najpierw komunikuj zmianę użytkownikom
- Rollback plan: Zawsze miej backup przed patchem — jeśli coś popsuje, będziesz mieć opcję przywrócenia
Tabela przykładowego harmonogramu na rok
| Miesiąc | Patch Tuesday (Microsoft) | Pre-Prod Deploy | Production Deploy | Typ Patchów |
|---|---|---|---|---|
| Maj 2026 | 12.05 | 12.05 | 26.05 (2:00–6:00 AM) | Security + Quality |
| Czerwiec 2026 | 09.06 | 09.06 | 23.06 (2:00–6:00 AM) | Security + Quality |
| Lipiec 2026 | 14.07 | 14.07 | 28.07 (2:00–6:00 AM) | Security (priorytet wysoki) |
Automatyzacja w Endpoint Central — harmonogramy i reguły
Manualny proces? Zapominasz o serwerze, deploy się opóźnia, serwer zostaje niezaplatany. Endpoint Central automatyzuje — deploy w określonym dniu/godzinie do wybranych serwerów, bez zaangażowania IT.
Konfiguracja w Endpoint Central (krok po kroku)
- Admin → Patch Management → Deployment
- New Patch Deployment
- Name: „May 2026 Security Patches - PreProd"
- Patch Type: Windows OS, Security Updates (zaznacz tylko Security)
- Devices: Wybierz pre-prod serwery (grupa device)
- Schedule: „May 12, 2026, 08:00 AM" (tuż po Patch Tuesday)
- Reboot: „Scheduled Reboot on May 13, 2026, 02:00 AM" (planowany restart w nocy)
- Actions on failure: „Pause deployment, notify admin" — jeśli patch się nie zainstaluje, system zatrzyma deployment dla innych serwerów
- Deploy — system automatycznie aplikuje patche we wskazanym dniu/godzinie
- Monitoring: Dashboard pokazuje status: „Pending" → „In Progress" → „Success/Failed"
Reguły automatyczne (Business Rules)
Możesz ustawić reguły, które automatycznie deploraują Security patche bez czekania na zatwierdzenie:
-
Reguła 1: Auto-deploy Security patche na test serwerach
Warunek: Jeśli Patch Type = Security Update → automatycznie deploy na serwery pre-prod w ciągu 24 godzin po wydaniu. Test serwerów mają niskie ryzyko, więc można szybciej.
-
Reguła 2: Alert dla krytycznych patche o CVSS > 9
Warunek: Jeśli CVSS Score > 9 (krytyczne CVE) → prześlij alert do Service Manager + security team. Te patche wymagają przyspieszenia — mogą być wdrażane w ciągu 7 dni.
-
Reguła 3: Exclude nieznanych patchów z auto-deploy
Warunek: Jeśli Patch = Quality Update AND nie ma czasu testowania > 14 dni → czekaj na ręczne zatwierdzenie. Quality patche są mniej pilne, mogą czekać.
Raportowanie zgodności — co audytorzy chcą zobaczyć
Jeśli masz compliance wymogi (SOC 2, ISO 27001, NIS2) — musisz raportować że serwery są patchowane. Audytor chce widzieć raport: „wszystkie serwery mają najnowsze patche, wyjątkami są XYZ zaplanowane na YY-MM-DD".
Co zawiera raport patch compliance
- Patch Inventory: Lista wszystkich serwerów, liczba zainstalowanych patche, liczba oczekujących patche
- Compliance % per Server: Np. serwer PROD-SQL-01 ma 145 zainstalowanych patche, oczekuje 2 (Quality) = 98.6% compliant
- Overdue Patches: Jeśli serwer ma Security patch starszy niż 14 dni — flaguj jako „Non-Compliant" + przyczyna
- Patch Timeline: Harmonogram wdrażania — gdy planują dalsze patche
- Executive Summary: „99.2% serwerów fully patched, 0 serwerów non-compliant, 3 Quality patche zaplanowane na 26.05"
Konfiguracja raportów w Endpoint Central
- Admin → Reports → Patch Compliance Report
- Filtr: Device Group = All Production Servers
- Period: Last 30 days
- Export PDF → wyślij do audytora / Security Team monthly
FAQ — Patch Management Windows Server
Kiedy skończy się WSUS (Windows Server Update Services)?
Windows Server Update Services (WSUS) osiągnął koniec wsparcia 10 kwietnia 2026. Microsoft oficjalnie zakończył aktualizacje bezpieczeństwa dla WSUS. Firmy używające WSUS powinny pilnie migrować na Microsoft Update for Business, Intune MDM lub alternatywy takie jak Endpoint Central ManageEngine.
Czy mogę bezpośrednio łączyć serwery z Microsoft Update Service?
Technicznie tak — serwery mogą się łączyć z update.microsoft.com bezpośrednio. Ale to znamen brak kontroli IT: każdy serwer dostaje patche gdy tylko się pojawią, bez testowania. Lepiej: Microsoft Update for Business (wbudowany w Windows Server, darmowy) lub Endpoint Central (płatny, ale z więcej kontrolą).
Jaka jest różnica między Security patched a Quality patches?
Security patches naprawiają luki bezpieczeństwa — te trzeba wdrażać szybko (w ciągu 2–4 tygodni). Quality patches naprawiają bugi i zwiększają stabilność — te mogą czekać (miesiące). W polityce patch management: Security = priorytet wysoki, Quality = priorytet normalny.
Czy patche mogą spowodować problemy z aplikacjami?
Tak, każdy patch nosi ryzyko — np. patch może zmienić API Windows, co powoduje konflikt ze starą aplikacją. Dlatego istnieje pre-production: deplorujesz patche najpierw na testowych serwerach (identyczne środowisko), testujesz aplikacje, potem idziesz do produkcji.
Jak często powinna się łatać Windows Server?
Microsoft wydaje patche w drugi wtorek każdego miesiąca (Patch Tuesday). Rekomendacja: testowanie w pre-prod przez 2 tygodnie, potem deploy do prod do konca miesiąca. Security patches — szybciej (7–10 dni). Quality patches — mogą czekać 30–60 dni.
Powiązane artykuły
ManageEngine Endpoint Central — zarządzanie patchami krok po kroku ManageEngine vs NinjaOne dla MSP 2026 — porównanie dla Managed Service Providers AI w ITSM 2026 — jak sztuczna inteligencja zmienia helpdesk IT ManageEngine CVE i bezpieczeństwo — co powinieneś wiedzieć jako administrator ManageEngine ServiceDesk Plus — konfiguracja od podstawPotrzebujesz pomóc w migracji z WSUS na Endpoint Central?
Rotech Group przeprowadzi full audit Twojej infrastruktury, zaproponuje politykę patchowania (pre-prod, prod), wdroży Endpoint Central i skonfiguruje harmonogramy. W ciągu 2–4 tygodni — od chaosu do automatyzacji.
Umów audit infrastruktury →