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

  • Question

  • 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?

    Tuesday, September 23, 2014 6:52 PM

All replies

  • Have you tried to disable/enable UM for the migrated users? You can also check the msExchUM.. attributes for this users.
    Sunday, October 12, 2014 9:55 AM
  • of course, doesn't fix it. Only new mailboxes work freshly created on 13
    Sunday, October 12, 2014 9:57 PM
  • 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?


    Friday, March 20, 2015 6:51 PM
  • 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/

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, March 20, 2015 9:29 PM
  • 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.



    Friday, March 20, 2015 10:47 PM
  • 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.

    Saturday, March 21, 2015 12:51 AM
  • 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.



    Monday, March 23, 2015 5:47 PM