Update: you can download my scripts here

Out of the box Service Manager 2010 can generate incident based on incoming e-mails. But there is no default feature to update incidents based on incoming e-mails. In this post I will show you a solution to that. The flow of the e-mail will be

1. A end-user sends a e-mail to scsm@scsmserver.hq.contoso.local
2. The end-user is connected to the normal Exchange server, which will forward all e-mails for the scsmserver domain to my SCSM server
3. On the SCSM server a vbscript will see if the e-mail contains “Contoso-IR” or not. If it does the e-mail will be moved to a “UpdateSCSM” folder, else it will be moved to a “NewSCSM” folder. As then it will generate a new incident in Service Manager
4. Another vbscript will check all e-mails in the “UpdateSCSM folder”. The script will read “FROM” from each e-mail and which incident to update, it will then kick of a power shell script that will update the incident and attach the e-mail as related item.

Instead of having Service Manager looking at all incoming e-mails the first vbscript will look at them. If the script decides that it is a e-mail that should generate a new incident it will move them over to a another folder and let Service Manager handle it with the default feature. Before you start, make sure to enable incoming e-mails in Service Manager (Administration, Settings, Incident Settings, Incoming E-mails).

The first thing you need to configure is e-mail deliver to a folder. I use my Exchange 2010 machine to send all e-mails for the scsmserver.hq.contoso.local to my SCSM server. On my SCSM server I run IIS and the built-in SMTP feature. It will drop all e-mails to C:\Inetpub\mailroot\drop. I have schedule the following vbscript to run every five minute to sort e-mails. If the e-mail contains “contoso-IR” it will be moved to the UpdateSCSM folder, else to the NewSCSM folder.

 

Once the e-mail is moved to the new folder, in my case C:\Inetpub\maildrop\drop\newSCSM\, the following scripts looks into it

This script looks in all files and tries to find the incident ID. In the e-mail that SCSM send out to end-users about the incidents the subject contains Contoso-IRXX where XX is the incident ID. The script then take the file patch and the incidnet ID and starts a power shell script. This power shell script, see picture below, runs a cmdlet that my colleague Patrik has build, you can download it here. The Set-SCSMIncident cmdlet let you update a incident. The power shell script input a comment and attach the e-mail as a related item to the incident.

 

The following five pictures first show the notification template that sends a e-mail to the affected user when a incident is created. As you can see the subject line contains Contoso-IR<Incident ID>, that is also the string that we look for in incoming e-mails. In the last four pictures you can see the e-mail that a affected user recives when a incident is registered. The end-user replies with and includes the Contoso-IRXX in the subject line. In Service Manager the incident is updated in the action log and the e-mail is attached as a attached file.

If you have problem with open EML files, please take a look at this post.

 

 

This week my friend Patrik Sundqvist and I delivered a Service Manager event together with Microsoft in Sweden. There were a lot of good questions from the audience and a great interest in the product. One of the questions was if the Active Directory synchronize blank attributes from Active Directory if there is a value in the CMDB. Of course we have tried this in a sandbox J

1. I created a new user account in Active Directory. I did not change any default values so the Office attribute (PhysicalDeliveryOfficeName) was set to < Not Set >
2. I ran the Active Directory connector synchronization
3. I verified that I had a blank Office attribute in the CMDB
4. I updated the attribute in the CMDB
5. I logged in and out with the account on a workstation
6. I ran the Active Directory connector synchronization
7. The Office attribute in the CMDB is back to blank

If my AD user object is updated, in this case some attributes was updated when the user loged into a workstation, the watermark on the user object is updated, then the whole user will be synchronized back to the CMDB.

Remember this! What you see is not always what you think in Service Manager. You might think that looking at a computer in the computer form is in fact looking at a single object in the CMDB. This is seldom the truth since most forms in Service Manager targets TypeProjections (which could be seen as a view displaying data from several objects related to each other). As an example you might take a look at the type projection acting as source to the “computer form” in Service Manager. As you can see in the definition below, quite a few different objects support the computer form.

Microsoft.Windows.Computer.ProjectionType :

<TypeProjection Accessibility=”Public”>

<Component Path=”$Context/Path[Relationship=’ConfigurationManager!Microsoft.SystemCenter.ConfigurationManager.DeployedComputerRunsWindowsComputer’ SeedRole=’Target’]$” Alias=”PhysicalComputer” />

 <Component Path=”$Context/Path[Relationship=’Windows!Microsoft.Windows.ComputerHostsOperatingSystem’]$” Alias=”OperatingSystem” />

 <Component Path=”$Context/Path[Relationship=’Windows!Microsoft.Windows.ComputerHostsLogicalDevice’ TypeConstraint=’Peripherals!Microsoft.Windows.Peripheral.NetworkAdapter’]$” Alias=”NetworkAdapter” />

