Merhaba

Windows Server 2025 üzerinde sıfırdan kurulan WSUS (Windows Server Update Services) sunucularında, initial synchronization (başlangıç senkronizasyonu) aşamasında takılan ve bir türlü tamamlanamayan bir sorun gündeme geldi. Sorun Haziran 2026’dan bu yana yeni kurulan WSUS (Windows Server Update Services) sunucularını etkiliyor ve kaynağı net: Windows Subsystem for Linux (WSL) ürün kategorisi.

Bu yazıda sorunun ne olduğunu, kök nedenini, hangi ortamlarda görüldüğünü ve elimizdeki geçici çözümü (workaround) derledim.

Sorun Neyle Ortaya Çıkıyor?

Microsoft Q&A üzerinde paylaşılan bir vaka, yeni kurulan bir WSUS (Windows Server Update Services) sunucusunda category sync (kategori senkronizasyonu) aşamasının sürekli aynı noktada hata verdiğini gösteriyor. WID (Windows Internal Database) kullanan, upstream olarak doğrudan Microsoft Update’e (proxy’siz) bağlanan bir Windows Server 2025 WSUS (Windows Server Update Services) kurulumunda, 19 configuration update’ten 18’i sorunsuz import ediliyor; yalnızca bir tanesi sürekli patlıyor.

Hata mesajı şöyle:

invalid update identity (AtLeastOne Prerequisite) in XML for update CF56FF39-8BA5-4177-9265-E30D4DD58CF5 revision 100

SQL tarafında ise error 50000 olarak invalid update identity in XML for update şeklinde loglanıyor.

Bu davranış Windows Server 2022 üzerinde de bağımsız olarak doğrulanmış durumda; yani sorun tek bir kurulumla veya belirli bir yama seviyesiyle sınırlı değil, GA’dan Ağustos 2026 cumulative update’ine kadar bütün patch seviyelerinde görülebiliyor.

Kök Neden: Eksik Prerequisite Kategorisi

Sorunun merkezinde CF56FF39-8BA5-4177-9265-E30D4DD58CF5 kimlikli WSL (Windows Subsystem for Linux) ürün kategorisi var. Bu kategorinin importu için iki prerequisite (ön koşul) gerekiyor:

1. Microsoft company category (56309036-4c77-4dd9-951a-99ee9c246a94): bu, sorunlu sunucularda mevcut.
2. Windows Subsystem for Linux product-family category (79d72fdc-efcd-4911-8d4f-a3f00c69bdf4, revision 201): bu kategori Microsoft Update tarafından hiç teslim edilmiyor.

İkinci prerequisite olmadan child category import edilemiyor ve senkronizasyon her seferinde aynı noktada patlıyor. Daha da rahatsız edici olan kısım şu: handshake anchor hiçbir zaman kaydedilmediği için WSUS (Windows Server Update Services) sürekli aynı işlemi tekrar tekrar deniyor, yani sonsuz bir retry döngüsüne giriyor.

Başka bir deyişle: Microsoft’un sync endpoint’i, WSL (Windows Subsystem for Linux) kategorisinin bağımlı olduğu üst kategoriyi (product-family) sunmuyor, ama alt kategoriyi (product) sunmaya devam ediyor. Bu tutarsızlık da WSUS’un XML validation aşamasında takılmasına neden oluyor.

Ortam Detayları

Sorunun görüldüğü tipik ortam özeti aşağıda.

Log Kanıtı: SoftwareDistribution.log

Konuyla ilgili paylaşılan detaylı bir vaka raporunda, sorunun SUSDB seviyesinde nasıl göründüğü de belgelenmiş. SoftwareDistribution.log dosyasından ilgili kesit şöyle:

CatalogSyncAgentCore.SyncConfigUpdatesFromUSS  Need 4239 config updates, 19 are new
DBConnection.ExecuteCommandNoResult  SqlException occurred. Number 50000 and message invalid update identity (AtLeastOne Prerequisite) in XML for update CF56FF39-8BA5-4177-9265-E30D4DD58CF5\100
CatalogSyncAgentCore.ImportMultipleUpdates  Imported 18/19 updates in 2 iterations; 1 will be retried
CatalogSyncAgentCore.SyncConfigUpdatesFromUSS  1 update(s) could not be imported after repeated retry:
CatalogSyncAgentCore.SyncConfigUpdatesFromUSS  Bad Update Revision #0: cf56ff39-8ba5-4177-9265-e30d4dd58cf5\100
CatalogSyncAgentCore.SyncConfigUpdatesFromUSS  new handshake anchor will not be saved.
CatalogSyncAgentCore.ExecuteSyncProtocol  One or more updates failed to import to local database. - Microsoft.UpdateServices.ServerSync.CatalogSyncException

Aynı raporda, sağlıklı çalışan bir WSUS sunucusuyla sorunlu sunucunun SUSDB’si karşılaştırılmış. Sağlıklı sunucuda tbUpdate tablosunda hem CF56FF39-... (Windows Subsystem for Linux, revizyon 100) hem de onun prerequisite’i 79d72fdc-efcd-4911-8d4f-a3f00c69bdf4 (revizyon 201) kayıtlı. Sorunlu sunucuda ise ikinci kayıt tbUpdate tablosunda hiçbir revizyonda mevcut değil; yani import başarısız olduğu için satır hiç yazılmıyor. Ayrıca ilginç bir detay: “AtLeastOne Prerequisite” koşulu mantıken “Microsoft” kategorisinin varlığıyla zaten sağlanıyor, ama import stored procedure’ü koşulu değerlendirmeden önce referans verilen tüm identity’leri çözmeye çalışıyor; tek bir çözülemeyen identity bile importu düşürüyor.

