How To Deploy SCCM Clients Using Group Policy

Q: How do I install the SCCM client manually with the command line?

From the Client folder on the site server (\\siteserver\SMS_sitecode\Client\) or a local copy, run ccmsetup.exe from an elevated Command Prompt with the parameters that match your environment, for example: ccmsetup.exe /mp:sccm-mp.contoso.local SMSSITECODE=P01 FSP=sccm-fsp.contoso.local. The installer runs silently in the background and writes its log to C:\Windows\ccmsetup\Logs\ccmsetup.log. A return code of 0 in the log means a successful install.

Q: What is CCMSetup.msi?

CCMSetup.msi is the Windows Installer package for the Configuration Manager (SCCM) client. It is assigned through a Software Installation GPO in Method 1. The MSI installs the client framework but does not accept installation parameters at install time, so it needs to find its site code, management point, and other properties from one of three sources: an extended AD schema, the registry provisioned via Method 3, or a follow-up call to ccmsetup.exe.

Q: Does installing the SCCM client require a reboot?

The client install itself does not force a reboot in most cases. However, deploying via a Software Installation GPO (Method 1) needs a reboot to trigger the install in the first place, since assigned MSI packages only run at boot. A reboot may also be required if the install replaces a prerequisite like .NET Framework that needs one to finish. After install, the SMS Agent Host service starts running without a reboot.

Q: What is the difference between client push and GPO deployment?

Client push is initiated from the SCCM site server, which connects out to each target over SMB and WMI using a designated client push installation account with local admin rights on the target. It requires inbound firewall ports open on the client and credentials that map to local administrators across the estate. GPO deployment is the inverse: the install runs on the target in the SYSTEM context against a copy of the client source files on a domain-readable share. There is no inbound connection from the site server, no credentials in flight, and no client push installation account to maintain. The trade-off is that GPO needs a reboot to trigger and does not report install status back to SCCM the way client push does.

Q: Where is CCMSetup.msi located?

On the SCCM site server, CCMSetup.msi is located at the ConfigMgr installation directory under bin\i386\CCMSetup.msi, which is typically C:\Program Files\Microsoft Configuration Manager\bin\i386\CCMSetup.msi. The full Client folder, which contains ccmsetup.exe and all its dependencies used for Method 2 and manual installations, is published as a share at \\siteserver\SMS_sitecode\Client\.

This guide walks through three methods for deploying the SCCM client via Group Policy: assigning the MSI package, running a startup script, and provisioning installation properties through ADM templates. It also covers how to verify the installation succeeded and how to troubleshoot common failures.

Why deploy the SCCM client via Group Policy

Microsoft Configuration Manager (SCCM), which is also commonly known as ConfigMgr or MECM, offers several ways to push the client to domain computers. This includes client push installation from the SCCM console, software update-based installation through Windows Server Update Services, and manual install with ccmsetup.exe, and Group Policy. Each has trade-offs, and GPO deployment exists for the cases where the others don't fit cleanly.

Group Policy is the right choice when client push is blocked by, for example, firewall rules, WMI issues, no admin credentials in the target environment. It's also a natural fit when you want a single configuration applied to every machine in an OU automatically, or when you're bootstrapping the SCCM client into an environment that doesn't have an existing Configuration Manager infrastructure to push from. It's also the method most teams reach for when standing up SCCM in a new domain.

One naming note up front: SCCM was rebranded to Microsoft Endpoint Configuration Manager in 2019 and is now commonly called Configuration Manager or ConfigMgr in Microsoft documentation. Group Policy is not a feature of SCCM. It's an Active Directory feature used to install and configure the SCCM client on domain-joined computers. Once the client is installed, SCCM has its own client settings policies that work independently of Group Policy.

Before you start: disable automatic site-wide client push installation

