Introduction
It has always been possible to trigger evaluation of an SMS_DesiredConfiguration instance using the TriggerEvaluation method on the SMS_DesiredConfiguration. Here’s an example of that from fellow MVP Timmy. The only information needed to trigger the instance evaluation was the instance’s Name and Version properties.
For the past couple of releases of ConfigMgr however, there has been a new type of SMS_DesiredConfiguration instance and triggering it’s evaluation requires one more piece of information, which is the PolicyType property from the instance.
If the SMS_DesiredConfiguation instance has a PolicyType parameter defined (not NULL) then the PolicyType value must be passed into the method call of TriggerEvaluation. Older SMS_DesiredConfiguration instances that have been triggered using only the Name and Version can continue to be triggered in this way.
Triggering policy
Let’s imagine that there is a SMS_DesiredConfiguration instance with DisplayName of “Enable BitLocker”, which corresponds to a previously created and deployed BitLocker Management policy as shown below.
On a Windows 10 client that has the policy deployed to it, let’s get the instance using the DisplayName property.
$instance = Get-WmiObject -Namespace root\ccm\dcm -Query "Select * from SMS_DesiredConfiguration WHERE DisplayName = 'Enable BitLocker'"
And below is some of the output from the above line when run on a Windows 10 client that has a policy matching that DisplayName (notice how the Enable BitLocker policy name is highlighted in the Configuration Manager client, so we know it’s deployed and active on this client).
So armed with this knowledge we can use it to trigger evaluation of the SMS_DesiredConfiguration instance with three different methods.
Method #1 – Invoke-CimMethod
Invoke-CimMethod -Namespace root\ccm\dcm -ClassName SMS_DesiredConfiguration -MethodName TriggerEvaluation -Arguments @{“Name” = $instance.Name; “Version” = $instance.Version; “PolicyType” = $instance.PolicyType}
When combined with the instance code from above, the result is shown below.
Method #2 – Invoke-WmiMethod
The order of ArgumentList is important. The parameter names are:
- IsEnforced
- IsMachineTarget
- Name
- PolicyType
- Version
The default value of IsEnforced is true and IsMachineTarget is null, so this call reflects that.
Invoke-WmiMethod -Namespace root\ccm\dcm -Class SMS_DesiredConfiguration -Name TriggerEvaluation -ArgumentList @($true, $null, $instance.Name, $instance.PolicyType, $instance.Version)
And below is the output from the second method.
Method #3 – TriggerEvaluation method on a wmiclass object
The order of the arguments is important again. The parameters are, in order,
- Name
- Version
- IsEnforced
- IsMachineTarget
- PolicyType
IsEnforced and IsMachineTarget are set to their default values.
$class = [wmiclass]'root\ccm\dcm:sms_desiredconfiguration' $class.TriggerEvaluation($instance.Name, $instance.Version, $true, $null, $instance.PolicyType)
And below is sample output from running the 3rd method on a client.
Triggering policy remotely
Methods #1 and #2 can be performed on a remote client by using the -ComputerName parameter with the cmdlets.
Method #3 can be performed on a remote client by prepending the client’s name to the class path. E.g. [wmiclass]'<clientName>\root\ccm\dcm:SMS_DesiredConfiguration’
Thanks goes to Frederic Mokren for this articles content.
