Sunucu Yama Yönetimi: WSUS, Azure Update Manager ve Azure Arc

Aylık güvenlik güncellemesi yayımlandığında asıl soru “kuralım mı” değildir; hangi sunucuya, hangi sırayla, hangi geri dönüş planıyla kurulacağı ve kurulduğunun nasıl kanıtlanacağıdır. Microsoft’un WSUS’u kullanımdan kaldırılan (deprecated) özellikler listesine alması, birçok BT ekibi için bu soruyu yeniden açtı. Aşağıda WSUS, Configuration Manager, Azure Update Manager ve hotpatch’i sahadaki işletme yüküne göre karşılaştırıyor; bakım penceresi, halka (ring) planı, küme sunucuları ve uyum raporu için uygulanabilir bir düzen veriyoruz.

Elinizdeki seçenekler

Şirket içi ve hibrit Windows sunucuları için pratikte dört yol var:

• WSUS: Windows Server ile gelen, güncellemeleri yerelde onaylayıp dağıtan rol. Lisans maliyeti yok; raporlama ve zamanlama zayıf.
• Configuration Manager (MECM): Dağıtımı koleksiyonlar, bakım pencereleri ve ayrıntılı uyum raporlarıyla yönetir. Yazılım güncelleme noktası (SUP) altta yine WSUS’u kullanır.
• Azure Update Manager: Azure VM’lerini ve Azure Arc ile bağlanan şirket içi ya da başka buluttaki sunucuları tek konsoldan tarar ve zamanlar. Windows ile Linux’u birlikte yönetir.
• Hotpatch: Uygun sürüm ve lisans koşullarında güvenlik güncellemesini bellekteki koda yeniden başlatmadan uygular. Dağıtım aracı değildir; bir güncelleme yöntemidir.

Bunlar birbirini dışlamaz. Azure Update Manager güncellemenin ne zaman kurulacağını yönetirken sunucu dosyaları hâlâ yerel bir WSUS’tan çekebilir. Karışık düzen sahada sık görülür. Sorun çıkaran, kimin neyi yönettiğinin yazılı olmamasıdır.

WSUS’un durumu ve sınırları

Microsoft, Eylül 2024’te WSUS’u deprecated olarak duyurdu. Rol hemen kalkmıyor: mevcut Windows Server sürümlerinde yer almaya devam ediyor, güncellemeler WSUS kanalıyla yayımlanıyor; ancak role yeni yatırım yapılmıyor. Sürücü senkronizasyonu gibi alt özelliklerdeki değişiklikleri Microsoft Learn’deki kaldırılan özellikler sayfasından takip edin.

İşletmede WSUS’un bilinen zayıf noktaları:

• Zamanlama, Group Policy’deki otomatik güncelleme ayarlarına bağlıdır. “Bu sunucuyu bu gece 02:00’de güncelle, şu sırayla yeniden başlat” diyen bir orkestrasyon yok.
• Veritabanı (WID veya SQL) bakım görmezse şişer; konsol zaman aşımına düşer, istemciler tarama hatası vermeye başlar.
• Raporlar “onaylanan güncelleme kuruldu mu” sorusunu yanıtlar, ama birden fazla WSUS sunucusu veya Linux için birleşik görünüm vermez.

