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

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

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.

Funktionsweise und Einrichtung

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.

Schritt Beschreibung Prüfung

Dienstkonto im Ziel anlegen und Eintragen

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, um dann die Daten mit seinem privilegierten Rechten zu ermitteln und auszuliefern.

Das Kennwort sollte ausreichend komplex sein aber sollte nicht geändert werden müssen und nicht ablaufen. Dieses Konto muss in Exchange dann noch eingetragen werden:

Set-AvailabilityConfig -OrgWideAccount domain\serviceaccount"

Das Konto benötigt KEIN Postfach

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 for 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

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.

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 möglich ist.

$cred = get-Credential

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 kann man nach diesem Schritt nicht. Sie können mit "Get-AvailabilityAddressSpace natürlich die aktuelle Konfiguration 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.
3

Kontakt anlegen

Zuletzt ist noch ein Kontakt in der Quelle anzulegen, da ansonsten der CAS-Server keine Anfrage stellt. 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 Zieladresse 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 hat auch noch einen anderen Grund:

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: nicht mehr nachvollziehbar

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.
4

CAS Zugriff nach Außen

Sobald nun ein Outlook 2007/2010 Client den eigenen CAS-Server nach den Frei/Belegt-Zeiten fragt und der CAS den Benutzer als Kontakt im AD findet und es für diese Domain einen "AvailabilityAddressSpace" gibt, versucht der CAS die andere Organisation zu erreichen.

Dazu fragt der CAS per Default erst mal per DNS an "autodiscover.andere.domain". SRV-Records werden hier leider geben so wenig unterstützt wie HOSTS-Einträge. Über Autodiscover findet der CAS dann die URL für die Exchange Web Services der anderen Seite und greift dann auf die ASURL zu. (Availability Service URL)

Sollte der CAS nicht direkt über DNS und HTTPS den anderen Server erreichen können, z.B. weil dazwischen ein HTTP-Proxy steht, dann müssen sie dies in der "web.config" für Autodisover und EWS auf ihrem CAS-Server konfigurieren. Details finden Sie weiter unten. Der CAS Server nutzt weder die Proxy Einstellungen ihres Internet Explorers noch Einstellungen per WinHTTP oder ProxyCFG.

Beim Einsatz eines Proxy können Sie in den Proxy-Logs nachverfolgen, dass der CAS-Server die anderen Seite erreichen will.

Ohne Proxy können Sie mit NETMON die HTTPS-Verbindungen suchen-. Zudem sollte bei einem "ipconfig /Displaydns" der Autodiscover-Eintrag im lokalen DNS-Cache des CAS erscheinen.
5

DNS Veröffentlichungen

Die abgefragte Domain muss natürlich für den abfragenden Server auflösbar sein. Daher muss im DNS die "autodiscover.fremde.domain" und die URL für die Webservices auflösbar sein.

 NSLOOKUP ist ihr freund, um ohne Proxy diese Namen zu prüfen.
6

EWS Veröffentlichung und Zertifikat

Kaum jemand wird in einer größeren Exchange Umgebung seine CAS-Server direkt aus dem Internet erreichbar machen. Meist steht ein Reverse Proxy (ISA, TMG o.ä.) davor, die den Zugriff filtern und schützen. Sie sollten darauf achten, dass die Zertifikate mit den Namen übereinstimmen und ein Zugriff per normaler HTTP-Anmeldung (Basic oder NTLM) möglich ist. Besondere Schutzfunktionen wie z.B. Tokens oder Client-Zertifikat müssen entsprechend "umgangen" werden.

Natürlich gilt das auch für Autodiscover.

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

EWS/Autodiscover-Funktion auf dem Exchange CAS-Server

Auf dem von extern erreichbaren CAS-Server sollten Sie nach erfolgter Konfiguration die Zugriffe des anderen CAS-Servers sehen

Kontrollieren sie im IIS-Log, ob sich ein Client mit dem Benutzernamen des Dienstkontos anmeldet.

Auch im Security Eventlog können Sie die Anmeldungen bei aktivierter Überwachung wiederfinden.

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 kennen:

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

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

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

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 kennen 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

RunspaceId : 167036cf-6ba9-4ae5-999d-7cd9c47371c8
Id         : 1111
Type       : Error
Message    : Receipent address user-ohne-kontakt@remotedomain.de is invalid. Please check your command parameters.
RunspaceId : 167036cf-6ba9-4ae5-999d-7cd9c47371c8
Id         : 1111
Type       : Error
Message    : When querying Availability for frank@cariustest.de received ErrorProxyRequestProcessingFailed:Unable to send c
             ross-forest request for mailbox <Frank Carius (test)>SMTP:frank@cariustest.de because of invalid configuration
             ., inner exception: Configuration information for 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

RunspaceId : 167036cf-6ba9-4ae5-999d-7cd9c47371c8
Id         : 1011
Type       : Error
Message    : When querying Availability for frank@carius.test received ErrorProxyRequestProcessingFaile
             d:Unable to send cross-forest request for mailbox <FrankTest>SMTP:frank@carius.test bec
             ause of invalid configuration., inner exception: Configuration information for 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.

RunspaceId : 167036cf-6ba9-4ae5-999d-7cd9c47371c8
Id         : 1111
Type       : Error
Message    : When querying Availability for 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 = <Thomas Howind (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 for 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.

http://www.testexchangeconnectivity.com

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
Keywords:Federation Kalender Org2Org