If your SCCM site has automatic site-wide client push installation enabled, the site server will try to push the client to every discovered computer over SMB and WMI, regardless of whether the GPO also installs it. The two mechanisms compete on the same machines: failed push attempts are recorded in CCM.log on the site server, GPO installation retries occur on the next reboot, resulting in a flood of installation logs that masks real failures.

The solution is to disable site-wide client push before you deploy via GPO, or scope it to a collection that excludes the OUs your GPO targets.

Open the Configuration Manager console.
Go to the Administration workspace and expand Site Configuration > Sites.
Select the primary site.
On the Home tab in the ribbon, click Client Installation Settings > Client Push Installation. (Right-clicking the site and selecting Client Installation Settings > Client Push Installation opens the same dialog.)
On the General tab of the Client Push Installation Properties dialog, clear the Enable automatic site-wide client push installation check box and click OK.

You can still run targeted client push from the console against specific resources after disabling the site-wide setting. The dialog just stops the automatic push for every discovered machine.

Prerequisites

A working SCCM site (primary site or central administration site) with at least one management point reachable from the target client subnet.
The SCCM client source files copied to a domain-readable file share.
The full Client folder lives at \\<siteserver>\SMS_<sitecode>\Client\ on the site server. For the MSI method you only need CCMSetup.msi; for the script method, copy the whole Client folder so ccmsetup.exe can find its dependencies.
A domain account with permission to create and link GPOs at the target OU.
The Group Policy Management Console (GPMC) installed on a workstation or the domain controller.
An OU that contains the computer accounts you want the client deployed to. Software installation and startup script policies apply to computers, so the OU structure matters.

Method 1: Assign CCMSetup.msi through a Software Installation GPO

This is Microsoft's documented Group Policy method. The MSI is assigned to computers in the OU and installs at the next reboot.

On the site server, navigate to <ConfigMgr installation directory>\bin\i386\ and copy CCMSetup.msi to a network share that domain computers can read (for example, \\fileserver\sccm-client\). Confirm the share has at least Read permission for Domain Computers.
On a workstation with GPMC installed, press Win + R, type gpmc.msc, and press Enter.
Right-click the OU containing the target computers and select Create a GPO in this domain, and Link it here. Name it something clear like Deploy SCCM Client (MSI).
Right-click the new GPO and select Edit.
Navigate to Computer Configuration > Policies > Software Settings > Software Installation.
Right-click Software Installation and select New > Package.
Browse to the share where you copied CCMSetup.msi and select it. Use the UNC path (\\fileserver\sccm-client\CCMSetup.msi), not a mapped drive letter. Drive mappings won't resolve in the computer context where this policy runs.
In the Deploy Software dialog, select Assigned and click OK. Assigned packages install automatically on the next computer startup.
Close the editor. Reboot a representative target machine to trigger installation.

Important: You cannot pass installation parameters (like SMSSITECODE, SMSMP, or FSP) to CCMSetup.msi. The MSI installs the client framework, then ccmsetup.exe runs and reads its install properties from either Active Directory (if the AD schema has been extended for ConfigMgr) or from the Windows registry. If your environment has not been schema-extended, use Method 2 instead, since the script method lets you pass site parameters directly.

Method 2: Run ccmsetup.exe from a GPO startup script

The startup script method is more flexible. It lets you pass site code, management point, fallback status point, and any other ccmsetup.exe parameters that match your environment, which is why most teams use it in practice over the MSI method.