Sahada en sık gördüğümüz WSUS arızası, yıllardır temizlik yapılmamış ve superseded güncellemelerle dolmuş bir veritabanıdır. WSUS’la bir süre daha devam edecekseniz aşağıdaki temizliği takvime bağlayın; büyük veritabanlarında saatler sürebilir, mesai dışında çalıştırın:

Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteUpdates `
  -CleanupUnneededContentFiles -DeclineExpiredUpdates -DeclineSupersededUpdates

Azure Update Manager ve Azure Arc

Azure Update Manager, Azure Automation Update Management’ın yerini aldı ve Log Analytics ajanı yerine sunucunun kendi güncelleme mekanizmasını kullanıyor. Şirket içi sunucuyu yönetebilmesi için sunucunun önce Azure Arc ile bağlanması gerekir. Arc ajanı (Connected Machine agent) sunucuyu Azure’da bir kaynak olarak temsil eder; bundan sonra şunlar kullanılabilir:

• Periyodik değerlendirme: Eksik güncellemeleri otomatik tarar, sınıflandırmaya göre listeler.
• Bakım yapılandırması (maintenance configuration): Tekrarlayan pencere, dahil edilecek sınıflandırmalar, KB hariç tutmaları ve yeniden başlatma davranışı burada tanımlanır.
• Dinamik kapsam: Abonelik, kaynak grubu, konum veya etiket (tag) filtresiyle sunucuları otomatik olarak plana bağlar. Yeni sunucuya doğru etiketi vermek, onu doğru halkaya almaya yeter.
• Ön ve son olaylar (pre/post events): Bakımdan önce ve sonra betik veya otomasyon tetikler; uygulama hizmetini durdurmak, sağlık kontrolü yapmak gibi.

Ücret tarafında Azure VM’ler için hizmet ek ücret istemez; Arc ile bağlanan sunucularda sunucu başına aylık ücret uygulanır. Bazı lisans programları ve Microsoft Defender for Servers planları bu ücreti kapsayabilir. Fiyat ve kapsam değişebilir; karardan önce güncel fiyat sayfasına bakın. İşleyişin ayrıntısı için Azure Update Manager genel bakış belgesi doğru başlangıç noktasıdır.

Karşılaştırma

Karar için basit bir yol: Configuration Manager zaten çalışıyorsa sunucu yamasını orada tutmaya devam edin. MECM yoksa ve sunucu sayısı onlarla ifade ediliyorsa, Azure Update Manager’a geçmek çoğu zaman yeni bir şirket içi yönetim sunucusu kurmaktan daha az işletme yükü getirir. İnternet erişimi politika gereği kapalı olan izole ağlarda ise WSUS veya MECM gerçekçi seçenek olmaya devam eder. İzole ağ, bulut aracı kullanamaz.

Hotpatch ne zaman anlamlı

Hotpatch, Windows Server 2022 Datacenter: Azure Edition ile Azure’da başladı; Windows Server 2025 Standard ve Datacenter sürümlerinde Azure Arc üzerinden ücretli abonelikle şirket içi sunuculara da açıldı. Döngü şöyle işler: yılda dört taban (baseline) ayında kümülatif güncelleme kurulur ve yeniden başlatma gerekir; aradaki aylarda güvenlik güncellemeleri yeniden başlatmadan uygulanır. Yıllık yeniden başlatma sayısı on ikiden dörde iner.

En çok işe yaradığı yer, kesinti penceresi bulmanın zor olduğu, küme dışında tek başına çalışan kritik sunuculardır. Desteklenen sürüm, sanallaştırma tabanlı güvenlik (VBS) gibi önkoşullar ve abonelik koşulları sürüme göre değişiyor; uygulamadan önce Microsoft belgelerinden güncel gereksinimleri doğrulayın.

Bakım penceresi ve halka planı

Tüm sunuculara aynı gece yama basmak, hatalı bir güncellemenin bütün hizmetleri aynı anda düşürmesi demektir. Halka planı riski zamana yayar. Microsoft güncellemeleri her ayın ikinci salısı yayımlar; aşağıdaki örnek plan bu takvime göre kuruldu:

Bu tabloyu uygularken sahada atlanan noktalar:

• Yedekli çiftlerin (iki DC, iki DHCP, iki web sunucusu) üyelerini farklı halkalara koyun. Aynı gece ikisi birden giderse yedeklilik kâğıt üzerinde kalır.
• Her pencereden önce yedeğin başarılı bittiğini kontrol edin. Sanal sunucuda anlık görüntü (snapshot) kısa süreli geri dönüş aracıdır, yedek değildir.
• Aktif istismar edilen bir zafiyet için halkaları sıkıştıran bir “acil yama” prosedürü önceden yazılı olsun. O gece prosedür tartışılmaz.
• Yeniden başlatma sonrası doğrulama listesi tanımlayın: hizmet durumları, uygulama sağlık kontrolü, olay günlüğünde yeni hatalar.

Periyodik bakımın genel kapsamı için KOBİ’ler için sunucu bakım kontrol listesi yazısına, desteği biten sürümlerde yama alamama riski için Windows Server 2016 destek sonu geçiş planı yazısına bakın.

Kümelerde Cluster-Aware Updating

Failover Cluster düğümlerini klasik araçlarla güncellemek, roller boşaltılmadan düğümün yeniden başlaması riskini taşır. Sahada bunun sonucu, sanal makinelerin plansız taşınması ya da quorum’un sallanmasıdır. Cluster-Aware Updating (CAU) süreci düğüm düğüm yürütür: düğümü bakım moduna alır, rolleri diğer düğümlere taşır, güncellemeyi kurar, yeniden başlatır, kümeye geri alır ve sıradakine geçer.

CAU iki kipte çalışır. Kendi kendini güncelleme kipinde kümeye bir CAU rolü eklenir ve takvime göre çalışır; uzaktan güncelleme kipinde küme dışındaki bir yönetim makinesinden tetiklenir. Önce ortamın hazır olduğunu test edin, sonra tek seferlik bir çalıştırma yapın:

# Önkoşul kontrolü
Test-CauSetup -ClusterName CL-HV01

# Tek seferlik güncelleme çalıştırması
Invoke-CauRun -ClusterName CL-HV01 -CauPluginName Microsoft.WindowsUpdatePlugin `
  -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline -Force

