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

Voicemails sent from Microsoft Teams do not generate tickets #465

Open Taylor-Bryan opened 1 year ago

Taylor-Bryan commented 1 year ago

Describe the bug We're piloting out Microsoft Teams phone for a larger migration in the future and are attempting to set up a new phone number for our Service Desk team. Voicemails that are sent to email are not processed by the SMLets Exchange Connector, and I suspect it's because they have an invalid email in the From header on the message; specifically, the From header is +1 XYZ-ABC-DEFG <+1XYZABCDEFG>. When forwarding the same message from a different sender, a ticket was generated properly. I've enabled logging at level 4 and the events show that it's processing 0 messages, even though the voicemail message is unread in the inbox. It looks like the Reply-To header does have an email address in it that we could use (Reply-To: +1 XYZ-ABC-DEFG noreply@skype.voicemail.microsoft.com>)

Help us reproduce the bug Version of the connector you are using: 5.0.2.2 Features/variables you have enabled (i.e. $enableAzureCognitiveServicesForNewWI):

We've enabled the following settings:

Expected behavior We'd like the tool to process the email and create a ticket with either the Reply-To sender in the CMDB as the Affected User or a blank Affected User so that the team can still process voicemails in the system.

Location and Environment Where are you running this from? Task Scheduler? SMA? Workflow server?: SCSM Workflow What SCSM version are you running? (i.e. 2012R2, 2016, 2016 UR3, 1801, etc.): SCSM 2019

Additional context We're using Microsoft 365/Exchange Online services and the SMLets Exchange Connector has been in use for over a year in our environment with no issues; this is the first time we've had a problem that wasn't easily resolved or configured by a setting.

AdhocAdam commented 1 year ago

If the...

Then my gut reaction is it sounds like the voicemail is of an entirely different Message Class unknown to the connector. Which means it falls outside of the scope of processing as properties could be/are different than a regular email. I have a breakdown of message classes, what they are, and ones that the connector is capable of processing over here on the wiki.

However this is one of the reasons Custom Rules was created in the first place - to introduce support for wholly custom message processing with standard and non-standard outcomes. Again, assuming the above is true around Message Classes. You could create a rule that looks for items of this message class, with a subject of (I'm guessing) "Teams Voicemail" or "Voicemail", and then instead of picking "IR" type out "System.WorkItem.Incident" or another known message class. You would then have to build some PowerShell within Custom Events to handle how to process this new scenario. There is a walkthrough of some of this logic here.

Again, assuming it's a different message class - the thing that would stop formal support of this directly in the connector is really just analyzing a lot of sample data of this message class and ensure different scenarios are handled appropriately. For example:

Taylor-Bryan commented 1 year ago

I'll do some testing and see what we can come up with for you. If I can get something workable via the PowerShell Custom Events that can be merged in, I'll get a PR submitted, and if not, I can provide as much as information as necessary to get things squared away.

SimonZein commented 1 year ago

We had the same issue with voicemail messages coming from our phone system. In my case the "IPM.Note.Microsoft.VoiceMail.UM.CA" class was neither in the $inboxFilterString variable, nor was it defined as it's own case in the if-else statement

foreach ($message in $inbox)
{
if($message.ItemClass -eq ...)
.
.
.

We solved it by defining that variable

$audioMessageFromHelpdeskFilterString = '($_.ItemClass -eq "IPM.Note.Microsoft.VoiceMail.UM.CA")'

adding it to the $inboxFilterString variable with $inboxFilterString += $audioMessageFromHelpdeskFilterString

and then adding it's own rule in the if-else statement

elseif($message.ItemClass -eq "IPM.Note.Microsoft.VoiceMail.UM.CA")

I don't know if that's the same problem for you, but in our case it solved the problem :)

AdhocAdam commented 1 year ago

So is that to say @SimonZein that you receive voicemails from a phone system that is not Teams, but uses the Team's ...errr...Microsoft voicemail message class?

SimonZein commented 1 year ago

@AdhocAdam I don't know if this is the Teams voice message class tbh 🙈 In our case it occurs when people are calling our hotline and are leaving a voice message. Then an email with the voice message attached is sent to the helpdesk address where we are generating the tickets from. But it looks like an auto generated message. I can ask our responsibles for an example voice message + ticket, so I can show you how it looks like exactly.

AdhocAdam commented 1 year ago

Sure, but I suppose the point I'm trying to make here is that if you have a phone system that is not Microsoft Teams generating voicemail messages and @Taylor-Bryan is using Teams as his phone system and it is generating voicemail messages of that same message class. Is it safe to assume that both phone systems, follow this message class in such a way that would work for everyone?

If not, this is going to get interesting.