Awhile back I announced that there would be a “resource kit” for Service Manager which would include a bunch of things that we already had put out on the blogs like…
and some new things…
We’ve decided that instead of packaging up all of this stuff as one downloadable “resource kit” package we would create a Tools/Downloads page on TechNet. Then we can add to it whenever we want and point to all kinds of locations like CodePlex, third party software vendors, blogs with tools attached, and microsoft.com/downloads to get releases from Microsoft. It will be one convenient place to get all the tools and solutions available for Service Manager and we can update it continuously without the overhead of a release.
While it will take just a couple more weeks to set up the Tools page on TechNet….
I’m pleased today to announce the release to microsoft.com/downloads the Exchange Connector and the Send Email solution! You can get it from here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0b48d1f1-434a-4ee6-8017-fc13f4c16785&displaylang=en
Note: allow up to 30 minutes from the posting of this blog post for worldwide replication on the microsoft.com/downloads site.
It’s taken awhile to build these solutions because I had them thoroughly tested by about 15-20 customers. These customers found bugs and submitted feature requests that I went ahead and implemented to expand the scope of the Exchange connector to include a lot of additional capabilities beyond the scope defined originally. The Exchange Connector now features the following capabilities:
The Send Email solution is a separate solution that I’ve packaged with the Exchange Connector for convenience, but it can be deployed with or without the Exchange connector technically. When you have both of them deployed and configured correctly you can enable the end-to-end lifecycle for emails around incident management. For example, an analyst can be looking at a ticket and click a ‘Send Email’ task to request additional information from the affected user. When the user replies to that email with the additional information, the incident is automatically updated.
Lastly a big, huge thank you to all the community testers that made this possible. You know who you are. I really appreciate the effort you put in to test these solutions, provide feedback, and report bugs! Thank You!
Enjoy!
Update: Chris Ross put together a nice demo video of installing, configuring, and testing the Exchange connector . Thanks Chris!
http://vlog.myscsm.com/?p=171
Hi Travis
I am using SP1 + CU1.
The sulution of the problem was found by ButtyT. Please look at this topic: social.technet.microsoft.com/.../bd56f4d2-0304-426c-8533-9becdb05a7d7
When I added my username to internal SCSM group "Incident Resolvers" the SendEmail have earned according to the scenario.
Hi Travis,
We've just gone live with our Service Manager solution. When we get *any* external email in our Workflow Mailbox, the Exchange Connector stops processing all emails and throws an exception:
A Windows Workflow Foundation workflow failed during execution.
Workflow Type: Microsoft.SystemCenter.ExchangeConnector.ProcessEmailsWorkflow
Workflow Identifier: 2cb4bc8d-5817-9780-c67a-c4c471c1f6e4
Exception Type: System.ArgumentException
Exception Message: The specified string parameter is empty.
Parameter name: name
Exception Stack: at Microsoft.SystemCenter.ExchangeConnector.ExchangeInbox.ProcessMail()
at Microsoft.SystemCenter.ExchangeConnector.ProcessEmailsWorkflow.Execute(ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.CompositeActivityExecutor`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()
I have to delete the email after manually creating the incident and then all of the held-up ones get processed on the next run.
I've created an "Unknown" CI user as you suggested but it's not made a difference.
Are you able to suggest how we can get this working?
Thanks,
Rob
@Rob -
Please contact me via email so we can work on this together in more detail
twright@microsoft
I found 2 bugs with Exchange Connector.
1. The connector stops processing incoming emails with error: "Process Item: Cannot find work item ID prefix in subject." in the Operation Manager system log if email has an empty body.
2. The connector stops processing imcoming email when sender's address contains a "&" character in username (for example noreplyT&I@domain.com).
When it happens I have to delete these emails from the mailbox manually and then connector continues processing a remaining emails normally.
@Eldar -
Thanks for reporting the bugs. I was aware of the first one and have already fixed it. I've created a bug to track the second issue and will try to fix that as well. These fixes will be included in the next version of the Exchange connector.
I found and fixed the & bug. The fix will be included in the next release of the Exchange connector. I dont know exactly when that will be right now though.
Thank you. I will be waiting for the next release. Another one scenario:
Incoming email contains an Incident_ID in the topic that equals the existing Incident_ID in SCSM but from username that differs from affected user. In this scenario I would like to add just a comment to existing incident, but SCSM created a new incident. Is it bug?
Some additional info that may help you out in your next version. When an attachment contains another email, it seems the Exchange connector stops processing - I will dig out the actual event log entry and send through to you via email.
Also, when an inbound email is digitally signed it also does not process - as above will email you the event log.
Alan
Travis,
When trying to enable the exchange connector, we get the following error in evtviewer.
Note that we have autodiscover running,the only issue is that autodiscover is published via TMG.
Exception Message: Autodiscover blocked a potentially insecure redirection to autodiscover.domain/.../autodiscover.xml. To allow Autodiscover to follow the redirection, use the AutodiscoverUrl(string, AutodiscoverRedirectionUrlValidationCallback) overload.
Is there any workaround on this?
@Alan - thanks for the heads up. Please send the information to me as soon as possible (twright @ micorosft). I'm going to release a new version of the Exchange connector soon and could try to include bug fixes for these things if needed. I know about the email attachment issue. That has already been fixed.
@ Kyriakos Ioannou
The new version of the Exchange connector that I am going to release soon is going to include the ability to manually configure the Exchange web service URL so that in cases where auto discover doesnt work customers can manually specify the URL.
is there a time estimation on when the new connector will be released?
Hi
A few of our users are digital signing there emails
And the connector can’t read these, they just remains unread in the inbox folder
I think this I a bug with the connector
@Kristoffer Stormark
As far as I know there is no way to support those kind of emails. I'll add it to the to do list for the next version and we'll look into it some more though.
Thanks for the answer, for now we implantet a workaround jusing exchange transport Rules, and rerouting signed emails to a human monitored emailaress for manual read and apply.