System Center 2012 Configuration Manager and Orchestrator – Using Status Message as a Runbook Trigger Mechanism.
I love the integration of System Center 2012 Configuration Manage and System Center Orchestrator . Any day in which I get to work in a mutual space between these two technologies is a good day. As seen in some of my previous blog postings I have written an application that allows for the manual execution of Orchestrator Runbooks via. Console Extensions (Right Click Tools). This is neat and adds value in somewhat of a service driven or manual capacity. What I will be showing in this posting is another method by which to use System Center 2012 Configuration Manager in order to execute Orchestrator Runbooks however this time in more of automated/reactive fashion. As the title states, in this blog posting I will be exploring the use of Configuration Manager Status Messages as an Orchestrator Runbook trigger mechanism. The sample scenario used in this blog will detail the following process
- Automate the consumption of a very specific type of ConfigMgr Status Message (Software Update Scan Failure on client).
- Trigger an Orchestrator Runbook that will gather information about the effected client.
- The Runbook will then create a System Center Service Manager incident containing all gathered client information.
Please keep in mind that this is just a simple example meant to demonstrate System Center 2012 integration and is by no means a guide targeted at how to identify software update scan failures. While I attempt to use examples that represent common real world scenarios, and while this specific example may be very helpful, there are potentially an unlimited amount of applications for this type of System Center Integration and configuration – Be Creative.
Scenario Overview –
Here is the scenario. You are a service engineer tasked with using System Center 2012 Configuration Manager for the deployment of software updates to all client computers in your portion of an organization. It has been recognized that many machines in your organization experience issues in which an incorrectly applied Group Policy Object causes a software update scan cycle conflict which is causing the failure of all software update deployments to these machines. The issue may be that they have been placed in an incorrect OU or are experiencing some other Group Policy related issue. You would like to automate not only the identification of the offending machines but once identified would also like to automate the creation of a Service Manager Incident which will provide details relevant to the issue.
Technical Overview –
In order to meet the goals as described in this scenario the following will take place (each of these will be detailed later in this posting).
- An Orchestrator Runbook will be created which
- Consumes a Computer Name.
- Discovers the Computers distinguished name which will include the OU Location.
- Opens a Service Manager Incident using this information.
- A Status Filter Rule will be created in ConfigMgr which will trigger when any message with an ID 11424 is detected.
- This Status Filter Rule will execute an application which will in turn start the previously mentioned Runbook, passing to it a computer name consumed from the status message.
- Once the Service Manager Incident has been created an email will be sent from Service Manager informing of the Incident.
- At this point the assigned technician can engage the incident.
Client –
Before starting in on the solution let’s take a quick look at my sample client experiencing the software update scan failure. What I have done is simply created a new OU named and applied to this OU a GPO containing an invalid WSUS Intranet update service address. When applied to my client which is also being managed by configuration manager, the GPO creates a conflict with the Configuration Manager Software Update Point and botches the Software Update Scan Cycle.
WUAHandler.log from effected client (click image for a better view).
As a result of this failure a Status Message with an ID of 11424 is generated.
Status Message (click image for a better view).
Runbook –
The Runbook used in this example consist of three activities.
Click image for a better view.
- Initialize Data – Consumes a computer name.
- Get Computer Information – uses the Active Directory IP to discover the DN of a the identified computer.
- Create WUA Conflict Incident – uses a Service Manager template to create a new incident for the effected computer.
Note - This is a very simple Runbook void of all error handling and flow control. This sample is meant only to demonstrate the execution of Runbooks .via Configuration Manager Status Messages. If done with intent and in a production capacity I would personally add more activities to the Rubnook (or series of Runbooks) which would better handle the start to end execution.
If you would like more information on Runbook Design best practices Charles Joy’s blog is a great place to start with – Charles Joy's Blog
Service Manager Components –
There is not much configuration if any that needs to take palace in Service Manager to support this example solution. For my demonstration (See Video) I have created a Template from which to create the incident however there is no fancy configuration here. I also have my Service Manager environment configured to create and deliver a notification when an Incident is created. So while there is not much to write about on the Service Manager end I will take the opportunity to highlight that in this solution Service Manager itself handles the email notification workflow (as opposed to Orchestrator).
Configuration Manager –
Finally the Configuration Manager portion of the solution. To start this solution we will be creating a Status Filter Rule – this rule will take action when a specific status message has been processed by the Configuration Manager application. As previously discussed when a client fails to scan for software updates due to a GPO conflict a status message of 11424 is generated. So for each client that experiencing the issue, this status message will be generated at each scan cycle.
To create the status filter rule right click your site and select status filter rules.
Click image for a better view.
Click on Create to open up the Status Message Filter Rule property window.
Click image for a better view.
Select Message ID and enter the ID 11424.
Click image for a better view.
Click on the Actions tab in order to configure the action that will execute once a status message of 11424 has been received.
So up until this point I have only indicated that this status filter rule will trigger the execution of an Orchestrator Runbook. I have not detailed how this will be achieved. Thanks to the Orchestrator Web Service there are multiple different approaches that could be used – ultimately each one will be interfacing with the Orchestrator Web Service, passing to it all needed parameters and starting the Runbook. Rather than use a script or cooking up a solution I will be using SCOJobRunner. SCOJobRunner was written by Robert Hearn and supports the remote execution of Orchestrator Runbooks. More information can be found at the following blog.
In order for this to work grab a copy of SCOJobRunner.exe and place this on an accessible share. The command line I have used to support this solution is similar to the following.
\\share\c$\SCOJobRunner.exe -ID:"ECA14605-EDCE-4F16-9E1C-23C2FD3D9819" -Webserver:"<SCO WebService Computer>" -User:<user name> -Domain:<domain> -Password:<password> -Parameters:Computer=%msgsys
Take note of the parameter value - Computer = %msgsys. This piece will pull the effected computer name from the status message and pass this to the Computer (or other specified) parameter in the Orchestrator Runbook.
Execution –
With all of the pieces in place, once an effected machined has attempted and failed at a software update scan cycle, a status message will be generated, the Orchestrator Runbook will execute consuming the computer name from the status message filter rule, collecting data about this computer from active directory, and finally open up a System Center Service Manager Incident including relevant computer details.
Generated Email (click image for a better view).
Created Service Manager Incident (click image for a better view).
Closing and Video Demonstration –
I hope that you have enjoyed this blog and have found this information helpful. I have created a short video demonstration of this process in action. Enjoy!
Video – click here to view the video.
Comments
Anonymous
January 01, 2003
Very nice! I have been recently tasked with working up SCORCH in our environment, and I'm always looking for real-world examples to model. I could see this being very valuable, but in my case I would think that these types of events would be reported up to SCOM from the SCCM mp? So I could create a runbook that reads that event in and processes from there? Also, we're using Service-Now for ticketing, are you aware of an IP that handles that? Thanks,Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
thanksAnonymous
November 01, 2013
Do you have a ny sampless of combining System Center Config Manager and Orchestrator for Automatic Patching?