Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Voicemails sent from Microsoft Teams do not generate tickets #465

Open
Taylor-Bryan opened this issue Jun 14, 2023 · 6 comments
Open

Voicemails sent from Microsoft Teams do not generate tickets #465

Taylor-Bryan opened this issue Jun 14, 2023 · 6 comments
Assignees
Labels
feature request Idea to expand functionality

Comments

@Taylor-Bryan
Copy link

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:

  • Create Users not Found in CMDB
  • Attach Email to Work Item
  • Move to Deleted Items After Processing
  • Update Work Items missing [Work Item]
  • If Work Item to Update is Closed - Create, Relate, and Copy into a New Work Item
  • Process Encrypted Emails
  • Process Digitally Signed Emails (and the sub-item for certificate error processing)
  • Workflow runs every 3 minutes and is enabled

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
Copy link
Owner

If the...

  • logging level is 4/verbose
  • the item is in the inbox
  • it's unread even after a run of the connector
  • the connector isn't recognizing it as it shows "0 messages to process"
  • but the connector picks it up when someone forwards it over

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:

  • is the "shape" of voicemails left by Teams (VOIP) or from actual phone numbers different in terms of the message that is delivered by/in Exchange. Is this consistent across different organizations?
  • Is there any translation that would have to be done to identify a phone number to an AD User? do users have multiple numbers? Is the data at least in the same place across organizations despite it may or may not exist?
  • For users that are not in Active Directory (e.g. an external caller) should they be handled the same or differently than "known users in the CMDB"

@AdhocAdam AdhocAdam self-assigned this Jun 15, 2023
@AdhocAdam AdhocAdam added the feature request Idea to expand functionality label Jun 15, 2023
@Taylor-Bryan
Copy link
Author

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
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor

@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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Idea to expand functionality
Projects
None yet
Development

No branches or pull requests

3 participants