Cannot successfully test Exchange CAS connection in Unity

[elie_ibrahim34]

Good day everyone

I need to setup Unified Messaging in Cisco Unity.

I have configured all the required information for our office 365 setup however when i test the connection i get these error messages

Searching the network		Failed connected to Exchange CAS server at (https://outlook.office365.com/autodiscover/autodiscover.xml)
	Searching the network		Failed connected to Exchange CAS server at (https://autodiscover.outlook.office365.com/autodiscover/autodiscover.xml)
	Searching the network		Failed connected to Exchange CAS server at (https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml)
	Searching the network		Failed connected to Exchange CAS server at (http://autodiscover.outlook.office365.com/autodiscover/autodiscover.xml)

All my captures on my dns and firewall seem to be correct, i have even called office 365 support and have them investigate on their side as  well

Any ideas what im missing?! The unified messagign service is pretty simple and straightforward 

Thanks for your help

[Jonathan Schulenberg · Accepted solution]

Checking one of the basics: have you tried unchecking the validate certificates checkbox? A TLS handshake error would be one possible explanation why it can’t connect. The CA chain presented by O365 in the TLS Server Hello must be imported to Tomcat-trust and CUC-trust.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/11x/unified_messaging/b_11xcucumgx/b_11xcucumgx_chapter_01.html#task_0EA8EF95E7274B5A81A2D4E7175FE7C8

[elie_ibrahim34]

Hello Jonathan

The checkbox Validate Certificates for Exchange Servers  is uncheked in Unity.

Furthermore, i have done the Application Impersonnation as per the procedure listed in this link

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/11x/unified_messaging/b_11xcucumgx/b_11xcucumgx_chapter_01.html

I have tried to substitue outlook.office365.com by putting one of the IP's but it still fails.  There is no on-premise Exchange server, it's all in Office 365

Thank you

[Ratheesh Kumar]

Hi there

Since you have already tries the solution 1 could you try solution 2 and see that helps.

https://www.cisco.com/c/en/us/support/docs/unified-communications/unity-connection/116641-problemsolution-unified-00.html

Solution 1

Change the data in the Search for Hosted Exchange Servers field from mycompany.mail.onmicrosoft.com to outlook.office365.com. Save the changes and run the test again. The problem should be resolved.

Solution 2

This behavior also occurs if there is a firewall or routing issue that blocks communication between Unity Connection and the Internet. In order to determine this, collect a network capture from the CLI of Unity Connection. Use Wireshark to open the capture and enter dns in the display filter.

Look for the packet with the CNAME Domain Name System (DNS) response returned from the DNS server to Unity Connection. This contains all of the public IP addresses of Office 365 servers that Unity Connection is told to use. Once you have located the list of those IP addresses within the packet, modify your display filter so it is easier to follow:

dns || ip.addr == X.X.X.X || ip.addr == X.X.X.X || ip.addr == X.X.X.X || ip.addr == X.X.X.X

The X.X.X.Xs are the public IP addresses of Office 365 returned in the DNS CNAME response.

If Unity Connection is unable to connect to these public IP addresses, TCP SYN leaves Unity Connection to those public IP addresses. There is not a TCP SYN,ACK return, which causes Unity Connection to attempt to connect to the next several IP addresses. This results in the described failure.

Hope this Helps

Cheers
Rath!

***Please rate helpful posts***

[elie_ibrahim34]

Hello Rath

I have proceeded with the capture on the Unity box and checked the it with the filters applied

Here is the output.

It seems the 3-way handshake is functionnal with the 1st host returned in the cname answer : 40.97.188.226

However, as jonathan pointed out in a previous post, it seems there is a TLS conversation going on even though i have the box to validate certificates unchecked. Am i missing something here?

Thanks for the help

[Jonathan Schulenberg]

This is always TLS traffic. Unchecking that box just tells CUC not to validate that the issuing CA chain presented in the Server Hello is valid.

You can see CUC issue a TLS Alert and tear down the connection. The answer is probably in the Tomcat security or SIB logs.

[elie_ibrahim34]

Hello Jonathan

I have added the certificate  to tomcat-trust as mentionned in the procedure in the link you provided.

Is there something else i need to check? I'm not sure i understand what you mean by Tomcat security or SIB logs.

Thanks for the help!

[oliverpowell]

Hi,

Were you able to resolve this issue? I am having a similar problem. Packet capture shows 2 way communication but still no service.

Thanks

Oli

[richyvrlimited]

I too am having the same issue with oauth and Unity, was there a resolution to this issue?

[vincent.morton]

I had problems getting this to work even after following all of the above advice and a few other things I found elsewhere. It turned out the customer had created the account in their on-premise AD and it was snyched through to Azure. When they created a new account in Azure and I configured Unity to use those credentials, the OAuth2 worked first time.

[Jtech1]

in my case we found the Unified Messaging>Unified Messaging Services>O365>Client Secret was expired in O365. we had to generate a new key and input the value in Unity and set to expire in 24 months. That fixed the issue for us.