Getting Domain-Joined Clients into ConfigMgr (and Making Software Center Useful)

You’ve got ConfigMgr installed. You’ve got a domain controller. You’ve even got a client VM sitting there, domain-joined, doing absolutely nothing. Time to connect them.

This is a quick rundown of what it actually takes to push the ConfigMgr client to domain-joined machines and get applications showing up in Software Center. Fewer steps than you’d think, but every single one matters.

The Prerequisites Nobody Tells You About

Client push sounds simple. ConfigMgr copies files to the client’s ADMIN$ share, creates a service, and starts it. But it won’t even get that far unless three things are true on the client:

  1. The File and Printer Sharing firewall rules are enabled (inbound and outbound).
  2. The Windows Management Instrumentation (WMI) firewall rules are enabled (inbound).
  3. The push account is a local administrator on the target machine.

That’s SMB (TCP 445), RPC endpoint mapper (TCP/UDP 135), and RPC dynamic ports. Without all three, the push silently fails and the CCM.log on your site server just shows connection errors.

Do It With GPO, Not Per Machine

Don’t touch the client manually. Create a GPO, link it to your Computers OU, and configure two things:

Firewall rules (Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Inbound Rules):

Enable the predefined rule groups “File and Printer Sharing” and “Windows Management Instrumentation (WMI).”

Local admin for the push account (Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups):

Update the built-in Administrators group and add your push service account. I’m using DEV\svc_cmpush, a dedicated account in the Service Accounts OU. Not a Domain Admin. I would never do that. *cough*

Anyway, every future client that lands in that OU gets both settings automatically. No per-machine prep.

The ConfigMgr Side

Four things need to exist before you push manually:

AD System Discovery. Administration > Hierarchy Configuration > Discovery Methods > Active Directory System Discovery. Point it at your Computers OU, enable recursive search, and run a full discovery. Your client needs to show up in Assets and Compliance > Devices before you can push to it.

Boundary and boundary group. Create an IP subnet boundary for your lab network, then a boundary group that references it. Assign your site server as the site assignment server and distribution point. Without this, the client installs but never figures out which site it belongs to.

Client push installation account. Administration > Site Configuration > Sites > your site > Client Installation Settings > Client Push Installation > Accounts tab. Add the DEV\svc_cmpush account here.

Don’t enable automatic push if you want manual control. Leave that checkbox alone.

Push It

Force a gpupdate /force on the client. Verify with net localgroup Administrators (your push account should be listed) and check that the firewall rules are active.

Then from the site server, confirm connectivity:

Test-Connection CT-CLIENT01 -Count 1
Test-Path "\\CT-CLIENT01\ADMIN$"

Both pass? Go to Assets and Compliance > Devices, right-click your client, and choose Install Client. Walk through the wizard.

The CCM.log on your site server will show the push connecting via the admin share, copying ccmsetup.exe, creating the ccmsetup service, and starting it. You’ll see a WMI error about root\ccm namespace (0x8004100e) and an NTLM fallback warning. Both are harmless. The first is ConfigMgr checking if a client already exists (it doesn’t). The second is informational since Kerberos succeeded.

On the client, watch C:\Windows\ccmsetup\Logs\ccmsetup.log for the installation progress. Give it a few minutes to finish, then trigger a machine policy retrieval:

Invoke-WmiMethod -Namespace root\ccm -Class SMS_Client -Name TriggerSchedule "{00000000-0000-0000-0000-000000000021}"

The client should flip to “Yes” in the console’s Client column.

Brand Software Center

Before deploying apps, make Software Center look like it belongs to your organization.

Administration > Client Settings > Default Client Settings > Properties > Software Center. Set “Select these new settings to specify company information” to Yes, then configure:

  • Company name (shows in the top banner)
  • Color scheme (primary color for the banner)
  • Logo (JPEG or PNG, 400×100 pixels, max 750 KB)

You can also add custom tabs that point to internal URLs. I pointed one at our internal wiki just to see it working.

Deploy Applications

Create a query-based device collection that catches all your client machines. I used a WQL query matching on computer name:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client
from SMS_R_System
where SMS_R_System.Name like "CT-CLIENT%"

Any new client matching that pattern rolls into the collection automatically.

Then, Software Library > Application Management > Applications > Create Application. Point it at an MSI file on a network share, let the wizard auto-detect the metadata, and finish. Distribute the content to your DP, then deploy it to your collection as Available.

Trigger a policy refresh on the client, open Software Center, and there it is. Users can install it on demand. Switch the deployment purpose to Required when you want forced installs.

The Whole Chain

When you line it all up, this is what makes client push and Software Center work:

  • GPO: firewall rules + local admin for push account
  • Discovery: finds the machine in AD
  • Boundary group: ties the network to the site
  • Push account: registered in ConfigMgr, member of local Administrators via GPO
  • Client settings: Software Center branding
  • Application + deployment: content distributed, deployed to a query-based collection

Miss any one of these and something breaks quietly. But once it’s in place, every new client you spin up just works.