2011’den bu yana Windows cihazları koruyan Secure Boot sertifika altyapısı değiştiriliyor. Intune ile yönetilen Windows 11 cihazlarda yeni Secure Boot 2023 sertifikalarının Haziran 2026’dan önce UEFI veritabanına yazılmış olması gerekiyor. Bu tarihin ardından geçişi tamamlamamış cihazlar, Secure Boot ile ilgili gelecekteki güvenlik güncellemelerini sorunsuz alamayabilir.
Sorun şu: Mayıs 2026 kümülatif güncellemesini yüklemek, geçişin gerçekten tamamlandığı anlamına gelmiyor. Bazı cihazlar süreç ortasında takılıp yeniden başlatma bekliyor. Diğerleri otomatik tetikleyiciyi hiç alamıyor; Microsoft’un telemetri tabanlı kademeli dağıtımı, yüksek güven skoru veremediği sistemleri atlıyor. Co-managed ortamlarda ise aynı cihaz hem Intune’da hem SCCM’de sağlıklı görünürken asıl UEFI sertifika veritabanı hiç değişmemiş olabiliyor.
Bu yazı, Intune Remediations kullanarak production ortama hazır bir Secure Boot CA 2023 tespit ve düzeltme iş akışını adım adım anlatıyor. Çözüm; iki PowerShell scripti, altı durumlu bir uyumluluk modeli, güne dayalı yeniden başlatma bildirimleri, UEFI veritabanı doğrulaması ve gerçek ortam dağıtımları için bir doğrulama listesi içeriyor.
Bu bölüm Intune implementasyonuna odaklanıyor. SCCM Configuration Baseline ve co-managed dağıtım senaryoları bir sonraki bölümde ayrıca ele alınacak.
Kapsam: Secure Boot etkin, Intune veya Compliance workload’u Intune’a taşınmış co-management ile yönetilen Windows 11 cihazlar. Windows 10 senaryoları ayrı servicing ve doğrulama adımları gerektirdiğinden bu kılavuzun kapsamı dışındadır.
Secure Boot Sertifika Güncellemesi Nasıl Çalışır?
Windows bu süreçte standart bir güncelleme paketi değil, registry tetikleyicili bir servicing iş akışı kullanıyor. HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates değeri 0x5944 olarak ayarlandığında Windows yerleşik zamanlanmış görevi tetikliyor: \Microsoft\Windows\PI\Secure-Boot-Update
Görev yaklaşık her 12 saatte bir çalışarak Secure Boot sertifika değişikliklerini bir veya iki yeniden başlatma üzerinden uyguluyor.
HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing UEFICA2023Status → NotStarted | InProgress | Updated WindowsUEFICA2023Capable → 0 | 1 | 2
Uyumluluk tespiti için yalnızca bu registry değerlerine güvenmenin sorunu şu: UEFICA2023Status = Updated, servicing iş akışının tamamlandığını düşündüğünü gösterir, sertifikanın gerçekten UEFI veritabanında olduğunu değil. Firmware yazma hataları ve yeniden başlatma kesintileri, registry’yi Updated gösterirken UEFI DB’yi değişmeden bırakabilir.
Tespit scripti bunu iki katmanlı bir yaklaşımla çözüyor. 1. Katman registry’yi okur. 2. Katman, Microsoft Windows Production PCA 2023 parmak izinin UEFI İmza Veritabanı’nda gerçekten bulunup bulunmadığını doğrulamak için Get-SecureBootUEFI komutunu çalıştırır. Cihaz ancak her iki katman da geçtiğinde Compliant durumuna ulaşır.
Uyumluluk Durum Modeli
İş akışı, cihazları sadece uyumlu veya uyumsuz olarak işaretlemek yerine, doğrudan düzeltme ve eskalasyon eylemlerine karşılık gelen altı operasyonel durum kullanıyor.
Her tespit çalışması bu durumlardan birini, SecureBootCA2023 kaynağı altında Windows Application log’una yazar. Bu sayede durumlar, log dosyalarını ayrıştırmaya gerek kalmadan CMPivot ve Log Analytics üzerinden sorgulanabilir hale gelir.
Tespit ve Düzeltme Scriptleri
Her iki script da SYSTEM hesabıyla 64-bit PowerShell üzerinde çalışıyor. 64-bit süreç zorunludur; Secure Boot servicing registry yolları 32-bit bir PowerShell host üzerinden erişildiğinde eksik veya yanıltıcı sonuçlar dönebilir.
Tespit scripti
Tespit scripti tamamen salt okunurdur. Durumu değerlendirir, operasyonel olayları yazar ve çıkar. Registry’yi hiçbir zaman değiştirmez veya düzeltme eylemlerini tetiklemez.
Tespit iş akışı
• Scriptin 64-bit süreçte çalıştığını doğrula
• Secure Boot’un etkin olduğunu doğrula Devre dışıysa → NotApplicable (çıkış 0)
• 1. Katman: Registry’den servicing durumunu doğrula (NotStarted / InProgress / Updated / Capable kontrolü)
• 2. Katman: Get-SecureBootUEFI ile UEFI DB’yi doğrudan doğrula parmak izi bulunursa Compliant (çıkış 0), bulunamazsa ManualReview (çıkış 1)
Tespit Scriptini İndir: Detect-SecureBootCA2023.ps1
Düzeltme Scripti
Düzeltme scripti üç şey yapar, fazlasını değil:
• Servicing mekanizmasını tetiklemek için AvailableUpdates değerini 0x5944 olarak ayarlar
• \Microsoft\Windows\PI\Secure-Boot-Update zamanlanmış görevini başlatır
• Oturum açmış kullanıcıya toast bildirimi gönderir
Zorla yeniden başlatma kullanılmıyor. Yeniden başlatma kontrolü aktif oturumları ve üretim iş yükünü engellemekten kaçınmak için kullanıcıda kalıyor.
Güne dayalı bildirim kademeleri
Düzeltme Scriptini İndir: Remediate-SecureBootCA2023.ps1
Neden Settings Catalog Kullanılmıyor?
Intune Settings Catalog bir Secure Boot politika düğümü içeriyor, ancak bu karışık sürüm ortamlarında güvenilirlik sorunlarına yol açıyor. Başlangıçta Windows Pro olarak dağıtılıp daha sonra abonelik aktivasyonuyla Enterprise’a yükseltilen cihazlar, CSP katmanından Error 65000 dönebilir. Politika başarıyla uygulanmış olsa bile uyumluluk sinyali güvenilmez hale gelir.
Gerçek dünya ortamlarında yaygın olan, Windows Pro ve Enterprise lisans durumlarının karışık olduğu filolarda bu durum tutarsız raporlamaya yol açar ve yalnızca etkilenmeyen cihazları dinamik olarak hedeflemenin güvenilir bir yolu kalmaz.
Script tabanlı remediation yaklaşımı CSP bağımlılığını tamamen ortadan kaldırıyor ve desteklenen tüm Windows 11 sürümlerinde tutarlı davranıyor.
Paketi Oluşturma
Intune portalında Devices > Remediations > Create yolunu izleyin.
Basics Sekmesi
Settings Sekmesi
Assignments
Hedef grup: Intune ile yönetilen Windows 11 cihazlarınızı içeren bir grup oluşturun veya mevcut bir grubu kullanın. Co-managed ortamlar için Compliance workload’u Intune’a atanmış cihazları hedefleyin.
Intune’a kayıtlı cihazlar için dinamik grup kuralı:
(device.deviceManagementAppId -eq “0000000a-0000-0000-c000-000000000000”)
Zamanlama: Günlük. Uyumlu bir cihazda tespit scripti üç saniyenin altında tamamlanıyor; günlük değerlendirme bir performans sorunu oluşturmuyor.
Çalıştığını Doğrulama
Geniş ölçekli dağıtım öncesinde tek bir test cihazında doğrulama yapın. Kontrol edilmesi gereken dört şey var.
1. Intune Management Extension Logu
%ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
Intune’un yürütme zinciri buradan başlar. Remediation zamanlaması tetiklendiğinde IME, önce tespit scriptini, tespit çıkış kodu 1 dönerse ardından düzeltme scriptini çalıştırmak için agentexecutor.exe’yi çağırır. Scriptler yerel olarak C:\WINDOWS\IMECache\HealthScripts\ altında önbelleğe alınır.
2. Script Log Dosyaları
%ProgramData%\Microsoft\IntuneManagementExtension\Logs\SecureBoot-Detection.log %ProgramData%\Microsoft\IntuneManagementExtension\Logs\SecureBoot-Remediation.log
Remediation logu kritik sıralamayı doğrular: AvailableUpdates değeri 0x5944 olarak ayarlandı, zamanlanmış görev tetiklendi, kullanıcı oturumu tespit edildi ve toast bildirimi gönderildi.
3. Yeniden Başlatma Bildirimi
Bildirim, SYSTEM bağlamından herhangi bir müdahale olmaksızın oturum açmış kullanıcının oturumuna ulaşır. Gün 1’de ton bilgilendiricidir; kullanıcı iki seçenek görür ve ne zaman yeniden başlatacağına kendisi karar verir.
Bu bildirim zamanlanmış görev değil, WTSQueryUserToken ve CreateProcessAsUser üzerinden iletilir. Zamanlanmış görev yaklaşımı Entra ID’ye katılmış cihazlarda sessizce başarısız olur; Windows Task Scheduler bulut SID’lerini aktif oturuma çözemez. Win32 oturum token yaklaşımı domain-joined, Entra ID joined ve hibrit yapılandırmaların tamamında tutarlı çalışır.
4. Registry Durumu
Remediation çalışmadan önce cihaz değiştirilmemiş durumu gösterir:
- UEFICA2023Status = NotStarted
- WindowsUEFICA2023Capable = 2
- AvailableUpdates = 0
Remediation ve yeniden başlatma sonrasında servicing iş akışı tamamlanmıştır:
- UEFICA2023Status = Updated
- WindowsUEFICA2023Capable = 2
- AvailableUpdates = 16384
AvailableUpdates = 16384 (0x4000) değeri, servicing görevi tamamlandıktan sonra Windows’un kendisi tarafından yazılır. Bu değeri görmek, yalnızca scriptin çalıştığını değil, Windows’un güncellemeyi işlediğini kanıtlar.
5. Windows Olay Logu
Olay Görüntüleyicisi → Windows Logs → Application → Kaynak: SecureBootCA2023 ile filtreleyin.
Intune Portal’da İzleme
Devices → Remediations → Remediation Secure Boot CA 2023 → Device status yolunu izleyin.
Pre-remediation detection output sütunu, her cihaz için tespit scriptinin durum dizesini gösterir. Bu operasyonel görünümünüzdür; hangi cihazların PendingRestart (tek bir yeniden başlatma uzakta), hangilerin ManualReview (OEM incelemesi gerekiyor) durumunda olduğunu tek bakışta görebilirsiniz.
Belirli durumlara daha yakından bakmak için portal’dan cihaz listesini CSV olarak dışa aktarın ve Pre-remediation detection output sütununa göre filtreleyin.
Sonuç
Bu noktada bir Remediation paketi dağıtıldı, bir test cihazı doğrulandı ve her uyumluluk durumunun operasyonel olarak ne anlama geldiği netleşti. Tespit scripti günlük çalışıyor, remediation gerektiğinde tetikleniyor ve kullanıcılar hiçbir şey zorla yapılmadan, görmezden gelirlerse tırmanan bir bildirim alıyor.
Daha geniş dağıtıma geçerken akılda tutulması gereken birkaç nokta:
- ManualReview durumuna düşen cihazlar bir script hatası değil, scriptin doğru tespit ettiği ancak düzeltemediği bir firmware sorunudur. Bunları ayrıca takip edin ve OEM desteği ya da donanım yenileme döngüsü üzerinden çözün.
- PendingRestart durumunda uzun süre kalan cihazlar teknik değil, kullanıcı davranışı sorunudur. Gün 7 bildirimleri onları harekete geçirmiyorsa, bu bir script değişikliği için değil, son kullanıcı iletişim planınız için bir konuşmadır.
Bir Windows özellik güncellemesi ya da BIOS sıfırlamasının ardından bir cihazın Compliant’tan uyumsuz duruma geçtiğini görürseniz, remediation bir sonraki değerlendirme döngüsünde otomatik olarak yeniden tetiklenecektir. Idempotent tasarım, herhangi bir manuel müdahale gerektirmeden gerilemeyi ele alır.
