SCCM / ConfigMgr

Client Push Installation in SCCM — Setup, Flow, and Troubleshooting

A complete guide to SCCM Client Push: prerequisites, configuration, the three installation phases, log-driven troubleshooting, and why HTTPS-enabled environments frequently break at the certificate template.

SCCM ConfigMgr Client Push PKI Certificates Troubleshooting Enterprise CA
2026-04-17 · Miloch · 18 min read

Client Push is the most commonly used installation method for the Configuration Manager client. It is automatic, works at scale, and — when it fails — produces a remarkably varied set of error signatures that often send administrators searching in the wrong direction. A misconfigured firewall rule is typically blamed for what is, in reality, a broken certificate template. The reverse is also common.

The following guide covers the entire Client Push path: what happens behind the wizard, which prerequisites must be satisfied, how the installation is configured in the ConfigMgr console, and how to diagnose the three phases of the process through the corresponding logs. A dedicated section addresses the PKI-related failure pattern that affects HTTPS-enabled sites and is particularly hard to trace because the error messages rarely point at the certificate itself.

All examples assume a working lab as built in Building an SCCM Lab on Windows Server 2025. The identifiers LAB-DC01, LAB-CM01, and LAB-CL01, the domain cm.lab, and the site code LAB are used throughout.

When Client Push Is the Right Choice

Configuration Manager offers several client installation methods: Client Push, Software Update-based installation, Group Policy, manual ccmsetup.exe, imaging, and ConfigMgr's own discovery-driven deployment. Each has a defined purpose.

Client Push is suitable when:

It is not the right choice when clients are on the public internet (a Cloud Management Gateway is the intended path), when firewalls disallow inbound SMB, or when the operational pattern favours GPO-based deployment with a fixed policy.

What Happens During a Push

Client Push is a three-phase process. Each phase runs on a different system, against a different protocol, and writes to a different log. Understanding the phase boundaries is the single most useful skill when troubleshooting the process.

Phase 1 — Initiation on the Site Server

The Client Configuration Manager component on the site server opens a connection to the target's administrative share (\\TARGET\Admin$), copies the bootstrap files ccmsetup.exe and MobileClient.tcf, and creates a service remotely through WMI over DCOM. The component then starts the service to launch ccmsetup.exe on the client.

Relevant log: ccm.log on the site server, located at <ConfigMgrInstallDir>\Logs\ccm.log.

Phase 2 — Bootstrap and Client Installation on the Target

Once running, ccmsetup.exe downloads the full client package from the management point (over HTTP or HTTPS, depending on site mode), verifies the digital signatures of the package contents, and installs the MSI. The process registers a service ccmsetup during installation, which is removed after the installation completes successfully.

Relevant log: ccmsetup.log on the client, at C:\Windows\ccmsetup\Logs\ccmsetup.log.

Phase 3 — Client Registration and Policy Request

After the MSI installation, the CCM agent starts. The ClientIDManagerStartup component generates a GUID for the new client and — in HTTPS mode — selects a client authentication certificate from the local certificate store. The agent then contacts the management point to register and request its initial policy.

Relevant logs on the client, all at C:\Windows\CCM\Logs\:

A client that appears in the ConfigMgr console but shows as inactive or no client has almost always cleared phases 1 and 2 and is failing in phase 3 — typically for certificate reasons.

Prerequisites

Network and Firewall

The site server must reach the target over the following ports:

The target must reach the management point over:

The Windows Firewall inbound rule group File and Printer Sharing must be enabled on the target, along with Windows Management Instrumentation (WMI). In a lab environment, disabling the firewall on all member servers and clients is an acceptable shortcut:

powershell 
# Lab only — do not apply this in production
Set-NetFirewallProfile -All -Enabled False

In production, targeted exceptions are deployed through Group Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security.

The Client Push Installation Account

The Client Push Installation Account must hold local administrator rights on every target. A single account is supported, and multiple accounts can be specified — ConfigMgr tries each in turn until one succeeds.

