Le serveur %1 d'accès au client Microsoft Exchange a tenté d'établir une liaison proxy pour le trafic Outlook vers le serveur ...

Le serveur %1 d'accès au client Microsoft Exchange a tenté d'établir une liaison proxy pour le trafic Outlook vers le serveur d'accès au client %2. Cette tentative n'a pas abouti car l'authentification de la connexion entre les deux serveurs d'accès au client a échoué. Cela peut être dû à l'un des problèmes de configuration suivants : 
1. Il se peut que le nom d'hôte dans %2 ne soit pas enregistré comme nom de principal du service (SPN) auprès de Kerberos sur le serveur d'accès au client cible. Cela se produit généralement lorsque vous utilisez l'adresse IP, au lieu du nom d'hôte, du serveur d'accès au client cible dans la configuration « internalURL » du répertoire virtuel Outlook Web App sur le serveur d'accès au client cible. Vous pouvez modifier la configuration « internalURL » du serveur d'accès au client cible en utilisant la tâche « Set-OwaVirtualDirectory ». Si vous ne voulez pas modifier la configuration « internalURL » du répertoire virtuel Outlook Web App sur le serveur d'accès au client cible, vous pouvez également utiliser l'outil « setspn.exe » sur le serveur d'accès au client cible pour enregistrer des SPN supplémentaires pour lesquels ce serveur d'accès au client acceptera l'authentification Kerberos. 
2.Le serveur hébergeant %2 peut être configuré pour ne pas autoriser l'authentification Kerberos. Il peut être configuré pour utiliser l'authentification Windows intégrée pour le répertoire virtuel Outlook Web App, à condition d'être configuré pour utiliser uniquement l'authentification NTLM (non-Kerberos) pour l'authentification Windows intégrée. Si vous pensez que cela pourrait être la cause de l'échec, consultez la documentation d'IIS pour découvrir des opérations de dépannage supplémentaires.