# SCCM Client Dağıtım Hataları: ccm.log ve ClientIDManagerStartup.log Üzerinden Sorun Giderme

- Bağlantı: https://musti.org/sccm/sccm-client-dagitim-hatalari-ccm-log/
- Yayımlanma: 2026-09-21T21:44:09+03:00
- Yazar: mmutlu

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.