Serideki 6nci makalemizde Sccm tarafinda güncelleştirmelerle ilgili log dosyalarını nasıl okuyacağımızı, özellikle hangi log dosyalarına bakacağımızdan, monitoring tabının kullanımından bahsedeceğiz. Öncelikle Sccm 2012 yeniliklerinden biri de log dosyalarında ayrıntıya girmek yerine genel anlamda monitoring tabıyla genel durumu görebilmemizdir. Monitoring kısmında sadece güncelleştirmelerle ilgili kısımlardan bahsedeceğiz. Ardından daha detaylı sorun giderebilmek için log dosyalarından bahsedeceğiz. Tabi ki bir de dashboard diye adlandırdığımız bir bölüm var ki, bu bölüm genelde ziyareti unutulan bölümlerden biridir, aşağıda görebileceğimiz gibi eğer herhangi bir deployment için alarm tanımlanmışsa dashboard üzerinden görebiliriz, dashboard’u kullanmak için software updates klasörüne tıklamak yeterlidir.
Monitoring güncelleştirmeleri nasıl görüntüleyeceğiz? Burada bir checklistimiz var. Her şeyden önce hata checklist’e geçmeden önce bilmeliyiz ki eğer group policy tarafında bir wsus tanımı varsa bunu iptal etmeliyiz ve hedef istemcilerde bunun uygulanmadığını doğrulamalıyız, group policy, wsus tanımları, istemci tarafındaki kontroller, tüm istemcilerden toplu rapor çekme konularına group policy makalelerinden bakabilirsiniz. Ben hedef bir sccm istemcisindeki ayarı paylaşıyorum; sccm agent kurulu bir sunucuda aşağıdaki komutu çalıştırıyorum.
Burada önemli olan sağ taraftaki ayarın local group policyden gelmesi, bu ayarın sccm ile yapıldığını gösterir, eğer sağ taraftan bir group policy ismi yazılı ise sccm bu kısmı değiştiremez ve bu istemciye upate gönderemez, bu istemci wsus ile yönetilmeli veya group policy kapsamından çıkarılmalıdır.
Bu önemli bilgiden sonra gelelim listemize
1 – Genel anlamda WSUS senkronizasyonu ne durumda? Mesela şağıda 5 adet WSUS sunucusunda ana sunucu internetten diğerleri ise bu ana sunucudan updateleri alacak şekilde konumlandırılmış. Fakat en alttaki sunucu internetten güncelleştirmeleri alma ayarı yapıldığı halde dosyaları alamamıştır, konfigürasyonunun incelenmesi gerekir.
2 – Güncelleştirme için oluşturulan update gruplarının dosyaları internetten veya diğer wsus sunucusundan indirilip distribution point’e gönderilmiş mi ?
İçeriğin detaylarını kontrol etmek
Detaylar;
Bu kısmı hızlıca geçip 3ncü maddemize bakalım
3 – Deploy package için istemciler nasıl rapor üretmiş ?, aşağıda gördüğümüz gibi 29 adet istemciden 4 adetinde bu pakette bulunan güncelleştirmeler var, 25 tanesi raporlama yapmamış. Bu durumda istemciler;
Istemciler henüz güncelleştirmeleri kontrol etmek için sccm ile iletişime geçmediler, son durum güncellemesi tam 1 hafta önce yapılmış, bu arada istemciler rapor göndermiş ama bu pencere güncellenmemiş olabilir.
Peki bunu nasıl anlayacağız, tabiki view status ile; 29 adet istemci bulunan test isimli collectionda 24 adet istemci durumu unknown durumda
işte bu kısımda monitoring tablarındaki keyifli bir açık gezintimiz sona eriyor. İstemci tarafında tetikleme yapıp log okuma vakti geldi. Bunun için sccm right click tools yüklü bir sccm konsolunda aşağıdaki işlemler yapılır
Şimdi ise sıra istemci tarafında logları okumaya geldi. Tabiki cmtrace.exe varsayılan log okuyucumuz olmalı, ardından başarılı bir şekilde yukarıdaki ki işlemi çalıştırdığımız bir istemciye bağlanıp ccm log klasörüne erişiriz; bu logların tam listesini önceki makalelerimizde paylaşmıştık, tabiri caizse zaten doğaçlama yaparsanız tetiklenen bu işlem sonrası en son modifiye edilen dosyalara gore sıralama yaparsanız nelere bakılacağını kestirmiş olursunuz.
Mesela ilk gereksinim olan Group policy tarafında bir sorun varsa bu logda yazacaktır. Burada bir tek şey göze çarpıyor, “license terms”, fakat bu tek başına neden bu istemcinin unknown durumda olduğunu göstermez, bunun en kolay ağlaması unknown olmayan bir istemcideki aynı log dosyasını karşılaştırmaktır, böylece amacın dışına sapıp o an için sizi ilgilendirmeyen bir detayla vakit kaybetmezsiniz. Aşağıdaki unknown bir istemcinin günlüğü
Şimdi unknown durumda olmayan bi istemciye bakalım
Demek ki doğru logda olma ihtimalimiz yükseldi. Bu durumda 24 adet unknown üzerinde bir kaç istemciye daha bakıp aynı hataları görüyorsak işi sccm tarafında kişiselleştirmeden J windows update log dosyasına da bakılabilir. Aşağıda logları yan yana incelediğimizde de sol tarafta yine license terms’e yakın bir terim EULA karşımıza çıkıyor
Bu tip durumlarda, sorun istemci(ler) den mi kaynaklanıyor, yoksa sccm sunucu tarafında mı anlamak için sunu düşünmeliyiz;
- Sorun sadece bir istemcide mi, tüm istemcilerde mi?
* Sorun birden fazla istemcide
- Sorun yaşayan istemcilerde benzer hata logları var mı?
* Evet
- Hedef istemci grubundan (29) kaç adet sağlıklı istemci görünüyor
* 4
- Peki bu sağlıklı görünenler sağlıklı mı, yoksa diğer 25 adet istemciden bir farkları var ve bu fark sağlıklı olduklarını düşünmenize neden oluyor mu?
* Bu kısım önemli, burada 4 istemcide zaten bu güncelleştirme olduğu için kontrol etme ihtiyacı hissetmemeleri bu 4 istemcinin sorunsuz olduğunu göstermez.
Aslında burada tabi ki beklenti hr=80240033 hatası bu şekilde çözülür dememiz olabilir ama bu şekilde yüzlerce hata var ve artık herkes bir şeyler yazıyor, benim size tavsiyem bu tip sorunları kendi fikrinizle çözmeye çalışıp daha sonra araştırmak, bu makalede de amaç sccm tarafında sorunlara bakış açımıza mümkünse bir artı katmak. Dolayısıyla yüzlerce hata kodunu çözüp makale yazmak değil. Burada amacımız bu hatayı çözmek değil, herhangi bir hatada nerelere genel anlamda bakmamız gerekir onu görmektir.
Burada istemcilerden bir tanesinin sccm client uninstall – install edilerek test yapılabilir mesela.
İstemci tarafında windows update manuel test edilebilir, iki istemci (sağlıklı – sağlıksız olan) windows update check test edilebilir. Tabiki sccm tarafında bir çok log dosyamız var ama loglarda kaybolmadan basit anlamda da bir şeyleri bulabiliriz, çünkü sccm tarafında odaklanınca genelde hedef istemci sorunları unutuluyor, OS deploy yapılan bir sunucuda diskin bağlanmasının unutulması gibi J Ya da hedef işletim sistemi, yüklü programları kontrol etmeniz gerekebilir. Mesela bu örnekte 4 adet istemcide server 2012, 25 adetinde ise server 2008 var. Güzel bir ipucu değil mi J, mesela windows server 2008 r2 sunucuları için bir ön update gereklidir ve bu sorunu çözüyordur. Veya extra bir update için bir paket oluşturup bu gruba dağıtıp deneme yapabilirsiniz, bu durumda sorunun sadece eula içeren windows updatelerden kaynaklandığına kanaat getirebiliriz.
Ya da biraz daha detay görebiliriz.
Ayni zamanda eula dosyaları henüz transfer edilmemiş de olabilir ve senkronizasyon yapabilirsiniz.
Ve ayrıca sistem tarafında genel kontroller de yapmanızda fayda var;
Ve tabiki Deployment package tekrar oluşturulabilir, malum bütün gün loglara bakmak zorunda değiliz, biz örneğimizde updateleri tekrar senkronize ettik ve istemci tarafını tetiklediğimizde aşağıdaki gibi update yüklenebilir duruma geçti, tabiki tekrar senronize etmek, tekrar pakedi deploy etmek vs gibi işlemler başarılı olmayabilir, bu tip durumlarda sunucudaki windows olay günlüğüne de bakarak bazı basit sorunları yakalayabilirsiniz veya antivirus, network kaynaklı sorunlar karşınıza çıkabilir.
Bu makalemizde kısaca update tarafında bakmanız gereken monitor ekranları, log dosyaları ve hatalara yaklaşım önerilerimizdi, yaşadığınız sorunları forumda her zaman bizimle paylaşabilirsiniz. Yeni bir makalede görüşmek dileğiyle.