Action Log Monitor and Notification System for Service Manager Using Orchestrator

The solution detailed in this wiki article provides a complete email based notification system for Service Manager which is not provided natively in System Center Service Manager 2012 R2. All runbooks are available upon request and will be available via Codeplex in the few weeks.

Summary

The Action Log Monitor and Notification System is built using System Center Orchestrator 2012 R2 and is not dependent on any workflow or management pack in Service Manager. It was developed using an installation of System Center Service Manager 2012 R2 as the back end. This system has a total of six runbooks acting as either monitors or functions for the monitors. The monitors watch the action logs for updates and, when detected, uses the other runbooks as functions to parse, format, and email the users on the incident. The end product is a comment log that is maintained for the life of the incident, with all the comments in sequential order, in a text file that can be emailed in a HTML format.

Runbooks

• Analyst Action Log Monitor
• User Action Log Monitor
• AppendCommentLog Function
• AffectedUser Function
• AssignedTo Function
• AllIncidentUsers Function

How It Works

Triggering the System

• The Analyst and User Action Log Monitors should be set to run all the time.  Each monitor uses its respective comments class and triggers based on new entries to the action log. 
• Runbook details will be added soon.

 

Getting the Incident

• The monitors use the Service Manager activities ‘Get Object’ and ‘Get Relationship’ in Orchestrator to find the incident ID that is related to the action log entry that triggered the system. 
• Runbook details will be added soon.

Who Made the Comment?

• The monitors pass the incident ID to either the GetAffected or GetAssignedTo runbooks to determine who made the comment using ‘Get Object’ and ‘Get Relationship’ and correlate it to an actual AD account. 
• Runbook details will be added soon.

The Comment Log

• The monitors pass this function the incident description, ID, the most recent comment, who entered the comment, and that persons AD account.  
• A folder is created, if it does not already exist, using the incident ID for the name.
• A text file is created using the comment, passed from the monitor, so that is the comment can be parsed to only include the latest comment and also for things that will cause issues in HTML formatting later in this runbook.
• A Power Shell script parses the text file using the following rules, in order:
  1. Replaces any “>” with “>” and “<” with “<”.  This needs to be done in case a user types something like <insert word here>, the same will appear in the final comment log.
  2. Replaces “`r `n” with “<br>”.  This needs to be done because the final output of this PowerShell is one long string.  If the carriage returns are not replaced with HTML line breaks, then comment will be one long string regardless of spacing in the original comment.
  3. Finds the string “From:” and deletes it and everything after it using the regex “From:[\s\S]+".  This is done in case the comment came via email, it will only keep the actual reply and not the entire thread.  Note:  This was developed assuming users would be using Outlook or OWA.  Both format replies in such a way that this works.
  4. This last part was created to accommodate a mobile workforce using iPhones.  The script uses two different regex to parse replies from iPhones.  The regex 'Sent from my iPhone[\s\S]+' looks for the default signature and deletes it and everything after it.  If someone has changed their signature, we can parse out the signature but the following, really long, regex finds the string matching anything line “On April 18, 2014 “ and deletes it and everything after.  The regex is "On(\s+)...(\s)((?:(?:[0-2]?\d{1})|(?:[3][01]{1})))(?![\d]),(\s)((?:(?:[1]{1}\d{1}\d{1}\d{1})|(?:[2]{1}\d{3})))(?![\d])[\s\S]+"
• The name of the user that made the comment is going to be used in the comment log, but can’t be used in the format passed by the monitor, “Last Name, First Name”.  A PowerShell script is used to split the string, on the comma, and creates an array with the two resulting strings.
• The next activity determines if a log file already exists.  If one already exists, it skips this next section that parses the description.
• Each comment log begins with the original incident description and who submitted the incident.  To make this happen, the GetAffected function is called to get name of the person who submitted the incident.  A PowerShell script is used to split the name, like above, so it can be reversed.  The process for parsing the description is the same used for the comment.  The resulting output is the first section that is appended to the comment log.
• This is where gets is confusing because the end result we want is a log file that has the latest comments on top but appending files in Orchestrator adds to the bottom, so every time a comment is added to the log we have rebuild the comment log in order. So…starting at this point in the runbook, it doesn’t matter if this is the first comment or the tenth comment, the following will be same:
  1. Copy existing comment into memory
  2. Delete the comment log
  3. Recreate the comment log by appending the latest comment that was parsed earlier
  4. Append the comment log you from memory from step 1
• The last step is to prep it for HTML mail.  To do this:
  1. Copy existing comment into memory
  2. Create the temporary version of the comment log by appending some HTML formatting
  3. Append the comment log you from memory from step 1
• Control is passed back to the monitor.

Who Gets Notified

• To determine who gets notified, the GetAllIncidentUsers function is called which return the Assigned To, Affected, and all Related Users in the incident. An email is created using the temporary comment log as the body and is sent all the users returned by GetAllIncidentUsers. The final step is to delete the temporary comment log.