Exchange 2007 Kalender Federation

Die Federation mit Exchange 2010 wurde anders gelöst, so dass auch keine Kontakte, Trusts und Dienstkonten mehr erforderlich sind. Sie können aber weiterhin auch diese "alte" Verbindung konfigurieren.

Cross Org Availability using Federation Trust and Organization Relationship
http://blogs.technet.com/b/exchange/archive/2011/06/28/cross-org-availability-using-federation-trust-and-organization-relationship.aspx

Aktuell scheint die Verbindung immer nur dann zu gehen, wenn die CAS-Server direkt miteinander kommunizieren können. Auch wenn es viele Hinweise gibt habe ich noch keinen Weg gefunden, dass der CAS-Server einen HTTP-Proxy nutzt und schon gar nicht wie er sich daran anmelden kann. (Eventuell Computername$).
Es sollte möglich sein, wenn eine Firewall eine direkte Verbindung über einen Proxy leitet.

Exchange 2007 war die erste Version, welche direkt eine Verbindung zwischen zwei Organisationen für Frei/Belegt-Zeiten erlaubt. Schlüssel sind hierzu ein paar Konfigurationen und eine Verbindung der CAS-Server. Ein Outlook 2007 oder höher erfragt dann von einem CAS-Server die Frei-Belegt-Zeiten, die diese dann normalweise aus den Postfächern der eigenen Organisation direkt oder mit Hilfe eines weiteren CAS-Servers in dem Standort der Mailbox ermittelt. Zwischen verschiedenen Exchange Organisationen ist dies aber ebenfalls möglich, wenngleich die Administratoren hierzu etwas konfigurieren müssen.

Trusted oder untrusted

Microsoft unterscheidet bei Exchange 2007 zwei Betriebsarten:

  • Nicht vertraute Forests
    Dabei gibt es keine Windows Vertrauensstellung oder Kopplung zwischen den beiden Forests. In dem Fall kann es nur ein generische Einrichtung geben, bei der alle Frei/Belegt-Zeiten unabhängig vom anfragenden Benutzer "gleich" zurück gegeben werden
  • Forest mit Trust
    In dem Fall kann ein Exchange Server auch das anfragenende Konto dank dem Trust überprüfen und abgestuft die Antwort liefern. Hierzu sind aber weitere vorarbeiten notwendig, z.B. der Export des "Service Connection Point" in einer Organisation und der Import in der anderen Organisation. Dann kann der Zugriff über Sicherheitsgruppen gesteuert werden.

Im folgenden beschreibe ich Verbindung zweiter Forests ohne Vertrauensstellung. Die Verbindung von Forests über eine Vertrauensstellung erfordert eine interne VPN-Verbindung und macht einige Einstellungen einfacher (z.B. Autodiscover), die hier das große Thema sind.

Die weitere Beschreibung geht davon aus, dass es keinen Trust gibt und nur die CAS-Server miteinander kommunizieren und die Kontakte bereit gestellt wurden.

Funktionsweise

Schauen wir uns an einem Schaubild mit Exchange 2007 einmal an, wie ein Anwender auf der linken Seite seinen CAS-Server fragt, und dieser dann "irgendwie" über Server im Ziel die Daten besorgt.

Folgende Punkte sind dabei zu beachten. Der Einfachheit halber beschreibe ich nur eine Richtung. Wer dies auf Gegenseitigkeit einrichten will, muss die Arbeit doppelt machen. Hier noch ein Ablaufdiagramm der Abfrage eines Clients:

Dieses Bild ist besonders bei der Fehlersuche hilfreich, da z.B. die DNS-Abfragen auch mit NETMON oder mit "IPCONFIG /DisplayDNS" gesehen werden können. Die ganzen IIS-Abfragen kann man auch bei verschlüsselten Verbindungen (HTTPS) im IIS-Log des Zielservers erkennen oder in der Firewall als direkte Verbindung. Denn sonst gibt es fast keine direkten Verbindungen zwischen CAS-Servern, die ihre Analyse stören könnten.

Einrichtung Seite1: der Freigebende

Zuerst muss die Exchange Organisation, die ihre Frei/Belegt-Zeiten einer anderen Organisation bereitstellen will, ein paar Voraussetzungen erfüllen. Diese sollten vorab gewährleistet sein:

Beschreibung Status

Eindeutige Routingdomäne

Die später anfragenden Systeme müssen per Autodiscover und eine eindeutig ihrer Organisation zugeordnete SMTP-Domäne sie finden. Das ist kein Problem zwischen Firmen, die ansonsten getrennt sind.

Anders sieht es aus, wenn Sie mehrere Exchange Organisationen betreiben, die einen gemeinsamen Adressraum nutzen. Die für die Frei/Belegt-Anzeige sowieso erforderlichen Kontakte auf der "anderen Seite " müssen mit einer "TargetAddress" versehen sein, die auch als Ziel für die Frei/Belegt-Anfrage dient.

Die TargetAdress muss nicht die primäre Adresse des Empfängers sein. Es reicht diese als sekundäre Adresse zu haben. Sie können so eine Adress auch per PowerShell direkt ohne Änderung der Empfängerrichtlinien addieren. Weil die Exchange 2010 PowerShell die Verkettung zweier Piplines oft verhindert. Und ich die Liste der betroffenen Konten gerne kontrolliere, nutze ich eine Variable als Zwischenspeicher.