<Component Path=”$Context/Path[Relationship=’Windows!Microsoft.Windows.ComputerHostsLogicalDevice’ TypeConstraint=’Peripherals!Microsoft.Windows.Peripheral.Processor’]$” Alias=”Processor” />

<Component Path=”$Context/Path[Relationship=’Windows!Microsoft.Windows.ComputerHostsLogicalDevice’ TypeConstraint=’Peripherals!Microsoft.Windows.Peripheral.PhysicalDisk’]$” Alias=”PhysicalDisk” />

<Component Path=”$Context/Path[Relationship=’Windows!Microsoft.Windows.ComputerHostsLogicalDevice’ TypeConstraint=’Peripherals!Microsoft.Windows.Peripheral.LogicalDisk’]$” Alias=”LogicalDisk” />

<Component Path=”$Context/Path[Relationship=’System!System.ComputerPrimaryUser’]$” Alias=”PrimaryUser” />

<Component Path=”$Context/Path[Relationship=’System!System.ConfigItemOwnedByUser’]$” Alias=”Custodian” />

<Component Path=”$Context/Path[Relationship=’WorkItem!System.WorkItemRelatesToConfigItem’ SeedRole=’Target’]$” Alias=”ImpactedWorkItem” />

<Component Path=”$Context/Path[Relationship=’WorkItem!System.WorkItemAboutConfigItem’ SeedRole=’Target’]$” Alias=”RelatedWorkItem” />

<Component Path=”$Context/Path[Relationship=’SupportingItem!System.ConfigItemHasFileAttachment’]$” Alias=”FileAttachment” />

<Component Path=”$Context/Path[Relationship=’System!System.ConfigItemRelatesToConfigItem’]$” Alias=”RelatedConfigItem” />

<Component Path=”$Context/Path[Relationship=’System!System.ConfigItemRelatesToConfigItem’ SeedRole=’Target’]$” Alias=”RelatedConfigItemSource” />

<Component Path=”$Context/Path[Relationship=’CoreKnowledge!System.EntityLinksToKnowledgeDocument’]$” Alias=”RelatedKnowledgeArticles” />

        </TypeProjection>

A short summary of this is ”last-write wins” and that you should be very aware that a form can be a mix of the result of a number of connectors and synchronized data.

Last week when working with Service Manager I found this event again, in the Operations Manager log on the Service Manager server. Event ID 33880 from Health Service Module. It is generated when you try to send notification to a user, for example affected user, with a notification template that don’t support the user CI localization settings. More information about that scenario here. How to fix it? Make sure you have the same localization settings in your notification template and on your user CIs.

A Windows Workflow Foundation workflow failed during execution.
Workflow Type: Microsoft.EnterpriseManagement.ServiceManager.Incident.Workflows.
AutomaticIncidentChangeWorkflow
Workflow Identifier: 742dc6d1-90cf-9834-044f-9906bcf9dbf9
Exception Type: System.NotSupportedException
Exception Message: Culture 'en' is a neutral culture. It cannot be used in
formatting and parsing and
therefore cannot be set as the thread's current culture.
Exception Stack: at System.Globalization.CultureInfo.CheckNeutral
(CultureInfo culture)
at System.Globalization.CultureInfo.get_DateTimeFormat()
at System.DateTime.ToString(IFormatProvider provider)
at Microsoft.EnterpriseManagement.Notifications.Workflows.IReplaceableToken.
GetLocalizedPropertyValue(UserSettings settingsIn,
EnterpriseManagementObject instance)
at Microsoft.EnterpriseManagement.Notifications.Workflows.TokenizedMessage.
PopulateTokenValues(UserSettings userSettings,
EnterpriseManagementObject instance,
Dictionary`2 relationshipIdToInstanceToRelatedObjectMapping)
at Microsoft.EnterpriseManagement.Notifications.Workflows.RecipientGroupMessage.
PopulateTokenValues(UserSettings userSettings,
EnterpriseManagementObject instance, Dictionary`2
relationshipIdToInstanceToRelatedObjectMapping)
at Microsoft.EnterpriseManagement.Notifications.Workflows.SendNotificationsActivity.
Execute(ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity,
ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity activity,
ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutorOperation.Run
(IWorkflowCoreRuntime workflowCoreRuntime)
at System.Workflow.Runtime.Scheduler.Run()