Copy the entire Client folder from \\<siteserver>\SMS_<sitecode>\Client\ to a domain-readable share (for example, \\fileserver\sccm-client\). Both ccmsetup.exe and the supporting files must be present at the same path.
Save the following as install-sccm-client.bat on the same share:
Click to copy script
@echo off if exist "%WINDIR%\ccmsetup\ccmsetup.exe" goto :EOF "\\fileserver\sccm-client\ccmsetup.exe" /mp:sccm-mp.contoso.local SMSSITECODE=P01 FSP=sccm-fsp.contoso.local
The first line checks whether the client is already installed and exits, if necessary, so the script doesn't reinstall every boot. Replace the management point hostname, site code, and fallback status point with values from your environment.
In the GPMC, create a new GPO linked to the target OU (or open the GPO from Method 1 if you're using one combined policy). Name it something like Deploy SCCM Client (script).
Right-click the GPO and select Edit.
Navigate to Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown).
Double-click Startup.
Click Add and browse to install-sccm-client.bat on the share. Use the UNC path.
Click OK to save.
Reboot a representative target computer. The script runs as SYSTEM at boot, so it needs the share to be readable by Domain Computers, not just authenticated users.

Common ccmsetup.exe parameters worth knowing:

Parameter	Purpose
/mp:<hostname>	The management point the client should contact first
SMSSITECODE	The three-character site code (for example, P01); use AUTO to let the client auto-discover via AD
SMSMP	Specifies the management point during installation
FSP	Fallback status point. Useful for installation failure reporting
CCMHOSTNAME	The cloud management gateway, when deploying clients to internet-based machines
/forceinstall	Reinstalls even if the client already exists. Use sparingly
/source:<path>	Source location for the client files when the share path differs from the calling path

Method 3: Provision installation properties using the SCCM ADM templates

Method 3 is different from the first two. It doesn't deploy the client. What it does is provision installation properties (site code, management point, fallback status point) to the registry on every machine in the OU. When CCMSetup actually runs later, whether triggered by Method 1, by software update-based installation, or by client push, it reads those properties from the registry instead of needing them on the command line or in an extended AD schema.

This is the canonical Microsoft approach when the AD schema has not been extended for Configuration Manager. It's also the right choice when you want central, GPO-enforced control over which site a machine assigns to, separated from the mechanism that runs the install.

Two .adm templates ship with the SCCM site server:

