Der Microsoft Exchange-Clientzugriffsserver '%1' hat versucht, als Proxy für Outlook-Datenverkehr für den Clientzugriffsserver ...

Der Microsoft Exchange-Clientzugriffsserver '%1' hat versucht, als Proxy für Outlook-Datenverkehr für den Clientzugriffsserver '%2' zu fungieren. Bei der Authentifizierung der Verbindung zwischen den beiden Clientzugriffsservern ist ein Fehler aufgetreten. Die Ursache kann in einem der folgenden Konfigurationsprobleme liegen: 
1. Der Hostname in %2 ist möglicherweise bei Kerberos auf dem Clientzugriffs-Zielserver nicht als Dienstprinzipalname (Service Principal Name, SPN) registriert. Dies geschieht normalerweise, weil die IP-Adresse anstelle des Hostnamens des Clientzugriffs-Zielservers in der "internalURL"-Konfiguration für das virtuelle Outlook Web App-Verzeichnis auf dem Clientzugriffs-Zielserver verwendet wurde. Die Konfiguration von "internalURL" für den Clientzugriffs-Zielserver kann mithilfe der Exchange-Administratoraufgabe "Set-OwaVirtualDirectory" geändert werden. Wenn Sie die "internalURL"-Konfiguration für das virtuelle Outlook Web App-Verzeichnis auf dem Clientzugriffs-Zielserver nicht ändern möchten, können Sie auch das Programm "setspn.exe" auf dem Clientzugriffs-Zielserver ausführen, um zusätzliche SPNs zu registrieren, für die der Clientzugriffsserver die Kerberos-Authentifizierung akzeptieren soll. 
2.Der Server, auf dem '%2' gehostet ist, ist möglicherweise nicht für das Akzeptieren von Kerberos-Authentifizierung konfiguriert. Möglicherweise ist er für die Verwendung der integrierten Windows-Authentifizierung für das virtuelle Outlook Web App-Verzeichnis konfiguriert, jedoch für die integrierte Windows-Authentifizierung nur für NTLM (nicht jedoch Kerberos) konfiguriert. Wenn Sie hier die Ursache des Problems vermuten, finden Sie weitere Schritte zur Problembehebung in der IIS-Dokumentation.

Der Microsoft Exchange-Clientzugriffsserver '%1' hat versucht, als Proxy für Outlook-Datenverkehr für den Clientzugriffsserver '%2' zu fungieren. Bei der Authentifizierung der Verbindung zwischen den beiden Clientzugriffsservern ist ein Fehler aufgetreten. Die Ursache kann in einem der folgenden Konfigurationsprobleme liegen: 
1. Der Hostname in %2 ist möglicherweise bei Kerberos auf dem Clientzugriffs-Zielserver nicht als Dienstprinzipalname (Service Principal Name, SPN) registriert. Dies geschieht normalerweise, weil die IP-Adresse anstelle des Hostnamens des Clientzugriffs-Zielservers in der "internalURL"-Konfiguration für das virtuelle Outlook Web App-Verzeichnis auf dem Clientzugriffs-Zielserver verwendet wurde. Die Konfiguration von "internalURL" für den Clientzugriffs-Zielserver kann mithilfe der Exchange-Administratoraufgabe "Set-OwaVirtualDirectory" geändert werden. Wenn Sie die "internalURL"-Konfiguration für das virtuelle Outlook Web App-Verzeichnis auf dem Clientzugriffs-Zielserver nicht ändern möchten, können Sie auch das Tool "setspn.exe" auf dem Clientzugriffs-Zielserver ausführen, um zusätzliche SPNs zu registrieren, für die der Clientzugriffsserver die Kerberos-Authentifizierung akzeptieren soll. 
2.Der Server, auf dem '%2' gehostet ist, ist möglicherweise nicht für das Akzeptieren von Kerberos-Authentifizierung konfiguriert. Möglicherweise ist er für die Verwendung der integrierten Windows-Authentifizierung für das virtuelle Outlook Web App-Verzeichnis konfiguriert, jedoch für die integrierte Windows-Authentifizierung nur für NTLM (nicht jedoch Kerberos) konfiguriert. Wenn Sie hier die Ursache des Problems vermuten, finden Sie weitere Schritte zur Problembehebung in der IIS-Dokumentation.