For a lab, a domain administrator account is sufficient. In production, a dedicated least-privilege account is created, typically named svc_cmclient or similar, and added to a group distributed via Group Policy Restricted Groups or Group Policy Preferences into the local Administrators group of all target systems. The account is never used interactively.

The account is created in Active Directory like any service account:

powershell 
New-ADUser `
    -Name "svc_cmclient" `
    -SamAccountName "svc_cmclient" `
    -UserPrincipalName "svc_cmclient@cm.lab" `
    -Path "OU=Special Use Accounts,OU=Users,OU=LAB,DC=cm,DC=lab" `
    -AccountPassword (ConvertTo-SecureString "P@ssw0rdP@ssw0rd" -AsPlainText -Force) `
    -PasswordNeverExpires $true `
    -CannotChangePassword $true `
    -Enabled $true

Boundary and Boundary Group

Client Push relies on discovery data, and discovery data gains its site assignment through boundaries. Without a Boundary Group that contains the target's IP range and references the site, Client Push will not attempt the installation — the site server sees the discovered system but has no site to assign it to.

Configuration is done under Administration → Hierarchy Configuration → Boundaries and Boundary Groups, as described in the lab article.

Discovery Must Have Run

Only systems known to ConfigMgr through one of its discovery methods can be targeted by Client Push. In practice, Active Directory System Discovery is the relevant method for domain-joined machines. The client appears in Assets and Compliance → Devices shortly after discovery completes.

Configuration in the ConfigMgr Console

The Client Push configuration lives in two related places: the site-wide Client Installation Settings and the per-device / per-collection Install Client action.

Client Push Installation Properties

Under Administration → Site Configuration → Sites, the active site (LAB) is selected, and from the ribbon Client Installation Settings → Client Push Installation is opened. Three tabs control behaviour:

General tab

Accounts tab

Installation Properties tab

Typical installation properties for a lab with a single primary site:

text 
SMSSITECODE=LAB SMSMP=LAB-CM01.cm.lab

For HTTPS sites that use PKI certificates:

text 
SMSSITECODE=LAB SMSMP=LAB-CM01.cm.lab /UsePKICert

The full list of client installation parameters is documented on Microsoft Learn — About client installation properties. Notable entries:

Triggering a Push Manually

A manual push runs from the console against an individual device or an entire collection. In Assets and Compliance → Devices, a right-click on the device offers Install Client. A wizard collects a few options (allow the site to be chosen automatically, include domain controllers, always install) and triggers the push.

For collections, the same action appears under Assets and Compliance → Device Collections → → Install Client.

Log-Driven Verification

Troubleshooting Client Push without reading logs rarely succeeds. The sequence below mirrors the three phases and is the fastest path from "the client did not appear" to a meaningful diagnosis.

Live-Tail the Site Server Log

On LAB-CM01, the Client Configuration Manager log captures the push initiation:

powershell 
Get-Content "E:\Program Files\Microsoft Configuration Manager\Logs\ccm.log" -Wait -Tail 50

The log records the target name, the account used, the outcome of the SMB copy, and the WMI service creation. When phase 1 fails, it fails here.

Live-Tail the Client Setup Log

On LAB-CL01, the bootstrap log shows the MP download and MSI installation:

powershell 
Get-Content "C:\Windows\ccmsetup\Logs\ccmsetup.log" -Wait -Tail 100

The log ends with CcmSetup is exiting with return code 0 on success. Any non-zero code corresponds to an MSI or network failure and is documented in the ccmsetup.exe return codes table.

Verify Registration

Once the client is installed, the following logs indicate whether it registered successfully:

powershell 
Get-Content "C:\Windows\CCM\Logs\ClientIDManagerStartup.log" -Wait -Tail 50
Get-Content "C:\Windows\CCM\Logs\CcmMessaging.log"         -Wait -Tail 50

A successful registration writes messages such as Client is registered in ClientIDManagerStartup.log and a sequence of authenticated messages to CcmMessaging.log. Persistent failures point either at certificate issues (HTTPS) or at time drift (Kerberos).

Troubleshooting by Phase

Phase 1 Fails — Site Server Cannot Reach the Target

