Konsolda bir istemcinin “Unknown” durumda takılı kaldığını ya da kurulu göründüğü halde hiçbir politika almadığını gördüğünüzde, tahmin yürütmek yerine doğru log dosyasına bakmak zaman kazandırır. Bu yazıda MECM istemci sorunlarını teşhis ederken izlediğim log okuma sırasını paylaşıyorum.
Hangi Log Nerede?
İstemci taraflı loglar genellikle C:\Windows\CCM\Logs klasöründe bulunur. Dört dosya özellikle kritik: ClientIDManagerStartup.log istemcinin GUID oluşturma ve site atama sürecini gösterir, “kimliğini bulamayan” client’larda ilk bakılacak yerdir. ccmsetup.log istemci kurulum sürecinin kendisidir — kurulum başarısız oluyorsa oradan başlanır. LocationServices.log istemcinin Management Point’i AD, DNS veya WINS üzerinden nasıl bulduğunu gösterir. PolicyAgent.log ve PolicyEvaluator.log ise istemcinin politika alıp almadığını, alıyorsa nasıl işlediğini ortaya koyar.
İstemci MP’yi Bulamıyorsa
LocationServices.log‘da “Failed to send location request” hatası görüyorsanız, sorun genellikle DNS/AD üzerinde MECM’in yayınladığı Service Connection Point kaydına erişilememesidir. İstemci tarafında MP bağlantısını manuel test etmek için:
# İstemci tarafında MP bağlantısını manuel test certutil -urlcache -split -f "http://[MP-Sunucu-Adı]/sms_mp/.sms_aut?mplist"
Komut başarılıysa (bir liste dönerse), ağ/DNS seviyesinde bağlantı sorunu yok demektir; sorun muhtemelen istemci yapılandırmasında.
Konsolda “Unknown” Görünen İstemciler
Bu genellikle heartbeat discovery’nin henüz çalışmadığına veya istemcinin site koduna doğru atanmadığına işaret eder. ClientIDManagerStartup.log‘da “Failed to create GUID” gibi bir hata varsa, istemci sertifika/kimlik oluşturma sürecinde takılmış demektir.
Politika Ulaşmış Ama Uygulanmamışsa
İstemciye politika ulaşmış görünüyor ama uygulama kurulmuyorsa, sırayı AppDiscovery.log ve AppEnforce.log‘a çeviririm. Bu iki log, detection method’un neden başarısız veya başarılı olduğunu ve kurulum komutunun tam olarak hangi çıkış koduyla (exit code) sonuçlandığını gösterir.
Sunucu Tarafında Bakılacaklar
İstemci tarafı temiz görünüyorsa sıra sunucuda: MP_GetPolicy.log ve site sunucusundaki SMS_EXECUTIVE.log genel sağlık durumunu ortaya koyar. Konsoldaki Monitoring > System Status bölümü de bileşen bazlı hataları hızlıca görmek için kullanışlı bir nokta.
Bu logları okurken Notepad yerine CMTrace kullanmanızı öneririm — renk kodlu hata gösterimi ve canlı takip özelliği analizi ciddi şekilde hızlandırıyor. Genel olarak sıralama hep aynı işliyor: önce istemci MP’yi bulabiliyor mu (LocationServices), sonra politika alabiliyor mu (PolicyAgent), son olarak eylemi gerçekleştirebiliyor mu (AppEnforce/AppDiscovery). Bu üç aşamayı sırayla kontrol etmek, vakaların büyük kısmında kök nedeni dakikalar içinde ortaya çıkarıyor.
[…] örüntüyü aramaya karar verdim: başarısız olan cihazların ortak bir noktası var mıydı? İstemci taraflı logları (özellikle AppEnforce.log ve CBS.log) birkaç örnek cihazdan topladım ve […]