That looks familiar right? It is the wonderful co-management settings introduced in SCCM 1710. At our organization we have begun working with Intune, which naturally leads us down the Co-Management path via SCCM. During the setup of Co-Management you are able to setup a ‘Pilot’ deployment so that you can test out some of the features before promoting them to production use. Ultimately, these Co-Management configs are Configuration Policies that get deployed to your device collections. You’ll see one is deployed to your ‘All Systems’ collection while the pilot settings are deployed to your Pilot collection that you specify.
This is all fine and dandy, but what if I want to start testing the waters of these settings a bit more granularly? You’ll noticed that you’ve no way to interact with these outside of manipulating the Deployment settings such as the schedule, or deleting it altogether. Imagine a scenario where you have a large number of users successfully piloting Endpoint Protection policies from Intune, and now you want to test ‘Windows Update policies’ or ‘Office Click-to-Run apps’ on a subset of your pilot users without mucking up your larger pilot group.
Initially when I was looking into creating multiple co-management pilots I was checking out the XML definition of the policy and thinking I could create a new one. I quickly realized I was overthinking things. As I am prone to doing, I resorted to PowerShell…
And I struck gold! New-CMCoManagementPolicy sounds like exactly what I want. A quick first observation, this always generates a Configuration Item with the same name, CoMgmtSettingsPilot2. Because of this, any subsequent runs of the cmdlet will throw an error unless you rename your previously created Co-Management policies. We will cover that below.
This cmdlet has one required parameter, AutoEnroll. This parameter determines if the Co-management setting deployment will force auto-enrollment with Intune. Aside from that, all others are optional and default to $false. Below is a quick reference for what the other parameters map to.
- CAWorkloadEnabled = Compliance policies
- RAWorkloadEnabled = Resource access policies
- WufbWorkloadEnabled = Windows Updates Policies
- EPWorkloadEnabled = Endpoint Protection
Notice anything odd? Office Click-to-Run apps is not an option! Device Configuration is also not, but that workload is implied by either Endpoint Protection or Resource Access policies. More on this later, for now let’s create our new policy, rename it and deploy it.
In my scenario I’m actively piloting everything except Office Click-to-Run apps and Windows Update policies. I would like to pilot those additional features, but only on a smaller subset of our pilot users. We will start with Windows Updates as there is a parameter available to us for this workload.
$NewPolicy = New-CMCoManagementPolicy -AutoEnroll $true -WufbWorkloadEnabled $true
$PolicyID = $NewPolicy.CI_ID
$NewPolicy | Set-CMConfigurationItem -NewName ‘CoMgmtSettingsPilot-WUFB’
#This one works in 1806
Get-CMConfigurationPolicy -Id $PolicyID | New-CMConfigurationPolicyDeployment -CollectionName ‘Pilot – Intune WUFB’
#This one works in 1810, and might work in 1806, but I upgraded my lab…
New-CMConfigurationPolicyDeployment -CoManagementPolicy (Get-CMConfigurationPolicy -Id $PolicyID) -Collection (Get-CMCollection -Id $CollectionID)
BAM! That’s all you gotta do. You now have a ‘granular’ deployment of JUST the windows update setting for Intune. It even has an informative name! I also rename it because you can’t set the name on creation, and future attempts to create a CMCoManagementPolicy will throw an error otherwise. We can check our CoManagementHandler.log on the respective clients and should see some entries similar to below. You can actually see all of the Co-Management policies being evaluated in the log. The client will use the cumulative policy from all deployments.
We also can view all our deployed Co-Management policies in the Configuration Manager applet as seen below as well. Look how nice that custom labelled one looks!
Three’s company!
In the log snippet above you can see that the workloads for Co-Management have some magical numbers associated with them! Fun fact, I have a degree in Math. The log above shows that I merge workload 17 with 47 resulting in a final workload of 63.
- Spoiler: 17+47 != 63
We all seem to know that when you add capability, the number seems to go up! As thorough as that explanation is, I decided to dig in a little bit. Below is a link to a function on GitHub to translate these numbers to workload names, and vice-versa. I’ve also provided a GIF of it in action.
The gist of what is in the git is bitwise operators and hashtables!
$Workloads = @{
3 = “Compliance policies”;
5 = “Resource access policies”
17 = “Windows Updates Policies”;
33 = “Endpoint Protection”
45 = “Device Configuration”
129 = “Office Click-to-Run apps”
}
As an example, if we want “Windows Update Policies” and “Office Click-to-Run apps” then we need both 17 and 129. If you input ’17 -bor 129′ into a PowerShell prompt you’ll receive 145 as an output. This is easier to visualize if we convert everything to binary.
I like to think of -band and -bor as the ‘least common denominator’ of the binary world. The picture above demonstrates this in the context of our Co-Management workloads.
Alright, last thing! I’m piloting everything except… C2R apps. For whatever reason this is not a parameter on our New-CMCoManagementPolicy cmdlet. Configuration Items are just XML right? So let’s generate a new policy, rename it, gather the XML, update our workload value, update the Configuration Policy and deploy it.
$PolicyName = ‘CoMgmtSettingsPilot-C2R-Appss’
$PilotCollectionName = ‘Pilot – Intune C2R-Apps’
$Workload = Convert-CoManagementWorkload -DesiredWorkload “Office Click-to-Run apps”
$NewPolicy = New-CMCoManagementPolicy -AutoEnroll $true
$PolicyID = $NewPolicy.CI_ID
$NewPolicy | Set-CMConfigurationItem -NewName $PolicyName -OutVariable NewPolicy
[xml]$XML = Get-CMConfigurationPolicy -Id $PolicyID | Select-Object -ExpandProperty SDMpackagexml
($XML.DesiredConfigurationDigest.ConfigurationPolicy.Rules.rule | Where-Object { $_.id -eq ‘CCMSS_CoManagement_Settings_Capabilities’ }).expression.operands.constantvalue.value = $Workload.ToString()
Set-CMConfigurationItem -Id $PolicyID -DigestXml $xml.OuterXml
#This one works in 1806
Get-CMConfigurationPolicy -Id $PolicyID | New-CMConfigurationPolicyDeployment -CollectionName $PilotCollectionName
#This one works in 1810, and might work in 1806, but I upgraded my lab…
New-CMConfigurationPolicyDeployment -CoManagementPolicy (Get-CMConfigurationPolicy -Id $PolicyID) -Collection (Get-CMCollection -Id $CollectionID)
That all looks to add up if you ask me. We are now able to granularly deploy the various Intune workloads to pilot collections. In the end, this may be unnecessary for some environments. It might be that you don’t care if your pilot collection is testing all of the settings at once. Hopefully you at least learned something, -bor and -band maybe?
Cody Mathis
Add comment