Symptoms in ccm.log:

Systematic checks, in order:

  1. Name resolution — Resolve-DnsName LAB-CL01.cm.lab from the site server must return the correct IP
  2. Reachability — Test-NetConnection LAB-CL01.cm.lab -Port 445 and -Port 135 must both succeed
  3. Account permissions — the Client Push Installation Account must be a member of the local Administrators group on the target. A quick test from the site server: Get-CimInstance -ComputerName LAB-CL01 -ClassName Win32_OperatingSystem -Credential (Get-Credential) using the push account's credentials
  4. File and Printer Sharing — must be enabled in the Windows Firewall on the target
  5. Admin$ share — on the target, Get-SmbShare -Name Admin$ must return the share. Some hardening baselines remove administrative shares

When all five checks pass, phase 1 typically succeeds.

Phase 2 Fails — Client Bootstrap Does Not Complete

Symptoms in ccmsetup.log:

Checks:

  1. MP reachability from the client — Test-NetConnection LAB-CM01.cm.lab -Port 80 (HTTP) or -Port 443 (HTTPS)
  2. Correct MP URL structure — the bootstrap requests /CCM_Client/ccmsetup.cab from the MP; a 404 indicates a misconfigured MP role or a broken IIS virtual directory
  3. Disk space and Windows Installer health — MSI: 1603 frequently results from low disk space, a corrupt Windows Installer, or an antivirus engine interfering with the MSI cache
  4. Transcript for manual repro — running ccmsetup.exe /mp:LAB-CM01.cm.lab SMSSITECODE=LAB manually on the client as a local administrator often produces clearer error messages than a push

Phase 3 Fails — Client Installs but Does Not Register

This is the most common — and most deceptive — failure class. The client is installed, but it does not appear in the console, or it appears briefly and then stops checking in.

Symptoms in the client logs:

A 403 response from the management point during a policy request is the fingerprint of a PKI misconfiguration. The deep dive in the next section addresses it in detail.

A No certificate available message indicates the client never obtained a Workstation Authentication certificate — either because auto-enrollment is not configured, because the template has no permissions for the client, or because the CA is unreachable.

The HTTPS / PKI Deep Dive

HTTPS mode requires every client to present a valid certificate during the TLS handshake with the management point. The certificate must:

A broken certificate anywhere in this chain produces an HTTP 403 response from the management point when the client tries to request policy. The MP's IIS log on the site server contains the authentication failure code, which is a useful cross-reference.

The Certificate Template Trap

In most Enterprise CA deployments, the client certificate is issued through the built-in Workstation Authentication template or a duplicate. When a duplicate is created, the wizard asks for a compatibility level — and this setting has larger consequences than its name suggests.

When a duplicate was made years ago, possibly by a predecessor, and has been quietly retained, the compatibility setting is frequently overlooked. A new SCCM deployment on Windows Server 2025 will receive certificates from that template, present them to the management point, and be rejected — with a 403 response that does not mention certificates at all.

The fix is not to modify the existing template (which can affect already-issued certificates) but to create a new duplicate with the correct compatibility level.

Creating a Compatible Template

On the CA (LAB-DC01 in a single-DC lab, or a dedicated Enterprise CA in production), the Certificate Templates console is opened with certtmpl.msc.

  1. Right-click Workstation Authentication → Duplicate Template
  2. On the Compatibility tab, set Certification Authority to Windows Server 2016 (the most widely supported modern baseline)
  3. Set Certificate Recipient to Windows 10 / Windows Server 2016 or higher
  4. On the General tab, give the template a descriptive name such as SCCM Client Authentication
  5. On the Subject Name tab, choose Build from this Active Directory information, Subject name format: DNS name, and include DNS name as an alternate subject
  6. On the Security tab, add Domain Computers with Read, Enroll, and Autoenroll permissions
  7. On the Cryptography tab, confirm Provider Category: Key Storage Provider and Request hash: SHA256

After the template is created, it is published on the CA:

powershell 
# Run on the CA
Add-CATemplate -Name "SCCM Client Authentication" -Force

