Client Push Failures: A Log-Driven Troubleshooting Guide for ConfigMgr

When a Client Push fails, the console rarely tells you why. It aggregates status, masks transport-layer rejections, and leaves you guessing. If you’re still relying on high-level compliance states or waiting for a retry cycle, you’re adding noise to an already broken process.

This guide walks through a systematic, log-driven approach to diagnosing and resolving Client Push failures in Microsoft Endpoint Configuration Manager (MECM/ConfigMgr). It covers prerequisites, server and client log correlation, error-layer resolution, and modern onboarding alternatives.

No Client in SCCM console

1. Prerequisites & Account Model

Before you even click Install Client, verify the baseline. Client Push is a remote execution mechanism. If the underlying requirements aren’t met, the request fails silently or queues indefinitely.

Account Model

  • The Client Push Installation Account must be a domain user (local accounts are ignored).
  • It must have local administrator rights on the target machine at the time of push.
  • Password drift or account lockout will cause immediate ERROR_LOGON_FAILURE (64). In newer versions, consider using a Group Managed Service Account (gMSA) to eliminate password synchronization.
  • Verify the account isn’t restricted by LSA policies (e.g., SeDenyNetworkLogonRight or SeInteractiveLogonRight misconfigurations).

Site System & Package Readiness

  • SMS_EXECUTIVE must be running. Check Services.msc or Get-Service -Name SMS_*.
  • At least one Distribution Point or Management Point must host the Client Installation Package. If the package hasn’t replicated, the push fails with 0x87D00324.
  • Verify site system roles: MP, DP, and Software Distribution Point must be healthy. Check Site Status > SMS Provider and Distribution Point tabs.

Network & OS Baseline

  • Supported OS for your current CB version (check Microsoft’s compatibility matrix).
  • Outbound/Inbound traffic allowed:
    • SMB: TCP 445 (required for admin$ share access)
    • WMI/DCOM: TCP 135 + dynamic RPC range (usually 49152–65535)
    • DNS: FQDN must resolve consistently to the target IP. NetBIOS fallback can mask stale records.
  • Third-party AV/EDR policies often block remote WMI/SMB as “lateral movement.” Verify EDR telemetry for blocked connections before assuming firewall misconfiguration.

2. Server-Side Triage: Reading ccm.log Correctly

Open CMTrace (located at C:\Program Files\Microsoft Configuration Manager\tools\cmtrace.exe) and use it to read logs.

SCCM log opened in CMTrace

The server-side initiation log is located at:
C:\Program Files\Microsoft Configuration Manager\Logs\ccm.log

Focus on the SMS_CLIENT_CONFIG_MANAGER component. You’re looking for the request lifecycle:

======>Begin Processing request: "2097157214", machine name: "PC09"    
---> Attempting to connect to administrative share '\\PC09.domain.com\admin$' using account 'DOMAIN\ClientPush'    
---> NetUseAdd failed: 64: dwParamError = 0 for DOMAIN\ClientPush authentication    
---> ERROR: Unable to access target machine for request: "2097157214", machine name: "PC09", access denied or invalid network path.    
<======End request: "2097157214", machine name: "PC09".

How to parse it effectively

  • Use Ctrl+H to highlight the target hostname or IP. Look for the Begin Processing requestEnd request block.
  • Extract the RequestID (e.g., 2097157214). This ID is passed to ccmsetup.exe on the client. You’ll use it to correlate server and client logs.
  • Check the STATMSG line for the final error code. In the example above, ID=3015 maps to a push failure in the site database.
  • Logs rotate at 10 MB × 10 files. If the push attempt is older than the rotation window, you’ll need to enable debug logging or rely on Windows Event Viewer (Security/Operational logs) for historical context.

3. Client-Side Reality: Correlating & Installing

Сcm.log only shows that the server attempted to push. The actual installation, download, and registration happen client-side. Navigate to:
C:\Windows\CCM\Logs\

