The automation system I always wanted

Posted by

0

It’s amazing that in 2018 I still get Orchestrator questions, so thank you to everyone who appreciated my small bits of work.

While I haven’t posted anything for years, I’m still very much involved in this space and I was lucky enough to start something that can take these ideas to the next level.

I absolutely loved Orchestrator, even with all its bugs and shortcomings. I think it was a great idea. Actually, the whole System Center stack was such a great story:

  • with CIs coming from AD and SCCM (even SCOM);
  • and alerts opening ticket from SCOM;
  • and the integration between SCORCH and SCSM.

If only SCSM wasn’t so slow and complex, forcing you through the ITIL nomenclature. I’ve yet to see someone actually implementing ITIL right and not just cherry picking whatever they feel most comfortable with.

So what have I done since?

For a while I tried to live with SMA and Windows Azure Pack. Then I was lucky enough to get the chance to actually work on this problem.

Together with some great guys we co-founded a company that’s trying to make automation easy to build, easy to manage and – most importantly – friendly for the end user. Our approach enables the automation not only of IT processes, but of any process. Think about it as a lightweight RPA (Robotic Process Automation).

How do you build automations? With PowerShell. Let me explain:

  • What if you write the PowerShell script – say for onboarding a user – then publish it in Azure Automation. And when the end user formulates the request (in natural language) she sees this:blog-automation
  • As you see, we use a conversational UI as the driver (let’s say a bot) along with some clever tricks to match what the user writes with the correct automation and to ask for the input parameters in a natural, user-friendly way.
  • Here’s our website nibo.ai, and here are some of our blogs: https://blog.nibo.ai. Email us 📧 if you are interested in a demo.

Cool, but with it work with our initial investment in SCSM?

Sadly, no.

I did try that initially. I wasted a whole year on it. But you just can’t fight it, it’s too slow, and even with caching and all sorts of other tricks you can only get so far. I also wanted to simplify the whole idea a bit, because for most companies having a service catalog à la ITIL (Automation → Activity → Request offering → Service offering) is overkill.

No SCSM, no ITIL, so now what?

Light Kanban. There’s actually a book that inspired a lot of the ideas and I highly recommend this to any person working in IT: The Phoenix Project.

Our take on this is simple:

  • Spend less time and effort learning the system, and more on actually building automations.
  • Avoid lock-in caused by using proprietary tech, and instead use something open like PowerShell.
  • Build and test your automation easily on any machine, with no need for special designers, special VMs, UIs etc.
  • Make this easy for the end user to interact with.

There is a lot more, such as ML, analytics, cool search… If you’re interested I’d love to show it to you. The system can be used as:

  • Automation system only (no ticketing) or;
  • Automation + ticketing.

Ping me 🤙

Valentin

Configuring SCVMM to SCSM connector – finding the required Management Packs

Posted by

0

This post was written based on the experience with System Center 2012 R2. There are dozens of posts on the web and technet explaining how to configure the SCVMM connector in SCSM, but in this post I just want to explain where you can find the management packs required for this.

Setting up SCOM, SCCM, AD, SCORCH connectors in SCSM is really easy. It’s so easy that when you start configuring the SCVMM connector, you start thinking that it should be another way of doing this.

In order to get SCVMM objects on SCSM, you actually need SCOM as sort of a “proxy” doing the discovery. Since this connector does a mapping between SCOM and SCSM objects, you need to install some MPs both on SCOM and SCSM. The cool part starts when you want to find these MPs. I would say below is a quick and dirty walkthrough, but it’s actually not that quick.

Continue reading →

Automating Incident & Problem management – Part IV: Replacing Counters with Database tables

Posted by

1

 

Continuing this series, I will provide a more reliable and flexible replacement mechanism for counters: database tables. I am not going again through all the activities in the runbook, since most of them are already described in Part III. I will only focus on the four new activities which replace the counter-based activities from the previous version of the runbook.

Replace Orchestrator Counters with Database
Continue reading →

Automating Incident & Problem management – Part III: Using Orchestrator to remediate the issue (Counter edition)

Posted by

5

After setting up all the prerequisites from Part I and Part II, it is time to create the Orchestrator runbooks that will provide the auto-remediation for active incidents and problems:

Incident Management Automation: This runbook will be triggered by the SQL-related Incidents which were auto-generated in SCSM by the SCOM Alerts. The “fix” for the generating issues, covered in Part I, will be enclosed in a PowerShell Script activity. The result is that an email will be sent to the Incident Owner, notifying him that a problem had been detected and Orchestrator fixed it.

Problem Management Automation: The counters in this runbook will keep track of the number of instances for which an incident was created. If the same incident is triggered and fixed 5 times, a problem will automatically be generated and the runbook will attach any existing and future similar incidents to it. This goes by the principle that a recurring issue should be identified as a problem, not as an incident. Once the problem is marked as “Resolved” or “Closed”, the counter is reset.

SCSM Incident automation, SCSM Problem Automation

Additionally, from Orchestrator’s perspective, this post will also demonstrate why “Counters” are not a very practical solution in most situations, mainly because they are global and not runbook-specific. This idea will be resumed in Part IV, where a more advanced replacement for counters will be implemented.

Before starting the main runbook, besides completing Part I and Part II and installing the IPs, three prerequisites need to be prepared. These include creating two child-runbooks, which might seem out-of-context at this point, but will make sense once they are integrated in the main runbook.
Continue reading →

Automating Incident & Problem management – Part II: Configuring the SCOM–SCSM connector

Posted by

34

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 →

Automating Incident & Problem management – Part I: Creating a SCOM monitor and generating fake alerts

Posted by

3

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.

Continue reading →

While modifying a runbook, I deleted some of my activities / links

Posted by

0

Bad news: There is no “Undo” button. So what do you do when this happens?

You have two options:

  1. Since you deleted part of your runbook, you are probably still in “check out” mode with it. So, in order to see how the runbook was before check-out, log on from a different machine, to Orchestrator Runbook Designer. Select everything inside the runbook and copy it to a new runbook, then start modifying again.
  2. If you just want everything restored in the same runbook, verify the time when you deleted your activities / links (let’s say it was 10:00 a.m.), then go to your Orchestrator database, and run the following query:

use Orchestrator

Select * from OBJECTS where Deleted = 1 and LastModified > ‘2013-11-22 09:55:00.000‘ and LastModified < ‘2013-11-22 10:05:00.000‘

Update OBJECTS set Deleted = 0 where Deleted = 1 and LastModified > ‘2013-11-22 09:55:00.000‘ and LastModified < ‘2013-11-22 10:05:00.000‘

In case you deleted the entire runbook, or worse, an entire folder of runbooks, you should check this post, which covers well the rest of the available undeleting tricks.

Child runbooks in Orchestrator: Automating an uniquely named,fully patched VM with basic apps installed.

Posted by

1

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:

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).

Continue reading →

Orchestrating Software Updates and Applications Deployment

Posted by

2

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.

20131110 - 0 0 Small Picture

Continue reading →