Windows Server ortamlarında güncelleme yapmamak ciddi güvenlik açıklarına davetiye çıkarır; ancak plansız yapılan güncellemeler de en az güncelleme yapmamak kadar tehlikelidir. Kontrolsüz bir yeniden başlatma kritik bir iş saatinde servisleri devre dışı bırakabilir, test edilmemiş bir yama uygulamaları çalışmaz hale getirebilir. Güncelleme yönetiminin amacı bu iki uç arasında kontrollü, tekrarlanabilir ve geri alınabilir bir süreç kurmaktır.
Bu yazıda Windows Server güncellemelerini merkezi olarak yönetmek için WSUS yapılandırmasını, güncelleme gruplarıyla aşamalı dağıtımı, bakım penceresi planlamasını ve güncelleme sonrası kontrol adımlarını ele alıyoruz.
Güncelleme yapmamak neden riskli?
Microsoft her ayın ikinci Salı günü (Patch Tuesday) güvenlik güncellemelerini yayınlar. Bu güncellemeler yayınlandığı anda aynı zamanda güvenlik açığının detayları da kamuya açık hale gelir. Saldırganlar yayınlanan yama notlarını tersine mühendislik yöntemiyle analiz ederek, yamalanmamış sistemleri hedef alan exploit kodlarını genellikle birkaç gün içinde üretir. Güncelleme uygulanmayan her gün, bu exploitlere karşı açık pencere süresini uzatır.
Ransomware saldırıları yamalanmamış sistemleri birincil hedef olarak seçer. EternalBlue gibi bilinen güvenlik açıkları, yama yayınlandıktan aylar sonra bile yamalanmamış sunucularda aktif olarak kullanılmaya devam etmiştir. Kuruluşlar yalnızca teknik risk değil, aynı zamanda uyumluluk riski de taşır. ISO 27001, PCI DSS ve KVKK gibi düzenlemeler düzenli yama yönetimini açıkça zorunlu kılar; denetim sırasında yama geçmişi sunulamaması doğrudan bulgu olarak raporlanır.
Güncelleme yapmama kararı bilinçli bir risk kabulü olmalıdır; ancak çoğu ortamda bu bilinçli bir karar değil, süreç eksikliğinden kaynaklanan bir ihmaldir. Aşağıdaki adımlar bu ihmali yapılandırılmış bir sürece dönüştürmeyi hedefler.
WSUS ile merkezi güncelleme kontrolü
Windows Server Update Services (WSUS), Microsoft güncellemelerini merkezi olarak indirip onaylama, dağıtma ve raporlama imkanı sunan ücretsiz bir sunucu rolüdür. Her sunucunun bağımsız olarak Microsoft Update sunucularına gitmesi yerine, WSUS sunucusu güncellemeleri bir kez indirir ve iç ağdaki makinelere dağıtır. Bu hem bant genişliği tasarrufu sağlar hem de hangi güncellemelerin hangi sunuculara uygulanacağı üzerinde tam kontrol verir.
WSUS rolünü kurmak için Server Manager üzerinden Add Roles and Features sihirbazı kullanılır. Kurulum sırasında güncelleme dosyalarının saklanacağı disk bölümü ve upstream sunucu (doğrudan Microsoft Update veya başka bir WSUS sunucusu) belirlenir. Kurulum tamamlandıktan sonra WSUS yönetim konsolundan ürün ve sınıflandırma seçimi yapılarak yalnızca ortamınızdaki işletim sistemleri ve uygulamalarla ilgili güncellemeler senkronize edilir.
WSUS'un en güçlü özelliklerinden biri bilgisayar gruplarıdır (Computer Groups). Sunucularınızı işlev, kritiklik veya lokasyona göre gruplara ayırarak her gruba farklı onay politikaları uygulayabilirsiniz. Bir güncelleme önce test grubuna onaylanır, sorunsuz çalıştığı doğrulandıktan sonra üretim grubuna onaylanır. Bu yaklaşım test edilmemiş bir yamanın tüm sunuculara aynı anda dağıtılmasını engeller.
Sunucuların mevcut güncelleme durumunu hızlıca kontrol etmek için PowerShell kullanılabilir:
# Son 10 yuklu guncellemeyi listele
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
# Ciktida HotFixID, InstalledOn ve InstalledBy gorunur
# Ornek cikti:
# KB5034441 2026-04-15 NT AUTHORITY\SYSTEM
# KB5033372 2026-04-15 NT AUTHORITY\SYSTEM
# Bekleyen guncellemeleri kontrol et (PSWindowsUpdate modulu gerekir)
Install-Module -Name PSWindowsUpdate -Force
Get-WindowsUpdate
# WSUS sunucusundaki bilgisayar durumunu sorgula
Get-WsusComputer -NameIncludes "SRV" | Select-Object FullDomainName, LastReportedStatusTimeGroup Policy ile istemci sunucuların WSUS sunucusuna yönlendirilmesi gerekir. Computer Configuration > Administrative Templates > Windows Components > Windows Update altındaki Specify intranet Microsoft update service location ayarıyla WSUS sunucusunun adresi tanımlanır. Otomatik güncelleme davranışı da yine bu politika grubundan kontrol edilir; üretim sunucularında otomatik indirme ancak yükleme için bildirim seçeneği tercih edilmelidir.
Güncelleme gruplarını planlayın
Güncellemeleri tüm sunuculara aynı anda uygulamak, tek bir hatalı yamanın tüm altyapıyı etkilemesi riskini taşır. Aşamalı dağıtım (staged rollout) bu riski minimize eder. Üç kademeli bir yapı çoğu ortam için yeterli ve yönetilebilir bir denge sağlar.
1. Test grubu: Üretim yükü taşımayan veya kritik olmayan sunucular bu gruba dahil edilir. Geliştirme sunucuları, iç test ortamları veya yedek sunucular bu grup için uygundur. Güncelleme WSUS konsolunda onaylandıktan sonra ilk olarak bu gruba dağıtılır. Yama uygulandıktan sonra en az 48 saat boyunca servis durumu, uygulama uyumluluğu ve olay günlükleri izlenir.
2. Pilot grubu: Üretim ortamını temsil eden ancak tam kritik olmayan sunucular bu gruba atanır. Farklı rollerdeki sunuculardan (dosya sunucusu, uygulama sunucusu, veritabanı sunucusu) birer temsilcinin bu grupta bulunması, güncellemelerin farklı iş yükleriyle uyumluluğunun doğrulanmasını sağlar. Test grubundan 48-72 saat sonra pilot gruba dağıtım yapılır.
3. Üretim grubu: Tüm kritik sunucular bu gruptadır. Pilot grubunda en az 72 saat sorunsuz çalışma doğrulandıktan sonra üretim grubuna dağıtım gerçekleştirilir. Bu dağıtım mutlaka planlı bakım penceresi içinde yapılır ve geri alma planı hazır olmalıdır.
Her kademe arasında bekleme süresi tanımlamak kritiktir. Bazı uyumluluk sorunları yama uygulandıktan hemen sonra değil, belirli koşullar tetiklendiğinde ortaya çıkar. Yetersiz bekleme süresi bu tür gecikmiş sorunların tespit edilmeden üretime taşınmasına neden olur.
Bakım penceresi ve geri alma planı
Güncelleme uygulamak, sunucuların yeniden başlatılmasını ve kısa süreli servis kesintilerini gerektirebilir. Bu kesintilerin iş operasyonlarını etkilememesi için bakım penceresi (maintenance window) tanımlanmalıdır. Bakım penceresi, güncellemelerin uygulanabileceği ve gerekirse geri alınabileceği, iş etkisinin en düşük olduğu zaman dilimidir.
Bakım penceresini planlarken şu adımlar izlenmelidir: Öncelikle iş birimlerinden düşük kullanım saatleri hakkında bilgi alın. Hafta sonu gece saatleri çoğu ortam için uygundur ancak 7/24 çalışan sistemlerde dönüşümlü bir plan gerekebilir. Bakım penceresi süresi, güncelleme sayısı ve geri alma ihtimaline göre yeterli uzunlukta belirlenmelidir; tipik olarak 2-4 saat yeterlidir.
Güncelleme uygulamadan önce mutlaka geri alma planı hazırlanmalıdır. Sanal sunucularda bu plan büyük ölçüde snapshot almakla çözülür. Hyper-V veya VMware ortamında güncelleme öncesi snapshot alınır; güncelleme sonrası sorun yaşanırsa snapshot'a geri dönülerek sunucu güncelleme öncesi durumuna saniyeler içinde getirilir. Fiziksel sunucularda ise sistem yedeği alınmalı ve Windows Update geri alma adımları belgelenmelidir.
# Hyper-V - Guncelleme oncesi snapshot al
Checkpoint-VM -Name "SRV-DC01" -SnapshotName "PrePatch-2026-04-18"
# Guncelleme baslatma
Invoke-WUInstall -ComputerName "SRV-DC01" -Script {
Install-WindowsUpdate -AcceptAll -AutoReboot
} -Confirm:$false
# Alternatif: wuauclt ile guncelleme tetikleme
wuauclt /detectnow
wuauclt /updatenow
# Guncelleme sonrasi bekleyen yeniden baslatma kontrolu
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" -ErrorAction SilentlyContinue
# Sorun yasanirsa snapshot'a geri don
Restore-VMSnapshot -Name "PrePatch-2026-04-18" -VMName "SRV-DC01" -Confirm:$falseGeri alma planı yalnızca teknik adımlardan ibaret olmamalıdır. Sorun tespit edildiğinde kimin karar vereceği, kimlerin bilgilendirileceği ve geri alma sonrası hangi kontrollerin yapılacağı da belgelenmelidir. Plansız bir geri alma, plansız bir güncelleme kadar kaotik olabilir.
Güncelleme sonrası kontrol listesi
Güncelleme uygulandıktan ve sunucu yeniden başlatıldıktan sonra her şeyin beklendiği gibi çalıştığından emin olmak için sistematik bir kontrol yapılmalıdır. Aşağıdaki liste bu kontrolleri kapsar:
- Kritik servislerin durumunu doğrulayın: Active Directory, DNS, DHCP, IIS, SQL Server gibi temel servislerin çalışır durumda olduğunu kontrol edin.
Get-Servicekomutuyla servis durumları listelenebilir. - Uygulama işlevselliğini test edin: Web uygulamalarında temel sayfaların yüklendiğini, veritabanı bağlantılarının kurulduğunu ve kritik iş akışlarının çalıştığını doğrulayın.
- Disk alanını kontrol edin: Güncelleme dosyaları ve geri alma verileri ek disk alanı tüketir. Sistem diskinde yeterli boş alan kaldığından emin olun.
- Olay günlüklerini inceleyin: Event Viewer'da Application ve System loglarında yeni hata veya uyarı olaylarını kontrol edin. Güncelleme sonrası ortaya çıkan hatalar genellikle burada görünür.
- Bekleyen yeniden başlatma durumunu kontrol edin: Bazı güncellemeler birden fazla yeniden başlatma gerektirebilir. Sunucunun bekleyen yeniden başlatma durumu olmadığını doğrulayın.
- Ağ bağlantısını doğrulayın: Sunucunun iç ağ ve dış ağ bağlantısının sağlıklı olduğunu, DNS çözümlemesinin çalıştığını kontrol edin.
- Yedekleme işlerini kontrol edin: Güncelleme sonrası zamanlanmış yedekleme görevlerinin hala çalışır durumda olduğunu doğrulayın.
- Performans metriklerini karşılaştırın: CPU, bellek ve disk I/O kullanımının güncelleme öncesindeki normal değerleriyle tutarlı olduğunu kontrol edin.
Sık yapılan hatalar
Güncelleme yönetimi sürecinde tekrarlayan hatalar, sürecin doğru kurgulanmadığına işaret eder. En yaygın hatalar ve neden sorun oluşturduklarını anlamak, sürecinizi güçlendirir.
Tüm güncellemeleri otomatik onaylamak: WSUS'ta auto-approve kuralı tanımlamak yönetim yükünü azaltır gibi görünse de test edilmemiş güncellemelerin doğrudan üretime dağıtılmasına neden olur. Özellikle feature update ve driver güncellemeleri uyumluluk sorunlarına yol açabilir. Güvenlik güncellemeleri için bile en azından test grubunda doğrulama yapılmalıdır.
Test grubu kullanmamak: Güncellemeleri doğrudan üretim sunucularına uygulamak, sorunların ancak iş etkisi oluştuktan sonra fark edilmesine yol açar. Tek bir test sunucusu bile bu riski önemli ölçüde azaltır.
Geri alma planı olmadan güncelleme yapmak: Güncelleme öncesi snapshot veya yedek alınmadığında, sorunlu bir yama geri alınamaz. Manuel geri alma denemesi saatler sürebilir ve her zaman başarılı olmaz.
Driver güncellemelerini yoksaymak: WSUS varsayılan yapılandırmasında driver güncellemeleri senkronize edilmez. Ancak kritik depolama veya ağ kartı sürücü güncellemeleri güvenlik yamaları kadar önemli olabilir. Driver güncellemelerini ayrı bir onay akışıyla değerlendirmek gerekir.
WSUS sunucu sağlığını izlememek: WSUS veritabanı zamanla büyür ve bakım yapılmazsa performans düşer, senkronizasyon hataları oluşur. Düzenli olarak WSUS Server Cleanup Wizard çalıştırılmalı ve veritabanı bakımı yapılmalıdır.
# WSUS sunucu temizligi
Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates
# WSUS veritabani bakim scripti (SUSDB)
# SQL Server Management Studio veya sqlcmd ile calistirilir
# Indeksleri yeniden olustur
USE SUSDB
GO
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD'
GOGüncelleme yönetimi, güncellemeleri uygulamaktan çok planlı bir süreç kurmakla ilgilidir.
Sonuç
Windows Server güncelleme yönetimi, güvenlik açıklarını kapatmanın ve sistem kararlılığını korumanın temel taşıdır. WSUS ile merkezi kontrol, aşamalı dağıtım grupları, planlı bakım pencereleri ve sistematik kontrol listeleri ile güncelleme süreci öngörülebilir ve güvenli hale gelir. Bu süreç bir kez kurgulandıktan sonra her ay tekrarlanabilir bir döngüye dönüşür.
Daha büyük ortamlarda SCCM ile ölçeklenebilir yama yönetimi için SCCM yönetim hizmetlerimi inceleyebilirsiniz. Genel altyapı yönetimi ve izleme ihtiyaçlarınız için sistem yönetimi hizmetleri sayfasına göz atabilirsiniz. Sorularınız veya mevcut ortamınıza özel bir güncelleme planı oluşturmak için benimle iletişime geçebilirsiniz.