Using the Exchange Connector and the default Incident-by-Mail function together to get the best of both worlds

Wow, what a long title for a blog post! Due to a customer request I built the solution mentioned in the title some days ago. It works very good and satisfies the customers needs. What it does? It allows very flexible Work Items handling by mail. But read more …

There are two ways to create Incidents by mail – one is the default function that is included in the product, the other one os the Exchange Connector. Let’s first take a look at the two methods.

Default Incident-by-Mail function

Service Manager allows the creation of new Incidents by Mail which is very helpful to unburden your IT staff. The User has the possibility to just send an email to a specific address which then automatically creates an Incident. To make this work, you can install the SMTP Service on the Service Manager Management Server and share the folder where the SMTP Service stores the incoming mails. Now configure a mail address or a mail domain that you SMTP Service is responsible for. The easiest way to go is to create a Sub-Maildomain of you company mail domain. In our case, the main mail domain is itnetx.ch, so the one for Service Manager would be something like scsm.itnetx.ch, the final address for instance servicedesk@scsm.itnetx.ch. Make sure that all mails that are sent to this domain are forwarded to the Service Manager SMTP Service. This means that you must configure Hub Transport Rules on your Exchange Infrastructure. Forward all mails that are sent to *@scsm.itnetx.ch to the Service Manager SMTP Server.

image

Now, Service Manager needs to be configured to catch all mails that are sent to the configured domain. For this, first share the folder where the mails will be stored and make sure that the Service Manager Service Account has modify permissions. In the Service Manager Console (Administration, Settings, Incident Settings) you can specify the paths to the folders and then enable the function.

image

When a user now sends a mail to servicedesk@itnetx.ch, it will be forwarded to the Service Manager SMTP Service, stored in the drop folder and then picked up by Service Manager (the message file is then deleted). The mail subject becomes the Incident title, the mail body becomes the Description, the mail sender becomes the affected user and the complete email including all pasted graphics will be attached to the Incident in eml-format.

image

image

This methods works great, but the problem is that it cannot do more than just create Incidents. It’s not possible to update Incidents with additional information or resolve Incidents by mail. Therefore the Exchange connector was released.

Exchange Connector

The Exchange Connector is an optional component that was shipped in January 2011 as part of a Resource Kit. It allows the following:

  • Create incident from email
  • Update incident action log from email
  • Resolve or close incidents from email
  • Approve/reject change requests from email
  • Update change request “action log” from email
  • Mark manual activities completed from email
  • Add email file attachment to work items as attachments
  • Send notifications to users from the console

After downloading and installing the Exchange Connector, create a mailbox for the Service Manager Workflow Account and assign the preferred mail address, for instance servicedesk@itnetx.ch. Then configure the Exchange Connector in the Service Manager console.

image

Every mail sent to this mailbox (e.g. servicedesk@itnetx.ch) will create a new Incident. But If you send a mail to that mailbox that contains an ID (in brackets) of an existing Incident in the subject line, the action log of that Incident will be updated with the text in the mail body. Beside this, it is possible to resolve or close Incidents by sending emails back that contain a specific keyword in the mail body, e.g. [Resolved] or [Closed]. The connector can also handle Change Requests and Activities, but in this blog post I will only cover the Incident relation functions.

So, the Exchange Connector seems to have much more functionality than de default Mail-to-Incident function as it allows also updating and resolving Incidents, as well as handling other Work Items like Activities. But it has one important disadvantage: when creating new Incidents with the Exchange Connector, the complete mail is not attached to the Incident. This means, that you could lose information that your users might want to send you to help solving the Incident.

A solution can now be to combine the two functions together to get the best of both worlds. Here’s how it works (indeed there are multiple ways to achieve the goal).

Combination of both methods