$mblist = get-mailbox
$mblist | %{ `
   Set-Mailbox `
      -Identity $_.identity `
      -EmailAddresses @{add=("SMTP"+$_.alias+"@routingdomain.tld")}}

Der Alias ist innerhalb einer Organisation in der Regel eindeutig und daher ideal geeignet. Der Get-Mailbox kann natürlich über "-organizationalunit xxxx" und andere Kriterien gefiltert werden. Wenn sie mehr als 1000 Objekte erwarten, sollten Sie ein "-resultsize unlimited" anhängen. Mehrere Domänen werden mit einem "-IgnoreDefaultScope"-Parameter durchsucht.

Autodiscover für Partner

Für die gewählte eindeutige Routingdomäne muss natürlich auch Autodiscover funktionieren. Und da die Exchange CAS-Server hier keine SRV-Records o.ä. Unterstützten müssen Sie:

  • DNS-Eintrag "autodiscover.<routingdomain>"
    Den müssen Sie anlegen oder die anfragende Stelle muss mit PinpointDNS-Zonen oder HOSTS-Einträgen auf deren CAS-Server arbeiten
  • SSL-Zertifikat für ""autodiscover.<routingdomain>"
    Natürlich muss der später anfragende CAS-Server einen Zugriff auf https://autodiscover.<routingdomain> nutzen können. Wer erst später beim Zusammenschluss von Firmen eine neue Routingdomain einführt, wird also das Zertifikat erweitern müssen.
  • Veröffentlichung
    Zudem muss der anfragende CAS-Server die URL über Internet oder intern überhaupt erreichen können. Das kann ein ReverseProxy sein oder auch einfach nur eine interne Firewall.

Lassen Sie ihren Gegenüber den Zugriff auf "autodiscover.<routingdomain> von dessen CAS-Server überprüfen,

Dienstkonto anlegen

Da eine Abfrage nie anonym möglich ist, muss der Administrator in der Organisation, die ihre Informationen bereitstellen will, ein Dienstkonto anlegen. Dieses Konto benötigt nur minimalste Rechte, d.h. selbst Domain Benutzer ist schon viel. Es benötigt auch kein Postfach. Es dient dem CAS-Server einfach dazu, die Gültigkeit der Anforderung zu prüfen. Das Kennwort sollte ausreichend komplex sein aber sollte nicht geändert werden müssen und nicht ablaufen.

Wenn mehrere Firmen ihre Frei/Belegt-Zeiten abfragen, werden alle Firmen das gleiche Benutzerkonto nutzen.

Prüfung: Melden Sie sich im Ziel an einem PC mit dem Benutzer und Kennwort an. Später können Sie im Security Eventlog und IISLog sehen, dass die andere Exchange Organisation sich anmeldet.

Tipp
Die andere Organisation benötigt ihre Postfächer als Kontakte. Wenn es eine Netzkopplung gibt, kann die andere Firma das gleiche Konto nutzen, um die Kontakte auszulesen.

Dienstkonto in Exchange eintragen

Dieses Konto muss in Exchange dann noch eingetragen werden, damit der CAS-Server Anfragen dieses Benutzers per EWS auch beantworten kann

Set-AvailabilityConfig -OrgWideAccount domain\serviceaccount"

Das Konto benötigt KEIN Postfach und muss in keinster weise privilegiert sein. Überprüfen die die korrekte Eintragung mit:

Get-AvailabilityConfig | fl

Kontrollieren sie zur Sicherheit auch noch mal die Schreibweise. Es muss genau passen.

The second example of the Set-AvailabilityConfig command is useful if the remote forest is not trusted. When you are prompted, type the user name and password. Because this account is used für a cross-forest free/busy proxy account or group, minimize security vulnerabilities by using the credentials of a user who does not have an Exchange mailbox
Quelle: http://technet.microsoft.com/en-us/library/bb124103(EXCHG.80).aspx

42 Tage und 62 Tage

Exchange 2007 fragt per Default die Frei/Belegt-Zeiten der nächsten 42 Tage ab. Exchange 2010 hat diesen Zeitraum auf 62 Tage erweitert. Stellt nun ein Exchange 2010 Server eine Anfragen an einen Exchane 2007 Server so lehnt dieser ab, wenn mehr als 42 Tage in die Zukunft angefordert werden. Eine kleine Anpassung an der Konfiguration von Exchange 2007 löst das Problem. Editieren Sie dazu die web.config in "<Exchange-Installationspfad>\V14\ClientAccess\ExchWeb\EWS\web.config"

<appSettings>
    <add key="maximumQueryIntervalDays" value="62" />
</appSettings>

Damit sollte auf der Seite es Anbieters auch schon alles erledigt sein.

Einrichtung Teil2: Der Anfragende

Die Organisation, die ihrerseits die Frei/Belegt-Zeiten einer anderen Firma abfragen will, muss natürlich auch einige Einstellungen vornehmen.

Beschreibung Status

Add-Availability

Auf der Seite der anfragenden Organisation muss natürlich eingetragen werden, dass der Zugriff auf die Frei-Belegt-Zeiten der entsprechenden Domain per Federation erlaubt ist. Weiterhin müssen hier die von der anderen Seite als Dienstkonto bereitgestellten Anmeldedaten erfasst werden.

# Erfassen der Anmeldedaten einmalig interkativ
$cred = get-Credential

# Anlegen der Federation.
Add-AvailabilityAddressSpace `
   -ForestName netatwork.de `
   -AccessMethod OrgWideFB `
   -Credentials $cred

Wenn Sie keine direkte Kopplung über die CAS-Server betreiben, dann können Sie auch weiter wie früher die öffentlichen Ordner replizieren. (Siehe auch IOREPL. Dann lautet der Befehl etwa:

Add-AvailabilityAddressSpace `
   -ForestName <Domainname> `
   -AccessMethod PublicFolder

Viel testen können Sie hier noch nicht. Allerdings können Sie die konfigurierten Domänen mit "Get-AvailabilityAddressSpace" auslesen. Zudem sollten Sie natürlich entsprechende Latenzzeiten im AD und LDAP-Caches in Exchange berücksichtigen. Es kann also etwas dauern, bis die Einstellungen wirken.

Kontakt anlegen

Wenn später ihr Outlook ihren Exchange Server befragt, dann schaut der CAS-Server zuerst nach, ob es denn auch einen passenden Kontakt im Active Directory gibt. Damit wird z.B. verhindert, dass jemand auch "wild" adressiert. Allerdings muss der Kontakt nicht per MIIS oder GalSync angelegt werden, wie Microsoft das beschreibt. Es ist einfach nur ein "normaler Kontakt" (MailContact oder MailUser) der als TargetAddress die richtige SMTP-Adresse hat.

Sie können diesen Testweise natürlich auch manuell über die Exchange Management Console oder Shell oder jedem anderen Werkzeug zum Adressbuchabgleich anlegen. Ein Kontakt ist aber auch noch aus anderer Hinsicht interessant:

If Exchange 2007 is unable to match the incoming e-mail to an item in the GAL, it will not process the meeting request.
Quelle: hhttp://social.technet.microsoft.com/Forums/exchange/en-US/ec8982ae-1ed5-4814-9037-f1d7eb2327b5/autoaccept-from-external-address-not-working?forum=exchangesvrgenerallegacy

Prüfen Sie, ob der Kontakt nach einiger Zeit in Outlook und OWA auswählbar ist. Die Sichtbarkeit in Outlook kann etwas dauern, wenn sie mit dem Cached Mode arbeiten. Daher ist OWA der bessere Test. Zudem sollten Sie natürlich entsprechende Latenzzeiten im AD und LDAP-Caches in Exchange berücksichtigen. Es kann also etwas dauern, bis die Einstellungen wirken. Bei Outlook im Cached Mode werden die Kontakte erst nach dem nächsten OAB-Gen und Download sichtbar.

CAS Zugriff, Proxy, Firewall

Damit der CAS Server nun die Frei/Belegt-Zeiten ermitteln kann, muss er per HTTPS auf den anderen CAS-Server zugreifen können. Leider nutzt der Exchange CAS erst mal keine HTTP-Proxy-Einstellungen und Authentifizierungen.

  • Namensauflösung
    Der CAS-Server muss die anderen Exchange Server auflösen können, d.h. autodiscover und die als "ExternalURL" zurückgelieferten URLs.
  • Firewall/Proxy
    Und dann muss er per HTTPS die Ziele auch erreichen können. Am einfachsten ist es somit, wenn der CAS direkt z.B. per NAT auf die bekannten Ziele zugreifen kann.

Damit sollte die Einrichtung im groben erfolgt sein.

Funktionstest auf dem Client

In den meisten Fällen geht es aber dennoch nicht, so dass Sie Schritt für Schritt nachprüfen müssen, ob alles geht und wo es klemmt. Die kurze Stichpunktliste soll ihnen dabei helfen, Schritt für Schritt die Stationen abzulaufen und etwaige Fehler zu finden.

Hinter dieser Checkliste finden Sie weitere Kapitel, die einzelne Prüfungsschritte ausführlicher erläutern

Prüfung Status

Einladen in Outlook

Start ist eine Besprechungseinladung auf einem Outlook 2007 oder höher-Client, bei der ihr externe Kontakt eingeladen wird

  • Ist der Kontakt im Adressbuch vorhanden ?
    Wenn nicht, dann muss ihr Administrator den Kontakt als "MailContact" oder "MailUser" anlegen.
  • Ist die "Zieladresse" korrekt ?
    Schauen Sie sich die SMTP-Adresse des Kontakt an.
  • OWA statt Outlook
    Wenn Sie "nur" Outlook2003 haben oder EWS vielleicht nicht sauber funktioniert, dann können Sie auch mit OWA den Termin planen und damit Probleme auf dem Client ausschließen.

Der erste Aufruf kann durchaus einige Sekunden dauern. Warten Sie in der Terminübersicht, bis aus dem grauen Balken ein gestreifter Balken wird oder die Belegt-Zeiten angezeigt werden.

Mit Tools wie Fiddler können sie auf dem Outlook Client die WebService-Anfragen nachverfolgen. Ich hatte so z.B. schon mal das Problem analysiert, wenn der Benutzer in sehr vielen Gruppen Mitglied ist und daher das Ticket über 100kByte geworden ist.

  • 2491354 You cannot view the free/busy information of users in a mixed Exchange Server 2007 and Exchange Server 2010 environment

Suche auf dem CAS-Server

Wenn die Besprechungsplanung auf dem Client problemlos möglich ist aber die Abfrage der Frei/Belegt-Zeiten erfolglos ist, dann müssen Sie auf dem CAS-Server weiter schauen.

Hinweis:
Wer mehrere CAS-Server mit Loadbalancer hat, muss erst ermitteln, auf welchem CAS der Client agiert. Wenn der Loadbalancer eine Source-IP-Affinität nutzt, dann brauchen Sie nur einmal unter OWA die Information anzuzeigen um den CAS-Server zu wissen. Andere Administratoren legen sich eine Testdatei auf den IIS mit dem echten Servernamen, um so schnell den aktiven CAS zu finden und nebenbei über diese HTML-Datei auch einen Verfügbarkeitscheck zu erlauben.

Gegen wir davon aus, dass der Client seine Anfrage an den Exchange CAS-Server gestellt hat, der Kontakt vorhanden und die Domäne mit "Add-AvailabilityAddressSpace" addiert wurde. Dann wird der CAS erst eine Autodiscover-Anfrage stellen und dann mit der Antwort die Webservices der anderen Seite ansprechen. Auch dieser Prozess kann Schritt für Schritt nachgeprüft werden:

Prüfung Status

IPCONFIG /Displaydns

Suchen Sie nach dem Einträge zu "autodiscover.<routingdomäne>" um zu sehen, ob und wenn ja, welche Antwort der CAS bekommen hat. Ist hier kein Eintrag, dann hat der CAS noch nie gefragt.

  • Wiederholen Sie die Clientanfrage z.B. mit OWA
  • Ist die Domain wirklich "eingetragen"
  • Gibt es den Kontakt und ist seine TargetAddress richtig ?
  • NSLookup
    Liefert eine Abfrage per NSLOOKUP die korrekte Antwort? Kontrollieren Sie auch eventuelle alte Einträge in der HOSTS oder nutzen sie ersatzweise die Hosts um DNS-Probleme temporär zu umgehen

Autodiscover Zugriff

Wenn die DNS-Anfrage raus ist, dann sollten Sie prüfen, ob der Zugriff funktioniert. Starten Sie auf dem CAS einfach mal einen Browser und gehen sie auf https://autodiscover.<routingdomain>/autodiscover/autodiscover.xml und prüfen Sie

  • SSL-Verbindung kommt zustande ?
  • Zertifikat: Name gültig (CN oder SAN)
    d.h. hat die andere Seite auch autodiscover.<routingdomain> im Zertifikat ?
  • Zertifikat: Aussteller vertrauenswürdig ?
    Das ist insbesondere ein Thema bei der Verbindung von Firmen untereinander, die ein VPN nutzen und daher intern zugreifen. Intern kommen oft Zertifikate einer privaten CA zum Einsatz.

Eventlog

Aktivieren Sie auf dem Exchange CAS-Server die Diagnoseprotokollierung auf den "Availibilty Service". Sie sollten dann im Anwendungseventlog etwaige Fehler finden.

Netmon/Firewall

Wenn der Zugriff per HTTPS möglich ist, dann können Sie mit NETMON o.ä. oder auf der Firewall schauen, ob der CAS-Server einen Zugriff auf den anderen CAS-Server versucht. Ein Filter auf die TargetIP oder "tcp.DstPort==443" helfen, um ausgehende Verbindungen per HTTPS zu ermitteln.

IISLog/FREB

Wenn Sie ausgehende Verbindungen erkennen können, dann ist mit SSL kaum beizukommen, was da passiert. Nun sollten Sie den Administrator auf der anderen Seite mit ins Boot holen. Er kann sehen, auf welchem Webserver die Anfragen ankommen und dann im IISLog/LoadbalancerFirewall sehen, wie die Anfrage beschieden wird. Mit dem IIS als Backend kann der Administrator mittels FREB (IISDebugging) auf das Verzeichnis Autodiscover gehen, um die Anfrage und deren Antwort entschlüsselt zu analysieren

Eventlog auf der Gegenseite

Auch hier sollte im Security-Eventlog in der Regel die erfolgreiche Anmeldung gesehen werden. Vielleicht ist es ja nur ein falsch eingegebenes Kennwort bei "Add-AvalibilityAddressSpace"

EWS-Funktion

Wir nehmen mal an, dass nun der CAS-Server einen gültigen "Autodiscover"-Eintrag bekommen hat. Der Exchange Server holt sich aus der XML-Antwort die "ExternalURL" der Exchange Webdienste ihres Partnerunternehmens und versucht über diese URL dann die Frei/Belegt-Daten für den Anwender zu bekommen. für diese URL können die gleichen Schritte wie bei Autodiscover wiederholen.

Ein HTTPS-Zugriff auf die vorgeblichen Webadressen samt Servicekonto und Kennwort sind ein erster Test. Wer mag kann auch https://www.testexchangeconnectivity.com/ verwenden.

Es ist als schon etwas mehr, als was Microsoft so "kurz" mal in der Dokumentation mit wenigen Zeilen beschreibt. Vor allem die Fehlersuche ist nicht ganz trivial, da unterschiedliche Komponenten zusammen greifen.

Fun und Stress mit Autodiscover und EWS ASURL

Ein CAS-Server nutzt die Funktion über Autodisover, um die URL für den Zugriff auf die Web-Services zu erhalten. dazu muss man gleich mehrere Einschränkungen können:

  • Keine statische Konfiguration
    Anders als auf einem Outlook Client kann man keine XML-Datei hinterlegen, in der die Autokonfiguration vorgegeben ist.
  • Keine SRV-Records
    OutOutlook 2007 und 2010 unterstützen neben "autodiscover.domain.tld" auch die Anfrage nach "_autodiscover._tcp.domain.tld". Das funktioniert nicht beim CAS-Server

DNS Service Location (SRV) records do not work to locate the Autodiscover service to an Exchange 2007 Client Access server in a cross-forest scenario.
Quelle: http://technet.microsoft.com/en-us/library/bb125182(EXCHG.80).aspx

  • InternalURL
    Fast unbemerkt ist eine Aussage in dem gleichen Dokument, welches beschreibt, dass Exchange aus der Autodiscover-Antwort die "InternalURL" für den folgenden EWS Zugriff nutzt. Das ist natürlich komplett der falsche Ansatz, da ich bei Federation in den seltensten Fällen "intern" bin, mal abgesehen von dem Fall, dass zwei Organisationen ein VPN sharen und bald migriert werden wollen.

Autodiscover will return the Availability InternalURL to the Exchange 2007 Client Access Server.
Quelle: http://technet.microsoft.com/en-us/library/bb125182(EXCHG.80).aspx

  • Timeout = 10 Sekunden
    Der CAS-Server wartet maximal 10 Sekunden, ehe er aufgibt und dem Client einen Fehler liefert.

If the Autodiscover request does not finish in 10 seconds, the Availability service request für the cross-forest user may time out
Quelle: http://technet.microsoft.com/en-us/library/bb125182(EXCHG.80).aspx

  • Zertifikate
    By Default prüft natürlich der Exchange CAS als "SSL-Client" auch die Gültigkeit der Zertifikate. Wer also mit einem Proxy samt SSL-Inspection arbeitet oder wenn die Gegenstelle nicht Selbstzertifikaten arbeitet, m��������ssen Sie noch etwas nach bessern.
  • Firewall und Zugriff nur über Proxy
    Speziell größere Firmen möchten nicht, dass ein Server "ungesichert" direkt per Port 443 auf Webserver im Internet zugreift. Sicher können Sie in Firewalls die Zieladressen reglementieren aber der Einsatz von NAT ist schon verpönt, so dass der CAS auch darauf getrimmt werden muss, über einen Proxy zu gehen.

Es gibt also durchaus einige Stolpersteine bei der Umsetzung einer Kalender-Federation.

Bug: InternalURL bei EWS

Wenn ein CAS Server per Autodiscover von einem anderen Server sich die XML-Datei holt, dann übernimmt er leider die "InternalURL", welcher bei den WebServices hinterlegt ist. Diese ist in der Regel nicht von extern nutzbar. Faktisch funktioniert damit die Free/Busy-Federation nicht, es sei denn wir bauen uns eine Brücke. Die beste Lösung wäre natürlich, wenn Microsoft in Exchange das Verhalten ändern (z.B. auf ExternalURL) oder konfigurierbar machen würde. Aber davon ist nicht zu sehen, also geht es darum diese Problematik zu umschiffen. Und dazu gibt es gleich eine ganze Menge von möglichen Optionen, von denen alle vermutlich ihren Charme aber auch Nachteile haben.

Was Wer Beschreibung

VPN

Beide

Dies ist ideal, wenn die beiden Exchange Organisationen schon eng zusammen arbeiten wollen und es eine interne Netzwerkkopplung gibt, weil sowieso migriert werden soll. Dann stellt sich aber die Frage, ob man dann nicht besser den später sowieso erforderlichen Trust einrichtet und nicht die anonyme Federation nutzt.

Aber über diesen Weg könnte ein Server auch den CAS-Server der anderen Organisation über die "InternalURL" kommen und es stört also nicht mehr, dass Exchange leider die "InternalURL" nutzt.

InternalURL = ExternalURL

Ziel

Das Problem löst sich natürlich auch in Wohlgefallen, wenn die InternalURL und ExternalURL auf die gleichen Werte gesetzt werden. Das bedeutet natürlich, dass in dieser Exchange Organisation auch von intern der Exchange Server sicher erreicht werden muss und auch das Zertifikat entsprechend "passt".

Wer allerdings keinen "Split-DNS" betreibt, sollte verhindern, dass die internen Anwender über den Proxy dann wieder von Extern auf Exchange zugreifen und dabei die integrierte Anmeldung gestört wird oder sogar noch starke Authentifizierungen zu bewältigen sind. Beim einem SplitDNS können Sie den öffentlichen Namen von intern natürlich auf die interne IP-Adresse lenken. Alternativ können Sie über Proxy-Ausnahmen (z.B.: Zentral über WPad gesteuert die Clients umlenken.

Unschön wäre aber ein "Hosts" Eintrag auf jedem Client, da der zuverlässig die Verbindung von extern für den Client (Outlook über HTTP) unterbinden würde.

Hosts

Anfrager

Wenn der anfragende CAS-Server schon die internal URL bekommt, dann könnten wir mit HOSTS oder passenden DNS-Einträgen einfach dafür sorgen, das der CAS auch mit dieser URL den "richtigen" CAS der anderen Organisation erreicht.

Wenn die URL also "http://server.firma.intern" lautet aber extern als "owa.firma.de" unter der IP-Adresse 1.2.3.4 zu erreichen , dann könnte auf dem anfragenden CAS ja ein Eintrag "server.firma.intern A 1.2.3.4" stehen. Der Server kann dann das Ziel doch erreichen (Beim Einsatz eines HTTP-Proxy muss der Eintrag auf dem Proxy erfolgen.)

Allerdings wird dann natürlich das Zertifikat vermutlich nicht passen, wenn welche Firma bindet schon "server.firma.intern" auf ein öffentliches Zertifikat. Aber auch hier kann man den CAS anweise, solche unstimmigkeiten zu ignorieren, was aber zulasten der Sicherheit geht.

Wenn die veröffentlichende Firewall aber z.B. den Servername im "Hostheader" überprüft, dann muss auch der andere Administrator dies noch zulassen. dass Anfragen an server.firma.intern, die auf der externen offiziellen Adresse von owa.firma.de ankommen auch an den CAS intern weiter gegeben werden.

XML-Linktranslation

Proxy/Firewall

Wenn der anfragende Server vom Ziel eine "autodiscover.xml" bekommt, dann können verschiedene Systeme auch hier drin den Inhalt ändern. Zwar ist die Verbindung in der Regel SSL-verschlüsselt aber ein guter Proxy oder Publishing-Server kann solche Dinge trotzdem ändern. Die XML-Datei selbst ist nicht durch eine digitale Signatur geschützt.

Ein ISA/TMG-Server kann z.B. im Inhalt einer abgefragten Webseite intern Links auch umschreiben. Das ist z.B. wichtig, wenn eine interne Webseite von extern mit einem anderen Namen erreichbar ist. Würden dann Links in diesen Dokumenten auf den internen Namen verweisen, kann der ISA diese umschreiben.

By default, the link translation filter operates only on Web responses that include a MIME or file type specified in the HTML Documents content type. By default, the HTML Documents content type specifies the MIME types text/css, text/html, and text/webviewhtml, and the file extensions .htm, .html, .htt, .stm, and .xsl.
http://technet.microsoft.com/en-us/library/cc441600.aspx

Trotzdem ist dies natürlich schon nicht ganz einfach und kann andere Seiteneffekt mit sich bringen, die sehr schwer zu diagnostizieren sind.

Fake Autodiscover

Ziel

Nun könnten Sie auf den Gedanken kommen, als Anbieter den Autodiscover-Dienst einfach nicht auf Exchange zu leiten sondern selbst eine Fake-Seite mit einer vorbereiteten XML-Datei. Hier können Sie dann natürlich die "InternalURL" der ASURL richtig vorgeben. Allerdings fehlt dabei natürlich jede andere Funktion von Autodiscover. Und gerade Outlook Clients im Internet nutzen Autodiscover nicht nur um die Zugangspunkte für OAB, EWS, RPC etc. zu erlangen, sondern auch die Information über den HomeServer zu erhalten. Das kann so eine einfache Lösung nicht bereit stellen. Dieser Weg dürfte daher nicht gangbar sein.

Fake Autodiscover

Anfrage

Einfacher umzusetzen ist so eine gefälschte Autodiscover-Seite natürlich auf der Seite des Anfragers mit dem Ziel, nur den CAS auszutricksen. Ein einfacher Webserver pro Domain auf einer eigenen IP-Adresse mit einer XML-Datei und passendem "Hosts-Eintrag" auf dem CAS-Server und eine Ausnahme in der Proxykonfiguration des CAS reicht aus, damit der CAS bei der Anfrage die lokale XML-Datei "schnell" bekommt und dann die dort hinterlegte InternalURL für die eigentliche Anfrage verwendet.

Nachteil ist hier aber, dass eine Änderung der echten URL auf der anderen Seite natürlich nicht lokal aktualisiert wird. Die Funktion bricht bis der Admin auf der anfragenden Seite die "richtige URL" wieder in seine Fake-XML-Datei eingetragen hat.

Einen Ratschlag, welche Lösung die beste ist, kann ich ihnen nicht geben. Elegant ist natürlich, wenn InternalURL und ExternalURL identisch sind, wenn die DNS- und Proxy-Konfiguration dies zulässt. Wenn von der anderen Seite keine Mithilfe zu erwarten ist, dann kann man nur mit einem lokalen "Fake-Autodiscover" arbeiten.

Leider können ich keinen Weg, analog zu Outlook eine XML-Datei einfach auf dem Dateisystem abzulegen und über die Registrierung zu hinterlegen.

Konfiguration SSL Zertifikat

Der CAS-Server prüft die Zertifikate der Gegenstelle. Nun wissen Sie ja schon, dass die "InternalURL" für die Federation genutzt wird und wie man dieses "Problem" umgehen kann. Wenn nun auf der Gegenseite aber kein passendes Zertifikat zu dem verwendeten Namen zur Verfügung steht, dann kann diese Zertifikatsprüfung auf der Seite des Anfragenden angepasst werden

Achtung
Sie verlieren damit natürlich die Sicherheit, dass die Verbindung nicht umgelenkt wird und in so einem Fall jemand die Anmeldedaten des Dienstkonto beim Ziel in Erfahrung bringen kann. Es sollte also durchaus im Interesse des Ziels sein, einen "richtigen" Namen zu liefern oder das Zertifikat um den Namen zu erweitern.

Die Einstellungen selbst werden auf dem CAS-Server per REGEDIT gemacht, welcher die Anfrage über das Internet nach draussen stellt.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA]
"AllowInternalUntrustedCerts"=dword:00000001
"AllowExternalUntrustedCerts"=dword:00000001

Hinweis: In einigen Dokumenten wird "MSExchangeOWA" zusammen geschrieben, was aber falsch ist.

Konfiguration Proxy für Zugriff auf das Internet

Normalweise versucht der CAS die Gegenseite immer direkt zu erreichen. Das kann man auch gut mit NETMON nachvollziehen. In vielen Firmen kann der Server aber nicht direkt nach draußen, sondern muss einen Proxy verwenden. Administratoren stellen dies gewöhnliche wie folgt für "Local Machine" ein.

REM Bis Windows 2003
ProxyCFG -u

REM ab Windows 2008
netsh winhttp set proxy 192.168.100.21:8080 bypass-list=lokaler_Domänenname

REM Anzeigen
netsh winhttp show proxy

Normalerweise nutzen auch .NET Anwendungen und z.B.: ASPX-Anwendungen den Proxy von "Local System".

Exchange 2007 CAS/Availability Service scheint sich darum nicht zu kümmern und versucht trotzdem per DNS "autodiscover.remotedomain" aufzulösen und direkt zu erreichen.

Aber es ist durchaus möglich, auch den Proxy in der Machine.config oder in der web.config zu hinterlegen

<configuration>
  
<system.net>
     
<defaultProxy>
        
<proxy
           
autodetect = "false"
            usesystemdefault = "false"
            proxyaddress = "http://proxy:8080"
            bypassonlocal = "true"
         />
         <bypasslist>
             <add address="http://[a-z]+\.firma\.local/" />
             <add address="https://[a-z]+\.firma\.local/" />
         </bypasslist>
      </defaultProxy>
  
</system.net>
</configuration>

Beachten Sie, dass Sie in der bypass-Liste auch z.B. HTTPS und andere URLs addieren, die nicht über den Proxy gehen dürfen. Es ist ein nicht seltener Fehler, dass dabei HTTPS vergessen wird. Ansonsten versuchen Sie Dienste vielleicht zu viele Systeme über den Proxy im Internet zu suchen.

Die Web.config ist in zwei Verzeichnissen zu erweitern:

C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews
C:\Program Files\Microsoft\Exchange Server\ClientAccess\Autodiscover

Danach ist ein IISReset erforderlich.

Fehlersuche mit Test-OutlookWebSerives

Ein Werkzeug zur Fehlersuche ist das PowerShell Commandlet. "Test-OutlookWebServices". Damit kann man nicht nur die Webservices für einen lokalen user testen, sondern ebenso solche Federation-Zugriffe.

 Die Fehlersuche ist bei Kalender Federation etwas knifflig, da viele Komponenten zusammen spielen und SSL eine wesentliche Rolle spielt. Mitschneiden per Netmon ist da zudem nicht mehr so einfach. Insofern müssen Sie sich die Kette von Anfrager bis zum Zielpostfach vor Augen führen, um an den verschiedenen Stellen nach Fehlern oder Erfolgen zu suchen:

test-outlookwebservices -targetaddress user@anderedomain.tld | fl

Es kommt eine ganze menge von Tests zusammen, von denen ich hier einige Fehler mal wiedergebem

Bei Test-OutlookWebService sieht man auch, dass eine ungültige Adresse nicht genutzt wird.

Kontakt fehlt oder ist nicht korrekt

Id         : 1111
Type       : Error
Message    : Receipent address user-ohne-kontakt@remotedomain.de is invalid. Please check your command parameters.
Id         : 1111
Type       : Error
Message    : When querying Availability für frank@cariustest.de received ErrorProxyRequestProcessingFailed:Unable to send c
             ross-forest request für mailbox <Frank Carius (test)>SMTP:frank@cariustest.de because of invalid configuration
             ., inner exception: Configuration information für forest/domain carius.de could not be found in Active Dir
             ectory.

Manchmal liegt es aber auch einfach an der AD-Replikation und dem DS-Cache des Exchange Servers. Warten Sie vielleicht einfach etwas ab.

Kontakt angelegt aber die Domäne ist nicht als "AvailabilityAddressSpace" eingerichtet

Id         : 1011
Type       : Error
Message    : When querying Availability für frank@carius.test received ErrorProxyRequestProcessingFaile
             d:Unable to send cross-forest request für mailbox <FrankTest>SMTP:frank@carius.test bec
             ause of invalid configuration., inner exception: Configuration information für forest/domain carius.test
             could not be found in Active Directory.

InternalURL nicht erreichbar

Hier sieht man gut, dass per "Autodiscover" der Exchange CAS zwar die andere Seite auflösen kann aber die interne URL (srv01.fremd.tld) genutzt wird und nicht erreichbar ist.

Id         : 1111
Type       : Error
Message    : When querying Availability für fremduser@fremdfirma.de received ErrorProxyRequestProcessingFailed:System.Ne
             t.WebException: The remote name could not be resolved: 'cas1.fremd.tld'
                at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()
                at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAs
             yncState, Stream& responseStream)
                at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
                at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult
             asyncResult)
                at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebReq uest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)
                at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult
             )
                at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling():<No r
             esponse>. The request information is ProxyWebRequest type = CrossForest, URL = https://srv01.fremd.tld/
             EWS/Exchange.asmx
             Mailbox list = <FromUser (extern)>SMTP:fremduser@fremdfirma.de, Parameters: windowStart = 18.10.2010 0
             1:00:00, windowEnd = 18.10.2010 02:00:00, MergedFBInterval = 30, RequestedView = FreeBusy
             ., inner exception: The remote name could not be resolved: 'cas1.fremd.tld'

