Azure Local Güncellemeleri Değişiyor: 2610 ve Patch Tuesday Döneminde Runbook’unuzu Nasıl Güncellemelisiniz?
Azure Local (eski adıyla Azure Stack HCI) ortamlarında güncelleme yönetimi, operasyon ekiplerinin en çok dikkat etmesi gereken konulardan biri. Ekim 2026’da yayımlanan 2610 sürümü (solution version 12.2610.1004.50) ve Kasım ayında devreye girecek değişiklikler, güncelleme sürecini daha düzenli ve görünür hale getiriyor.
Bu değişikliklerle birlikte hem güncelleme takvimini hem de mevcut update runbook’larını gözden geçirmek gerekiyor.
Öne çıkan yenilikler
Azure Local güncellemelerinde öne çıkan değişiklikler şöyle:
- Patch Tuesday güvenlik güncellemeleri: Kasım 2026’dan itibaren işletim sisteminin en son cumulative update’i (LCU) ve .NET güncellemeleri, bir sonraki feature veya cumulative release beklenmeden Patch Tuesday haftasında yayımlanacak.
- Güvenlik odaklı güncelleme davranışı: En güncel Azure Local sürümünü kullanan sistemlerde bu paketler security-only update olarak çalışacak. Uygun bir eski sürümdeki sistemlerde ise güncelleme, hedef security release sürümüne ulaşmak için gerekli Azure Local güvenlik güncellemelerini de içerebilecek.
- Birleşik OS ve SBE güncellemesi: İşletim sistemi güncellemeleriyle OEM firmware ve driver paketleri, yani Solution Builder Extension (SBE), artık tek bir koordineli Cluster-Aware Updating (CAU) çalışmasında uygulanabilecek. Böylece ayrı güncelleme turları ve yeniden başlatma sayısı azalacak.
- Yeni
Get-SolutionHealthSummarykomutu: Son solution health check sonuçlarını özetleyerek öncelikle giderilmesi gereken kritik ve önemli sorunları gösteriyor. - Yarı yıllık Composed ISO: Composed ISO yayın takvimi, OEM doğrulama ve sürüm döngüleriyle uyumlu olacak şekilde yarı yıllık döneme geçiyor.
Önceki sürümlerde gelen bazı yenilikler de bu süreçle yakından ilişkili:
- 2608 sürümü, güncellemeyi önceden hazırlayıp daha sonra yüklemeye imkân veren prepare updates workflow’unu ve OEM doğrulaması bekleyen feature update’ler için Pending OEM Validation durumunu getirdi.
- 2607 sürümü, sınırlı bağlantı veya offline ortamlar için update paketlerinin Azure portal üzerinden indirilmesini sağladı.
Bu değişiklikler neden önemli?
Yeni Patch Tuesday takvimi, Azure Local güncellemelerini iki ayrı operasyon akışı olarak planlamayı gerektiriyor:
- Patch Tuesday dönemine bağlı güvenlik güncellemeleri
- Aylık 26xx sürümleriyle yayımlanan feature ve solution güncellemeleri
OEM tarafından doğrulanması gereken sistemlerde feature update’in portaldaki durumu Pending OEM Validation olabilir. Bu, çoğu durumda bir hata veya arıza anlamına gelmez; ilgili donanım için OEM doğrulamasının beklendiğini gösterir.
Bu nedenle bir güncelleme portalda görünmesine rağmen yüklenemiyorsa, önce update durumunu ve OEM doğrulama sürecini kontrol etmek gerekir.
Güncelleme öncesi kontrol runbook’u
Aşağıdaki örnekler, güncelleme öncesi temel kontrolleri ve sürecin PowerShell ile nasıl izlenebileceğini gösteriyor. Get-SolutionHealthSummary komutu 2610 ve sonraki sürümlerde kullanılabilir.
1. Mevcut sürümü ve ortam durumunu kontrol edin
Get-SolutionUpdateEnvironment |
Select-Object State, CurrentVersion, CurrentSbeVersion, HealthState
HealthState sağlıklı değilse güncelleme işlemine başlamadan önce mevcut sorunları inceleyin. Sağlık durumu sorunlu bir cluster üzerinde update başlatmak, sürecin başarısız olmasına veya beklenmeyen sorunlara yol açabilir.
2. Health summary sonuçlarını inceleyin
Get-SolutionHealthSummary
Bu komut, son health check sonuçlarını daha kısa ve okunabilir bir biçimde sunar. Güncelleme öncesinde Critical olarak işaretlenen sorunları giderin. Important bulguları da inceleyin; bunlar güncelleme adımlarında hata olarak tekrar karşınıza çıkabilir.
Destek kaydı açmanız gerekirse 2610 sürümündeki SANDiagnostics rolü, SAN tabanlı dağıtımlarda log filtrelemeye yardımcı olabilir. Ayrıca 2601 sürümünden itibaren diagnostic log’lar Azure portal üzerinden de toplanabiliyor.
3. Kullanılabilir güncellemeleri ve durumlarını kontrol edin
Get-SolutionUpdate |
Select-Object DisplayName, Version, State, PackageType |
Format-Table -AutoSize
State sütununu dikkatle inceleyin. 2608 ile gelen Pending OEM Validation durumu, OEM doğrulaması bekleyen sistemlerde görülebilir ve beklenen bir durum olabilir.
4. Güncellemeyi başlatın veya önceden hazırlayın
Durumu Ready olan en güncel güncellemeyi bulup başlatmak için örnek:
$Update = Get-SolutionUpdate |
Where-Object { $_.State -eq 'Ready' } |
Sort-Object Version -Descending |
Select-Object -First 1
if ($null -ne $Update) {
Write-Host "Starting update: $($Update.DisplayName) ($($Update.Version))"
$Update | Start-SolutionUpdate
} else {
Write-Host "No update in a 'Ready' state - nothing to do."
}
İndirme ve hazırlık adımlarını bakım penceresinden önce tamamlayıp kurulumu daha sonra başlatmak istiyorsanız, 2608 sürümüyle gelen prepare updates workflow’unu değerlendirin. Otomasyona geçmeden önce ortamınız için geçerli adımları ve güncel komutları ürün dokümantasyonundan doğrulayın.
5. Güncelleme ilerlemesini izleyin
Aşağıdaki örnek, update durumunu belirli aralıklarla kontrol etmek için başlangıç noktası olarak kullanılabilir:
$Stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
:MonitorUpdate while ($true) {
$Run = Get-SolutionUpdate |
Where-Object {
$_.State -like '*Installing*' -or
$_.State -eq 'Installed' -or
$_.State -like '*Failed*'
} |
Select-Object -First 1
switch -Wildcard ($Run.State) {
'Installed' {
Write-Host "Update installed."
break MonitorUpdate
}
'*Failed*' {
throw "Update failed - state: $($Run.State)"
}
default {
Write-Host "Update state: $($Run.State) (sleeping 5 minutes)"
Start-Sleep -Seconds 300
}
}
if ($Stopwatch.Elapsed.TotalHours -gt 12) {
throw "Timeout Exceeded"
}
}
Update state değerleri ortama ve sürüme göre farklılık gösterebileceğinden, script’i otomasyona eklemeden önce kendi ortamınızda dönen değerleri doğrulayın. İlerlemeyi Azure portal veya Azure Update Manager üzerinden de takip edebilirsiniz.
Güncelleme sürecinde yapılması gerekenler
Yeni değişikliklere uyum sağlamak için güncelleme planınızda şu adımları değerlendirin:
- Patch Tuesday sonrasına aylık bir bakım aralığı ekleyin. Güvenlik güncellemelerini feature update takviminden ayrı planlayın.
- Desteklenen update path’lerini takip edin. Güvenlik güncellemeleri yalnızca desteklenen yollar üzerinden uygulanabilir. Sürümler arasında çok geride kalan cluster’larda aylık bakım süreci zorlaşabilir.
- SBE takvimini OEM’inizle eşleştirin. OS ve SBE güncellemeleri tek CAU çalışmasında uygulanabildiği için firmware ve driver paketlerinin zamanlaması önem kazanıyor.
- Health summary kontrolünü otomasyona ekleyin. Jenkins, Azure DevOps veya GitHub Actions gibi pipeline’larda kritik sorunlar varsa
Start-SolutionUpdateöncesinde süreci durdurun. - Sınırlı bağlantılı lokasyonlar için indirme sürecini önceden deneyin. Azure portal üzerinden paket indirme ve ardından paketi içeri aktarma adımlarını bir bakım penceresini beklemeden test edin.
Azure Local güncellemeleri daha sık, öngörülebilir ve güncellemenin neden uygulanamadığını daha anlaşılır biçimde gösteren bir yapıya doğru ilerliyor. Patch Tuesday güvenlik güncellemeleri, birleşik OS ve SBE CAU süreci ve yeni health summary komutu; bakım planlarını ve otomasyonları güncellemek için iyi bir fırsat sunuyor.
Kasım ayındaki güvenlik güncellemesi döneminden önce runbook’unuzu gözden geçirmek, OEM doğrulama adımlarını planlamak ve health check sonuçlarını güncelleme ön koşulu hâline getirmek operasyonel hazırlığı artıracaktır.