For combining you can now do the following:

  • Configure both functions as described
  • Configure Exchange Hub Transport Rules that do the following: Forward all Mails sent to servicedesk@itnetx.ch to servicedesk@scsm.itnetx.ch exept the ones that have the pattern “[IR” in the subject line

What happens now?

  • If a user sends a Mail to servicedesk@itnetx.ch the mail is immediately forwarded to the Service Manager Server and then picked up by the default function to create a new Incident.
  • If configured (optional, bur preferred): The user automatically gets a mail with an information that an Incident was created. This mail should have the Work Item ID in brackets in the subject line, e.g. “A new Incident has been created [IR462]”, the sender address should be servicedesk@itnetx.ch.
  • If the user answers to that mail to provide more information about his Incident, the mail will be sent back to servicedesk@itnetx.ch (to the Mailbox), the subject line will automatically contain the ID and will therefore NOT be forwarded to the Service Manager SMTP Service. Instead, it will be stored in the Mailbox of the Service Manager Workflow Account. From there, it will be picked up by the Exchange Connector and will be used to update the Action Log of the related Incident.

I hope this clarifies things about the two methods. The combination is indeed very powerful unburden your IT support staff and give you more flexibility for Incident handling.

regards
Marcel

This entry was posted in SCSM and tagged , , , . Bookmark the permalink.

38 Responses to Using the Exchange Connector and the default Incident-by-Mail function together to get the best of both worlds

  1. w00tm3 says:

    Can you explain how you setup the transport rule for this to work?

    • Hey
      I’m not an Exchange Specialist, but here are some details …

      – Create a Hub Transport Rule (Global Setting in Exchange Organization)
      – The Rule should forward ALL mails to the address that forwards the mails to the SM Server except when this is true (depends on your config):
      —- Mail Subject Contains “[IR*” or “[RA*” or “[MA*” etc.

      This way mails to update existing work items stay in the mailbox and the Exchange Connector will pick them up. All other mails are forwarded to the SM Server where new Tickets get created.

      regards
      Marcel

  2. Iliass says:

    Hello,

    Is this still needed with v2 of the Exchange connector ? I configured v2 and when sending e-mail I don’t see any missing info ?

    Thanks a lot!

    Iliass

  3. Dominik says:

    hello,
    Iliass, what type of SCSM do you trying to deploy ? is it 2010 or 2012 ?
    The difference is beacuse SCSM EX Connector won’t work with scsm 2012 (at least I red over inet about scsm 2012 and someone wrote that)

    • iliass.el.taghadouini@xylos.com says:

      Hello Dominik,

      I deployed SCSM 2012 SP1 and didn’t experience the issues you described. Perhaps it’s only applicable for the 2012 release.

  4. w00tm3 says:

    Dominik you can put the V2 Exchange connector on 2010. The method described above makes it so that under the ‘Related Items’ tab, under ‘Attachments’ you get an attachment with an .eml extension that is a copy of the origianl email. This way any hyperlinks, screenshots, etc can be seen in the ticket by viewing the copy of the original email. We’ve done that here and the helpdesk loves it.

  5. Ton says:

    1- I would like to be to update the status code to any other code rather than closed or resolved
    2- When creating a new incident from a email I would like to be able to to set autmatically the support – group & maybe the calssification category or even more fields by code in the email header or body … is this possible?

    • Hey

      The Exchange Connector offers some possibilities OOB descibed in the guide. For your more advanced scenario you could use Orchestrator to do what you need. Exchange Connector does not offer this.

      regards
      Marcel

      • Ton says:

        Thanks Marcel for your feedback …..

        Not a very possitve remark but any other (cheap) helpdesk package outhere can do the simple tasks which Service Manager is lacking of by default.

      • Hey

        The problem with eMail is that you cannot send structured data to the system. This makes it almost impossible to modify all fields in a way that guarantees integrity for every possible situation. But of course i understand your concern. Myself I advise customers to use the self service portal for almost everything. The only thing I recommend email is for approval when people are travelling and do not have access to the portal. But at the end of course it’s a customers decision.

        regards
        Marcel

  6. Dirk says:

    hi guys,

    i have two problems.

    the first is with the Default Incident-by-Mail function. Everythings looks okay so far, but the scsm doesn’t delete the mail which are in the drop folder. So i have to delete them manually, otherwise … you now what happens…

    the second problem is with the prefix for incidents. when i put [IR] in the field, the scsm makes [IR]4 for example. when is put in [IR{0}], the scsm makes [IR4]4 out of it. But don’t want to have the second 4 and i don’t know where it is from.

    do you have any idea or solution for this probs ?

    thx und best regards

    • Dirk says:

      okay the first problem was a a read only flag on the drop folder. i checked it off and everthing is okay. Now the read only flag is there again (from the system) but it still works…….

  7. Techie Lost says:

    hi guys,

    I am stuck at one point and hope you can help me out. I am working in the test environment and having SCSM 2012 with Exchange 2010. I have created the SMTP server as advised but when i send email to the support group, it gets stuck in the Unreachable Domain queue with the message “a matching connector cannot be found to route the mails to external recipient”.

    Y is the mail flow going through internet? How to route the emails sent to SM- Management Server to create the Incidents.

    • Hey

      Did you create a Connector for the Service Manager “Mail Domain” that forwards those mails to the SM Server? This seems to be missing …

      Cheers
      Marcel

  8. Madininarawak says:

    Hi everybody,

    I installed my Exchange connector on my SCSM2012 SP1 platform with servicedesk@contoso.com as email adress to monitor.

    I ennabled the connector.

    For routing, I took the default incident model.
    But when I send an email to any email adress (servicedesk@contoso.com), nothing happened in my SCSM environment: No incident is created.

    What is my problem or where can I search for analyze what is wrong in my configuration.

    Regards,

    Phil
    Madininarawak

  9. Madininarawak says:

    Hi everybody,
    Thanks Marcel for your help.
    I install a sniffer on my server and I found the root cause of my problem:
    The exchange connector use the web service and the “https” protocole. We had some problem with our DNS.
    I just add an entry for the IP address of my exchange server in my host file on my SCSM server and it works fine !

    Regards
    Phil
    Madininarawak

  10. Techie Lost says:

    hi all,
    I have created a lab environment where the email notification is working fine. When end user submits an request to Helpdesk@mylab.com the IR is getting generated and end user is being notified that an IR has been created. However, when the end user replies back to the mail, instead of getting updated as comment, it ends up as *.eml attachement.

    I have ensured the option “Attach email as a .eml file attachment is unchecked.

    I have selected the “Default Incident Template” for “Incident Templates to be apply when Incidents are updated”. Now should i create a new template say “email updated” should i use the string [IRxxx] or [IR***]??

    just FYI,

    I created a blank email templated with title being just [IR***]. Now when i reply back to the email, in “related items” – “attached files”, a *.eml file is present.

    Is it possible to provide a detailed walkthrough about how this needs to be configured.

  11. Madininarawak says:

    Hi everybody,
    I had a new question:
    I success to install the exchange connector on my SCSM 2012 SP1 platform, and I can open and update tickets by receiving mail on my email box (servicedesk@contoso.com).
    I would know if it is possible to send a specific mail by the SCSM console to the affected user.
    For example:
    – ” we need more information for…”
    – ” we closed your ticket and you have … to do…”
    With a specific message for each ticket. (That’s not notification)

    Regards
    Phil
    Madininarawak

  12. ronin8996 says:

    Is it possible to use email to automatically create problem tickets as well? We have automated alerts from networking equipment that send emails to our helpdesk, and subsequently a ticket is opened, but we really feel these should be problems, so are wondering if we can have an automatic problem ticket opened instead.

  13. Madininarawak says:

    I think it is possible to do it by using SCOM connector with Orchestrator

    Regards
    Phil
    Madininarawak

  14. Adam says:

    Is it possible (via Exchange connector, or something else) to send IR closure email notifications based off the IR classification category at the time of closure?

    So if we constantly get tickets in category X, and we have tools/trainings we want to push to user’s to help them solve issues themselves (ex: Password resets), then instead of using the default, ‘IR XYZ has been closed, etc. etc. etc.), b/c it sees that it’s in category X it’ll send a different templated email w/ maybe learnings, hyperlinks to tools, etc. to the user along w/ the default information?

    So for specific categories they’ll receive custom emails (if it’s something we have tools/trainings on) and for everything else they’ll receive the same usual default closure email.

    • Hey

      Sorry, I somehow missed that comment 😦 Hmm, I’m not sure if I understand what you mean. Can you clarify that little bit and describe the process?

      Cheers
      Marcel

      • Adam says:

        Basically what I mean was if we have a category, and it’s ex, ‘Telecom\Voicemail-Troubleshooting’, then whenever we close a ticket in that category the user will get a specific email template we’ve created w/ the basic stuff (closure info, survey, etc.) but also containing training links, etc., on the specific area pertaining to the closed category. So it could look something like this:

        IR Category –> Email
        [Nonspecified IR Category] –> Default Closure Email
        [Specified Category 1] –> Custom email for SC1, including training links pertaining to the subject-matter of SC1
        [Specified Category 2] –> Custom email for SC2, including training links pertaining to the subject-matter of SC2

        So a way for SCSM/Orchestrator/Ec to send specific closure emails off specific IR categories at the time of closure, so we can better tailer our training templates.

        Hope that clears some stuff up,

        Thx,
        A

      • Hey

        OK, makes sense to me now 🙂 You should be able to achieve this by using the SCSM workflows. Administration\Workflows\Configuration\Incident, then create a new entry for “Updated” Incident objects. Use criteria like this:

        Changed from:
        – Status IS NOT Resolved

        Changed to:
        – Status IS Resolved
        – Classification IS Telecom\VoiceMail-Troubleshooting

        Then enable notification and select a notification template, e.g. “Incident Resolved – VoiceMail-Troubleshooting” (must be created). This template then contains all the information that will be sent out whenever a VoiceMail-Troubleshooting Incident will be resolved. Repeat the steps for all categories.

        I hope this is what you are looking for 🙂

        Cheers
        Marcel

  15. Jordan Fillery says:

    Hi Marcel,

    Is it possible for the Exchange connector to hand the re-opening of closed incidents?

    I have got mine configured so when the user reply to a closed notification email it updates the original incident but the incident status is still set to resolved. Is there anyway of activating this and changing to update required.

    Thanks,
    Jordan Fillery

    • Hey

      I assume you are talking about re-activating incidents that have been resolved (not closed). You could use a specific template that changes the Incident status to active whenever an incident is updated by the Exchange Connector. That should do it.

      Cheers
      Marcel

  16. mihaela22011 says:

    Hi everybody,
    I have installed System Center Service Manager 2012 R2 and Exchange Connector 3.0 RC. Submited for Exchange Connector 3.0 RC who is maked are:

    I Created the following key in the registry
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center Service Manager Exchange Connector
    Value: EnableEWSTracing
    Value: LoggingLevel
    and added permisions on HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog registry key http://configmgrblog.com/2011/01/17/scsm-2010-sp1-exchange-connector-a-first-look/

    I ennabled the connector but I have error 33880 in Operation Manger
    For routing, I took the default incident model.
    But when I send an email to any email adress nothing happened in my SCSM environment: No incident is created.

    What is my problem or where can I search for analyze what is wrong in my configuration.

    Regards,

    • Hey

      Are the mails still sitting in the Exchange Connector Mailbox? And what’s the status of the Exchange Connector? Is there a specific reason why you chose the RC version and not the RTM version?

      Cheers
      Marcel

  17. Rosie Hawkins says:

    Hi,

    Wondering if you could help.
    When we resolved a incident but a user replys to the email saying we have resolved the incident. It is automatically reopening the incident and such breaching our SLAs.

    What could be causing the incident to reopen when a user replies to the resolved email?

    Please help.

    Rosie

    • Hey

      It seems that the incident template that you use to update incidents by using the Exchange connector is setting the status back to active. Check that …

      Cheers
      Marcel

      • Rosie says:

        Are we able to change the status for example to “update from user” which will stop the sla breaching? Only on incidents which have been reopened?

        If so could you point me to the right direction of achieving this. I’m new to service manager console and just trying to resolve this issue for my department.

      • Hey

        You could do this by using workflows or by just manually change the IR status to something like “pending” (default status). When this happens you could stop the SLO. However, this is not possible OOB and yo uneed some unsupported hack. Check out Anton’s blog about it here –> http://blog.scsmsolutions.com/2013/02/sla-in-scsm-2012-part-3-hidden-features/

        Cheers
        Marcel

  18. Phil says:

    Hi,

    I’ve created a custom form and a new class which inherits from class incident. The Exchange connector does not allow me to select Incident templates that are linked to my inherited class. It only seems to allow templates linked directly to class incident. Are you aware of a suitable work around for this?

    Any help would be greatly appreciated.

    Thanks,
    Phil

  19. Jankada Laziya says:

    Hi,

    I have a little challenge, when an end user logs in an incident via the self service-portal (SSP) the end user does not get a mail in his inbox notifying him of the incident he has logged in via the SSP but the person on the console when he assigns the incident to a technician, the technician gets a mail in his inbox. I want to know why is it that the end user’s mail does not drop in his inbox while the technician’s mail drops in his inbox.

    Thanks
    JK

    • Hey

      Did you check the workflow status in the SCSM console? Another thing you can check is the sending mail server. Check the transmission log.

      Cheers
      Marcel

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s