Hey folks, here with a quick post today in response to a question about ConfigMgr client deployment in the WinAdmins Community the other day. The question was posed in regards to alternative ways to deploy the CM client without using Client Push, because Client Push is bad and no one should use it for various reasons. The common answer is to use some form of startup script, such as the ConfigMgr Client Health Script by Anders Rødland, or the ConfigMgr Client Startup Script by Jason Sandys. However, there’s another method that can be used in environments where using scripts like this is not desirable for one reason or another: software update based client deployment. Microsoft documents this use here, however, I feel that their method could be made a bit more flexible.
WARNING: This post will go over directly setting registry items that are normally configured via Group Policy administrative templates, which may or not be 100% supported. It works it theory and in practice, but be forewarned, your mileage may vary, etc.
Prerequisites
- At least one active Software Update Point in your ConfigMgr site
- Updates classification enabled in SUP configuration
- Software update based client installation option enabled
- ConfigMgr site published to Active Directory
- Since software update based deployment does not support custom installation parameters, it must be able to discover the CM site information from AD
Configuration
Microsoft’s recommendation is to configure a Group Policy Object using the Windows Update admin template, similar to the following:
This seems pretty simple, but now you need to think about where it is linked. This setting should not be configured via Group Policy on CM-managed clients, so we need a way for it to no longer apply once the client is installed. Aha, I’ll use a WMI filter!
|
1 |
select Name from Win32_service where Name = 'ccmexec' |
But that will filter on computers with the service, not without, and I don’t think it’s quick and easy to make a “not” version of that query. Welcome to the stage, Group Policy Preferences, and Item Level Targeting!
Instead of using the admin template, create 3 new computer registry preferences, as follows (replace “https://CM-SUP.ad.domain.tld:8531” with your top-level Software Update Point URL):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Hive: HKLM Key Path: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Value Name: WUServer Value Type: String Value Data: https://CM-SUP.ad.domain.tld:8531 Hive: HKLM Key Path: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Value Name: WUStatusServer Value Type: String Value Data: https://CM-SUP.ad.domain.tld:8531 Hive: HKLM Key Path: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU Value Name: UseWUServer Value Type: DWORD Value Data: 1 |
Next, configure each of these preferences with Item Level Targeting:
|
1 2 3 4 5 |
Item Type: Registry Match Item Options: Is Not Match Type: Key Exists Hive: HKEY_LOCAL_MACHINE Key Path: SYSTEM\CurrentControlSet\Services\CcmExec |
Once this GPO is configured, link it to an OU containing computer objects that you want to target, and when they next scan for updates, they will only be offered the ConfigMgr client, and become managed!
Registry values #1 and #2 examples are identical, I think the Registry value name for #2 should be “WUStatusServer” and not “WUServer”?
I love this Item-Level Targeting example, and I’m going to start using this method! Thanks for sharing.
Haha, yes, that was just a minor copy/paste error, I’ve updated it, thanks!