Home » System Center Operations Manager 2007 » Send e-mail to affected user

Send e-mail to affected user

By in System Center Operations Manager 2007 on .

In this post I will show you how to build a simple task to send a e-mail to the affected user of a incident. The e-mail will be logged in the action log of the incident.Please note that this will not affect how you handle incoming e-mails, it will only give you a fast way to send a e-mail to the affected user.

  1. In the SCSM Console, go to Library, check Tasks
  2. In the Tasks pane click Create Task
  3. Input the following settings in the “Create a task” wizard
  4. General
    • Task name: Contoso – Send e-mail to affected user
    • Target class: Incident
  5. Categories: Incident Support Group Folder Tasks
  6. Command Line
    • Full path to command: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
    • Parameters: .\emailenduser.ps1 Property/WorkItem/ID Property/AffectedUser/Username Property/WorkItem/Title Property/AffectedUser/Firstname
    • Please note that each property is inserted with the “Insert Property” button
    • Check both “Log in action log when this task is run” and “Show output when this task is run”
    • Working Directory: C:\Scripts\
  7. Save your new task

As you can see in the task we are using a script here, C:\Scripts\emailenduser.ps1. It is a powershell script that you can download here, emailenduser. Please note that you will need to modify the script to work in your environment, there are some notes about that in the script.

Now, if you select a incident in a incident view you will have a new task in the tasks pane, “Contoso – Send e-mail to affected user”. If you click it you can input a text. This text will be in the e-mail. The e-mail will also add a “Hi affect user name” and “thanks, br service desk…”. Don’t forget to modify that part to in the script.

The operator will see the e-mail and it will also be inserted into the action log of the incident.

15 Comments

  2. Hi,
    I don’t know what happened to my last comment…

    What if I want to run this task as a service account? I don’t want give every analyst direct access to the PS script and unfortunately users that don’t have access to the folder where this script is located can’t run this task.

    Regards,
    Peter

  3. Hi,
    In order to run the script each user that wants to use this task needs to have access to PS script. What if I don’t want analysts to have access to PS script (it contains service account credentials)? Can I somehow make this script to run as scsm service account?

  4. I noticed that if the title of the incident has a special character (. , ‘) the script won’t run. Is there a way to edit the powershell to ignore those characters?

  6. Hi Anders,

    From what I understand, we can use this connector to send emails to affected user. Can we use the connector to send email to others? Say having a field to key in who I want to notify instead of automatically sending it to the affected user.

    Regards
    James

  8. Anders, I adapted your script to make a version that populates the text input box with the full email message, so the operator can see what is to be sent, and can also edit the message if desired. We are not using automatic notification to user when a job is logged in SCSM at present; my script allows our operators to choose whether or not to send a “job logged notification” to the client, and to customise the content for the particular job if desired. Happy to post the script here if that is appropriate, but I’ll leave that decision up to you.

    Thanks for your very helpful blogs.

    Tony Whelan
    Canberra, Australia

  9. Googled around for a solution to Powershell treating a space as an parameter separator:

    Enclose the variable in curly braces AND quotes: eg {“this is a string”}

    Here’s my parameter string from the script:
    .\emailenduser.ps1 $Context/Property[Type=’WorkItem!System.WorkItem’]/Id$ $Context/Path[Relationship=’WorkItem!System.WorkItemCreatedByUser’ TypeConstraint=’CustomSystem_Library!System.Domain.User’]/Property[Type=’CustomSystem_Library!System.Domain.User’]/UserName$ {“$Context/Property[Type=’WorkItem!System.WorkItem’]/Title$ “} $Context/Path[Relationship=’WorkItem!System.WorkItemCreatedByUser’ TypeConstraint=’CustomSystem_Library!System.User’]/Property[Type=’CustomSystem_Library!System.User’]/FirstName$

    Works for me.

  11. The overall process seems to be working well. Unfortunately, if the incident title has spaces in it, that breaks the parameter passing to the PowerShell script.

    I’ve tried amending the command line to emailenduser by putting double-quotes around the WorkItem’s Title but that hasn’t made any difference.

    Unfortunately, the result is that the PowerShell script gets the parameters wrong as the 2nd word of the incident’s title gets treated as the affected user’s first name.

    –Philip

  12. Hi Olaf,
    We solved this by putting the script on a share (in our case on the management server) and specifying the UNC path to the share as the working directory of the task.

    Another thing that we discovered was that the execution of PS scripts isn’t enabled by default on W7 clients. Our solution for that was to enable the execution of local scripts (and signed remote scripts) with a GPO scoped to all computers with the console installed.

    I hope this will help you!

    /Alexander

  14. I tried your example from a local console application and found out that in the command line options in the task item are looking on my local machine instead of the server.
    When I’m running the task on de console app directly on the SCSM server its working fine.
    Because you never know on design time where the console app is started runtime, this will almost never work. Have you got a solution for this?

Leave a comment

Your email address will not be published. Required fields are marked *

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