How I Handle SCSM Email Integration



System Center Service Manager is an awesome product, but doesn’t offer much in the way of email integration ‘out of the box’.

The Goals:

  • End-users get notified on ticket creation, new comments.
  • Correspondence with end-users emails gets routed into ticket comments.
  • Help desk can create service and incident requests directly from their email client.
  • Help desk can easily convert service requests to incidents and vice-versa.

I’m used to using RT (Request Tracker). The goals don’t seem lofty, but it took me a while to really understand that Service Manager is -not- just a Microsoft version of Request Tracker. Though SCSM and RT are both issue tracking products, their approaches are very different. A couple of awesome third-party products exist that offer comprehensive email integration for SCSM (here’s to you Cireson!), but at my current position I have to roll my own solution. Long story.

I needed the following tools to accomplish the goals above. Please download them if you’re trying to follow along.

System Center Service Manager with:

  1. SCSM PowerShell SMLets
  2. PowerShell ShowUI

System Center Orchestrator with:

  1. SCO Data Manipulation IP
  2. System Center 2012 R2 – Orchestrator Component Add-ons and Extensions, which contains:
    1. SCO Exchange User IP
    2. SCO Service Manager 2012 R2 IP
  3. Orchestrator Remote Tools 2.51

In the following blog series, I’ll focus on the goals one at a time:

  1. End-User notification upon ticket creation.
  2. End-User notification when analysts add a ticket comment.
  3. Ticket comment generation upon email receipt (from end users or analysts).
  4. Creating work items from an email client.
  5. Converting between IR’s and SR’s.

It might take a while to get all of this blogged out. Feel free to ping me if things are going too slow :). It’s good motivation.


System Center Orchestrator – Running Powershell

I’ve had a lot of trouble with SCORCH and PowerShell, primarily because Orchestrator will always call PowerShell 2.0. Here’s how I get things done.


  1. Add two new variables
    1. Powershell Scripts Username
    2. Powershell Scripts Password
  2. ‘Encrypt’ the password variable.
  3. Copy the PowerShell script you’d like to run to C:\Scripts on your target system.
  4. Add a ‘Run Script’ activity to your Runbook.
  5. Use the following code template, but replace username/password with variable subscriptions, and replace the PowerShell script name and path.
    $ErrorActionPreference = "Stop"
        $targetComputer = ""
        $username = "{Scripts Username}"
        $password = "{Scripts Password}"
        $securePassword = $password | ConvertTo-SecureString -AsPlainText -Force
        $creds = New-Object System.Management.Automation.PSCredential -ArgumentList $username,$securePassword
        $retval = Invoke-Command -Credential $creds -ComputerName $targetComputer -ScriptBlock {& "C:\Scripts\Generate-VMHostGuestInfoReport.ps1"}
        Throw $_.Exception

Getting data back out is a bit of a problem, so I’ve just been writing data to a file inside my target script, and then reading the file with Orchestrator. It’s a bit of a cludge, but it works.