ConfigMgrAssignment.adm configures the assigned site code, the site assignment retry interval, and the site assignment retry duration.
ConfigMgrInstallation.adm configures the CCMSetup command-line properties (everything you'd otherwise pass to ccmsetup.exe).

Both live at <ConfigMgr installation directory>\tools\ConfigMgrADMTemplates\ on the site server, or under SMSSETUP\TOOLS\ConfigMgrADMTemplates\ on the installation media. Note these are legacy .adm files, not modern .admx. They import into the Classic Administrative Templates node of a GPO.

Copy the ConfigMgrADMTemplates folder from the site server to a workstation that has GPMC installed (or run GPMC directly on the site server).
In the GPMC, create a new GPO linked to the target OU (or open one of the deployment GPOs from Methods 1 or 2 to put everything in one policy). Name it something like SCCM Client Provisioning.
Right-click the GPO and select Edit.
Navigate to Computer Configuration > Policies > Administrative Templates.
Right-click Administrative Templates and select Add/Remove Templates.
Click Add, browse to the ConfigMgrADMTemplates folder, and select ConfigMgrAssignment.adm. Click Add again and select ConfigMgrInstallation.adm. Then click Close.
Navigate to Computer Configuration > Policies > Administrative Templates > Classic Administrative Templates (ADM) > Configuration Manager > Configuration Manager Client. The two policies imported in step 6 appear here.
Double-click Configure Configuration Manager Site Assignment, select Enabled, set the Assigned Site Code to your three-character site code (for example, P01), and leave Site Assignment Retry Interval (minutes) and Site Assignment Retry Duration (hours) at the defaults of 5 and 1 unless you have a specific reason to change them. Click OK.
Double-click Configure Configuration Manager Client Deployment Settings, select Enabled, and in the CCMSetup field enter the same parameters you'd pass on the command line, for example SMSSITECODE=P01 SMSMP=sccm-mp.contoso.local FSP=sccm-fsp.contoso.local. Click OK.
Close the editor.

The settings populate HKLM\SOFTWARE\Microsoft\CCMSetup on every machine in the OU at the next Group Policy refresh. When CCMSetup runs (deployed by Method 1 or any of the other supported methods), it reads from that registry path instead of expecting properties on the command line.

One known limitation worth flagging: ConfigMgrInstallation.adm has a 255-character cap on the CCMSetup field. If your install command has more than a handful of parameters or long FQDNs, it can hit the limit. The workaround is to keep the most critical properties (site code, MP, FSP) in the ADM template and pass the rest on the ccmsetup.exe command line in Method 2.

How to verify the client installed

After the target machine reboots, confirm the SCCM client is installed and registered.

On the target machine, open Control Panel > System and Security > Configuration Manager (or open it directly with c:\windows\ccm\smscfgrc.cpl). The Configuration Manager applet appears once the client is installed.
In the applet, the General tab should show the assigned site code, the management point, and a green Connected status.
From an elevated Command Prompt, run gpresult /r /scope computer and confirm the deployment GPO appears under Applied Group Policy Objects.
Check C:\Windows\ccmsetup\Logs\ccmsetup.log for installation details. Successful installation ends with the line CcmSetup is exiting with return code 0.
Check C:\Windows\CCM\Logs\ClientIDManagerStartup.log for the client's initial registration with the site.
If you used Method 3 to provision install properties, confirm the registry was populated: reg query "HKLM\SOFTWARE\Microsoft\CCMSetup". The values should match what you set in the ADM template policies.

Troubleshooting

The MSI installs but the client never registers with the site.
The schema is probably not extended, so the client can't find installation properties in AD. Either switch to Method 2 with explicit SMSSITECODE and SMSMP parameters, or store installation properties in the registry under HKLM\SOFTWARE\Microsoft\CCMSetup and use a registry preferences GPO to populate them.
ccmsetup.log shows "Failed to access source path" or error 0x80070005.
The share is not readable by Domain Computers. Startup scripts run in the SYSTEM context, which reads share permissions as the computer account, not the logged-on user. Add Domain Computers to the share and NTFS permissions with Read access.
The script runs every reboot and reinstalls.
The if exist check in the batch file is missing or the path is wrong. Confirm the script uses %WINDIR%\ccmsetup\ccmsetup.exe (the installed binary) rather than the source share path.
GPO is applied but no installation attempt happens.
Software installation policies require a reboot. They do not install on gpupdate /force. Force a reboot on the test machine.
Different return code than 0 in ccmsetup.log.
Microsoft publishes a list of ccmsetup.exe exit codes. The most common in GPO deployments are 0x80004005 (generic, usually a permissions or network issue at the share) and 0x80070643 (a prerequisite, often .NET Framework, is missing on the target machine).
Clients appear in the SCCM console as failed pushes after the GPO succeeds.
Site-wide client push installation is still enabled and is racing the GPO. Go back to the Before you start section and disable site-wide push (or scope it away from the GPO's target OUs).
Method 3 settings don't show up in the GPO editor.
The classic ADM templates were imported but the Filtering view in Administrative Templates is hiding non-managed policies. In the GPO editor, click Administrative Templates, right-click and select Filter Options, and check Show "Filter Out" options. Make sure Show only configured policy settings is cleared.
HKLM\SOFTWARE\Microsoft\CCMSetup is populated but CCMSetup ignores the values.
Any installation properties passed on the ccmsetup.exe command line override the provisioned registry values. If you're combining Method 2 and Method 3, choose one source of truth for site code and MP, not both.

How to manage the deployment GPO at scale with ADManager Plus

ADManager Plus provides a centralized, web-based GPO management console that complements the work you do in the Group Policy Management Editor. Once your SCCM client deployment GPO is created, with either the Software Installation package or the startup script configured, ADManager Plus helps you operationalize the rollout across the domain without giving every admin direct GPMC access.

Bulk GPO linking: Link the SCCM client deployment GPO to multiple OUs in a single action, especially useful when a rollout expands from a pilot OU to six or seven OUs across multiple sites, instead of repeating each link manually in GPMC.
Link order management: Adjust GPO precedence directly from the web UI when a conflicting policy, often an older client deployment GPO from a previous rollout, is overwriting the new one, ensuring the right configuration wins.
On-demand policy refresh: Trigger an immediate GPO refresh on selected computers, useful when you want to verify the policy reached the machine before rebooting it to kick off the installation.
GPO replication: Copy the SCCM client deployment GPO to another domain in a multi-forest environment without rebuilding the MSI package or startup script entry from scratch, keeping configurations consistent across environments.
Application visibility: Use the GPO Settings report to confirm the MSI path or startup script is configured correctly across all your deployment GPOs in one view, and the Resultant Set of Policy report to confirm the policy actually applied to a specific computer before hunting through ccmsetup.log.
Delegation oversight: Scope GPO updates and GPO reporting tasks to help desk technicians through role-based delegation, so the team rolling out the SCCM client doesn't need Domain Admin rights to perform the policy operations.

Frequently asked questions

How do I install the SCCM client manually with the command line?

From the Client folder on the site server (\\<siteserver>\SMS_<sitecode>\Client\) or a local copy, run ccmsetup.exe from an elevated Command Prompt with the parameters that match your environment, for example: ccmsetup.exe /mp:sccm-mp.contoso.local SMSSITECODE=P01 FSP=sccm-fsp.contoso.local. The installer runs silently in the background and writes its log to C:\Windows\ccmsetup\Logs\ccmsetup.log. A return code of 0 in the log means a successful install.

What is CCMSetup.msi?

CCMSetup.msi is the Windows Installer package for the Configuration Manager (SCCM) client. It's what you assign through a Software Installation GPO in Method 1. The MSI installs the client framework but doesn't accept installation parameters at install time, so it needs to find its site code, management point, and other properties from one of three sources: an extended AD schema, the registry (provisioned via Method 3), or a follow-up call to ccmsetup.exe.

Does installing the SCCM client require a reboot?

The client install itself doesn't force a reboot in most cases. However, deploying via a Software Installation GPO (Method 1) needs a reboot to trigger the install in the first place, since assigned MSI packages only run at boot. A reboot may also be required if the install replaces a prerequisite like .NET Framework that needs one to finish. After install, the SMS Agent Host service starts running without a reboot.

How do I push the SCCM client without GPO?

Configuration Manager supports five main client installation methods besides Group Policy:

Client push installation from the SCCM console (the site server connects to each target over SMB and WMI with a configured client push installation account).
Software update-based installation (the client is published through WSUS and installs via the Windows Update channel).
Manual installation (run ccmsetup.exe directly on each target).
OS image-based installation (include the client in a base Windows image via task sequence).
Microsoft Intune co-management enrollment for cloud-managed scenarios. Each suits a different deployment context.

What is the difference between client push and GPO deployment?

Client push is initiated from the SCCM site server. The site server connects out to each target over SMB and WMI, using a designated client push installation account with local admin rights on the target. It needs inbound firewall ports open on the client and credentials that map to local administrators across the estate. GPO deployment is the inverse: the install runs on the target, in the SYSTEM context, against a copy of the client source files on a domain-readable share. There's no inbound connection from the site server, no credentials in flight, and no client push installation account to maintain. The trade-off is that GPO needs a reboot to trigger and doesn't report install status back to SCCM the way client push does.

Where is CCMSetup.msi located?

On the SCCM site server, CCMSetup.msi is at <ConfigMgr installation directory>\bin\i386\CCMSetup.msi, which is typically C:\Program Files\Microsoft Configuration Manager\bin\i386\CCMSetup.msi. The full Client folder, which contains ccmsetup.exe and all its dependencies (used for Method 2 and for manual installations), is published as a share at \\<siteserver>\SMS_<sitecode>\Client\.

How to deploy SCCM clients using Group Policy