# List published templates for verification
Get-CATemplate | Select-Object Name, Oid | Format-Table -AutoSize

Enabling Auto-Enrollment via GPO

A published template alone does not enroll anything. Auto-enrollment must be enabled through Group Policy so that domain-joined computers request the certificate during the next policy refresh.

In the Group Policy Management Console, a new GPO is linked to the OU containing the target systems — typically Member Servers and Clients — and configured under:

Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client — Auto-Enrollment

A gpupdate /force followed by certutil -pulse on the client triggers an immediate enrollment attempt.

Verification:

powershell 
# Machine certificate store — the new certificate should appear with purpose "Client Authentication"
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication" }

Forcing ConfigMgr to Use PKI Certificates

A client installed in HTTP mode continues to use HTTP unless explicitly switched. For new installations, the /UsePKICert parameter in the Client Push Installation Properties forces certificate-based communication. For existing clients, the client properties are changed centrally under Administration → Site Configuration → Sites → Client Settings → Computer Agent.

Common Pitfalls

Client appears as No Client in the console forever The device was discovered but never received a push. Common causes: push is not enabled site-wide, the Boundary Group does not cover the target, or the device is a domain controller and domain controllers are excluded by default.

Installation succeeds on first run, then fails silently on every subsequent push ccmsetup.exe refuses to reinstall an identical or newer version. The existing client must be uninstalled manually with ccmsetup.exe /uninstall before a fresh push, or the push properties must include a version that forces replacement.

Client Push works for workstations but not for servers The System types setting under Client Installation Properties excludes Servers or Domain Controllers by default, depending on version. Both are separate checkboxes.

Random "Access is denied" during push Password rotation on the Client Push Installation Account without updating the account in ConfigMgr. The site server continues to use the stale credentials.

403 responses persist after the new certificate template is deployed Old certificates from the defective template remain in the client's store and are preferred by the CcmMessaging component. Removing the old certificate, forcing re-enrollment (certutil -pulse), and restarting the SMS Agent Host service on the client clears the issue.

CRL-related failures The CRL Distribution Point URL embedded in the certificate must be reachable from every client. Internal URLs (ldap://...) work for domain-joined clients but break for clients on segregated networks. A second, HTTP-based CRL URL on the CA eliminates the asymmetry.

Time drift Kerberos tolerates five minutes of time skew by default. A target with a drifted clock — common on VMs that have been suspended — will fail the Client Push account authentication with misleading "access denied" messages. w32tm /resync on the target usually resolves it.

Takeaways

Client Push is deceptively simple at the configuration layer and relentlessly phased at the operational layer. The three phases — site server initiation, client bootstrap, client registration — each fail with different symptoms, write to different logs, and require different remediations. Attempts to troubleshoot without distinguishing the phase seldom yield useful results.

The PKI path deserves particular attention. A certificate template created at the wrong compatibility level silently breaks every new HTTPS client in the organisation, and the resulting 403 response from the management point gives no hint that the cause is cryptographic rather than network-related. Creating a fresh duplicate at a modern compatibility level, publishing it correctly, and deploying it through auto-enrollment is the durable fix.

Rule of thumb: When an SCCM client behaves strangely, the log lives on the system where the phase was running. Site server log for push initiation, ccmsetup.log on the target for installation, CcmMessaging.log and ClientIDManagerStartup.log for registration. Reading the correct log first saves more time than any checklist.

Tested against: Configuration Manager Current Branch 2503 on Windows Server 2025, SQL Server 2022 Developer Edition, Windows 11 24H2 clients, Enterprise CA on Windows Server 2025.

SCCM ConfigMgr Client Push PKI Certificates Troubleshooting Enterprise CA
M

Miloch

Enterprise IT, SCCM & ConfigMgr, PowerShell & Automation — building systems right.

Related Posts

SCCM / ConfigMgr

Building an SCCM Lab on Windows Server 2025

Step-by-step setup of a fully working SCCM test environment on Windows Server 2025 — Domain Controller, SQL Server 2022, and Primary Site Server.