Fehlersuche per DNS

Wenn ihr CAS-Server direkt per HTTPS mit dem Zielserver reden wird, dann können Sie einfach mal den lokalen DNS-Cache fragen

C:\> IPCONFIG /DisplayDNS | find "autodiscover"

Sie sollten den Eintrag der andere Domäne finden. Ansonsten versucht der Server entweder keine Auflösung, weil die Domain nicht als "AvailabilityAddressSpace" aufgeführt. ist. Wenn dies aber erfolgt ist, dann scheint der CAS per DNS den Namen nicht auflösen zu können. Dann versuchen Sie mal einen

C:\> NSLOOKUP autodiscover.fremdedomain.tld

Hier muss eine IP-Adresse zurück kommen.

Achtung
Das gilt nicht, wenn Sie den CAS per Konfiguration zur Nutzung eines ausgehenden HTTP-Proxy konfiguriert haben. Dann sehen Sie keine dieser Einträge, da alle Anfragen an den Proxy gehen und der die Auflösung macht.

Fehlersuche per Browser auf EWS via HTTPS

Der CAS-Server macht ja nichts anderes als Anfragen per HTTPS um zuerst die Autodiscover.xml zu erhalten und dann die Exchange Web Services zu befragen. Es hindert uns nichts daran, diese Funktion einfach mit einem Browser auf dem CAS-Server auszuprobieren.

