Day 23: PowerShell and System Center Service Manager 2012–SMLets

Welcome to Day 23 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.

In my previous post, “Day 18: PowerShell and System Center Service Manager 2012 – Getting Started”, I introduced us to the out-of-the-box PowerShell cmdlets that ship with System Center Service Manager 2012 (SCSM), and I created a short script that used those cmdlets to create a new incident.  The beauty of the SCSM cmdlets is that they are available with the product. However, as we saw in the blog post, they can be a little difficult to work with, as you have to know specific class names to be able to use the cmdlets effectively.  I can’t just call “Create-Incident”, I have to get the Incident class, then call New-SCSMObject using that class.

But what if I want the ability to just say “Create An Incident”? Demand for this type of common task automation led to the creation of the SCSM PowerShell SMlets, a complimentary set of PowerShell cmdlets, created by the community, for automating common tasks in SCSM.

NOTE: These PowerShell cmdlets rely on the Service Manager SDK assemblies, so they need to be run either on the Service Manager Management Server or a computer where the Service Manager console is installed.

The latest version of the SMlets is SCSM PowerShell Cmdlets BETA 4, March 24, 2012.

Let’s look at how we can create the same incident from my previous post, using the SMlets:

I’ve taken 25 lines of code and reduced it to 2! The first line imports the SMlets module. After that, all I have to do is call the New-SCSMIncident cmdlet, and pass in the appropriate parameters. Notice how I don’t have to use a hashtable. Instead, I can add the appropriate parameters to the cmdlet to create the incident.

You can find a detailed list of all the SMLets at

This brings up the question, when should you use the native PowerShell SCSM cmdlets, and when should you use the SMLets.  And the answer, of course, is, it depends.  The SMLets usually provide an easier way of of interacting and working with SCSM.  The catch is, you have to make sure the Service Manager console, as well as the SMLets themselves, are installed on any machine that will be executing your PowerShell scripts (such as your desktop, an Orchestrator runbook server, or your SCSM Management Server).   If you rely just on the native SCSM PowerShell cmdlets, they can take a little more “elbow-grease” to get working, but you can feel confident they will run on any machine where the Service Manager console is installed. Personally, I tend to stick with the native PowerShell cmdlets for a majority of my PowerShell tasks in Service Manager, for just this very reason. But the choice is yours. If you have complete control over your environment, then the SMLets may provide a better route for interacting with SCSM.

Now that we have looked at the two different ways of using PowerShell to interact with System Center Service Manager, lets tie this back to our previous TFS conversations. In my next post, I’ll show you how we can create a new work item in TFS, based off a new incident being created in Service Manager.

One thought on “Day 23: PowerShell and System Center Service Manager 2012–SMLets

  1. Bad Kitty

    Hey Mickey, you lost me a little here. In your previous post, I see you created an incident with PowerShell. What do the SMLets add to the equation here? Just to make the script for creating an incident shorter and simpler?

    It would be great if maybe you could clarify in this post or in the comments:

    • Do you recommend using SMLets in a production environment?
    • Do you recommend your customers use the SMLets?
    • What are some common situations where you use them?


Leave a Reply

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