Share via

System Center 2012 Configuration Manager: Determine Reboot Pending State Using WMI / PowerShell / Orchestrator Runbook

  • Article

While recently working on a Runbook solution for patching Windows Failover Clusters, I ran into the need of detecting if the Software Update installation process had placed the target system into a reboot pending state. After doing some research, I found many ‘loose’ methods for reboot detection, however nothing concrete. That is, until I happened upon a new WMI Class of the CCM_ClientSDK namespace named CCM_ClientUtilities. This little gem was waiting at idle capable of providing reboot pending information. In this post I will be quickly taking a look at the CCM_ClientUtilities class and discussing how to use this class for pending reboot detection in your PowerShell / Orchestrator automation solutions.

Before Getting Started:

Before jumping into the guts and glory of CCM_ClientUtilities, maybe I should lay out the situation in which we may need this pending reboot information. For sure, if a Configuration Manager delivered update requires a reboot, shouldn't we just let Configuration Manager handle the reboot, thus no detection needed? While in many circumstances I would agree with this notion, I have found that when automating process around the installation of updates, when a reboot is not required, there is not a good trigger mechanism indicating that it is ok to advance to the next automated task. Thus, if we pause after update installation, and then check for reboot applicability, we can then either reboot the system before carrying on with the remaining process, or skip a reboot (when one is not needed) and move onto the remaining process items.

CCM_ClientUtilities:

So check it out, below is a graphical representation of the namespace ROOT\ccm\ClientSDK, the class CCM_ClientUtilities, and the Class Method DetermineifRebootPending.

Click Image for better view:

We can invoke this method using any number of WMI interfaces; however for the sake of establishing building blocks towards orchestrator Runbook automation I will be using PowerShell.

PowerShell:

The following PowerShell script first returns the CCM_ClientUtilitiis class object and then executes the DetermineIfRebootPending method, placing the results into a variable $results. I’ve then displayed the results using Write-Host.

$reboot = [wmiclass]"\\<Computer Name>\root\ccm\ClientSDK:CCM_ClientUtilities"

$result = $reboot.DetermineIfRebootPending() | Select RebootPending

Write-Host $result

Pretty simple - lets place this into Orchestrator.

Orchestrator Runbook Use:

For sample sake I am going to provide here a very simple example of this script in use. We will enter a Computer Name into the Initialize Data activity, run the script basically as detailed above, and then perform some link logic against the returned (Published) data from the Run .NET Script activity. If the returned data indicates a reboot is necessary we will do so and then proceeded on with the Runbook (indicated by the Continue Workflow activity). If a reboot is not needed we will jump straight to the Continue Workflow activity.

Sample Runbook (Click image for better view):

Run .NET Script Activity PowerShell (Click image for better view):

Published Data from Run .NET Script Activity (Click Image for better view):

Link Logic when a reboot is required (Click image for better view):

Link Logic when no reboot is required (Click image for better view):

Finally for some practical context, here is an example of a real world Runbook in which this reboot detection logic is used. This Runbook is part of a series of Runbooks that applies software updates to a Windows Failover Cluster (more on this later this week).

Sample Runbook (Click image for better view):

Conclusion:

Simple, quick post here. Just wanted to demonstrate the use of this cool new System Center 2012 Configuration Manager WMI trick. In this post we have looked at some PowerShell that allows us to use the CCM_ClientUtilities class to determine is a Reboot is pending on a system due to Configuration Manager activities. We have then seen how to further use this PowerShell in our Orchestrator Runbook solutions.

Comments

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    June 26, 2013
    Hi Neil, thanks for this great post! Maybe it is worth mentioning that you need to install the SCCM Console on the Orchestrator Server! Further: you should know, that when you have installed the Orchestrator Integration Pack for SCCM, the SCCM Console does not start up any more and the CMDLets won't work anymore. Which means: you need to choose if you use the Integration Pack or the PowerShell CMDlets (i would always go PowerShell regarding Performance) best regards, Pascal

  • Anonymous
    June 26, 2013
    sorry, my earlier post was intended for this post of Neil: blogs.technet.com/.../running-2012-configuration-manager-sp1-powershell-cmdlets-from-an-orchestrator-run-net-script-activity.aspx

  • Anonymous
    June 26, 2014
    A few days ago one of my peers ask me a very interesting question, how can I get a report that show reboot