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:

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

Set-AvailabilityConfig -OrgWideAccount domain\serviceaccount"

Get-AvailabilityConfig | fl

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

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

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

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

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

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:

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.

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.

• Fehler der Proxyanforderung, weil ein SSL-Zertifikat auf dem Ziel-Clientzugriffsserver ungültig ist.
  http://technet.microsoft.com/de-de/library/bb218543(EXCHG.80).aspx
• The proxy request failed because an SSL certificate on the destination Client Access server is not valid
  http://technet.microsoft.com/en-us/library/bb218543(EXCHG.80).aspx
• Understanding the Self-Signed Certificate in Exchange 2007
  http://technet.microsoft.com/en-us/library/bb851554(EXCHG.80).aspx
• 975165 EWS proxying requests fail after you run Availability Service requests in a CAS to CAS proxying scenario in Exchange Server 2007

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.

• Proxying CAS HTTP Cross Forest availability requests
  http://blogs.technet.com/b/appssrv/archive/2009/08/11/proxying-cas-http-cross-forest-availability-requests.aspx
• Configuring Internet Applications
  http://msdn.microsoft.com/en-us/library/5w91x7a7.aspx
• System.NET - <defaultProxy>-Element
  http://msdn.microsoft.com/de-de/library/kd3cf2ex.aspx
• <bypasslist> Element
  http://msdn.microsoft.com/en-us/library/aa903323(VS.71).aspx
• 318140 PRB: Error on .NET client that consumes a Web service through an HTTP proxy server
• 307220 How to configure an XML Web service client by using the .NET Framework to work with a proxy server
• Web Services and the 15 Second Delay
  http://www.bizbert.com/bizbert/2007/03/10/Web+Services+And+The+15+Second+Delay.aspx

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.

• How to Diagnose Availability Service Issues
  http://technet.microsoft.com/en-us/library/bb124805(EXCHG.80).aspx
• Test-OutlookWebServices: Exchange 2010 SP1 Help
  http://technet.microsoft.com/en-us/library/bb124509.aspx
• Diagnose Availability Service Issues: Exchange 2010 SP1 Help
  http://technet.microsoft.com/en-us/library/bb124805.aspx

 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.

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

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

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