If you've been tasked with deploying configuration manager clients using group policy, you probably already know that while there are flashier ways to get the job done, this method remains a solid, reliable standby for many sysadmins. It's one of those "set it and forget it" strategies that handles new computers the moment they join the domain, which honestly saves a ton of manual clicking in the long run.
Setting this up isn't exactly rocket science, but there are a few moving parts you need to get right so you don't end up with half your fleet missing the client. Let's break down how to handle this without making it more complicated than it needs to be.
Why stick with the Group Policy method?
With all the talk about Intune and cloud management gateways, you might wonder why we're still talking about Group Policy Objects (GPOs). The reality is that for on-premises environments, GPO is still incredibly efficient. It doesn't rely on the ConfigMgr site server having to "push" the client through a firewall or needing specific administrative shares to be wide open on every single workstation.
Instead, the workstation itself sees the policy, realizes it needs the software, and pulls it down. It's a "pull" rather than a "push," which usually leads to fewer headaches with blocked ports or credential issues. Plus, it's a great safety net. Even if a technician forgets to install the client on a new build, the GPO will catch it the next time that machine reboots on the network.
Getting the ground rules ready
Before you jump into the Group Policy Management Console, you need to make sure your Active Directory is actually ready to talk to Configuration Manager. If you haven't extended your AD schema for ConfigMgr yet, you're going to have a rough time.
Extending the schema lets Configuration Manager publish site information directly to AD. When the client installs via GPO, it looks at Active Directory to find out which site it belongs to. Without this, you'd have to manually script in the site code and the management point, which defeats half the purpose of an automated rollout.
Also, make sure the ccmsetup.msi file is accessible. You can find this in the installation folder of your ConfigMgr site server. You'll want to copy this to a network share where "Domain Computers" has read access. If the computer can't reach the file, the installation will obviously fail before it even starts.
The two ways to handle the deployment
When it comes to deploying configuration manager clients using group policy, you generally have two paths: the "Software Installation" method or the "Startup Script" method.
Using the Software Installation feature
This is the "official" way built into Group Policy. You navigate to the Computer Configuration, go to Software Settings, and add a new package. You point it at that ccmsetup.msi we mentioned earlier.
The cool thing about this is that Windows handles the installation logic. It sees the MSI is assigned and installs it during the boot process. However, there's a catch. The MSI itself is just a "wrapper." It doesn't actually contain the whole client; it just kicks off the ccmsetup.exe process. Because of this, you still need to make sure the client has a way to find its installation properties (like the site code). This is why having your site info published to AD is so critical here.
Using a Startup Script
A lot of old-school admins actually prefer using a startup script instead of the Software Installation node. Why? Because it gives you more control. You can write a simple batch or PowerShell script that checks if the CcmExec.exe service already exists. If it doesn't, the script runs ccmsetup.exe with all the specific command-line parameters you want, like /mp:Srv01 or SMSSITECODE=ABC.
It's a bit more "manual" in terms of setup, but it's often more reliable if your AD schema isn't extended or if you're dealing with a complex network where site assignment is tricky.
Setting up the actual GPO
If you're going with the standard MSI route, here's the gist of how you'll set it up. Create a new GPO and give it a name that actually makes sense—something like "ConfigMgr Client Deployment."
- Navigate to Computer Configuration > Policies > Software Settings > Software installation.
- Right-click and choose New > Package.
- Browse to the UNC path of your
ccmsetup.msi. Don't use a local drive letter; the computers won't know what that is. - Choose Assigned as the deployment method.
Once that's done, you aren't quite finished. You should also look into the Administrative Templates that come with Configuration Manager. If you haven't already, grab the ConfigMgrInstallation.admx file from the installation media and add it to your Central Store. This allows you to go into the GPO and explicitly define the "Configure Configuration Manager Client Deployment Settings." Here, you can type in your command-line properties (like SMSSITECODE=XYZ) just to be absolutely sure the client knows where to go once it wakes up.
Dealing with the "Wait for Network" issue
One of the biggest reasons deploying configuration manager clients using group policy fails is that the computer tries to install the software before it has a solid connection to the network. This happens a lot with fast-booting SSDs.
To fix this, you'll want to enable a specific setting in the same GPO: Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon.
Yes, it might make the first boot take an extra five seconds, but it ensures the machine actually sees the MSI on the network share. Without this, the GPO often just gives up and moves on, and you'll be left wondering why only 20% of your machines have the client installed.
Checking if it actually worked
Once you've linked your GPO to the right Organizational Unit (OU), you'll want to reboot a test machine and see what happens. Don't expect it to be instant. Sometimes it takes a couple of reboots for the policy to apply and the installer to kick off.
The best place to look is the C:\Windows\ccmsetup\Logs\ccmsetup.log. This file is your best friend. It will tell you exactly what's happening. If you see "Installation succeeded with return code 0," you're golden. If you see a 1603 error, you've likely got a permissions issue or a conflict with an existing version.
Another thing to check is the Task Manager. You should see ccmsetup.exe running under the System account. Just let it do its thing. It has to download the rest of the client files from the Management Point, so it might take ten to fifteen minutes depending on your network speed.
Common pitfalls to avoid
I've seen a lot of people pull their hair out over this, and usually, it's something small. First, check your Boundaries in Configuration Manager. Even if the GPO successfully starts the installation, the client won't finish if it can't find a Distribution Point that's "allowed" to talk to its IP address.
Second, make sure you don't have a firewall blocking the client-to-MP communication. If the client installs but never shows up as "Active" in the console, your ports (usually 80 or 443) might be closed.
Lastly, be careful about where you link the GPO. Don't just link it at the domain root unless you want every single server (including your Domain Controllers) to start installing the ConfigMgr client. It's usually better to target specific OUs where your workstations live.
Wrapping it up
At the end of the day, deploying configuration manager clients using group policy is a tried-and-true method that still holds up in most environments. It's great for making sure no machine gets left behind and it doesn't require the same level of overhead that some other deployment methods do.
Get your MSI on a share, tweak your GPO settings to wait for the network, and keep an eye on those ccmsetup.log files. Once you see those clients starting to pop up as "Active" in your ConfigMgr console, you'll know the hard work is over. It takes a little bit of prep, but the automation it provides is well worth the effort.