Merhaba arkadaşlar,
Bu makalemizde Windows Update Server sunucularınızda karşınıza çıkabilecek bir sorunu nasıl düzeltebileceğinizi anlatmaya çalışacağım. Ben bu sorunu bir SCCM server üzerinde çalışmayı durduran WSUS servisi üzerinde yaşadım, araştırdığımda sorunun SCCM’e bağlı degil WSUS’a özel bir sorun olduğunu SCCM olmayan ortamlarda da yaşanabildiğini farkettim.
WSUS Servisi çalışmıyor ve SCCM üzerindeki WCM.log dosyasını incelediğimizde aşağıdaki hatalar ile karşılaşıyorduk.
Failed to create assembly name object for Microsoft.UpdateServices.Administration. Error = 0x80131701
Log Name: Application
Source: SMS Server
Event ID: 7000
On 8/13/2015 3:22:40 AM, component SMS_WSUS_CONTROL_MANAGER on computer WSUS.fqdn reported: WSUS Control Manager failed to configure proxy settings on WSUS Server “WSUS.fqdn”.
Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted.
Solution: Verify that the WSUS Server version 3.0 SP2 or greater is installed. Verify that the IIS ports configured in the site are same as those configured on the WSUS IIS website.You can receive failure because proxy is set but proxy name is not specified or proxy server port is invalid.
İncelemelerimiz sonucunda buradaki “Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted” hatasının bizi eksik bir güncelleme varmış gibi yanlış bir araştırmaya yönledirdiğinin farkına vardık.
Aşağıdaki kaynaklar kısmında paylaştığım linklerde sorunun asıl sebebinin IIS altındaki Application Pool içindeki WsusPool isimli servisin çalışmamasından kaynaklandığını gördük bizim ortamımızda da.
WSUS pool yukarıdaki resimde görüldüğü gibi durmuş durumda ve çalıştırılamıyor durumda idi.
Referans olarak kullandığımız sitelerdeki arkadaşlar, WsusPool ayarlarındaki aşağıdaki resimdeki Queue Length değerinde yazılı 1000 değerini 25.000 olarak güncellememizi öneriyor idi. Buradaki değeri önerilen şekilde 25.000 yaptım servis çalıştı ama sunucunun tüm CPU core’lar %99’da çalışıyor duruma geldi restart sonrasında. ☹ Bu pek sevilen bir durum değil tabiki, bir süre bekledik ama düzelme CPU kaynaklarının kullanımında bir düşüş olmadı daha uzun beklesek belki oldurdu ama o kada zamanımız yoktu.
Başka bir sitede bu değer için önerilen değer 2000 idi, bizde bu değeri 2000 olacak şekilde düzenledikten sonra CPU kullanımlarının nispeten daha makul seviyelere indiğini gözlemledik.
Bu kurumda bu şekilde izliyoruz ve yaklaşık 4-5 aydır tekrar aynı sorun karşımıza çıkmadı.
https://github.com/Microsoft/SCCMdocs/blob/master/sccm/sum/plan-design/plan-for-software-updates.md
Applications Pool Defaults General Tabı altındaki Queue Length değerinin yeri ve orjinal değerleri aşağıdaki resimdeki gibidir.
Bu değeri aşağıdaki resimdeki gibi 2000 olarak güncelleyelim.
Çözüm için referans olarak kullandığımız sitede Process Model altındaki \ Maximum Worker Processes = 0 yapılması öneriliyordu, ama bu değerin 0 yapılmasıda sunucu CPU değeri %99 yapıyor. Bu değerin 1 şeklinde kalmasını öneriyoruz.
Aşağıdak ekranda görülen aşağıdaki değerleri önerdiğimiz şekilde düzeltmenizi tavsiye ederim.
Rapid-Fail Proteciton altında orjinal değerleri 5 olan iki değer;
Failure Interval Minutes = 30,
Maximum Failures = 60
şeklinde düzenlenmelidir.
Recycling altındaki Specific Times değeri TimeSpan[] Array şeklinde olmalıdır.
Buradaki değerlerimiz aşağıdaki resimdeki gibi olmalıdır.
Pool Recycling Ayarlarına erişelim ve benim ortamımda aşağıdaki gibi 1843200 KB olarak ayarlanmış (2 GB) Private memory değerini 4194304 (4 GB) olacak şekilde yeniden düzenleyelim. Hizmet verdiğini client bilgisayarı saysısına göre bu değeri daha yüksek ayarlayabilirsiniz.
Private Memory usage boyutunu 4GB (4194304) yaptım.
Sunucumuzu restart edelim ve bir süre izleyelim servis tekrar duracakmı gözlemleyelim, büyük ihtimalle durmadan çalışmaya devam edecektir diye düşünüyorum.
Kaynaklar :
http://justforadmins.blogspot.com.tr/2016/11/wsus-doesnt-synchronize-after.html
Faydası olması dileklerimle.