Runbook Export and Step by Step Configuration Guide - TechNet Gellery
Two years ago at MMS 2011 I gained my first exposure to System Center Orchestrator (Opalis). True story – I am sitting in a conference room at the Mandalay Bay casino and resort. Unbeknownst to me I am gaining my first exposure to a ‘newish’ technology that would eventually work its way into my career. The session is going off great, minds being sufficiently blown at the coolness that is Opalis, and then the fire alarm goes off. Seriously, there may be a fire in the building. I suppose that my first reaction should have been to run for my life, I do recall at least one individual doing so. However for most in the room, the reaction was to stay put. Some stood up so that the presentation could be heard better, some actually moved closer to the stage. I am reflecting back on this MMS session because the content of that session included the integration of Opalis and Configuration Manager Operating System Deployment, with focus on providing self-service scheduling of the OSD process. I went into the session mostly interested in Operating System Deployment, I left an Orchestrator guy.
In this blog post I will be paying a small homage to that MMS session. I will be demonstrating how Service Manager, Orchestrator, Configuration Manager, and Exchange can be used to provide a Self Service - Operating System Deployment - scheduling mechanism. This demonstration is by no means as feature rich as what was presented at MMS 2011, however should provide a good foundation on which to build.
In this post I will be demonstrating the automation of four basic processes:
- How to provide a self-servicing OSD scheduling mechanism (integrated with the Outlook Calendar)
- How to provide rich reminder notifications of pending OS deployment
- Once scheduled, how to use the Exchange appointments as a trigger mechanism for the actual OS deployment
- How to scrub the systems of any canceled deployment items
Without doubt this demo includes an intricate series of runbooks and I will not be able to deep dive into each aspect. I will however provide a demonstration video, and then step through each runbook at a high level, calling out any activity or other automation piece that is worth noting. Finally, I will be providing an export of the runbooks. Included with the export is a document that provides step by step instruction for configuring the runbooks.
Standard Disclaimer:
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use
The runbooks detailed and made available in this blog posting are for demonstration and sample purposes only. These samples are not production ready and are not intended for placement into production systems. These runbooks are not feature complete and include no error control or resiliency control. These samples should be tested in a lab or other non-production environment only. Each runbook will need to be evaluated and modified to match standard runbook control patters for each individual environment.
Process Demonstration Video:
I am going to kick this post off with a quick video demonstration of the process. My hope is that after seeing the process in action, examining each included runbook will be a bit less tedious.
Service Manager Configuration:
I will not go into any detail on how to configure the Service Manager components of this solution, rather provide a few links that should help piece together a similar Service Manager Self Service Portal experience.
- Charles Joys - Automation–Orchestrating Service Manager Orchestrating Orchestrator
- Travis Wright – Displaying a User’s Computers in a Request Offering
Runbooks:
There are many runbooks involved in this sample solution. I have organized these in several logical (sub solution) folders (1.0, 2.0, etc.). I will be stepping through each sub solution highlighting any worthy activates, expected inputs and outputs. Along with the four sub-solutions, I have created a folder of ‘common’ components. These are basically re-useable runbook which have been discussed many times both in my blogging and other places. These common runbooks perform processes such as retrieving an email address from a user name, or retrieving a user name from SCSM Service Request. I will not be detailing these common runbooks in this posting, however have included them in the runbook exports for examination and re-use.
Once you have completed this 'high level' solution and runbook overview, you can download the ready sample runbook at this location - TechNet Gallery . This download includes a step by step configuration document.
Runbook Folder Structure - notice that each sub process is organized into a numbered folder (1.0 - create meeting, 2.0 - email notification, etc.) and contains a main runbook and one or more sub runbooks.
1.0 - Create Outlook Meeting:
This folder consists of one main runbook, and two sub process runbooks. The main runbook also executes two common runbooks (not shown). The process is as follows:
Actions or Inputs:
- Take in the date, time, and AM/PM from the submitted service request and format
- Get user from the service request (common runbook)
- Get users email address (common runbook)
- Create Exchange (Outlook) appointment
Output or Results:
- An appointment is placed on the requestors Outlook calendar.
Main runbook - nothing of note here.
Format Time Sub Routine - takes in the date, time, and AM/PM and returns a properly formatted date / time.
With the user and email address taken from the SR and the properly formatted time, an Exchange appointment is created.
2.0 – Email Notification:
This process consists of one main runbook and two sub runbook’s.
Actions or Inputs:
- Execute main runbook once an hour
- Filter out any past appointments
- Get OS deployment information (User) from current appointments
- Send email notification to those with appointments occurring within the hour
Output or Results:
- Requesting User receives an email notification with instruction on how to cancel deployment if the so desire.
Main runbook is executed once an hour.
This filter routine will remove any old appointments from the data flow, returning only current appointments. This will then return the email address of any user whom has a current appointment scheduled within the hour.
An email notification is sent to the email gathered from the previous sub-process..
3.0 - Create Deployment and Close SR:
This component consists of one main runbook and three sub runbooks. The main runbook also executes two common runbooks. The process is as follows:
Actions or Inputs:
- The main runbook is schedule once every five minutes.
- Any past appointments are filtered out
- All OS Deployment appointments that occur within five minutes are gathered
- The SR information is gathered for each of these appointments (related computer object).
- The computer is added to a pre-defined Configuration Manager collection.
- The Exchange appoint is modified to reflect that the deployment has started
- The Service Manager SR is closed.
Output or Results:
- The operating system deployment process is started on the related computer
- The Exchange appointment is updated to reflect that the process has started
- The Service Manager Service Request is closed
Main runbook - scheduled to execute every five minutes.
This runbook will filter out any appointment that to do not have a start time of five minutes from runbook execution. The Location (SRID) of each current appointment is then returned to the main runbook.
Not shown in the screen shot is a common runbook execution which will take the returned location (SRID) and gather the associated computer name. This informaiton is then used to add the computer to the deployment collection and then refresh Configuration Manager policy on the computer.
Finally the SCSM Service Request will be updated and closed
4.0 -Scrub any Stale SR:
Finally, in the event that an appointment is canceled, which will prevent the OS Deployment process, I would like to go back and close out the corresponding Service Manager Service Request. This process consists of one main runbook, and one sub runbook. The process is as follows:
Actions or Inputs:
- Once a day the main runbook is executed.
- We then check for any ‘In Progress’ SR’s with a title of ‘CM Schedule OSD - Service Request’.
- The SRID’s of these requests are compared to the location field of the Exchange appointment.
- If no appointment is found with a location (SRID) that matches the SR SRID, then the SR is closed.
Output or Results:
- Any Service Requests without a corresponding Exchange appointment are closed.
Main runbook scheduled to run once a day
Each OSD Scheduling SR with a status of in progress is compared with exchange appointments. for any SR without a related appointment, the SR up completed (closed).
Conclusion:
I hope that you find the content here as well as the sample runbook helpful. Not only is the outcome of the sample runbook (OSD scheduling) pretty cool, but the exercise of piecing together the solution should also provide some good hands on experience working with Orchestrator integration into both Service Manager and Exchange. Until next time, happy automating, subscribe to my twitter feed on using the button located on this page, and I hope to see you at TechMentor Las Vegas 2013 where I will be talking about all things Orchestrator.