Error with processing incoming mail
Stephane_Bouillon
Customer Advanced IT Monkey ✭✭✭
Hi, i'm finding a lot of information messages in the event log with the following:
Exchange Connector: Unable to process mail item. Subject="[IN94670] - [RESOLVED] - Administration", Error Message=The key value of an object cannot be changed.
The result is that the Template is not applied to the incident, and that the mail isn't processed correctly. Any ideas what might be causing this ?
Stephane
Exchange Connector: Unable to process mail item. Subject="[IN94670] - [RESOLVED] - Administration", Error Message=The key value of an object cannot be changed.
The result is that the Template is not applied to the incident, and that the mail isn't processed correctly. Any ideas what might be causing this ?
Stephane
0
Best Answers
-
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
If I recall correctly...- This is a known bug with the stock Exchange Connector
- I think it has something to do with class extensions on Incidents, Service Requests, and/or Users (as the user is the one performing an action on an IR/SR when they reply)
- I think I managed to repro it back in the day when the Incident I was trying to update had a related runbook where the prefix was missing (i.e. the runbook was simply just '54262' instead of 'RB54262'). This issue around IDs was something you can find cited when...
- You'll actually find quite a bit of talk about this issue if you search with the tail end of your error - "Error Message=The key value of an object cannot be changed." Unfortunately, no one really provides a clear or definitive fix.
5 -
Stephane_Bouillon
Customer Advanced IT Monkey ✭✭✭
Indeed, this involves mails and an extension of the incident class. Strangely, not all mails are discarded. Is there a workaround ? I haven't heard about the SMLets exchange connector. Would this solve my issue ?
0 -
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
When it comes to SMA, you'll need to create a schedule for every 5 minute interval of the day. To say the least, it's rather time consuming through the GUI. But as you might guess, this is something you can script into existence using the SMA PowerShell module.
One such example can be found here. Something tells me @Tom_Hendricks probably did something similar?
1 -
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
Well, it's certainly an interesting way of running it that I had never previously considered. But...
I think there is only 1 potential drawback and I'd be assuming a lot of your environment in the process so allow me to explain. If you have 3rd party systems, vendors, or really anything that emails into your SCSM inbox when the connector isn't running - that means the first batch of emails every day will have the "incorrect" Created Date.
Since the SMLets Exchange Connector doesn't define the Created Date on a Work Item because SCSM sets this automatically....that means if an email came in at 2:32am, that email would't have a Created Date until 8am. Scaling this out, it means you could potentially have a batch of Work Items that always have an 8am Created Date. I personally would tend to think you'd want to capture the Created Date as close as you could to the actual received time of that email especially if you're trying to do metrics such as Average Resolution Time.
The long and short of it - I don't think the approach is wrong per se given a different set of business requirements, but it's not one I would personally use.6 -
Tom_Hendricks
Customer Super IT Monkey ✭✭✭✭✭
To add to that, if you are running this in SMA, for example, it is always better to generate a new instance of the job than to just let one run for the entire timespan needed, for a number of reasons. Right off the bat, your output logs are going to be that much more difficult to parse through, but also consider that this has implications for the way SMA sandboxes jobs. You could be keeping an "old" sandbox alive longer than you should be, for example.Stephane_Bouillon said:Stupid suggestion maybe: what if I just kick it off once in the morning at 8am and let the script run throughout the day with a 5min wait between every cycle within the script itself ? It could then just stop itself around 6pm, no need to run through the night. Would that be a wrong way of doing ?
This would technically work, of course, but I would recommend against it, unless you are trying to avoid overlapping jobs and are not using SMA or Orchestrator.6
Answers
- This is a known bug with the stock Exchange Connector
- I think it has something to do with class extensions on Incidents, Service Requests, and/or Users (as the user is the one performing an action on an IR/SR when they reply)
- I think I managed to repro it back in the day when the Incident I was trying to update had a related runbook where the prefix was missing (i.e. the runbook was simply just '54262' instead of 'RB54262'). This issue around IDs was something you can find cited when...
- You'll actually find quite a bit of talk about this issue if you search with the tail end of your error - "Error Message=The key value of an object cannot be changed." Unfortunately, no one really provides a clear or definitive fix.
This was actually one of the bugs that spurred the development of the SMLets Exchange Connector.The SMLets Exchange Connector doesn't suffer from the issue because it's only updating a very specific subset of fields on a Work Item (as opposed to a template which is a blanket update of sorts and would clearly be custom across customers). As such, it also means that it isn't negatively impacted by any number of class extensions that could have been performed in an environment.
Apart from the link above which inevitably would lead you over to my GitHub. The most recent article on it is Cireson's adoption of it.
Thanks Adam
https://github.com/AdhocAdam/smletsexchangeconnector/wiki/Configuration-Examples
As far as how to configure the script/runbook, we've gone to a pretty detailed length of listing out what every single variable/configuration does inline of the script. Just open up smletsExchangeConnector.ps1 and past the change notes you'll see what I'm referring too.
Feel free to ping me back with any other questions you may have.
This last instruction fails with the following error
Exception calling "Bind" with "2" argument(s): "When making a request as an account that does not have a mailbox, you must specify the mailbox primary SMTP address for any distinguished folder Ids."
At
+ $inboxFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($ex ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ServiceResponseException
I based myself on the settings in our existing Exchange Connector:
I must be overlooking Something obvious ?
Stephane
and then tried to update the code to use an FolderId instead, but now get another error:
The error I get is
Exception calling "Bind" with "2" argument(s): "Connection did not succeed. Try again later."
At
+ $inboxFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($ex ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ServiceResponseException
But when using a shared mailbox, one needs to pass a FolderId parameter to the Bind
I can now retrieve the mails, thanks for your assistance Adam !
I'll log the Shared mailbox issue you cited and investigate.
What I need to do next is have the script run at a regular interval eg. every 5 minutes. What is the best way of achieving this ?
Stephane
One such example can be found here. Something tells me @Tom_Hendricks probably did something similar?
In my case, I wrote a simple "trigger" script that invokes the runbook, and then ran that script via a Win task scheduler on the schedule I wanted. That worked very well for quite a while, but having to script for times when a job would hang and I did not want to trigger another (an advantage over SMA schedules) caused this to evolve even further. But it started with a 2-line script run by task scheduler.
Creating schedules outside SMA can seem counterintuitive but the results have been very good.
If you also run old-school Orchestrator, you could use it instead of task scheduler. It is vastly superior to SMA in terms of scheduling and security granularity, even after all these years. IMO, there is no shame in using the best tools to get the best result, even if you believe (like I do) that you shouldn't have to do it in this way. I decided against this approach, but only because our support teams are more familiar with task scheduler.
I think there is only 1 potential drawback and I'd be assuming a lot of your environment in the process so allow me to explain. If you have 3rd party systems, vendors, or really anything that emails into your SCSM inbox when the connector isn't running - that means the first batch of emails every day will have the "incorrect" Created Date.
Since the SMLets Exchange Connector doesn't define the Created Date on a Work Item because SCSM sets this automatically....that means if an email came in at 2:32am, that email would't have a Created Date until 8am. Scaling this out, it means you could potentially have a batch of Work Items that always have an 8am Created Date. I personally would tend to think you'd want to capture the Created Date as close as you could to the actual received time of that email especially if you're trying to do metrics such as Average Resolution Time.
The long and short of it - I don't think the approach is wrong per se given a different set of business requirements, but it's not one I would personally use.
This would technically work, of course, but I would recommend against it, unless you are trying to avoid overlapping jobs and are not using SMA or Orchestrator.