ConfigMgr Client Stuck in Provisioning Mode? Here’s the Fix

— it suppresses policy evaluation and most client actions so the task sequence has exclusive control while it’s still building the machine. The problem is when a task sequence fails, gets interrupted, or errors out partway through, the client can get left in provisioning mode permanently, even though the machine looks otherwise finished and in production. This is still a live issue on current ConfigMgr (the branch previously called SCCM/MECM), including the latest 2603 release — the mechanism hasn’t fundamentally changed since the 2012 era.

How to tell if a client is stuck in provisioning mode

Check the registry on the affected machine:

HKLM\SOFTWARE\Microsoft\CCM\CcmExec

Look for the ProvisioningMode value — TRUE means it’s stuck (assuming the task sequence has actually finished and the machine is in normal use). You can also check via WMI:

Get-WmiObject -Namespace root\ccm -Class CCM_Client | Select-Object ProvisioningMode

Symptoms that point at this: the client shows in the console but never receives new deployments, Software Center shows nothing available even though deployments target the collection it’s in, or ccmexec.log shows repeated entries referencing provisioning mode suppressing policy evaluation.

Fixing it

The supported way is via the built-in client action, run from an elevated command prompt on the affected machine:

"C:\Windows\CCM\CcmRepair.exe"

If that doesn’t clear it, set provisioning mode off directly using the client’s own PowerShell/WMI interface:

$SMSCli = [wmiclass]"ROOT\ccm:SMS_Client" → $SMSCli.SetClientProvisioningMode($false)

Then confirm the registry value flipped to FALSE and restart the SMS Agent Host service:

Restart-Service -Name CcmExec

Why it happens

Almost always a task sequence step failing after the “Set Dynamic Variables”/client-configuration steps have already flipped provisioning mode on, but before the final “Setup Windows and ConfigMgr” step properly turns it back off — a driver injection failure, an application install step erroring out, or the task sequence being cancelled mid-run (including by an unplanned reboot) are the most common triggers. Check smsts.log on the affected machine (usually under C:\Windows\CCM\Logs\ once deployment has finished, or X:\smstslog\ if you can catch it before the machine reboots into Windows) for the actual failure point if this is happening repeatedly across multiple machines rather than as a one-off.

Preventing repeat occurrences

If this is showing up across a batch of new deployments rather than one unlucky machine, it’s worth reviewing the task sequence for steps that are prone to transient failure (network-dependent driver or app installs are the usual suspect) and adding continue-on-error handling or retries where appropriate, rather than manually clearing provisioning mode on every affected machine after the fact.