Day 18: PowerShell and System Center Service Manager 2012––Getting Started

Welcome to Day 18 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC.

I’ve been talking about DevOps and PowerShell in the context of Team Foundation Server.  For my next several posts, I’m going to switch gears. DevOps, in my opinion, is not just about developers and IT Pros. The Service Desk also plays a significant role. By Service Desk, I include incident, problem, change, and service management functionality.  The Service Desk is where many of the issues in your environment are initially recorded, as well as where changes are tracked. Microsoft provides enterprise-class service desk software as part of the System Center Suite, called System Center Service Manager (SCSM).   In this post, I’m going to introduce you to using PowerShell with SCSM. Future posts will then build off this information.

NOTE: I’m running all these directly on the SCSM Server. As such, I’m not specifying the SCSM Server I want to connect to. I’ll show you in a future post how to do that.

SCSM ships with with out-of-the-box cmdlets divided into two modules:

  • System.Center.Service.Manager – contains cmdlets needed for common administrative tasks
  • Microsoft.EnterpriseManagement.Warehouse.Cmdlets – contains cmdlets needed for working with the SCSM data warehouse

SCSM ships with a PowerShell command window that automatically loads the System.Center.Service.Manager module. This cmdlet module is not installed in the typical path listed in the $env.PSModulePath variable. You can usually find it here: “C:\Program Files\Microsoft System Center 2012 R2\Service Manager\PowerShell”.  Click here to see a list of all the SCSM out-of-the-box cmdlets.

The following script creates a new incident in SCSM and writes out the incident ID:

Let’s break down the script.

I want to create a new incident, so I need a reference to the SCSM Incident class. I can get that using the Get-SCSMClass cmdlet.  By providing the appropriate class name, this cmdlet returns a class reference, in this case the incident class.  Some of the other classes I could use include:

  • System.WorkItem.Problem$
  • System.WorkItem.ChangeRequest$
  • System.WorkItem.ServiceRequest$
  • System.WorkItem.ReleaseRecord$

Next, I set the ticket number, or ID, of the incident. This is normally the number that is given to the affected user, to help them reference their service desk ticket.  In SCSM, by default, all incident ticket numbers begin with “IR”.  And the Id field itself is an auto-increment field, meaning it will automatically increase every time a new work item is created. The above code creates a new Id that starts with “IR”, and then appends the auto-incremented value. If I didn’t put the “IR” prefix in here, then the incident would just have a numeric value, which would not be following my SCSM standards.

I can set any field on the incident from within PowerShell. In the above code, I’m specifying the Title and Description of my incident.

According to ITIL, the priority of an incident is determined by its impact and urgency. Therefor, I need to set the impact and urgency fields on my incident.   But how the heck did I know what values to put there?  Well, I know that impact and urgency are both drop-down boxes in the SCSM console, so they are considered lists.  The first step is to find the list associated with each field.  If I run:

image

This returns all the properties for the Incident class. But I don’t see impact and urgency?  That’s because SCSM uses class inheritance. Impact and Urgency are defined farther back up the tree.  I can run the following code to back one level up the inheritance tree:

image

From here I can see that the two list names are:

  • System.WorkItem.TroubleTicket.ImpactEnum
  • System.WorkItem.TroubleTicket.UrgencyEnum

Now I can use Get-SCSMEnumeration cmdlet to get the values for each list

image

image

And voila, I now have all the list values for both lists.  I can then use the Get-SCSMEnumeration to get a reference to the specific list value that I want, as shown earlier.

Finally, I create a hash table containing all the incident properties, and values that I want to set, and then call the New-SCSMObject cmdlet, and pass it my hashtable to create my new incident.

Here is the output from my script:

image

Incident IR218 was created. I can view this incident using the SCSM Console:

image

By utilizing the out-of-the-box PowerShell cmdlets, as well as, say, the Service Manager Authoring Console, I can now create complex SCSM workflows to implement my Service Desk business processes. I can also use them to help integrate Service Manager with other systems, such as Team Foundation Server (more on that to come).

Next up, I’m going to show you another source of Service Manager PowerShell cmdlets.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.