https://autodiscover.fremdefirma.tld/autodiscover/autodiscover.xml

Es sollte eine normale Anmeldedialogbox kommen, in der Sie das übermittelte Dienstkonto samt Kennwort der anderen Seite eintragen, damit sie dann eine XML-Datei erhalten. Aus der XML-Datei können Sie sich die "InternalURL" zu ASURL suchen und diese ebenfalls ansurfen

https://owa.fremdefirma.tld/EWS/Exchange.ASMX

Auch hier sollte zuerst eine Anmeldung erfolgen und dann die Beschreibung der Exchange API im Browser sichtbar sein.

Fehlersuche auf dem Backend im IISLog

Wenn Sie auf der Quellseite ziemlich sicher sind, dass alles korrekt ist, dann kann eine Suche auf dem Ziel helfen. Die vorherigen Tests mit einem Browser müssen im Ziel an den verschiedenen Stellen sichtbar sein. Daher ist z.B. das IISLog des CAS-Servers, auf dem die Anfragen der anderen Organisation ankommen, eine interessant Quelle. So sieht z.B.: das gekürzte Log einer erfolgreichen Anfrage aus:

POST /autodiscover/autodiscover.xml - ASAutoDiscover/CrossForest/EmailDomain//14.01.0255.000 401 2 2148074254
POST /autodiscover/autodiscover.xml - ASAutoDiscover/CrossForest/EmailDomain//14.01.0255.000 401 1 0
POST /autodiscover/autodiscover.xml domain\svcuser ASAutoDiscover/CrossForest/EmailDomain//14.01.0255.000 200 0 0
POST /EWS/Exchange.asmx - ASProxy/CrossForest/EmailDomain/EXCH/14.01.0255.000 401 2 2148074254
POST /EWS/Exchange.asmx - ASProxy/CrossForest/EmailDomain/EXCH/14.01.0255.000 401 1 0
POST /EWS/Exchange.asmx SoapAction=GetUserAvailability;AddressCount=1;local=1;intrasiteproxy=0;
     x-site=0;x-forest=0;PF=0;LocalLongPoleRPCLatency=78;LocalLongPoleRPCCount=13;
     LocalLongPoleServer=CAS.domain.intern;ADMainThreadRequests=1;ADMainThreadLatency=0;
     TimeInAS=224; domain\svcuser ASProxy/CrossForest/EmailDomain/EXCH/14.01.0255.000 200 0 0