Core Logs & What They Reveal

LogPurposeKey Indicators
ccmsetup.logDownloads ccmsetup.exe, handles auth, executes installationLook for RequestID, Downloading from MP/DP, Installation complete with error code 0x...
ClientIDManagerStartup.logClient identity creation, site code assignment, certificate enrollmentAssignedSiteCode, ClientID, Certificate retrieval failed
LocationServices.logMP discovery, FQDN/IP resolution, site assignment fallbackMP=..., Found 0 MPs, DNS resolution failed
CcmMessaging.logCommunication with MP, policy retrieval, heartbeat403 Forbidden, 404 Not Found, Timeout, SSL handshake failed

Correlating RequestID

On the client, open ccmsetup.log and search for the RequestID from the server log:

Select-String -Path "$env:ProgramFiles\Microsoft Configuration Manager\Logs\ccmsetup.log" -Pattern "2097157214"

This will show you whether the package downloaded, which MP/DP was contacted, and where authentication or BITS failed.

Enable Debug Logging (Temporarily)

If logs are ambiguous, increase verbosity:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Logging\@Global]
"LogLevel"=dword:00000003

Reset to 1 after troubleshooting to avoid log bloat.

4. Error-Specific Resolution (Layered Approach)

Group failures by the layer where they occur, not just by error code. This prevents misdiagnosis.

Network/Transport Layer (0x800706ba, Error 53)

  • 0x800706ba = RPC_S_SERVER_UNAVAIL
  • Error 53 = ERROR_NETPATH_NOT_FOUND
  • Root causes: Firewall blocking 135/445/dynamic RPC, WMI service stopped, EDR blocking remote DCOM/SMB, stale DNS, or machine offline.
  • Fix:
    • Verify Winmgmt and RpcSs are running on the target.
    • Test connectivity: Test-WSMan PC09, nmap -p 135,445 PC09, ping PC09.domain.com
    • Check EDR/AV quarantine for ccmsetup.exe or blocked WMI calls. Look for Event ID 5140/5145 in Windows Security logs.

Permissions/Authentication Layer (0x80070005, Error 5 or 64)

  • Error 5 = ERROR_ACCESS_DENIED → Pipes open, credentials rejected.
  • Error 64 = ERROR_LOGON_FAILURE → Authentication handshake succeeded, but session was denied.
  • Common causes:
    • Client Push account lacks local admin rights on target
    • Password drift or account lockout
    • Missing SPN registration for ccmexec or HOST/<FQDN>
    • Kerberos constrained delegation misconfigured
    • Time skew >5 minutes (rarely the sole cause in modern AD)
  • Fix:
    • Validate account status: Get-ADUser ClientPush -Properties PasswordLastSet, AccountExpirationDate, LockedOut
    • Check SPNs: setspn -L DOMAIN\ClientPush
    • Validate Kerberos: klist purge on client, verify DC time sync, check eventvwr.msc → Security → Logon Events (4625)
    • Manual share test: Runas /user:DOMAIN\ClientPush cmd.exe\\PC09\admin$

Package/Download Layer (0x87D00324, 0x80070003)

  • 0x87D00324 = Client package not found on DP/MP
  • 0x80070003 = Path not found (share blocked, BITS error, AV lock)
  • Fix:
    • Distribute client package to at least one DP: Right-click package → Distribute Content
    • Verify MP/DP services: Get-Service -Name CCM*
    • Check BITS jobs: Get-BitsTransfer | Where-Object {$_.JobState -eq "Transferring" -or $_.JobState -eq "Error"}
    • Proxy environments: Ensure ccmproxy settings or manual proxy auth are configured. Check CcmMessaging.log for 407 Proxy Authentication Required.

