Custom Auto Attendant Prompts through TUI not working for users who migrated from 2010 to 2013

In Exchange 2010, we started using unified messaging and set up Auto Attendants. We setup a admin role/RBAC for people of a security group to be able to update the message on the auto attendants. They have the UMPrompts assigned role. All of this is working great in 2010. We have now migrated to 2013, and the users who were migrated from 2010 to 2013 can no longer update the messages through TUI. Newly created 2013 users can and are assigned the EXASCT same permission as the users who have been doing this for well over a year on 2010.  When they call the AA and press #,* they are asked to provide their extension, after doing so the system tells them that extension is not correct. and asks for the extension again.  Newly created users with the same permissions get prompted for their PIN and can log in and change the message just fine. 

Confirmed Bug?  anybody else having this issue?

What would be different for this process between a user who was migrated from a previous version like 2010 compared to a newer user who has only ever existed on 2013?

September 23rd, 2014 6:52pm

Have you tried to disable/enable UM for the migrated users? You can also check the msExchUM.. attributes for this users.
Free Windows Admin Tool Kit Click here and download it now
October 12th, 2014 9:55am

Have you tried to disable/enable UM for the migrated users? You can also check the msExchUM.. attributes for this users.
October 12th, 2014 9:55am

of course, doesn't fix it. Only new mailboxes work freshly created on 13
Free Windows Admin Tool Kit Click here and download it now
October 12th, 2014 9:57pm

We are having the exact same issue. None of our existing mailboxes that had UM prompts can modify the AA.

I used a test account today and gave it UM Management role as well then it worked.

Of course we are not going to give the delegated persons that Role so we are looking at creating a new custom RBAC role once we identify the new permission.

Why the change? Does anyone know what new permissions the 2010 migrated mailboxes need now?

John

March 20th, 2015 2:54pm

What if the migrated 2010 users are in the same DB as the system mailbox? I had a similar issue during a migration; http://www.skypeadmin.com/2014/11/10/known-issue-um-automated-attendant-tui-editing-broken-migration/
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2015 5:32pm

We have that issue as well. We had to move all our Delegated Mailboxes that were delegated UM prompts role to the same Server that had the System Mailbox.

 

John

March 20th, 2015 6:49pm

Like Anthony stated in his blog post link, Microsoft is going to fix this in Office 365, but not for on-premise as of now.

We have to large of an environment, and planned out our mailbox database layout before we knew of this bug.  Our solution was to give each department who has a AA, a generic shared account to update their prompts.  These accounts reside on the same server as the system mailboxes.  Doesn't have to be the same database, but at least the same server cause of the way the SIP message flow happens.

Free Windows Admin Tool Kit Click here and download it now
March 20th, 2015 8:53pm

For the original issue I came up with a workaround. Create an RBAC Group with UM Prompts permissions. Make the scope Default instead of custom and this works. No need to change permissions just the scope.

I am contacting Microsoft to see why the change in behaviour from what worked previously.

John

 

March 23rd, 2015 1:49pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics