In November 2024, a Cisco Field Notice was published indicating Microsoft would be decommissioning RBAC Application Impersonation, which Unity Connection has historically used to sync voicemail to O365. Microsoft just begun shutting off the functionality as they indicated they would and many customers have been suddenly without UM. This is creating integrations to fail which did not upgrade before the deadline. In order for Unity Connection to continue to function with O365 integrations, you will need to be running a version of Unity Connection listed in the "Fixed Release" column outlined in the Field Notice here: https://www.cisco.com/c/en/us/support/docs/field-notices/742/fn74203.html
Once upgraded to a supported CUC version, there is also a new permission (full_access_as_app) required on the Azure side outlined in step 4g in the UM Configuration Guide.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/unified_messaging/guide/b_14cucumgx/b_14cucumgx_chapter_01.html#ID-2370-000005f5
Be sure that you remove the existing legacy permissions after adding this new permission.
If you're troubleshooting Mbxsync traces wondering if you are affected by this change, the logs will show the 403 bad response coming from Azure, the signature in the logs can resemble lines like these:
HTTP status=[403 Forbidden] Diagnostic=[Bad response from server, HTTP code returned: 403]
a:ErrorForbiddenImpersonationHeader</faultcode><faultstring xml:lang="en-US">ExchangeImpersonation SOAP header is not supported in delegate flow.
***EDIT*** You may find yourself already on a fixed release but UM still stopped working despite your having properly enabled full_access_as_app permission in Azure. In months past, if you upgraded to one of the fixed versions (great!), CUC would use the new client credentials flow by default. However, this could cause problems if you still chose to keep RBAC Application Impersonation permissions in place on the Azure side by not configuring the new full_access_as_app permission. Customers in this situation were given a temporary workaround to manually update the DB to force CUC to use the previous RBAC Application Impersonation method.
Now that Microsoft has removed RBAC Application Impersonation, this has now caused UM failure for these customers who have been running with the manual workaround in place (many have forgotten it was in place). The manual DB workaround needs to be reverted so that CUC will go back to using the new client credentials flow.
If you're in this situation where you're on a fixed release with the correct Azure permissions configuration and not sure if you've been running with the manual forced RBAC workaround from the past, you can run the command below to check, and if necessary revert CUC back to the default method of using client credentials, which is the way all fixed versions of CUC should be running.
Check the current value of "valuelong" on your system:
1 = RBAC Application Impersonation
0 = Client credential flow
run cuc dbquery unitydirdb select valuelong,fullname from tbl_configuration where fullname like '%GrantType%'
valuelong fullname
--------- ---------------------------------------------
1 System.Messaging.MbxSynch.OAuthTokenGrantType
If valuelong=1, this must be set back to 0 to use the new Client credential flow.
run cuc dbquery unitydirdb update tbl_configuration set valuelong=0 where fullname like '%GrantType%'
Then you will need to:
1. Restart the "Connection Mailbox Sync" service from Cisco Unity Connection Serviceability > Tools > Service Management.
2. Reset the Unified Messaging Service using "Reset" button on the Unified Messaging Service configuration page.
Hope this helps,
Brad