Die ersten drei Zeilen zeigen zuerst den Zugriff auf Autodiscover, der zuerst anonym erfolgt und daher fehlt schlägt und erst in der dritten Zeile mit einem 200 erfolgreich ausgeführt wird. Hier sehen Sie zum ersten Mal auch den useragenten "ASAutoDiscover/CrossForest/EmailDomain//14.01.0255.000" (Hier Exchange 2010 SP1) und das verwendete Dienstkonto.

Die nächsten drei Anfragen fordern dann die Frei/Belegt-Zeiten an. Auch hier sehen Sie erst die anonymen zugriffe, die mit meinem 401.2 und 401.1 abgelehnt werden, ehe dann der 200er Zugriff mit der passenden SoapAction und dem userAgent "ASProxy/CrossForest/EmailDomain/EXCH/14.01.0255.000" kommt.

Fehlersuche im Eventlog

Es gibt bei Exchange sehr viele Eventlog-Einstellungen, die auf "Expert" hochgestellt werden können. Interessant sind dabei folgende Protokolle:

MSExchange Availability\Availability Service
MSExchange Availability\Availability Service General
MSExchange Availability\Availability Service Authentication
MSExchange Availability\Availability Service Authorization
MSExchange Autodiscover\Core
MSExchange Autodiscover\Web
MSExchange Autodiscover\Provider

