Sending mail to users in the “Configuration Items: Computers, Services and People” field in System Center 2012 SP1 – Service Manager

The latest revisions to the Exchange Connector creates configuration items for the users on the To or Cc lines of an e-mail, then adds a relationship to those objects via the “Configuration Items: Computers, Services and People” field on the service request and incident request.

Recently one of our partners asked us to create an auto-response e-mail that was sent to everyone that was on the To and Cc line (as well as the original sender) of an e-mail that was sent to Service Manager. This notification subscription would run on service request creation.

Since the service request is created with the person who sent the e-mail being added as the affected user, we initially began by creating a notification subscription that sent mail to the affected user. This was done by adding the affected user field under the ‘Related Recipients’ section of the subscription:

We next tried to add the field that contains the configuration items in the “Configuration Items: Computers, Services and People” section. If you have ever tried this, you will find there are 100’s of different relationships to choose from in the notification subscription UI within the Service Manager console. After going through these, I didn’t know which to choose.

Instead of going through a lot of trial and error trying to find the right field, I decided to go straight to the management pack XML and add it directly.

To do this, we first need to save the subscription we started creating so we can modify it in the XML. Make sure you remember the name you gave it so we can find it later on. We then need to export the management pack we saved the subscription in.

We next need to identify the class that contains the relationships in the “Configuration Items: Computers, Services and People” field. I did this by first installing the SMLets cmdlets (https://smlets.codeplex.com/), a custom set of cmdlets built by members of the Service Manager product team. The SMLets contains a cmdlet called get-scsmrelationshipclass. Running this, we received a list of relationship classes that Service Manager contains. After looking through the entire list, I decided that the “system.workitemrelatestoconfigitem” looked like it was likely the correct class.

To test the class out, I ran the get-scsmrelatedobject cmdlet to see if I could retrieve all of the items from the “Configuration Items: Computers, Services and People” field on an SR. This was done by getting the Service Request class, retrieving a Service Request that I knew had related users in the “Configuration Items: Computers, Services and People” field, and pulling the relationships:

$class = get-scsmclass -name system.workitem.servicerequest | where {$_.name -eq 'System.WorkItem.ServiceRequest'}
$sr = get-scsmobject -class $class -filter 'displayname -like "*SR1161131*"'
$rel = get-scsmrelationshipclass system.workitemrelatestoconfigitem
get-scsmrelatedobject -smobject $sr -relationship $rel

Looking at the service request we have the same users on SR1161131 as we found in the PowerShell output, so we know we have identified the correct class (system.workitemrelatestoconfigitem).

Now we can crack open the management pack we exported earlier in our favorite XML editor. We first need to search for the friendly name of the notification subscription we created, then copy the DisplayString ElementId (the internal name for the subscription we created, highlighted below):

 

Searching the same MP for ‘NotificationSubscription_4d992732_b60d_4e82_98ae_a01b6aec6444’, we will arrive at a corresponding Rule Id that contains the criteria for this subscription:

Within this rule id, scroll down until you see “<WorkflowArrayParameter Name="PrimaryUserRelationships" Type="string">”. This is where your affected user criteria is defined:

Simply add an additional “<Item>” under the existing one that contains the class we found above:

<Item>$Context/Path[Relationship='CustomSystem_WorkItem_Library!System.WorkItemRelatesToConfigItem' TypeConstraint='CustomSystem_Library!System.User']$</Item>

Your final result will look like the following:

Once this is done you can save the management pack and reimport it into Service Manager. If you look at the newly modified notification subscription in the console, you will see your new field added:

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Hi Rob, Travis' release from April records users on the To and Cc lines of an e-mail to the "Configuration Items: Computers, Services and People" field, so yes, that release will work with this solution. Unfortunately all we are doing in the XML is telling the subscription what field to look at when sending mail to individual users.  There is no way that I am aware of to allow us to exclude a user or group.  Having said this, the Exchange connector doesn't actually seem to record groups to the "Configuration Items: Computers, Services and People" field, so you should be fine using this solution as the subscription won't find any groups in this field.  You can also double-check this by looking at any of your SRs where someone Cc'd a group.  The group shouldn't exist. Andrew

• Anonymous
  March 18, 2013
  So your saying....in the new version of the exchange connector that we can send an auto response to those users who are in the CC field or can it work for the exchange connector travis released last April for SCSM 2012?

• Anonymous
  March 18, 2013
  Can you exclude a CI from the XML file? We have users who e-mail a group so that group is in the related items tab. I think I understand it just need to know if there is a way to exclude that group? Thanks

• Anonymous
  May 15, 2013
  This is causing Circular loops, because the new exchange connector Add the TO address also in the related configuration Items. When the mail goes to All related recipients , which includes helpdesk email address for case creation !!