Update – response from Microsoft is as follows: “ I talked to the Escalation Engineer who put in the bug and it looks like the fix is going in for Exchange Online, but there is currently nothing planned for on-premises. The logic being that the workaround of making sure your admins are on the same mailbox database is fairly simple for the on-prem environment whereas it is impossible for the Cloud environment.”
So, this one won’t likely be fixed folks, however there is a workaround and if you feel it needs to be fixed please let me know and I can share case numbers and you can submit a business impact statement.
This is a developing issue but I wanted to write about it for anyone else out there searching. I will try to keep this blog post updated for when a resolution is found. I do not currently have all of the details. In brief, users in charge of recording Exchange UM prompts prefer to dial directly in to make the changes over the phone due to the high frequency of greeting changes. Once the IP Gateways have been pointed at Exchange 2013, calls to the Automated Attendants to record greeting audio is rejected with an audible “Sorry.. that extension isn’t correct.” error.
The environment is a mixed Exchange 2010 and 2013 environment across multiple sites. All servers are running all Exchange updates as of the writing of this article. A third party (not Lync) PABX is connected to the Exchange environment through four Sonus SBC 2000 devices. The TechNet article to Upgrade Exchange 2010 UM to Exchange 2013 UM is being followed, all steps through 14 have been completed. This means the system mailbox has been moved, and the IP gateways have been pointed at Exchange 2013.
A caller dials into the Automated Attendant and hits # then * and enters their extension. An audio file plays “Sorry.. that extension isn’t correct“. Pointing the IP gateways back at the Exchange 2010 UM servers resolves the issue. We’re not seeing other issues related to UM at this time.
- UM Services were restarted on CAS/MBX roles. -No affect
- Users needing prompt editing access were removed and re-added to the UM Management RBAC group -No affect
- Users with the Organization Management RBAC role and full domain administrative access show the same symptom.
- Disabled and re-enabled TUIPromptEditing with: Set-UMDialPlan -TUIPromptEditingEnabled $true -No affect
- Created new Automated Attendants from 2013 console -No affect
- Created new users on the 2013 side with full permissions -No affect
- Reviewed Event Logs and ran diagnostic logging. The results pointed at an error, but not a why. Similar results to a user without proper permissions making the attempt.
It smelled like a bug, and we’ve confirmed with Microsoft that it is a known issue. What should happen is the following:
- A call comes into a server hosting a CAS role/Unified Messaging Call Router via the IP Gateway.
- The call then flows to a server hosting the Mailbox role/Unified Messaging service.
- If this Mailbox server does not hold the user’s mailbox, it sends a SIP REFER back to the gateway noting which Mailbox server it should communicate with.
- The IP gateway connects with the appropriate Mailbox server which prompts for your pin.
Somehow, step 3 isn’t completed properly, we don’t see the REFER generated, and we hear the error. The workaround for now is to locate the mailboxes that need TUI access on the same database/server as the system mailbox. Please share your experience if you have this issue.