Per PowerShell kann dies schnell erfolgen:

Get-EventLogLevel "MSExchange Availability\Availability Service*" | Set-EventLogLevel -Level high
Get-EventLogLevel "MSExchange Autodiscover\*" | Set-EventLogLevel -Level high

Allerdings ist die Ausbeute eher mäßig. Ich habe zumindest auf Exchange 2007 noch nicht viel mehr Informationen aus dem Eventlog extrahieren können. Es gibt aber zumindest einige wenige Warnungen, die doch weite helfen:

Hier konnte schon mal keine Autodiscover-Antwort erhalten werden.

Ereignistyp:       Fehler
Ereignisquelle:    MSExchange Availability
Ereigniskategorie: Verfügbarkeitsdienst 
Ereigniskennung:   4001
Benutzer:          Nicht zutreffend
Computer:          CAS1
Beschreibung:
Fehler bei Prozess 3720[w3wp.exe:/LM/W3SVC/1/ROOT/owa-1-129272288756618820]: 
Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestWithAutoDiscover. 
Zurückgegebene Ausnahme: Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException:
A cross-forest Availability service that can fill request für mailbox SMTP:frank.carius@netatwork.dex 
could not be found.. Dieses Ereignis kann eintreten, wenn der Verfügbarkeitsdienst keinen 
Verfügbarkeitsdienst in der Remotegesamtstruktur erkennen kann.

