SCCM Software Updates Deployments Troubleshooting – 2

Herkese Merhaba;

Software Updates troubleshooting makalemizin 2.’sinde yine önemli bir konuyu sizlere aktarmak istiyorum.

Normalde SCCM SUP rolü için bildiğiniz gibi bir WSUS’a ihtiyacımız var. SCCM Server üstünde kurulabileceği gibi farklı bir server’a da konumlandırabileceğiniz WSUS ile ilgili son dönemler de CPU ve memory’nin sürekli pick yaptığı ve sistem altyapısında gereksiz bir network trafiği ile ilgili bir durumla karşı karşıya kalabilirsiniz.

Bir WSUS , best practice’de 60.000 client’a kadar, bir Software Update Point role yüklü server’da normalde 25.000 client’a kadar destek verebildiği MS tarafından söylenmektedir.

https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/size-and-scale-numbers

https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127528

Ancak prod. ortamda baktığınızda bu kadar makineye sahip olmasak da bu sorunla karşılaşmamız çok yüksek ihtimal.

İlk bakmamız gereken şey IIS üzerinde WSUS Pool stop durumda mıdır değil midir? Eğer siz makinelerde Software Update scan cycle başlatıp veya Update Deployment’dan bir süre sonra WSUS Pool’un stop olduğunu görüyorsanız (ki bu uzun süreden beri süre gelen bir durum) yapılması gereken Pool ile ilgili bazı ayarları değiştirmektir.

Bunlardan ilki de WSUS Pool’un kulandığı memory limitini artırmak. Default olarak yaklaşık 2 gb olarak ayarlı olan bu değer, iş yüküne karşı yeterli olmadığında memory değerini artırmak en azından pool’un stop durumunu ortadan kaldıracaktır.

İnternetten biraz araştırma yaptığınızda bu durumla ilgili bazı çözümler mevcut. Şu makale gerçekten bu problem için oldukça faydalı bir çözüm sağlıyor ancak hala sorunu tam olarak çözmek için yeterli olmadığını göreceksiniz.

http://iamrusso.com/w3wp-exe-100-cpu-wsus-3-0-and-sccm/

Private Memory Limit’i 0 yaparsanız herhangi bir kısıtlama olmadan memory kullanmasına olanak sağlamış olursunuz.

Yaptığınız config değişikliğinden bir süre sonra yine CPU’nun pick yapma durumu ile karşı karşıya kalmanız normal. Sorun çözüldüyse de ne güzel J

Şu bilgiyi hemen burada vermem gerekiyor. Bir client makine, update scan yaptığında WSUS ile konuşur ve catalog bilgileri içeren dosyayı kendisine alır.Bununla birlikte update deployment yaptığınızda veya sonrasında makinelerdeki update deployment cycle her çalıştırdığınızda da öncelikle WSUS ile konuşmaya çalışıp scan işlemini yapar ve sonra varsa kurulması gereken update’leri kurar. Dolayısı ile de bir kez update scan işlemini tamamladığını gözlemleyip update gönderdiğinizde updateleri kurmaya başlamıyorsa bilelim ki ilgili makine o anda wsus ile scan işlemini başarılı tamamlamamıştır.Peki neden tamamlamaz? Çok büyük ihtimal ile WSUS karşılayamadığı için timeout hatası almıştır.  Scan error hataları gerçekten update deployment sürecinde dikkat edilmesi gereken önemli bir konudur.

SCCM Console üzerinde

Monitoring–>Reporting–>Reports–>Software Updates – E Troubleshooting altında Scan Errors raporundan scan hatalarına bakabilirsiniz.

Client makine’de de c:\windows\ccm\logs altınd scanagent.log ve WUAHandler.log’u inceleyebilirsiniz.

80072EE2,80072EFD hataları time out hatalarıdır. Bu hatalardan çok varsa bunu çözmemiz gerekiyor ki bu da yine bu da yapacağımız çözümle çözülecek.

Pool’da ayarlar yaptık, WSUS’taki dar boğazı aşmak için donanımda da upgrade yaptık ancak sorun yine devam ediyorsa problemin asıl kaynağı ve çözümü şudur:

Client makinelerde (özellikle Windows 7 işletim sistemine sahip makinelerde) Microsoft Compatibility Appriser isimli bir schedule var ve default olarak hergün çalışacak şekilde ayarlı durumda.

Normalde client makineler, bir kez full scan yaptıktan sonra, sonraki scan işlemlerinde delta olarak devam edip eğer bir fark varsa, bu bilgileri alması gerekirken bu schedule’dan dolayı her scan işlemini full yapmaya çalışıyor ve full catalogu kendisine download etmek istediğinden (ki full catalog’da size olarak biraz büyük) işlem uzuyor haliyle de bir kuyruk oluşuyor ve WSUS cevap vermekte zorlanıyor.

Aynı zamanda da gereksiz bir network trafiği ve bandwidth kullanımı yaratıyor.

Çözüm :

İlgili schedule client makinelerde disable edildiğinde, bir seferliğine yine makineler full scan yaptıktan sonra süreç delta olarak devam edecek ve sorun çözülecektir.

Toplu olarak bu schedule ‘ı disable etmek için de aşağıdaki komutu bir bat dosyası şeklinde client makinelere SCCM üzerinden deploy edebilirsiniz.(Tabi önce test etmek şartıyla J)

schtasks.exe /CHANGE /TN “Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser” /DISABLE

Bu arada bu durum Şubat 2018’den beri süre gelen bir durum olmakla birlikte detay bilgilere aşağıdaki url’den ulaşabilirsiniz.

https://support.microsoft.com/en-us/help/4163525/high-bandwidth-use-when-clients-scan-for-updates-from-local-wsus-serve