One of the most common challenges for SCCM (MECM) administrators is managing disk space on Distribution Points (DPs). Over time, as you deploy applications, software updates, and OS images, the SCCMContentLib folder grows. Even after removing deployments or packages from the console, orphaned content can sometimes remain on the server, consuming storage.
In this post, I will walk you through how to use the Content Library Cleanup Tool (ContentLibraryCleanup.exe) to reclaim disk space by removing orphaned content safely and effectively.
Today, I’ve developed a solution for the CrowdStrike issue that has caused significant outages for numerous major companies using PowerShell WPF and SCCM. Microsoft recently released a recovery tool specifically designed to address this problem; however, it requires USB devices for recovery operations.
Bu yazıda geçtiğimiz günlerde hacklenenAnydesk uygulamasının SCCM ile cihazlardan kaldırılması ve eğer portable sürüm var ise bunun da tespit edilerek temizlenmesi üzerine çalışma yapacağız.
Selamlar, uzun zamandır bana da kılavuz olması adına hakkında yazmak istediğim site recovery konusunu lab ortamımda güncelleme sırasında sorun yaşadığımdan artık ele alabilirim. SCCM ortamımı 2309 versiyonuna geçiş sırasında elektrik kesintisi nedeniyle cihazım kapandı.
Selamlar, bu yazıda Microsoft tarafından önerilen WSUS best practicelerini uygulayacağız.
Kapasite Limiti
WSUS 100,000 ve hatta Configuration Manager üzerinden 150,000 makineyi destekleme kapasitesi olsa da Microsoft Scan Storm dediğimiz bir problemin meydana gelmemesi için bu rakamlara çıkılması yerine aynı SQL Server DB’nin paylaşıldığı 2-4 sunucunun daha konfigüre edilerek ortama dahil edilmesinin iyi olabileceğini belirtiyor. Shared DB kullanan WSUS sunucuları sayesinde kullanıcılar farklı bir WSUS sunucuya atladıklarında full scan yapmayacak ve 1GB’dan fazla olabilecek boyutlarda metadata dosyalarını sunucuya yeniden transfer etmeye çalışmayacaklar. Bu konu ile ilgili farklı bir zamanda bir yazı yazmaya çalışacağım.
Geri Dönüşümü İptal Etme ve Memory Limitasyonu Konfigürasyonu
WSUS güncelleme metadatalarını veri tabanından çeken bir cache mekanizması kullanır. Bu süreç çok maliyetli ve çok yoğun memory kullanabilir. Bu sebeple IIS’de WSUS’un bulunduğu pool’da geri dönüşüm(recycling) sürecine sokulabilir, bu duruma bir de yukarıda belirtilen scan storm eklenirse, WSUS’un sürekli olarak geri dönüşüm döngüsüne girmesi ve scan request’lerine HTTP 503 error’leri vermesi ile sonuçlanabilir.
Microsoft bu duruma karşı WSUSPool üzerindeki varsayılan Queue Length ‘in yükseltilmesini ve sanal(virtual) ve özel(private) memory limitlerinin kaldırılması adına 0 olarak düzenlenmesini önermektedir.
IIS Manager > Application Pools >WsusPool‘a sağ tıklıyoruz ve Advanced Settings.. ‘i seçiyoruz.
Yaklaşık 17,000 güncellemenin önbelleğe alındığı bir ortamda 24GB’dan fazla memory’e cache sabitlenene kadar ihtiyaç duyulabilir.
Setting name
Value
Queue Length
2000 (up from default of 1000)
Idle Time-out (minutes)
0 (down from the default of 20)
Ping Enabled
False (from default of True)
Private Memory Limit (KB)
0 (unlimited, up from the default of 1,843,200 KB)
Regular Time Interval (minutes)
0 (to prevent a recycle, and modified from the default of 1740)
Bandwidth’i Daha Verimli Kullanmak Üzere Sıkıştırmanın Açık Olup Olmadığını Kontrol Etmek
SCCM ile update paketlerimizi DP’lerimize gönderip oradan clientlarımıza dağıtıyoruz. Bu bandwitdh olarak devasa fayda sağlamakla birlikte, network’te saturasyonun ve over-subscription’ın da önüne geçiyor, ayrıca birkaç sunucu üzerinde darboğaz oluşmasını engelliyor. Fakat WSUS için aynı şeyi söyleyemeyiz. Evet WSUS makine bazlı trafiği update paketine nazaran çok daha ufak olmaktadır ancak DP mantığını kullanamadığımız için yukarıdaki problemlerin makine sayısına bağlı olarak olma ihtimali bulunuyor.
Bu durumda WSUS üzerinde oluşacak istekleri sıkıştırarak burayı biraz daha kontrol altında tutabiliriz. Bu sıkıştırma tabii ki WSUS sunucumuzun CPU kullanımını arttıracaktır, ancak bandwidth olarak tasarruf etmemizi ve yukarıda belirttiğim durumların yaşanmamasına faydası olabilir. Aynı durum tam tersi için de geçerli, eğer CPU’nun harcadığı güç kısıtlıysa ancak bir bandwidth sıkıntınız yoksa bu durumda da aşağıda ilettiğim ayar açıksa kapatabilirsiniz.
Sıkıştırma konfigürasyonu kontrol etmek için;
IIS’in config folderına gidiyoruz: C:\WINDOWS\System32\inetsrv\config httpCompression altında aşağıdaki konfigürasyon var ise,
SCCM ile birlikte WSUS ya da direkt WSUS kullanın farketmeksizin update’leri sync edeceğiniz product’larınızı arada bir gözden geçirmekte fayda olmaktadır. Artık kullanmadığınız, eski olduğunu tamamen temizlediğiniz ya da günceline geçiş yaparak eskisini kullanmayı sonlandırdığınız uygulamalarınızı kaldırarak metadata boyutunuzu düşürebilirsiniz.
SCCM Kullanıyorsanız; Administration > Site Configuration > Sites > Primary Site’a sağ klik > Configure Site Components > Software Update Point
Örneğin artık End of Life olmuş sizin de muhtemelen ortamınızda artık kullanmadığınız Windows Server 2012’yi artık product’larımız arasından kaldırabiliriz.
Sadece WSUS kullanıyorsanız bu ayar WSUS konsolunda Options > Products and Classifications altında yer almaktadır. (SCCM kullanıyorsanız tekrar buradan kaldırılmasına gerek bulunmuyor.)
Selamlar, Bu yazıda SCCM 2309 güncellemesi sırasında lab ortamımda çıkan “Potential SQL server performance issue caused by change tracking retention period.” warning’inin giderilmesini ele alacağım.
