Le serveur d'accès client %1 a tenté d'envoyer par proxy du trafic de services Web Exchange au serveur d'accès client %2. ...

Le serveur d'accès client %1 a tenté d'envoyer par proxy du trafic de services Web Exchange au serveur d'accès client %2. L'opération a échoué car l'authentification de la connexion entre les deux serveurs d'accès client a échoué. Cela est peut-être dû à l'un des problèmes de configuration suivants :
1. Le nom d'hôte dans %3 n'est peut-être pas enregistré en tant que nom de principal du service (SPN) avec l'authentification Kerberos sur le serveur d'accès client cible. Cela se produit généralement quand l'on utilise l'adresse IP, plutôt que le nom d'hôte, du serveur d'accès client cible dans le paramètre de configuration « internalHostname » pour le répertoire virtuel des services Web Exchange sur le serveur d'accès client cible. Vous pouvez modifier le paramètre de configuration « internalHostname » pour le serveur d'accès client cible à l'aide de la cmdlet « Set-WebServicesVirtualDirectory ». Si vous ne voulez pas modifier le paramètre de configuration « internalHostname » pour le répertoire virtuel des services Web sur le serveur d'accès client cible, vous pouvez utiliser l'outil « setspn.exe » sur le serveur d'accès client cible pour enregistrer des SPN supplémentaires pour lesquels ce serveur d'accès client acceptera l'authentification Kerberos.
2. Le serveur hébergeant %4 est peut-être configuré afin de ne pas autoriser l'authentification Kerberos. Vous pouvez le configurer pour utiliser l'authentification « Windows intégrée » pour le répertoire virtuel /ews, mais uniquement avec l'authentification NTLM (et non Kerberos). Si vous pensez qu'il est la cause de l'échec et avez besoin d'informations supplémentaires sur son dépannage, consultez la documentation des services Internet (IIS).

Le serveur d'accès client %1 a tenté d'envoyer par proxy du trafic de services web Exchange au serveur d'accès client %2. L'opération a échoué car l'authentification de la connexion entre les deux serveurs d'accès client a échoué. Cela est peut-être dû à l'un des problèmes de configuration suivants :
1. Le nom d'hôte dans %3 n'est peut-être pas enregistré en tant que nom de principal du service (SPN) avec l'authentification Kerberos sur le serveur d'accès client cible. Cela se produit généralement quand l'on utilise l'adresse IP, plutôt que le nom d'hôte, du serveur d'accès client cible dans le paramètre de configuration « internalHostname » pour le répertoire virtuel des services web Exchange sur le serveur d'accès client cible. Vous pouvez modifier le paramètre de configuration « internalHostname » pour le serveur d'accès client cible à l'aide de la cmdlet « Set-WebServicesVirtualDirectory ». Si vous ne voulez pas modifier le paramètre de configuration « internalHostname » pour le répertoire virtuel des services Web sur le serveur d'accès client cible, vous pouvez utiliser l'outil « setspn.exe » sur le serveur d'accès client cible pour enregistrer des SPN supplémentaires pour lesquels ce serveur d'accès client acceptera l'authentification Kerberos.
2. Le serveur hébergeant %4 est peut-être configuré afin de ne pas autoriser l'authentification Kerberos. Vous pouvez le configurer pour utiliser l'authentification « Windows intégrée » pour le répertoire virtuel /ews, mais uniquement avec l'authentification NTLM (et non Kerberos). Si vous pensez qu'il est la cause de l'échec et avez besoin d'informations supplémentaires sur son dépannage, consultez la documentation des services Internet (IIS).