Registration/Communication Layer (0x80004005, 403 Forbidden, 0x80244010)

  • Client installs but can’t call home.
  • Fix:
    • Verify AssignedSiteCode in registry: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client' | Select AssignedSiteCode
    • Check MP list: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\CCM\Location Services' | Select MPs
    • Clear stale identity: Stop CcmExec, delete %windir%\SMSCFG.INI, restart CcmExec. This forces a new ClientID and re-registration.

5. Modern Context: When Client Push Is Legacy

Client Push is a legacy mechanism designed for on-premises, WMI/SMB-reliant environments. In 2024/2025, it’s often the wrong tool for the job:

  • Co-management: Devices enrolled in both MEMCM and Intune may have push restricted or bypassed. Intune handles onboarding; ConfigMgr pulls policy.
  • Autopilot: Cloud-attached devices register directly via Entra ID. No on-prem push required.
  • Security Hardening: EDR, Zero Trust, and CIS benchmarks increasingly disable remote admin shares, restrict WMI, and enforce device-based identity. Client Push doesn’t survive these controls.
  • Migration Path: Use Intune win32 apps, GPO-based installation, deployment scripts (SCCM/Intune hybrid), or cloud-native onboarding for modern endpoints.

If you’re starting fresh, evaluate whether Client Push aligns with your security posture and cloud strategy. If not, document the deprecation and transition to supported, modern onboarding methods.

6. Validation & Prevention

Once deployed, verify the client is healthy and prevent recurring failures:

Quick Validation Snippet (Run on Client)

# Verify site assignment & MP reachability
$Client = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client'
Write-Host "Assigned Site: $($Client.AssignedSiteCode)"
Write-Host "MPs: $($Client.MPs -join ', ')"

# Check client service status
Get-Service -Name CcmExec | Select Name, Status, StartType

# Verify last successful policy refresh
Get-Content "$env:ProgramFiles\Microsoft Configuration Manager\Logs\CcmMessaging.log" -Tail 50 | 
  Select-String "Policy retrieval successful"

Prevention Checklist

  • Enforce client installation via GPO when possible: Computer Configuration\Policies\Administrative Templates\System\CMClient
  • Monitor SMS_CLIENT_CONFIG_MANAGER queue for stalled requests
  • Automate EDR/Firewall rule validation for new OUs
  • Rotate or migrate from expired domain accounts to gMSA
  • Log rotation & monitoring: Archive ccmsetup.log to central SIEM/Log Analytics for trend analysis

7. Quick Reference: Error Codes & Resolution

Error/CodeLayerPrimary LogAction
0x800706ba / 53Network/Transportccm.log, ccmsetup.log, Firewall/EDRVerify SMB(445), WMI(135+), RPC range. Check EDR lateral movement blocks.
0x80070005 / 5Permissionsccm.log, Security 5140/5145Validate Client Push account has local admin rights. Test \\PC\admin$ manually.
0x8009030e / 64Auth/Kerberosccm.log, Security 4625, klistFix password drift, validate SPNs, resync time, check delegation.
0x87D00324Package Missingccmsetup.log, SMS ProviderDistribute client package to DP. Verify site system health.
0x80070003Path/BITS Errorccmsetup.log, CcmMessaging.logCheck DP/MP availability, BITS jobs, proxy auth, AV file locks.
403 ForbiddenCommunicationCcmMessaging.log, LocationServices.logVerify MP FQDN, SSL certs, client identity (SMSCFG.INI), site code.

Final Notes

Client Push is deterministic. If it fails, the logs will tell you exactly which layer broke: network, permissions, package, or registration. Correlate the server RequestID with client ccmsetup.log, validate credentials and shares manually, and stop chasing console status messages.

As environments evolve toward co-management, Autopilot, and zero-trust architectures, Client Push becomes increasingly situational. Use it where it fits, validate it thoroughly, and document modern onboarding alternatives for future deployments.

If you need help parsing specific log snippets or validating a co-management push scenario, drop the STATMSG line and ccmsetup.log error code. I’ll help you map it to the exact fix.

Leave a Comment