Interessant ist natürlich auch das Security Eventlog, wenn die Anmeldung überwacht wird. Hier sieht man dann, wenn sich der andere Server (hier NAWEX001) am CAS-Server anmeldet.

Ereignistyp:	Erfolgsüberw.
Ereignisquelle:	Security
Ereigniskategorie:	An-/Abmeldung 
Ereigniskennung:	540
Benutzer:		DOMAIN\SVC-CalFed
Computer:	CAS
Beschreibung:
Erfolgreiche Netzwerkanmeldung:
    Benutzername:	SVC-CalFed
    Domäne:		DOMAIN
    Anmeldekennung:		(0x1,0x618751B1)
    Anmeldetyp:	3
    Anmeldevorgang:	NtLmSsp 
    Authentifizierungspaket:	NTLM
    Arbeitsstationsname:	NAWEX001
    Anmelde-GUID:	-
    Aufruferbenutzername:	-
    Aufruferdomäne:	-
    Aufruferanmeldekennung:	-
    Aufruferprozesskennung: -
    Übertragene Dienste: -
    Quellnetzwerkadresse:	192.168.14.126
    Quellport:	15060

Erscheinen hier "Fehlerhafte Anmeldungen" dann stimmen die auf der anderen Seite bei Add-AvailabilityAddressSpace eingegebenen Anmeldedaten nicht mehr.

