Contenu

Introduction

Problème

Solution 1

Solution 2

Introduction

Ce document décrit un problème rencontré lorsque le processus de détection automatique ne fonctionne pas lorsque Cisco Unified Messaging est utilisé avec Microsoft Office 365.

Problème

Lorsque vous essayez de configurer Cisco Unified Messaging avec Office 365, vous renseignez le champ Rechercher des serveurs Exchange hébergés avec mycompany.mail.onmicrosoft.com comme URL du site. Toutefois, lorsque vous cliquez sur Test, aucun des tests ne renvoie de résultats positifs.

Afin de collecter des informations supplémentaires, vous devez activer des traces supplémentaires sous la page Web Cisco Unity Connection Servicability. Pour effectuer cette opération, sélectionnez Trace > Micro Trace et activez :

CsMBXSync: 02, 10, 11,13,14,15,19,20,22,23

CsEWS: 10,11,12,13

EWSNotify:All

Utilisez l'outil de surveillance en temps réel afin de collecter ces traces à partir de la période pendant laquelle vous exécutez le test sur l'utilisateur :

- Synchronisation de la boîte aux lettres de connexion

- Tomcat de connexion

Ces résultats apparaissent dans les journaux en cas d'échec :

10:47:02.756 |31923,,,CsExMbxLocator,10,[CsExMbxLocator/CsExMbxLocator.cpp:1249]: HTTP

request failed with error: Couldn't resolve host name -- Could not resolve host:

mycompany.mail.onmicrosoft.com (DNS server returned answer with no data), HTTP

status code: 0, for Autodiscovery URL:

https://mycompany.mail.onmicrosoft.com/autodiscover/autodiscover.xml, verb: GET,

query:

10:47:02.756 |31923,,,CsExMbxLocator,13,[CsExMbxLocator/CsExMbxLocator.cpp:192] Test

Button result: Failed connected to Exchange CAS server at

(https://mycompany.mail.onmicrosoft.com/autodiscover/autodiscover.xml)

10:47:02.756 |31923,,,CsExMbxLocator,13,[CsExMbxLocator/CsExMbxLocator.cpp:1116]: HTTP

request: GET /

https://autodiscover.mycompany.mail.onmicrosoft.com/autodiscover/autodiscover.xml /

Solution 1

Modifiez les données du champ Rechercher des serveurs Exchange hébergés de mycompany.mail.onmicrosoft.com à outlook.office365.com. Enregistrez les modifications et réexécutez le test. Le problème doit être résolu.

Solution 2

Ce comportement se produit également en cas de problème de pare-feu ou de routage qui bloque la communication entre Unity Connection et Internet. Afin de le déterminer, collectez une capture réseau à partir de l'interface de ligne de commande de Unity Connection. Utilisez Wireshark pour ouvrir la capture et entrer dns dans le filtre d'affichage.

Recherchez le paquet avec la réponse DNS (Domain Name System) CNAME retournée par le serveur DNS à Unity Connection. Il contient toutes les adresses IP publiques des serveurs Office 365 qu'Unity Connection doit utiliser. Une fois que vous avez trouvé la liste de ces adresses IP dans le paquet, modifiez votre filtre d'affichage afin qu'il soit plus facile de suivre :

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

Les X.X.X.Xs sont les adresses IP publiques d'Office 365 retournées dans la réponse DNS CNAME.

Si Unity Connection ne peut pas se connecter à ces adresses IP publiques, TCP SYN laisse Unity Connection à ces adresses IP publiques. Il n'y a pas de retour SYN TCP, ACK, ce qui entraîne Unity Connection à tenter de se connecter aux adresses IP suivantes. Ceci entraîne l'échec décrit.