1. Ana Sayfa
  2. Configuration Manager (SCCM)
  3. SCCM Software Updates Deployments Troubleshooting -2

SCCM Software Updates Deployments Troubleshooting -2

070418_0817_SCCMSoftwar1.jpg

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

Normalde SCCM SUP rolü için bildiğiniz gibi bir ’a ihtiyacımız var. SCCM Server üstünde kurulabileceği gibi farklı bir server’a da konumlandırabileceğiniz 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 Production 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/

Resim-1

Resim-2

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.

Resim-3

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

Resim-4

, 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 isimli bir schedule var ve default olarak hergün çalışacak şekilde ayarlı durumda.

Resim-5

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.

Bu konuyla ilgili sorularınızı https://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

www.mshowto.org

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

TAGs: , 80072EE2,80072EFD, WSUS, , , , Microsoft Compatibility Appriser

Yorum Yap

Yazar Hakkında

Ayhan Aksu, Kocaeli üniversitesi Elektronik ve Haberleşme Mühendisliği’nden 2010 yılında mezun olmuştur. Üniversite sonrası yaklaşık 6 yıl Sentim Bilişim Teknolojileri A.Ş.’de Microsoft ürünleri ile ilgili Teknik Danışman olarak çalışmış ve özellikle System Center ürünleri ile ilgili birçok projeye imza atmıştır. Şu anda IBTECH’de Sistem Mühendisi olarak çalışmaya devam etmektedir. Bilişim sektörünün içerisinde aktif olarak çalışmalarını sürdüren bir danışman olarak System Center ürün ailesi ve Microsoft Azure platformu ile ilgili danışmanlık hizmetlerine ve eğitimler vermeye devam etmektedir. Sahip olduğu bazı sertifikalar : MS: Implementing Microsoft Azure Infrastructure Solutions MCT: Microsoft Certified Trainer (Since 2013) MCSA: Windows Server MCSE: Cloud Platform and Infrastructure, Private Cloud, Server Infrastructure MCTS: Administering and Deploying System Center Configuration Manager, Designing, Assessing, and Optimizing Software Asset Management (SAM)

Yorum Yap