Fehlersuche im Firewall-Log auf dem Ziel

Sollten Sie aber im Eventlog oder IISLog gar keine Treffer haben, dann kann natürlich die Firewall immer noch den Zugriff verweigern. Hier ein Bild eines erfolgreichen Zugriffs eines Exchange 2010SP1 Servers von der IP-Adresse 80.66.20.18 (das ist die offizielle IP-Adresse von Net at Work) auf einen Exchange Server eines unserer Kunden. Die Ausgabe stammt von einem ISA2004 Server beim Kunden, der die Exchange 2007 Webservices im Internet veröffentlicht.

In diesem Fall hat der ISA keine "Preauthentication" gemacht und hat den Zugriff zugelassen. Allerdings hat der Exchange Server hier einen 401 zurück gemeldet. Anhand des Client-Agent sind solche Anfragen recht schnell ausfindig zu machen. Das geht auf dem ISA natürlich gut, weil der SSL-Tunnel vom anfragenden Server hier aufgebrochen werden kann und die Anfragen lesbar und filterbar ist.

Fehlersuche mit TestExchangeConnectivity.com

Vor einiger Zeit hat Microsoft eine Webseite gestartet, welche einen Test der verschiedenen Dienste von extern erlaubt.

Allerdings wollen wir hier nicht OWA oder ActiveSync testen, sondern die Exchange Web Services.

Es kann sein, dass dieses Testprogramm einige Warnungen ausgibt. Schließlich kann es nicht wissen, ob sie auf ihrem CAS die Überprüfung von Zertifikaten oder die Namensauflösung korrekt eingestellt haben. Aber wenn es hier kein Fehler gibt, dann hat die andere Seite im großen ganzen ihre Hausaufgaben gemacht.

Fehlersuche in Outlook

Oftmals ist im Backend alles in Ordnung. Das sehen Sie z.B. daran, dass die Funktion per OWA sehr wohl gegeben ist. Dann kann es ratsam sein, einmal auf dem Outlook Client nachzuschauen. Auch hier gibt es Möglichkeiten, Fehler zu entdecken.

Fake-Autodiscover intern anlegen

Achtung
Die Umsetzung dieser "Umgebung" ist alles andere als einfach und bislang habe ich noch keine Bestätigung, dass es funktioniert.

Von allen Optionen gibt es eigentlich nur einen Weg, relativ unabhängig von der Konfiguration und Mitarbeit der abzufragenden Seite die Verbindung zu erreichen, wenn Autodiscover nicht funktioniert. Folgende Schritte sind dazu erforderlich

  • IISWebseite "Autodiscover.remotedomain.tld" anlegen
    Auf dem CAS-Server, auf dem sowieso schon ein IIS läuft, können Sie eine zweite virtuelle Webseite anlegen, die später die Anfragen nach Autodiscover.remotedomain.tld mit einer passenden XML-Datei beantworten wird

Name: Autodiscover.remotedomain.tld.
Listener: HTTP: 80 mit Hostheader "Autodiscover.remotedomain.tld"
Listener HTTPS 443  (Achtung Hostheader geht hier nur ab Windows 2008)
Pfad: c:\inetpub\Autodiscover.remotedomain.tld
Zugriffe: Anonyme Benutzer zulassen und "nur lesen" zulassen

  • IIS für "Post" einrichten
    Leider holt sich ein CAS die XML-Datei nicht einfach durch einen"GET", sondern sendet einen POST. Insofern muss man auf dem IIS noch einen Handler für ".XML" einrichten, der dann ein Modul startet um die Datei zurück zu geben. Aber auch das ist möglich, z.B. wenn man ".xml" mit der ASP.DLL verbindet. Siehe auch http://www.bluestudios.co.uk/blog/?p=1083. Und 308001 How To Create an ASP.NET HTTP Handler by using Visual C# .NET
  • Autodiscover.XML ablegen
    In diese virtuelle Webseite wird nun eine passende XML-Datei abgelegt. Leider können Sie diese nicht so einfach per Browser holen, da Exchange diese nur per "POST" und nicht beim GET rausrückt. Aber über www.testexchangeconnectivity.com können Sie diese erhalten, aus dem Browser über die Zwischenablage kopieren, anpassen und als Datei speichern. Interessant sind die Werte bei "<ASURL>"
    Pfad: c:\inetpub\Autodiscover.remotedomain.tld\autodiscover\autodiscover.xml
  • Proxyausnahmen
    Wenn der CAS über einen Proxy raus geht, sollten Sie autodiscover.remotedomain.tld als Ausnahme definieren, damit diese Anfrage "intern" bleibt, z.B.: mit eine Anpassung der web.config bei Exchange unter ClientAccess/Autodiscover und ClientAccess/EWS

<configuration>
  
<system.net>
     
<defaultProxy>
         <bypasslist>
             <add address="https://autodiscover\.remotedomain\.tld/" />
         </bypasslist>
      </defaultProxy>
  
</system.net>
</configuration>

  • SSL-Überprüfung deaktivieren
    Wenn Sie das Zertifikat auf dem internen IIS nicht auf "autodiscover.remotedomain.tld" ausstellen, dann müssen Sie die Zertifikatsprüfung auf dem CAS abschalten.
  • HOSTS-Anpassen
    Zuletzt bringen Sie den CAS nun über einen HOSTS-Eintrag dazu, nicht mehr bei der Suche nach "autodiscover.remotedomain.tld" nach extern zu gehen, sondern die IP-Adresse des internen Servers anzusprechen.

Autodiscover.remotedomain.tld  A cas.meinedomain.tld
owa.remotedomain.tld A IP.IP.IP.IP des anderen Zugangsknoten

Achtung:
Beim Einsatz eines HTTP-Proxy zum Zugang ins Internet müssen Sie die Änderungen bezüglich des Hosts zum Zugriff augf die EWS-Verzeichnisse der Gegenseite auf dem Proxy umsetzen, da der CAS ja dann nicht mehr selbst "sucht".

Über diese Hilfskonstruktion könnte es möglich sein, über eine lokale Autodiscover-Logik auch Firmen anzubinden, die mit ihrer Autodiscover-Implementierung Probleme haben.

Weitere Links