Voicemail

Default Cloud Voicemail Language

When Cloud Voicemail a.k.a. Azure Voicemail (which replaced Unified Messaging) is activated for a mailbox, a default language is set. This value is known as the ‘promptlanguage’ and according to Microsoft Documentation will be set based on the default language for your organisation in the Microsoft 365 admin center.

The problem is, that value is ‘English’ and doesn’t define which regional set of English you want – en-US, en-UK, en-AU etc. The full list of language codes is available here.

With Engish set as the preferred language, Azure Voicemail decides that you must be wanting en-US as your promptlanguage – which you may not actually want. The default voicemail greeting is rather different when set to en-US vs en-UK vs en-AU.

If you’d like to see what a user has, use the PowerShell command:

Set-CsOnlineVoicemailUserSettings -identity XYZ@XYZ.COM

and check the value ‘PromptLanguage’.

On a per user basis, this value can be changed either by the user themselves at https://mysettings.lync.com/voicemail or by an admin with the PowerShell command:

Set-CsOnlineVoicemailUserSettings -identity XYZ@XYZ.COM -PromptLanguage en-AU

This still doesn’t solve the tenant wide problem, or set a default.

For existing users, we just need to get a list of users and change the promptlanguage setting, which can be done with this set of PowerShell commands (includes connecting to SfBO which can be used for the above command also):

$sfbsession = new-csonlinesession -username adminaccount@conotoso.com -OverrideAdminDomain contoso.onmicrosoft.com


Import-PSSession $sfbsession


$users = Get-CsOnlineuser


foreach ($user in $users) {set-csonlinevoicemailusersettings -identity $user.userprincipalname -promptlanguage en-AU}

Note the use of the -OverrideAdminDomain switch, which I learnt from this blog post in case you are having issues connecting to Skype for Business Online.

This process also may take a long time depending how many users you have, as very roughly it takes about a second per user to change the value.

This will fix your existing users, but what about new ones? You could have the setting modified set as part of the user creation process, but that’s an extra step and you’d need to wait for Azure Voicemail to be ready – in my experience it’s not a service that’ll be available quickly after enabling. At this stage I haven’t found a way to do it though, so you’ll need to consider adding this configuration as part of user setup.

If you haven’t even thought about what language you’re using – have a look and try each one, as you might find one that you’re happier with than the US.

Exchange 2010 Unified Messaging – Unrecognised Voicemail Extension

Hi,

I had an issue where a particular user’s voicemail on Exchange 2010 wasn’t working. When they called the voicemail number, they were asked “To access your mailbox, please enter the extension” rather than being greeted with their name and messages. The user was on Lync 2010, and Unified Messaging was enabled on their account with the matching extension number. Also, when dialing voicemail and trying to enter the extension number just met the message ‘XXX isn’t a valid mailbox’.

Disabling and re-enabling Unified Messaging made no difference. I was rather confident this was an Exchange/Unified Messaging issue, so I had the idea of checking ADSI edit to see if UM was properly enabled.

Checking the attribute “msExchUMEnabledFlags” found the issue. When a user has UM enabled, the value of this field should be 831, or 830 when disabled. I’ve come across this issue before, where it’s the wrong value and needs to be changed, but this was the first time I’d come across it as being 832.

Never a good sign when you google something, and you get zero results:

exchange

Changing the Attribute value back to 831 instantly fixed the issue, didn’t even require disabling and re-enabling Unified Messaging. If all else fails, change the value back to 830, refresh your Exchange Management Console and the user should show as being disabled for Unified Messaging, then re-enable as you normally would.

Hope this helps anyone else who comes across a similar issue.