cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
445
Views
0
Helpful
3
Replies

Unified Messaging Issue on Cisco Unity Connection with office 365

ahaghdel
Level 1
Level 1

Solution

Log to the UNITY PUB CLI and run the following command

run cuc dbquery unitydirdb update tbl_configuration set valuelong=0 where fullname like '%GrantType%'


Then on the GUI unity connection serviceability > service management restart the Connection Mailbox Sync Service


removed the extra permissions from Azure side, only leaving the Full access as app permission. Refer to the attachments.

 

 

Issue

 

Despite following the official Cisco documentation Cisco Unified Messaging Guide for Cisco Unity Connection Release 14 and reconfiguring from scratch, the error persists.

Troubleshooting Steps Performed:

Verified Exchange Autodiscover Connectivity:

Successfully connected to Exchange CAS server (outlook.office365.com).

Checked ApplicationImpersonation Permissions:

Verified the "ApplicationImpersonation" role assignment.

Ensured the Unity service account has the necessary scope.

Verified EWS Access:

Confirmed that EWS is enabled on affected mailboxes using:

OAuth2 Authentication Configuration:

Validated OAuth2 is correctly configured.

Checked app registration in Microsoft Entra ID (Azure AD) with permissions:

EWS.AccessAsUser.All

Mail.ReadWrite

Recreated Unified Messaging Accounts:

Deleted and recreated Unified Messaging service accounts with updated credentials and permissions.

Service Restart:

Restarted Cisco Unity Connection services.

Error Logs:

The following error appears in the logs:

Impact:

Voicemail-to-email delivery is failing for multiple users.

Users cannot retrieve voicemail messages through their email inbox.

 

1 Accepted Solution

Accepted Solutions

Brad Magnani
Cisco Employee
Cisco Employee

Given the impact from the recent changes mentioned in https://community.cisco.com/t5/collaboration-applications/reminder-cuc-um-w-o365-stops-working-with-legacy-permissions/td-p/5267296 this command could cause a lot of confusion for people that are running on an affected version looking for a "fix" as they search online.  I strongly advise against running this command, for a few reasons.

The command was meant for customers who were already on any of the "Fixed Release" versions but were unwilling to move to the new full_access_as_app client credential method.  They wanted to remain operating with the old legacy Application Impersonation permissions, so as a workaround, the DB had to be manually updated to remove the logic to use the new client credential flow.  Today, it doesn't make sense to disable the new method since Microsoft has now removed Application Impersonation functionality, everyone must move to the new flow. 

Also, the impacted versions do not have this %GrantType% value in the configuration table, so the command will not do anything except cause more confusion. 

Hope this clarifies for anyone who is reading.
Brad

View solution in original post

3 Replies 3

Brad Magnani
Cisco Employee
Cisco Employee

Given the impact from the recent changes mentioned in https://community.cisco.com/t5/collaboration-applications/reminder-cuc-um-w-o365-stops-working-with-legacy-permissions/td-p/5267296 this command could cause a lot of confusion for people that are running on an affected version looking for a "fix" as they search online.  I strongly advise against running this command, for a few reasons.

The command was meant for customers who were already on any of the "Fixed Release" versions but were unwilling to move to the new full_access_as_app client credential method.  They wanted to remain operating with the old legacy Application Impersonation permissions, so as a workaround, the DB had to be manually updated to remove the logic to use the new client credential flow.  Today, it doesn't make sense to disable the new method since Microsoft has now removed Application Impersonation functionality, everyone must move to the new flow. 

Also, the impacted versions do not have this %GrantType% value in the configuration table, so the command will not do anything except cause more confusion. 

Hope this clarifies for anyone who is reading.
Brad

jbgeorge2010
Level 1
Level 1

We are on 12 SU8. We had issues even after following Cisco's guide. We were already set up to use OAuth2.0 and using Delegate. We changed to allow full_access_as_app client credential method as recommended by the Cisco guide. That part did not complete the fix because Cisco TAC forgot to tell us to remove the credentials in the Unified Messaging Service by running the "run cuc dbquery unitydirdb update tbl_configuration set valuelong=0 where fullname like '%GrantType%' " Once we ran that query in CLI, then restarted the service, "Connection Mailbox Sync" service, it started working correctly.