I’m not sure about the rest of the world, but Azure Voicemail (AVM), aka Cloud PBX Voicemail, has had me utterly confused. I want to take a minute and explain what I’ve discovered, deduced, and can divulge from conversations I’ve had with Microsoft.
Let’s be clear, I think AVM is a good thing. AVM brings all things SfB under one product group, which makes sense. It eliminates the Exchange group from the conversation and streamlines the process. I’m sure it makes development easier, regression testing easier, and support easier when it all falls under one umbrella. I know my job is much easier when resources and decision makers all align in one practice.
What I don’t understand though, is why it came to market without any documentation, without feature parity, and leaving the user with options that frankly don’t work in certain scenarios.
So what is AVM? Well, plain and simple, it’s a voicemail solution for SfB Cloud PBX with PSTN Calling or SfB Cloud PBX with OnPrem-PSTN Calling, that deposits voicemail messages into an Exchange Online or OnPrem mailbox.
Why do I find AVM confusing?
- It still requires ExUM…really?…yeah kind of!
- It doesn’t require an ExUM Policy
- But…if an ExUM Policy is applied which can happen in certain scenarios, none of the settings actually apply to the user
- There’s no configuration available for AVM at the moment
- There’s no documentation to help administrators make the right decision, or explain WTF is going on
There are 3 scenarios I want to look at:
1. A new user is enabled in O365, SfB Online and PSTN Calling
2. A user is migrated from SfB OnPrem and ExUM OnPrem, to SfB Online and AVM
3. A confused admin enables ExUM for a SfB Online user
Scenario 1: A new user enabled in O365, SfB Online and PSTN Calling
A new user (Skype4bT5) is licensed with an E5 and PSTN Domestic Calling plan. A new mailbox is auto-provisioned in Exchange Online and a new SfB account is created in SfB Online.
If we look in Exchange Online, Skype4bT5’s mailbox is auto-provisioned, and Unified Messaging is Disabled. Pretty straight forward.
Next we sign into the SfBO portal and assign Skype4bT5 a phone number.
After the user is enabled for PSTN Calling and assigned a number, we can go back and have a look at Exchange Online to see if UM is enabled. Nope, still disabled. Checked via console and PowerShell just to be sure.
Next we place a call to Skype4bt5 and leave a message.
The message is delivered to the mailbox, and Skype4bt5 is able see it and listen to it. Keep in mind that at no point did we enable ExUM for this user.
This is where things get interesting.
If we go back to Exchange, we can see that Unified Messaging is now Enabled. Without any administrator intervention mind you. There seems to be an automated process (Magic) behind the scenes that will enable UM if it is not previously enabled when a VM is delivered. You’ll also notice there is no extension and no UM MailboxPolicy.
When we check in the EAC, the user is enabled, but when we click “View Details”, we actually get an error message. Which apparently is the expected result…a feature I suppose you could say.
Why does it enable ExUM? Well, it would seem that ExUM gets enabled for a single purpose. From what I’m told by Microsoft, this is so the client side API’s light up visual voicemail in the Outlook Client.
ExUM Disabled (MP3 Attached) ExUM is enabled (Visual Voicemail Available)
The user now gets visual voicemail in the Outlook client and voicemail appears to be functioning properly in the SfB client. However, the user gets no control over things like: Call Answering Rules, Greetings, Notifications, Outlook Voice Access, Play on Phone, Reset PIN, and Voice Mail Preview. Settings that would traditionally be the Settings page in OWA, but these options don’t exist.
Which means there are no additional features currently available in AVM other than receiving voicemail to your mailbox. Transcription is currently available in Preview, but is not enabled by default.
Scenario 2: User migrated from SfB OnPrem and ExUM OnPrem, to SfB Online and AVM
In this scenario, we are making a few assumptions. First, let’s assume that we migrated our Exchange Mailbox from Exchange OnPrem to Exchange Online (ExO) sometime in the past. Which means we have setup an ExUM Dial Plan and ExUM Mailbox Policy in ExO and assigned an ExUM policy to every OnPrem SfB Enterprise Voice user.
Just so everyone follows, Exchange UM Online is setup as the voicemail solution for SfB OnPrem Enterprise Voice users. Follow me here?
Now, at some point in the future (let’s just assume we operated in this hybrid configuration for some time), SfB is migrated to SfB Online, and the users number is ported to Microsoft.
Now, both SfB and Exchange are enabled and homed purely Online in O365.
In this scenario, ExUM would have already been enabled for each user, a UM Mailbox Policy would have already been set and an Extension would have already configured. As seen below.
Since ExUM was already enabled and an ExUM Policy is set for the user in ExO, additional options are lit up on the Settings page in OWA:
That’s great right, it would appear that we now have the full range of ExUM features available for the SfBO end user! Well, not exactly. While the features appear to be available to configure, this unfortunately is just a side-effect of having an ExUM Policy set for the user. The user can go in and configure these settings till their heart’s content, which gives the user the appearance that these options are set and should work. Unfortunately, most of them don’t actually do anything in this scenario…such as: Call answering rules, greetings, notifications, voice mail preview options.
This leaves the user with a less than ideal experience. They *think* they’ve configured a bunch of settings, and will expect them to work, but in reality they don’t.
This can be especially confusing/frustrating if the user was using these features prior to the SfB Online migration. Where these may have already be configured, and simply stop working.
What’s still unclear to me, is what the admin should do at this point? Now that users are enabled for SfBO, PSTN Calling, and have an ExUM Mailbox Policy assigned, how do you clear the UM Mailbox Policy and reset the mailbox to get the expected AVM experience?
If the admin goes back and disables Exchange UM for the user, AVM does not do its behind the scenes magic and re-enable UM without a UM Mailbox Policy. ExUM simply remains disabled. Meaning AVM is still enabled and the user receives new voicemails, but Visual Voicemail is not available in Outlook.
So it would appear that the users are stuck with ExUM enabled with the pre-existing ExUM Mailbox Policy. End-user communication becomes critical as to ensure users are aware that these settings no longer function.
Next time, I will try to disable ExUM on the users prior to the SfB migration. This will hopefully allow AVM to auto-provision ExUM behind the scenes, enabling Visual Voicemail, all while not exposing the additional ExUM settings in the OWA settings page.
Scenario 3: A confused admin enables ExUM for SfB Online user
I’ll admit, this scenario is based off my experiences prior to working through this.
In this scenario, the administrator doesn’t have any guidelines, documentation, or best practices to follow (there aren’t any published), and he/she goes in and enables all SfB Online PSTN Calling Users for ExUM. Every user gets an ExUM Mailbox Policy, and an EUM extension.
The net results are exactly the same as Scenario 2. The user is enabled for ExUM and AVM continues to deliver the voicemail to the user’s mailbox as expected; unfortunately, the user is assigned an ExUM Voicemail Policy, which means Voice Mail settings are again exposed in the OWA settings, and they still don’t function.
Summary:
In summary, I hope this is only a temporary issue. The Skype for Business product groups is continuing to release features and add new things in Preview. I’m sure it won’t be long until features Online surpass those OnPrem. In the meantime, I hope this helps clear a little bit of the confusion with AVM and ExUM…if not making the waters just a bit murkier.