Es gibt einen Technet Artikel, der wohl (noch) eine falsche Information enthält:
http://technet.microsoft.com/en-us/library/bb310763.aspx
Darin steht:
If an Active Directory site is the target of an Outlook Web App or ECP proxy request from a Client Access server in any other Active Directory site, the InternalURL property for the /OWA and /ECP virtual directories on all Client Access servers in that Active Directory site must be set to the FQDN of the server. This is because Outlook Web App and the ECP use only Kerberos authentication, which will fail if the InternalURL property is set to a load-balanced value. Client Access server applications such as Outlook Web App and the ECP ignore the certificate settings when they perform proxy connections between Client Access servers. Therefore, individual server names on the certificate aren't needed for proxy purposes.
Das würde bedeuten, dass die InternalURL eines “Target-CAS” auf den Server FQDN gesetzt werden muss. Das wiederum hieße, dass die Target-Site nicht hochverfügbar ausgelegt werden könnte, da in diesem Fall die InteralURL auf die Loadbalancer URL gesetzt werden muss. Das ist aber falsch. Aber der Reihe nach:
Angenommen eine Firma hat nur einen Internet Break-Out für die weltweite Organisation. Man möchte z.B. nur mit einem Namespace für OWA (ActiveSync, etc.) nach aussen auftreten. Man wird also in der Hauptlokation, sagen wir mal, Frankfurt, ein CAS Array aufbauen und das durch einen (Hardware-) Loadbalancer ausfallsicher machen. Gehen wir mal davon aus, dass es nun noch eine weitere Niederlassung des Unternehmens in USA gibt. Auch dort möchte man eine ausfallsichere Infrastruktur aufbauen. Das bedeutet, dass man auch dort ein CAS Array installiert und ihm ein Hardwareloadbalancer vorschaltet. Um das ganze zum Fliegen zu bringen, muss man die InternalURL der CAS Server auf die URL des Loadbalancers setzen.
Eben dies “untersagt” aber der Technet Artikel, den ich oben zitiert habe. Wie gesagt, das würde bedeuten, dass eine “Proxy-Site” (für OWA und ECP) niemals hochverfügbar sein kann.
Warum ist das zwingend so das laut dem Technet Artikel die InternalURL auf den FQDN des Servers gesetzt werden muss? Microsoft begründet das mit einem Kerberos Problem. Kerberos braucht zwingend den FQDN des Zielservers.
Da ich in einem Projekt exakt dieses Problem habe, habe ich mal bei Microsoft nachgefragt und als Antwort erhalten, dass dies (was in dem Technet Artikel steht) nun nicht mehr zutreffen würde. Man könne auch in einer Proxy-Site, die InternalURL auf die des Loadbalancers setzen. Wenn Kerberos fehlschlägt, springt Exchange 2010 automatisch auf NTLM zurück.
Schaun wir mal wann der Artikel geändert wird …
Kommentare:
Was hindert jemand daran, auf einem CAS Array auch Kerberos zu aktivieren ?. Das geht seit Exchange 2010 SP1 relative einfach. http://technet.microsoft.com/en-us/library/ff808312.aspx und andere. dann sollte das alles auch kein problem mehr sein. und besser ist es eh
Ja, guter Hinweis. Nachdem der Technet-Artikel von dem ich schreibe wohl nicht mehr gültig ist, dürfte nun die ASA Geschichte funktionieren ...
Kommentar veröffentlichen