Today I discovered that there has been an update to Microsoft Teams Auto Attendants and Call Queues Shared Voicemail. In the past it was only possible to configure a Microsoft 365 Group as the transfer target of shared voicemail, as it’s described in this article.

Now the search box in Auto Attendant or Call Queue Wizards also return Distribution Lists and Mail Enabled Security Groups.

I don’t know when this change was implemented but there’s evidence out there that it has been around for at least some time or even since shared voicemail has been rolled out.

Since all the official Microsoft documentation I could find (then and now) only mentioned Microsoft 365 Groups, I honestly never even tried to search for another group type.

I feel like it’s been like this for a bit but I couldn’t tell you when.

— Robert Schoneman (@rschoneman) January 27, 2023

A customer insisted on trying it 2 years ago and to my surprise it worked

— Dario Woitasen 🇦🇷🇮🇹🇪🇸 (@dariomws) January 27, 2023

Has always worked since shared voicemail was an option, could never understand why one would create a m365 group to route voicemail. The search exposed it the first time I went to set it.

— Michael LaMontagne (@RealTimeUC) January 28, 2023

The documentation is not updated yet. Better yet, it still says Office 365 instead of Microsoft 365 group.

The OverflowActionTarget parameter represents the target of the overflow action. If the OverFlowAction is set to Forward, this parameter must be set to a Guid or a telephone number with a mandatory ‘tel:’ prefix. If the OverflowAction is set to SharedVoicemail, this parameter must be set to an Office 365 Group ID. Otherwise, this parameter is optional.

The description in the Auto Attendant and Call Queue Wizard also still references Microsoft 365 Groups only. But it does return Distribution Lists and Mail Enabled Security Groups when we search for them.

It does not find security groups, which makes sense, since they’re not capable of receiving emails.

Testing

This begs the question: is it only possible to choose these new group types or are shared voicemails actually delivered to Distribution Lists too?

Let’s find out…

It seems to be working just fine. Here’s a screenshot of the email received in Outlook.

When hovering over the recipient’s address, we can see what type of group it is.

Note that shared voicemail emails to Distribution Lists and Mail Enabled Security Groups look exactly the same in Outlook. Both are labeled as “Distribution list”, even though they are technically of different group types.

PowerShell

Nothing has changed on the PowerShell side of things. The OverflowAction is still called “SharedVoicemail” and the OverflowActionTarget.Type is still “Mailbox” while OverflowActionTarget.Id remains the group’s Object Id.

PS V:\GitHub\M365CallFlowVisualizer> $cq.OverflowAction                                        
SharedVoicemail

PS V:\GitHub\M365CallFlowVisualizer> $cq.OverflowActionTarget  
  
Id                                   Type  
--                                   ----  
413a7c2e-e359-4424-b2f7-xxxxxxxxxxxx MailBox

The Auto Attendant properties also remain unchanged.

PS V:\GitHub\\M365CallFlowVisualizer> $aa.DefaultCallFlow.Menu.MenuOptions  
  
  
Action         : TransferCallToTarget  
DtmfResponse   : Automatic  
VoiceResponses : {}  
CallTarget     : Type = SharedVoicemail  
                 Id = 413a7c2e-e359-4424-b2f7-xxxxxxxxxxxx  
Prompt         :  

Luckily, this means that I don’t have to update the M365 Call Flow Visualizer and everything continues to work like it did before.

Configuring via PowerShell

What’s a bit worrisome is that I was able to set the Id of a Security Group as the Shared Voicemail Target for a Call Queue through PowerShell. It doesn’t look like PowerShell is evaluating the group type when the queue is saved.

Once the queue has been updated through PowerShell, TAC will even display the name of the Security Group in the Wizard. As long as we don’t remove the Security group from the Shared Voicemail Target, it’s even possible to edit and save the queue through TAC. The invalid group remains.

When I delete the group and search for it again, nothing is returned anymore, as it should be.

To test this, I made a call to the queue. In this case, my overflow threshold was set to zero, so the call failed immediately with a busy tone.

I then did the same for the timeout action target and called the queue again. As soon as the timeout was reached, I could hear the transfer beep and then the call failed with a busy tone too.

Luckily, it’s a different story with Auto Attendants. When I tried the same thing there, an error was returned, like I expected for Call Queues in the first place.

Microsoft.Teams.ConfigAPI.Cmdlets.internal\Set-CsAutoAttendant :
A mail-enabled group with Id (da027ae9-467b-4334-829c-xxxxxxxxxxxx)
could not be found. Please give correct parameter value.

Conclusion

While I wouldn’t implement this in a production environment until the official documentation is updated and we know for sure, that this is working as Microsoft intended, I think it’s a great feature update for Teams Phone. Only being able to just use Microsoft 365 Groups, also meant that we always had to make sure that users are subscribed to receive all group emails or enabled the Follow in Inbox feature for themselves.

I will report the missing group type validation for Set-CsCallQueue to Microsoft and hope that they fix it soon. In the mean time, make sure that you’re extra careful and only configure Group Ids of M365 Groups, Distribution Lists or Mail Enabled Security Groups.

I’ll also see if I can update the Visualizer to include group type for shared voicemail in the diagrams.