# Takvimli, kendi kendini güncelleyen kip (her ayın 3. salı)
Add-CauClusterRole -ClusterName CL-HV01 -DaysOfWeek Tuesday -WeeksOfMonth 3 `
  -MaxFailedNodes 0 -RequireAllNodesOnline -EnableFirewallRules -Force

-RequireAllNodesOnline, bir düğüm zaten arızalıyken güncellemeye başlanmasını engeller. Bu parametreyi kaldırmayın. Azure Update Manager kullanıyorsanız küme düğümlerini aynı anda güncellenecek tek bir bakım yapılandırmasına koymayın; ya CAU ile devam edin ya da düğümleri ayrı pencerelere bölün. Küme tasarımının kendisi için Hyper-V Failover Cluster planlama yazısına bakabilirsiniz.

Yama uyumunu raporlama

Kurulduğunu kanıtlayamadığınız yama, denetimde kurulmamış sayılır. Sorulan sorular hep aynıdır: hangi sunucuda kaç kritik güncelleme eksik, en son ne zaman başarılı kurulum yapıldı, istisna olan sunucular hangileri ve neden?

Azure Update Manager değerlendirme sonuçlarını Azure Resource Graph’a yazar. Aşağıdaki sorgu Azure VM’ler ve Arc sunucuları için son değerlendirme durumunu listeler:

patchassessmentresources
| where type in~ ("microsoft.compute/virtualmachines/patchassessmentresults",
                  "microsoft.hybridcompute/machines/patchassessmentresults")
| project id, status = properties.status,
          lastAssessment = properties.lastModifiedDateTime,
          missing = properties.availablePatchCountByClassification

Arc kullanmayan ortamlarda en azından son kurulum tarihini toplayın. Get-HotFix her güncelleme türünü göstermez, ama sunucunun aylık kümülatif güncellemeyi alıp almadığını kabaca görmeye yeter:

$servers = Get-Content .\sunucular.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
  Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
} | Select-Object PSComputerName, HotFixID, InstalledOn

Bu raporu zamanlanmış görevle otomatik üretmek için PowerShell ile sunucu otomasyonu yazısındaki yaklaşımı kullanın. İstisnaları ayrı sütunda gösterin: üretici desteği yüzünden belirli bir güncellemeyi alamayan sunucu, sahibinin onayıyla ve bitiş tarihiyle kayda geçmeli. Tarihsiz istisna kalıcı açıktır.

Hibrit sunucu filosunda güncelleme altyapısını yeniden kurmak veya mevcut süreci düzenli bakıma bağlamak istiyorsanız sunucu ve bulut yönetimi ile teknik destek ve periyodik bakım sayfalarında nasıl çalıştığımızı görebilirsiniz.

Sık sorulan sorular

WSUS kullanımdan kaldırıldıysa mevcut sunucumuz çalışmayı bırakacak mı?

Hayır. Deprecated, rolün yeni özellik almayacağı ve ileride kaldırılabileceği anlamına gelir. Mevcut WSUS sunucuları güncelleme almaya ve dağıtmaya devam eder; değişen şey, uzun vadeli altyapı kararını bu bilgiyle vermeniz gerektiğidir.

Azure Update Manager kullanmak için sunucuların internete doğrudan çıkması gerekir mi?

Azure Arc ajanının Azure uç noktalarına HTTPS ile ulaşması gerekir; bu erişim proxy veya Private Link üzerinden de sağlanabilir. Güncelleme dosyaları ise sunucunun yapılandırılmış kaynağından, yani Windows Update’ten veya WSUS’tan iner.

Hotpatch ile sunucular hiç yeniden başlatılmaz mı?

Başlatılır. Hotpatch döngüsünde yılda dört taban güncellemesi yeniden başlatma ister; aradaki aylarda gelen güvenlik güncellemeleri yeniden başlatmadan uygulanır. Güvenlik dışı bazı güncellemeler ve .NET gibi bileşenler de yine yeniden başlatma isteyebilir.

Domain controller’ları hangi halkada güncellemek gerekir?

DC’ler pilot halkadan birkaç gün sonra, aynı anda değil sırayla güncellenir. Her etki alanında en az bir DC’nin her an çevrimiçi kalacağı şekilde iki ayrı bakım penceresi tanımlayın.