Category: Main Menu

Runbook is in an Invalid State

PROBLEM


A common issue I run in to a lot with SCSM automation is the Following error message:

The Runbook associated with this Runbook activity template <Name of template>, is in an invalid state. Select another Runbook or ensure that the Orchestrator connector is properly configured

The Runbook associated with this Runbook activity template <Name of template>, is in an invalid state. Select another Runbook or ensure that the Orchestrator connector is properly configured

Error message in the SCSM console

CAUSE


This is caused by the Runbook being in an invalid state within SCSM, not within Orchestrator.

To see what I mean, within SCSM, Navigate to the Library workspace and select the Runbooks node.

Invalid Runbook

Invalid Runbook

When a Runbook within SCSM is in an invalid state, it is usually because the input Properties for the Initialize activity within the Runbook itself has been changed since the first sync of the Orchestrator connector and SCSM does not know what to do with the new properties. (or the removal of the old ones)

SOLUTION


The solution is fairly straight forward.

Within the SCSM Console, select the Runbook that has a status of “Invalid” and select Delete.
This will delete it from the SCSM Console and not Orchestrator.

Then re-run the Orchestrator Connector:

  1. Select the Administration workspace
  2. Select the Connectors node
  3. Selecting the Orchestrator connector you need to re-run
  4. Click Synchronize Now in the tasks pane

Re-run the Orchestrator Connector

Re-run the Orchestrator Connector

Once the connector has finished it should all be back to normal.

Advertisements

Orchestrator Runbook Running….. but not.

I’ve had several customers come to me over the past few years complaining about one or more Runbooks showing that they are in a running state but they don’t show that there is any activity. Neither in the Log within the Runbook designer, nor in the console.

Problem


As you can see here the Runbook has been invoked and is in “Play” but there is no log data showing what step it is currently processing.

runbook

CAUSE


The thing that the Runbooks have in common are they are triggered from Service Requests within SCSM, usually from a Request Offering from the self-service portal.
On close inspection, it turns out that in passing properties to a Runbook the initialize data activity does not “Cleanse” the data and therefore any reserved characters are not protected by “” when used as input to the Runbook. So when a value gets passed that contains a character like &, > or <, the Orchestrator console try’s to interpret it as a command.

Solution


Don’t use &, < or > in any value that you pass to Orchestrator.

Within SCSM ensure any enumeration list or simple list that the end users may select from do not contain the &, < or > characters.

What gets harder is if the end user types this detail in to a free form text field. This you can prevent with a little >NET Regular Expression trickery.

On any text field that the end user will have free for them to enter text as they see fit that will be used to pass to a Runbook, use the following .NET Regular Expression filter to filter out any special characters:

^[a-zA-Z0-9~!@#$%*()-=+;:,.? ]+$

 

Neat Trick to Get SCSM Service Request Attachments

Have you ever wished that you could get the attachments out of an SCSM work item without having to go into the console and dig them out?

I know I did.

With the almighty power of Google, I found a few PowerShell scripts that do this, and I thought I would share how I have used some of that code. In this example I am using a SCORCH Runbook to call this PS script. This way we can leverage the Runbook in other automation activities.

First, an example or two of how this can be used.

Let’s say we have an SCSM Request Offering published via the portal. In this RO, the user can attach a document (let’s call it a work order). Normally, the analysts processing this request would have to dig it out of the SCSM work item manually. By utilizing this Runbook , we can automate storing the attachment in a network folder. Perhaps this folder is monitored by your document management system, or maybe it’s just a central repository for these documents.

Another way you might use this is to email that attachment to another party via Runbook automation. The user submits the attachment, the job gets logged, the Runbook kicks off, the attachment is stored in a temporary folder and then attached to an email sent from SCORCH.

So how do we do this?

An overview of the Runbook (pretty simple hey)

rb

The Initialize Data activity has some fields that we might like to pass along to the following activities. You can plan this ahead of time to best suit the way you wish to use it. You will need one for the SC Object GUID of the Service Request. I’ve also added a field for Destination and the friendly ID of the work item (e.g.. SR123456). The script creates a folder with that ID to store the files in. Your Runbook will need to know this ID to move that folder after the script has run. You could pass the variable out of the script to the Runbook , but if you are already parsing the SR’s SC Obj GUID, it’s easy enough to also pass through the SR ID.

The .net activity is a PowerShell script, and it is going to invoke a PSSession on the SCSM server. You could also use the Execute PowerShell Script activity with the appropriate details of your SCSM Server.

Here is the script.

$Session=New-PSSession -ComputerName “scsmserver”
Invoke-Command -Session $session -ScriptBlock
{
Import-Module ‘C:\Program Files\Microsoft System Center 2012\Service Manager\Powershell\System.Center.Service.Manager.psd1’
$SMServer=”scsmserver”
$SR=Get-SCClassInstance -ComputerName $SMServer –Id ‘{SC Object GUID from “Initialize Data”}’
$targetclass=Get-SCSMRelationship -ComputerName $SMServer -DisplayName “Has File Attachment” | where {$_.Source -eq (get-scsmclass -ComputerName $SMServer -Name System.WorkItem)}
$files=$SR.GetRelatedObjectsWhereSource($targetclass)
$ArchiveRootPath=”C:\Temp\OrchestratorRemote\”
#For each file, archive to entity folder
$filelist=@()
if($files -ne $Null)
{
#Create archive folder
$nArchivePath=$ArchiveRootPath + “” + $SR.Id
New-Item -Path ($nArchivePath) -ItemType “directory” -Force|Out-Null

$files|%{
Try
{
$filelist+=”$nArchivePath$_”
$fileId=$_.EnterpriseManagementObject.Id
$fileobject=get-scsmclassinstance -ComputerName $SMServer -Id $fileId
$fs = [IO.File]::OpenWrite(($nArchivePath + “\” + $_.EnterpriseManagementObject.DisplayName))
$memoryStream = New-Object IO.MemoryStream
$buffer = New-Object byte[] 8192
[int]$bytesRead|Out-Null
while (($bytesRead = $fileobject.Content.Read($buffer, 0, $buffer.Length)) -gt 0)
{
$memoryStream.Write($buffer, 0, $bytesRead)
}
$memoryStream.WriteTo($fs)
}
Finally
{
$fs.Close()
$memoryStream.Close()
}
}
}
$file1=$filelist[0]
$file2=$filelist[1]
$file3=$filelist[2]
}

Remove-PSSession $Session

What that has done is copied any attached files from our Service Request to C:\Temp\OrchestratorRemote\(SR ID) on the SCSM Server. You can alter that path to whatever suits.

The last activity in the Runbook is going to move that folder to the path specified in Initialize Data. Add a “move folder” activity, with the source as \\scsmserver\c$\temp\orchestrator and the destination path as {Destination from “Initialize Data”}

Now, if you ever need to get attachments out of work items – you can just invoke this Runbook and off it goes.

Making Better Use of Service Request User Input in SCSM – Part 3

At a recent meeting of the Adelaide System Center User Community and also at Cireson Innovate 2015 I did a presented on Self-Service Automation Deep Dive (https://vimeo.com/143957653) and showed several automation techniques that I have used over the years. In this series of blog posts I will explain these techniques, why they are useful and how to go about automating them in your environment. (And maybe even share a Runbook or two.)

In Part 1 we looked at taking the Affected User’s name and placing it in the title of the service request to make it easier to find when looking at a queue of work.
In Part 2 we looked at taking some basic user input text fields and placing them in the Description field of the service request.
In Part 3 we will look at taking a multi select query field and enter each of the results in the description field so they are nicely formatted.

What’s Wrong With User Input?

When an end user enters data in to a service request the results are recorded in properties of the associated SR or any activities that are related to that SR. To try and “Help” the analyst these values are then also displayed in the User Input section on the SR form.

With text and drop down lists the data is shown in a format that is easy to read.

image_thumb3_thumb

Query results however are not as easy.

image_thumb1_thumb

Not only is the select value shown but also the GUID of the item. If the query is set to allow multiple selections, like the one above, there can be multiple values all mixed together.

This is far from simple and some analysts, especially second and third level support, may never actually read this data or understand what it all means.

How Could User Input  Be Used Better?

There are a couple of ways I will cover that I think are the most useful ways to use this User Input data on a day-to-day basis. This data would be much more useful if it was somehow added in a nicely formatted way in the SR description or even key pieces of data in the Title.

In part one we looked at the title only and in Part 2 we will cover the Description field.

Multiple Values in the Description

In this example SR a user can select multiple values from a query of Business Service CI’s that are distribution lists.
Instead of having to use the User Input field to determine what DL to add the user to it would be much easier for the analyst to have this information nicely formatted in the description field for easy retrieval and action.

Like so:

image_thumb6_thumb

Once the user has selected multiple Configuration Items (CI’s) they are then associated with, or related to, the Work Item we are dealing with. (In this case, and in most, the work item is a Service Request)

A Runbook that we might use to update the SR description text with a list of all the items selected by the user (in this case distribution lists) might look a little like this:

Update Description Runbook

Looks fairly simple enough, lets quickly run through it:

  1. Get the Service Request item back from SCSM
  2. Get any Service Request and User relationships
  3. Filter the user CI’s that have been returned to only pass the Affected User
  4. Get the Affected User’s AD User CI from SCSM and update the title of the SR
  5. Get any AD Groups that have a relationship to the SR
  6. Get the Related AD Group and update the Description of the SR with the Distribution list

Seems simple enough. Each AD User group that represents a Distribution List will be found and the value written to the SR Description like so:

Update Description Runbook2

The issue is, that with each AD Group that is found that “Branch” (for lack of a better word) of the Runbook will run once. So if the user selects 3 AD Groups, the branch (labelled #6 in the previous image) will run 3 times.

Instead of appending the AD Group Display name to the description each time, it will over write the description with a new value each time, so the end result will be the last of the 3 groups being listed but nothing else.

To get around this and list each one, we need to do the following:

  1. Read the SR Description as it is right now
  2. Read the Display Name of the AD Group
  3. Write the Original SR Description back to the SR and append the AD Group we just found.

So how do we do this?

To do this we remove the Get AD Group and Update SR activities from our existing Runbook, and replace them with a single Invoke Runbook activity. Like so:

Update Description Runbook3

We then have to create a new Runbook that this will call each time.

Update Description Runbook4

As we described above this Runbook will:

  1. Read the SR Description as it is right now
  2. Read the Display Name of the AD Group
  3. Write the Original SR Description back to the SR and append the AD Group we just found.

The Update SR Description activity just has the description from the Get AD Group activity, plus, the Display Name from the Get SR Object activity. Like so:

Update Description Runbook5

So long as the SR Description field has all the precursor text we want in the template then that will contain the heading for us.

Such as: “Please add this user to the following AD Groups:”

The final output should look something like:

Please add this user to the following AD Groups:
– Social Club
– All Users
– Accounting
– Asia Pacific

Like always, I hope this was helpful.

Making Better Use of Service Request User Input in SCSM – Part 2

At a recent meeting of the Adelaide System Center User Community and also at Cireson Innovate 2015 I did a presented on Self-Service Automation Deep Dive (https://vimeo.com/143957653) and showed several automation techniques that I have used over the years. In this series of blog posts I will explain these techniques, why they are useful and how to go about automating them in your environment. (And maybe even share a Runbook or two.)

In Part 1 we looked at taking the Affected User’s name and placing it in the title of the service request to make it easier to find when looking at a queue of work.
In Part 2 we will look at taking some basic user input text fields and placing them in the Description field of the service request.
In Part 3 we will look at taking a multi select query field and enter each of the results in the description field so they are nicely formatted.

What’s Wrong With User Input?

When an end user enters data in to a service request the results are recorded in properties of the associated SR or any activities that are related to that SR. To try and “Help” the analyst these values are then also displayed in the User Input section on the SR form.

With text and drop down lists the data is shown in a format that is easy to read.

image_thumb3

Query results however are not as easy.

image_thumb1

Not only is the select value shown but also the GUID of the item. If the query is set to allow multiple selections, like the one above, there can be multiple values all mixed together.

This is far from simple and some analysts, especially second and third level support, may never actually read this data or understand what it all means.

How Could User Input  Be Used Better?

The user input data would be much more useful if it was somehow added in a nicely formatted way in the SR description or even key pieces of data in the Title.

In Part 1 we looked at the title only and in Part 2 we will cover the Description field for some basic input fields such as First Name, Last Name, Phone number etc.

Basic Fields in the Description

In this example SR a user can enter basic text fields in to the service request.

Lets Automate it!

Like before we create a new Runbook and give it a name that we will be able to find later. Remember: When in SCSM the folder structure of Orchestrator is lost so don’t rely on the folder structure to be able to find Runbooks when you need to. Add a numbering sequence at the front of the Runbook name to help with that.

SNAGHTML16279182

Then, like all automation Runbooks, we need to start the Runbook with an Initialize Data activity that will get the Input from the SR. In this case, we will want to gather not only the SR number but whatever fields we want to bring in from the User Input also. (We technically don’t need this as we can retrieve the stored data from the SR at a later date, but it saves time in the long run.)

Add a property in the Initialize Data for the following fields:

  • SR Number.
  • First Name
  • Last Name
  • Phone Number

NOTE: You can really put any fields here you want to capture from the user input or SR class.

Select Service Request as the class for the Get Object and filter on the ID property using the subscribed SR Number from the Initialize Data activity.
image image

At this point we have all the fields we need to capture the data input by the end user for use within the Runbook.

To cut this post short I’ll not go in to mapping the User Input fields to the Runbook Automation activity, but needless to say it is exactly the same as you would do for mapping the value to an SR property.

So, assuming we now have all the User Input mapped to these properties we can then start to update the SR just like we did in Part 1 but the Description property instead of the Title. Building on the Runbook that we built in part 1 of this series we will just add the additional properties tot he Update SR Object. Just like the Title we want to take the current Description on the SR (given to us from the Get Object activity) and then update the Description field with the current value *plus*  each of the properties that we captured in the Initialize activity.

image_thumb17

Open the Update SR Object and add the Description property in the Fields to be updated. Right click on the text box and select Expand, to make our lived easier. We are now going to add the Title value that we retrieved when we first ran the Get Object. This will give us the Title as it is right now.
We can then add a space, a hyphen and another space to make the formatting look nice, then add the users Display Name field.
image_thumb6 image_thumb19 image_thumb20 image_thumb21

The updated field will now look like this:
image_thumb22

And we’re done.

To make it even easier to follow the Runbook is available Here to download.

Making Better Use of Service Request User Input in SCSM – Part 1

At a recent meeting of the Adelaide System Center User Community and also at Cireson Innovate 2015 I did a presented on Self-Service Automation Deep Dive (https://vimeo.com/143957653) and showed several automation techniques that I have used over the years. In this series of blog posts I will explain these techniques, why they are useful and how to go about automating them in your environment. (And maybe even share a Runbook or two.)

In Part 1 we will look at taking the Affected User’s name and placing it in the title of the service request to make it easier to find when looking at a queue of work.
In Part 2 we will look at taking some basic user input text fields and placing them in the Description field of the service request.
In Part 3 we will look at taking a multi select query field and enter each of the results in the description field so they are nicely formatted.

What’s Wrong With User Input?

When an end user enters data in to a service request the results are recorded in properties of the associated SR or any activities that are related to that SR. To try and “Help” the analyst these values are then also displayed in the User Input section on the SR form.

With text and drop down lists the data is shown in a format that is easy to read.

image

Query results however are not as easy.

image

Not only is the select value shown but also the GUID of the item. If the query is set to allow multiple selections, like the one above, there can be multiple values all mixed together.

This is far from simple and some analysts, especially second and third level support, may never actually read this data or understand what it all means.

How Could User Input  Be Used Better?

The user input data would be much more useful if it was somehow added in a nicely formatted way in the SR description or even key pieces of data in the Title.

In Part 1 we will look at the title only and in Part 2 we will cover the Description field.

The SR Title

Does your Service Request view look like this:

SNAGHTML78a6ad4

All service requests look the same.
An end user then calls up and asks for an update on their service request but hasn’t got their SR Number so you have to search for this Affected User or even the Requested User if someone other than the affected user  is calling.

Instead, what if we took the Affected User, or the Requested User from the SR Input data (or any other unique data for the matter) and add it to the Title of the SR?
It would look like this:

SNAGHTML7887f30

Now, doesn’t that look better?!
Much easier to read and quicker to see which SR is which and much easier to jump to the SR that I want as quick as possible.

Lets Automate it!

It’s all well and good knowing what we would like it to look like but if we have to manually type this information in it kind of defeats the purpose of trying to save time and effort.

Like with any automation we need to have a way to call the Runbook (Orchestrator or SMA) in the right sequence and to do this we use the activity workflow.
I usually like to call these Runbooks “Process <Service Request>” so I can create multiple of them that are custom to the type of service request being processed and so that I can keep track of them.

In this example I am going to automate the formatting of data for a single service request with no other activities. I will cover multiple activities in a future blog post.

First off, we need to create a new Runbook in Orchestrator and give it a name that is easy to remember.
This one I’m going to call “Process DL Request”.

NOTE: When in SCSM the folder structure of Orchestrator is lost so don’t rely on the folder structure to be able to find Runbooks when you need to. Add a numbering sequence at the front of the Runbook name to help with that.

SNAGHTML98680d

Then we need to start the Runbook with an Initialize Data activity and we need to get the SR record with a Get Object activity filtered on the SR ID passed from the Initialize Data activity.

image

Add one property in the Initialize Data for the SR Number that will be passed from the Service Request.

Select Service Request as the class for the Get Object and filter on the ID property using the subscribed SR Number from the Initialize Data activity.
image

  image

Once we have the Service request we then have access to all the data stored in the Service Request and any relationships that SR has.
Properties such as Title, Description and User Input are stored in the SR but fields that contain a class, such as Affected User or any multi select query types, are stored as relationships between the SR and the target class.

So to pick the Affected User and add it to the end of the title on the Service Request we first have to retrieve all related user class objects and filter all excluding the Affected User object.

image

Add the Get Relationship activity and rename it to something like Get SR\User Relationships and link it to the Get Object activity for the Service Request. Then add a Get User Object to the Get Relationship activity. This will be used to get the User record from SCSM once we know it.

We are looking for the relationships between the Service Request class and the Active Directory User class. This will return ALL user relationships that may exist with this SR. These may be Affected User, Assigned User, Related User, etc. so we have to filter out what we don’t want. To return the User information we get the user SC Object Guid from the Related Object Guid that is returned. At this point we  will return ALL the users that are related to the SR. So we need to filter the results and this is done on the link.
Double clicking on the link will allow you to create an exclude filter based on Relationship Class.
Exclude all results that DO NOT EQUAL “Affected User”
Do yourself a favour and change the colour of the link to red and maybe even name the link to make it easier to read later.
image image imageimage

We now have all the prices we need to edit the information. Add an Update Object activity from the Service Manager Integration pack so we can now manipulate the data on the SR.

What we want to do is take the current title on the SR (given to us from the Get Object we just added) and then update the Title field with the current value *plus* the Affect User name.

image

Select the Service Request class and the SCObjectGuid from the Get Object activity.
Add the Title property in the Fields to be updated. Right click on the text box and select Expand, to make our lived easier.
We are now going to add the Title value that we retrieved when we first ran the Get Object. This will give us the Title as it is right now.
We can then add a space, a hyphen and another space to make the formatting look nice, then add the users Display Name field.
image image image image

The updated field will now look like this:
image

And we’re done.

To make it even easier to follow the Runbook is available Here to download.