O Servidor de Acesso para Cliente %1 tentou intermediar, via proxy, o tráfego dos Serviços Web do Exchange para o Servidor ...

O Servidor de Acesso para Cliente %1 tentou intermediar, via proxy, o tráfego dos Serviços Web do Exchange para o Servidor de Acesso para Cliente %2. Isso não ocorreu, pois houve uma falha na autenticação da conexão entre os dois Servidores de Acesso para Cliente. Isso pode ter ocorrido por causa de um destes problemas de configuração: 
1. O nome do host em %3 pode não ter sido registrado como um SPN (Nome da Entidade de Serviço) com Kerberos no Servidor de Acesso para Cliente de destino. Isso normalmente acontece quando você usa o endereço IP (e não o nome do host) do Servidor de Acesso para Cliente de destino na configuração "internalHostname" do diretório virtual dos Serviços Web do Exchange no Servidor de Acesso para Cliente de destino. Você pode alterar a configuração "internalHostname" do servidor de acesso para Cliente de Destino usando o cmdlet "Set-Webservicesvirtualdirectory". Se você não quiser alterar a configuração "internalHostname" do diretório virtual dos Serviços Web do Exchange no Servidor de Acesso para Cliente de destino, também poderá usar a ferramenta "setspn.exe" no Servidor de Acesso para Cliente de destino para registrar outros SPNs para os quais o Servidor de Acesso para Cliente aceitará a autenticação Kerberos.
2 O servidor que hospeda %4 pode ser configurado para não permitir autenticação Kerberos. Ele pode ser configurado para usar a autenticação "integrada do Windows" para o diretório virtual /ews, mas ser configurado para usar somente autenticação NTLM (não Kerberos) para autenticação integrada do Windows. Se você acha que essa pode ser a causa da falha, consulte a documentação do IIS para verificar outros procedimentos de solução de problemas.