The first part covered how to setup a SCOM monitor and trigger a fake alert. This post will focus on configuring the connector between SCOM and SCSM. The goal is to have incidents that are auto-generated from SCOM events.
Continue reading
Introduction
Automating Incident & Problem management – Part I: Creating a SCOM monitor and generating fake alerts
This is the first part of a series of posts which will demonstrate how automation can be implemented in Incident and Problem Management. For this, fake SCOM alerts will auto-generate incidents in SCSM, triggering specific Orchestrator runbooks that will provide a fix for the generating issue.
This first part walks through the steps of configuring a Monitor in SCOM and creating fake alerts to be used in future posts.
Child runbooks in Orchestrator: Automating an uniquely named,fully patched VM with basic apps installed.
I always see people comparing PowerShell with Orchestrator, or thinking of Orchestrator as a GUI for PowerShell. From my point of view the real power of Orchestrator lies in its capabilities to integrate at different levels to multiple systems and bring them together in a simple “runbook”.
Finally in this post, we can bring together all the previous runbooks and get to experiment with child runbooks. For this all the previous runbooks have to be ready:
- Part 1: Install SCCM agent
- Part 2: Generate Unique VM Name
- Part 3: Orchestrating Software Updates and Application Deployment
Another prerequisite for this runbook is having a VM template (with Windows 7 in my case) ready for deployment.
Scenario
The main idea, when creating these little runbooks, was to have a VM that:
- Was auto generated
- Has an unique name that complies with a specific standard
- Is fully patched
- Has a minimum of applications installed
Following this scenario, we easily get to connect to Active Directory, Exchange, SCCM and SCVMM. And we could go even further, by integrating this runbook with SCSM, for change management (future post).
Orchestrating Software Updates and Applications Deployment
This scenario continues the idea of the automatically generated virtual machine, adding automatic patching and basic application deployment. All the pieces will fit together in the next post.
With this example I want to point out that you don’t necessarily have to do everything in Orchestrator. Since it relies a lot on SCCM, there is a lot of flexibility in this runbook, it’s up to you how much do you automate in Orchestrator and what it remains to be done in SCCM.
Generate Unique VM Name
This small runbook is a demonstration on how to use counters and variables and some basic smart link conditions. It also emphasizes one important difference between Opalis and SC Orchestrator (spoiler: cycles are not allowed! More about this on this cool post: http://www.sc-orchestrator.eu/index.php/scoblog/49-cycles-in-pipleline-mode)
The scenario for this runbook: You want to create a VM but you want the name to be auto-generated following some basic naming convention and you want to make sure that is unique. You also might have users manually creating VMs using the same naming conventions so you need to check this carefully. The runbook will look like this:
An automation blog 