Ağ bağlantısı, DNS çözümlemesi ve sws.update.microsoft.com adresine TLS doğrulaması (log’da “SSL validation succeeded” olarak görülüyor) sorunsuz çalışıyor; yani sorun ağ veya sertifika kaynaklı değil.

Elenen Olası Nedenler

Aynı vaka raporunda üç olası neden de test edilip elenmiş:

• KB5121986 (TestProduct detectoid birikimi): Bu hotfix’in kapsadığı senaryoda SUSDB’de Product Detectoid for ProductName TestProduct başlıklı detectoid’ler birikiyor. Sorunlu sunucuda bu tür detectoid sayısı 0; yani bu hotfix’in çözdüğü sorun bu değil.
• MaxXMLPerRequest: Bu ayar yalnızca downstream istemcilere dönen XML boyutunu sınırlıyor, Microsoft Update’ten alınan veriyi etkilemiyor. Hata zaten veritabanına import aşamasında, veri alındıktan sonra oluşuyor.
• SUSDB bozulması: Sorunlu sunucu sıfırdan kurulmuş, veritabanında manuel bir değişiklik yok. Ayrıca aynı hata Haziran 2026’dan bu yana Windows Server 2019/2022/2025 üzerinde temiz kurulumlarda bağımsız olarak bildirilmiş (Bkz. Microsoft Q&A soru 5920536), bu da sorunun tek bir sunucuya özgü bir bozulma olmadığını gösteriyor.

Geçici Çözüm (Workaround)

Şu an için resmi bir Microsoft düzeltmesi yok. Toplulukta doğrulanan geçici çözüm, WSUS (Windows Server Update Services) ürün listesinden WSL (Windows Subsystem for Linux) kategorisini kaldırmak:

1. WSUS konsolunda Options > Products and Classifications kısmına gidin.
2. Ürün listesinden WSL (Windows Subsystem for Linux) seçimini kaldırın.
3. Senkronizasyonu yeniden çalıştırın.

Bu adım WSL (Windows Subsystem for Linux)’i sunuculardan veya istemcilerden kaldırmıyor, sadece WSUS (Windows Server Update Services)’un senkronize etmeye çalıştığı ürün listesinden çıkarıyor. Bu şekilde WSUS, hiç teslim edilmeyen prerequisite’e takılmadan diğer 18 kategoriyi normal şekilde import edebiliyor. Çözümün hem Windows Server 2022 hem de Windows Server 2025 üzerinde çalıştığı toplulukta doğrulandı.

Alternatif Geçici Çözüm: wsusutil.exe export/import

Ürün listesinden WSL’i çıkarmanın yanında, detaylı bir vaka raporunda henüz uygulanmamış ama mantıklı görünen ikinci bir yaklaşım da öneriliyor: sağlıklı çalışan başka bir WSUS sunucusundan wsusutil.exe export ile metadata dışa aktarıp sorunlu sunucuda wsusutil.exe import ile içeri almak (ya da sorunlu sunucuyu geçici olarak sağlıklı sunucuyu upstream olarak kullanacak şekilde ayarlamak). Bu yöntemin hem eksik olan üst kategoriyi (79d72fdc-...\201) hem de alt kategoriyi (CF56FF39-...\100) sorunlu sunucuya taşıması ve ardından Microsoft Update ile senkronizasyonun sorunsuz devam etmesi bekleniyor. Ancak bu yöntem sağlıklı bir WSUS sunucusuna erişim gerektiriyor ve genel bir çözüm değil; ürün listesinden WSL’i çıkarmak çoğu ortam için daha pratik.

Önemli Not

18 Temmuz 2026’da yayınlanan KB5121986 hotfix’i bu senaryoyu kapsamıyor; yani bu sorunun çözümü değil. Ayrıca burada paylaşılan kök neden analizi Microsoft tarafından resmi olarak doğrulanmış değil, kullanıcı gözlemlerine ve loglara dayanıyor. Yine de birden fazla bağımsız raporun aynı bulguya işaret etmesi, analizin doğru yönde olduğunu gösteriyor.

Genel Değerlendirme

WSUS (Windows Server Update Services) ortamı Haziran 2026’dan sonra sıfırdan kuruluyorsa ve initial sync bir türlü tamamlanmıyorsa, ilk bakılacak yer WSL kategorisi olmalı. Özellikle WID tabanlı, doğrudan Microsoft Update’e bağlanan kurulumlarda bu senaryo daha sık karşımıza çıkıyor. WSL (Windows Subsystem for Linux)’i WSUS (Windows Server Update Services) ürün listesinden geçici olarak çıkarmak, senkronizasyonu tamamlamak için pratik ve düşük riskli bir adım; ancak bu tür bir değişikliği uygulamadan önce mevcut ürün seçim listenizin bir yedeğini almanızı öneririm.

Microsoft’tan resmi bir açıklama veya sync endpoint düzeltmesi geldiğinde bu yazıyı güncelleyeceğim.

Başka bir yazımızda görüşmek dileğiyle…