AdhocAdam / smletsexchangeconnector

SMLets PowerShell based Exchange Connector for controlling Microsoft System Center Service Manager 2016+
https://adhocadam.github.io/smletsexchangeconnector/
GNU General Public License v3.0
29 stars 19 forks source link

Conversation Id is not consistent in Reply Messages #478

Open SimonZein opened 10 months ago

SimonZein commented 10 months ago

This affects the merging of workitems, when the reply regex is found inside the subject, but no [IR****] number has been passed. It seems that sometimes the merging is not working, although the user has been replying on the original message or one from this conversation. The reason for us is, that, sometimes, the Conversation Id of a reply message is different than the one from the original message. So in the confirm-workitem function the original ticket is not found and a new ticket will be generated. Until now I don't know how to reproduce it.

The reply message has been sent around 4 hours after the original ticket has been created. But that does not seem to be the reason, as merging worked for a test ticket, where the response has been sent 1 day after.

I checked the Description of both attachemens: original: ExchangeConversationID:AAQkADVkODg2NGQ0LWZiNTItNDMyOS1hNGQ1LWExZTdkMDdkNjg0YQAQAEyozngU60uPnSrZilYt6YA=;

reply: ExchangeConversationID:AAQkADVkODg2NGQ0LWZiNTItNDMyOS1hNGQ1LWExZTdkMDdkNjg0YQAQALscCcfuORZFlNrzAM/5HUM=;

It seems the last 23 characters are different, but the rest is equal. I also found an article on the web, where the equality of only the first 44 characters in the conversation id has been stated. But this article is 4 years old . I don't know if this has something to do with that, but in the above case, where the conversation ID wasn't completely equal, in both messages another message has been added as attachement, maybe this is the reason. I will try to test that as well.

SimonZein commented 10 months ago

I tested the behavior with a message, which had another message attached, and the merging still worked fine. So I still don't know how I might be able to reproduce this :(

AdhocAdam commented 10 months ago

If I remember correctly, when I was originally testing this functionality out in v1.2 back in the day - there was one thing that caused the conversation ID to change.

For absolute certain, someone/something changes Subject changes (which I believe is tied to the Conversation Topic) changes. For example, 3 messages in the chain are queued for processing all on the same conversation. SCSM "changes" the conversation when it sends out the initial email that "Your Incident has been created" and includes the Work Item in the Subject. But it's at this point though, the Subject contains the Work Item in which case a different Conversation ID is moot because we now have the qualifier we're expecting to process.

Suffice it say, if there is another scenario it is currently unknown to me.

SimonZein commented 10 months ago

Hy Adam, in this scenario, the user replied to the original mail, without the Incident Number in the subject. The subject has not been changed neither, except for the answer (RE:) prefix. I remember thinking "why did that not merge" about another message some days before - But also in that case I have no clue why the conversation ID has been different :(

EDIT: Ok the thing from last week has solved itself, the replier added something to the subject when replying, so the ID has changed :/ I will keep you updated.