CAS-Array

Die Exchange 2010 DAG erlaubt es ja die Datenbank auf vielen Server online repliziert zu betreiben und beim Ausfall des aktiven Servers wird kein "virtueller Exchange Server samt IP-Adresse" geschwenkt. Aber für CAS-Server ist ein MSCS der falsche Ansatz. Hier sind eher Network Load Balancing oder  LoadBalancer gefragt, damit die Clients "einen" virtuellen Namen ansprechen und "etwas" die Anfragen an einen funktionsfähigen CAS-Server weiterreicht. Allerdings müssen die Clients natürlich erst mal "wissen", wie diese Name denn lautet. Und dazu dient dann die Konfiguration eines CASArray.

Recommendation: Enabling Kerberos Authentication für MAPI Clients
http://blogs.technet.com/b/exchange/archive/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients.aspx

Exchange: Combining Web Farm publishing with Software or Hardware Based Load Balanced CAS arrays
http://blogs.technet.com/b/schadinio/archive/2010/07/21/exchange-combining-web-farm-publishing-with-software-or-hardware-based-load-balanced-cas-arrays.aspx

Hinweis:
Ein CASArray ist einfach nur ein Name, der dann im Outlook Profil als „Exchange Server“ eingetragen wird. Wichtig ist nur, dass ein Client, der per RPC auf den Namen geht auf einem funktionierenden CAS landet. Über die Verteilung der Zugriffe müssen sie selbst bestimmen. Da kann NLB oder ein Loadbalancer sein. DNS-RoundRobin ist aber nicht möglich, da hierbei die "Affinität" nicht gegeben ist, d.h. dass ein Client auf dem gleichen CAS bleibt.

Achtung::
Nutzen Sie als Name für CASARRAY und Outlook Anywhere (RPC/HTTP) nicht den gleichen FQDN. Wenn Outlook zuerst RPC versucht, sollte es aus dem Internet NICHT den Namen des CASARRAY auflösen können. Ansonsten dauert der Start sehr lange.

It's important that the (FQDN) specified in the command be only resolvable internally. If the name is also resolvable externally, these external clients will attempt to connect to the array via a TCP connection instead of HTTPS.
Quelle: http://technet.microsoft.com/en-us/library/ee332317.aspx#CASarray

In Exchange 2013 gibt es kein CAS-Array mehr !.
Die Funktion ist ersatzlos gestrichen worden, weil die CAS-Server nicht mehr der MAPI-Endpunkt sind, sondern die RPC/HTTP-Anfragen auf den jeweils aktiven Mailboxserver durchreichen. Im MAPI-Profil taucht dann eine GUID auf.

Das wichtigste Vorab

Das CASArray ist seit Exchange 2010 neu dabei. Um Probleme zu vermeiden sollten Sie ein paar Dinge beachten:

  • Das "CASArray" ist nicht viel mehr als ein weiteres Objekt im Active Directory
  • Das CASArray ist der Name des Server für MAPI/RPC
    Er ist nicht relevant für andere Dienste wie OWA, ECP, EWS, POP, IMAP, Autodiscover etc. Er musst daher auch nicht im Zertifikat für den Server enthalten sein.
  • Der Name sollte NICHT aus dem Internet auflösbar sein, Der für OutlookAnywhere (MAPI/HTTP) aber schon
    Sonst versuchen Client erst per TCP eine Verbindung, was eine Verzögerung bedeutet.
  • Damit ist auch klar dass das CASArray und der RPC-Proxy unterschiedliche Namen haben sollten
  • Legen Sie zuerst ein CASARRAY an, ehe Sie Mailboxdatenbanken anlegen
    Das sollten sie auch tun, wenn Sie erst mal "nur" einen Server haben.
  • ändern Sie den Namen nicht mehr, nachdem Mailboxen auf den Servern angelegt wurden.
    Der Name des CASArray steht z.B. an neu angelegten Datenbanken.

Eine umfangreichere Beschreibung hat das Exchange Team ebenfalls publiziert.

Outlook und der "erste Server"

Wenn sie glauben, dass CAS-Arrays nur für Firmen relevant sind, die mehrere CAS-Server mit einem Loadbalancer zur "Hochverfügbarkeit" einsetzen, der sollte weiterlesen. Outlook oder besser Exchangen 2010 hat bis Exchange 2010 SP3RU2 das Problem, dass ein Zugriff auf den "falschen" CAS-Server keine Rekonfiguration des MAPI-Profile mehr mit sich bringt. Dieser "Verweis" wurde in Exchange 2010 nicht mehr installiert. Das bedeutet aber auch, dass nach der ersten Konfiguration des Outlookprofils der hinterlegte CAS-Server bestehen blieb.

Update: Exchange 2010 SP2 RU3 korrigiert diese Verhalten:
RPC Client Access Cross-Site Connectivity Changes
http://blogs.technet.com/b/exchange/archive/2012/05/30/rpc-client-access-cross-site-connectivity-changes.aspx

 Wird der Server später aber abgebaut, dann hängt Outlook in der Luft, wenn er nicht per Autodiscover einen neuen Weg findet oder ein DNS-Alias auf einen anderen Server verweist. Da ist es dann besser gleich einen "virtuellen Namen" zu verwenden und nichts anderes ist das CAS-Array

  • IMMER ein CAS-Array definieren. Auch wenn man (erst mal) nur einen CAS hat.
    So wird vermieden, dass ein physikalischer Servername im Outlook Profil hinterlegt wird.
  • Kerberos ist "empfohlen"
    Wer nur einen CAS hat, der nutzt eh schon Kerberos aber mit einem CAS-Array sind weitere manuelle Schritte erforderlich. Wer ein CAS-Array einrichtet wird, dann gibt es zu den Namen aber erst mal keinen SPN und kein Computer/Benutzerkonto im Active Directory. Diese Konfiguration ist manuell erforderlich und weiter unten beschrieben

Auch wenn die Einrichtung eines CASArray mehr Arbeit bedeutet, so ist es ratsam dieses Einrichtung vorzunehmen denn bei der nächsten Erweiterung, Migration, Aufrüstung mach es den umbau deutlich einfacher.

Basiseinrichtung

Ohne besondere Vorkehrungen würde auf dem Client ein CAS-Server in den MAPI-Einstellungen hinterlegt. Wer also mehrere CAS-Server als hochverfügbaren Verbund betreiben will, muss aktiv werden und ein CAS-Array definieren. Dabei ist immer genau ein CAS-Array pro Active Directory Site konfigurierbar. Das geht nicht per GUI sondern ist eine Aufgabe für die PowerShell:

New-ClientAccessArray 
  -Name CAS 
  -Fqdn cas.domain.tld
  -Site Paderborn

Über diesen "Trick" erhalten die Exchange CAS-Servers die Information, dass es ein Array für die konfigurierte Active Directory Site gibt und dass alle Exchange CAS-Server in dieser Site diesen Dienst bereitstellen. Sie müssen natürlich die Adresse per DNS auflösbar und per IP-Adresse erreichbar machen. Technisch ist es aber "nur" ein Eintrag im Active Directory und so für die Clients erst mal nicht sichtbar. Daher ist ein zweiter Schritt erforderlich.

Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer cas.domain.tld

Hinweis: Seit Exchange 2010 SP1 scheint der Server beim Anlegen einer neuen Datenbank automatisch den RpcClientAccessServer einzutragen,

Über diesen Befehl pro Postfachdatenbank wird dann auf der Datenbank dieser virtuelle Name hinterlegt. Verbindet sich dann ein Client per MAPI irrtümlich mit dem Postfachserver, dann wird dieser auf den neuen virtuellen Namen umlenkt. Auch hier müssen Sie als Administrator einer größeren Umgebung natürlich sicherstellen, dass die Postfachdatenbanken passend zu den AD-Standorten konfiguriert werden. Wenn Sie mehrere Standorte mit lokalen CAS-Servern betreiben, müssen sie entsprechend mehrere CAS-Arrays konfigurieren.

Addieren Sie diesen Schritt in ihr Betriebshandbuch zu "Neue Datenbank anlegen", damit auch neue Datenbanken den Client zum CAS-Array verweisen. Dies wird aus der Erfahrung sonst gerne vergessen

Virtueller Name auf physikalische Server

Damit kommt natürlich gleich die Frage auf, wie Sie nun mehrere CAS-Server unter einem virtuellen Namen veröffentlichen. Auf den ersten Blick fallen einem da gleich mehrere Wege ein

  • NLB
    Ein möglicher Weg ist die Zusammenschaltung mehrere CAS-Server unter einer virtuellen IP-Adresse über das Windows Bordmittel Network Load Balancing. Allerdings müssen ihre Switches und Router mitspielen und oft gibt es (aus meiner Sicht unberechtigte) Vorbehalte gegen NLB. Hierüber ist aber die Affinität einfach über NLB zu steuern
  • Externe Load-Balancer
    Natürlich können Sie den Array-Namen auch auf ein anderes System lenken, welches die Anfragen dann nach innen an die eigentlichen CAS-Server verteilt. Solche externen Lastverteiler prüfen die Erreichbarkeit der internen Dienste und verteilen die Anfragen nach eigenen Kriterien an diese Server. Oft enthalten Sie noch Funktionen, um die Verschlüsselung von SSL dem Backend abzunehmen und auch die Inhalte zu analysieren. Allerdings ist MOMT kein HTTPS-Zugriff, sondern RPC in der kompletten Bandbreite. Prüfen Sie daher, ob das Drittprodukt auch eine Lastverteilung für RPC-Protokolle unterstützt.
  • DNS Round Robin  mit Alias oder eigener IP IST NICHT SUPPORTET
    Sie könnten in der DNS-Zone einfach den CAS-Namen als CNAME auf den oder die CAS-Server eintragen. Allerdings ist es nicht offiziell gestattet, einen CNAME mehrfach anzulegen (auch wenn es meist geht). Wenn Sie statt dessen mehrere A-Records auf die IP-Adressen der CAS-Server eintragen, dann ist dies zwar hinsichtlich DNS möglich, aber wird nicht funktionieren, da die Clients dann den CAS-Server wechseln. (keine Affinität)
  • "Microsoft Cluster Name"
    Wie ich auf 2-Server-DAG beschrieben habe, könnte man ja auch den Gedanken kommen, eine virtuelle Cluster-IP als CAS-Endpunkt vorzusehen, so dass immer nur ein Knoten aktiv ist und im Fehlerfall der andere Knoten diese IP "übernimmt". Das wäre keine Lastverteilung aber eine Hochverfügbarkeit. Allerdings ist dies laut Microsoft nicht supported. Ich sage nicht, dass es nicht geht.

Wichtig ist einfach, dass ein Client beim Zugriff auf den virtuellen Namen direkt oder indirekt einen CAS-Server erreicht, welcher dann auch die Anfragen an den richtigen Postfachserver weiter geben kann.

Achtung
Laut Microsoft muss sichergestellt, dass die "Affinität" gewahrt bleibt, d.h. dass ein Client bei einer Verbindung auch immer zum gleichen RPC-Knoten kommt und kein "Load Balancing" oder gar DNS-RoundRobin stattfindet.

Achtung: NLB und CASARRAY mit eigenem NLB-Subnetz
Vergessen Sie nicht, das neue IP-Subnetz auch in den Active Directory Sites und Services einzutragen !!

NLB und Cluster
Die Koexistenz von NLB und MS Cluster auf dem gleichen System ist nicht möglich. Eine Kombination der CAS-Rolle mit einer DAG funktioniert also nur mit externen Loadbalancer.

CAS und fixe Ports

Diese Einstellungen sind z.B. beim Einsatz mit einem LoadBalancer zur Verteilung der Zugriffe interessant.

Wer über einen Lastenausgleich nicht nur HTTPS verteilt, sondern auch RPC, wird auf dem Loadbalancer natürlich die Zielports angeben müssen. Es ist Ratsam, indem Fall die Exchange Ports fest zu legen, damit sich diese nicht nach einem Dienstneustart ändern. Dazu sollte man natürlich zwei "freie" Ports finden und auch wenn zwischen 1024 und 65535 viel Platz ist und auch SQL mit 1433, Lync mit 5060/5061 und andere immer in latenter Gefahr schweben, wäre eine eindeutige Zuweisung vielleicht nett.

Beachten Sie dazu auch 65535 Port-Limit.

Für den Einsatz mit dem CAS-Array sind zwei Dienste und damit deren Ports von Belang:

Achtung:
Ich bin der Meinung, dass die von Microsoft vorgeschlagenen Port 59532 und 59533 nicht sicher sind, da sie auch im dynamischen Bereich liegen und die "Planer" dem Fehler aufgesessen sind, das die Zahl 50530 bei der Ausgabe von NetSH als Endport statt als Anzahl gewertet wurde.
Ich nutze daher 5000dez und 5001, welche unter 6005 liegen

  • CAS-Server und Mailbox: MSExchangeRPC Port
    Über diesen Weg kommunizieren die Clients mit dem CAS-Server, wenn Sie per RPC sich verbinden (Nicht RPC/HTTP). Der Port darf natürlich nicht belegt sein und sollte auf allen CAS-Server dann auch gleich eingestellt werden. Folgende Registrierungsdatei können Sie dazu auf dem CAS-Server importieren. Da Outlook für den Zugriff auf öffentliche Ordner immer noch am CAS vorbei auf die Mailboxrolle zugreift, müssen Sie hier die Einstellungen bezüglich MSExchangeRPC ebenfalls vornehmen. (ich nutze 5001dez und nicht den MS-Vorschlag 59532. Siehe 65535 Port-Limit)
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem]
"TCP/IP Port"=dword:0001389
  • CAS-Server: Exchange Adressbuchdienst (Bis Exchange 2010 RTM) 
    Dieser Dienst ist mittlerweile in .NET geschrieben, und die Einstellungen hierzu finden sich in der Datei "C:\Program Files\Microsoft\Exchange Server\V14\Bin\microsoft.exchange.addressbook.service.exe.config". Mit Notepad können Sie einen festen Port definieren. Hier ein Auszug aus der Datei.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <add key="RpcTcpPort" value="5000" />
    </appSettings>
</configuration>
  • CASServer: Exchange Adressbuchdienst (ab Exchange 2010 SP1)
    Mit der Installation von Exchange 2010 hat Microsoft diese Einstellung wieder in die Registrierung verlegt. Dies erlaubt zum einen eine Konfiguration per Gruppenrichtlinien und zudem bleibt die Einstellung auch erhalten, wenn ein Exchange-update die XML-Datei überschreiben sollte. Microsoft nutzt z.B.: 59533, was ich aber nicht unterstütze. Siehe Einleitung zu dem Kapitel und 65535 Port-Limit.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters]
"RpcTcpPort"="5000"

Damit die Einstellungen auch wirken, müssen Sie die beiden Dienste "Microsoft Exchange-Adressbuch" und "Microsoft Exchange RPC-Clientzugriffsdienst" auf den Servern neu starten.

Eine Kontrolle per NETSTAT, den Windows 2008 Ressourcen Monitor oder TCPView sollte die Wirkung dann bestätigen.

CAS Array und Kerberos

Die Geschichte mit dem Zugriff per OWA, EWS oder ActiveSync ist solange einfach, solange der Exchange Server auch die Authentifizierung übernimmt, sei es per "Formular" bei OWA oder per "BasicAuth" bei ActiveSync über SSL. Untereinander (CASProxy 2010) vertrauen sich die Exchange Server sowieso. Es kann also wünschenswert sein, Kerberos als Anmeldeverfahren zuzulassen, z.B. Um NTLM-Anmeldungen zu reduzieren oder über vorgelagerte Systeme mit Constraint Delegation zu arbeiten.

Nicht relevant ist dies, wenn das vorgelagerte System eine "Preauthentication" vornimmt, indem es Anmeldedateien per Klartext erfragt, z. B. indem es selbst nur BasicAuth oder ein eigenes Formular anbietet. Das erfordert aber vom Anwender eine erneute explizite Eingabe der Anmeldedaten, die dann von dem System aber nach hinten zum CAS Server explizit weiter verwendet werden können

Für die Anmeldung an Outlook WebApp kommt heute fast nur noch die "Formularbasierte Anmeldung" zum Einsatz. Hierbei ist Kerberos kein Thema. Anders sieht es aber aus, wenn LoadBalancer ins Spiel kommen und Outlook per RPC sich mit dem Exchange CAS verbinden. Dann würde Outlook 2003 und höher schon gerne mit Kerberos arbeiten und damit auch den CAS-Server entlasten. Genau das geht aber erst mal nicht, wenn Sie mit einem Exchange 2010 CAS-Array arbeiten, da dieses keinen ServicePrincipalName anlegt und selbst mit einem SPN kein CAS mit dem Ticket etwas anfangen könnte.

Erst seit Exchange 2010 SP1 ist es überhaupt möglich, die Exchange Dienste mehrere CAS-Server mit dem gleichen Dienstkonto laufen zu lassen, und so auch mit einem virtuellen Farmnamen zu arbeiten. Wenn Sie nun Kerberos auf den CAS-Servern erlauben wollen, dann müssen Sie ein paar Schritte durchführen: (Siehe auch CAS und Kerberos)

  • Dienstkonto anlegen
    Die CAS-Server dürfen nicht mehr jeder mit "seinem" Kerberos Account aktiv sein, sondern müssen ein gemeinsames Dienstkonto verwenden. Diese Konto (ein normaler Domainbenutzer oder Computer) muss manuell angelegt werden. Dies kann sogar ein Computerkonto sein. Bedenken Sie aber, dass niemand das Kennwort ändert. Nicht dass das Konto irgendwann aufgrund "Inaktivität" auffällt und vielleicht deaktiviert oder gar gelöscht wird. Das Kennwort wird auch nicht wirklich gebraucht. Insofern sollten Sie es komplex wählen.
  • Skript "RollAlternateserviceAccountCredential.ps1" starten
    Dieses Skript richtet die erforderlichen Einstellungen für die CAS-Server sein. Es gibt unterschiedliche Optionen aber in den meisten Fällen dürfte ein Dienstkonto für alle CAS-Server im Forst verwendet werden.
    Wer mehrere CASArrays betreibt, kann aber natürlich auch 
# Eintrag für forestweites Konto

.\RollAlternateserviceAccountPassword.ps1 `
   -ToEntireForest `
   -GenerateNewPasswordFor "Contoso\ComputerAccount$" `
   -Verbose
# Hier die Version um pro CASArray ein eigenes Konto zu nutzen

.\RollAlternateserviceAccountPassword.ps1 `
    -identity casarray.domain.tld `
    -toarraymembers `
    -generateNewPasswordFor "domain\casname$" `
    -verbose
  • ServicePrincipalName Einträge addieren
    Nun geht es daran, dem gerade angelegten und eingetragenen Benutzerkonto auch die erforderlichen ServicePrincipalName zu verpassen, damit das Kerberos Distribution Center (KDC) auch auf Anfragen nach diesen Namen das Konto findet und ein Ticket ausstellt. dabei geht es um folgende Einträge mit dem Namen des CAS-Array, die per SetSPN oder ADSIEDIT addiert werden. Achtung: SPNs dürfe nur genau einmal vergeben sein. 
Setspn -S http/autodiscover.contoso.com dienstkonto
Setspn -S http/mail.contoso.com dienstkonto
Setspn -S exchangeMDB/mail.contoso.com dienstkonto
Setspn -S exchangeRFR/mail.contoso.com dienstkonto
Setspn -S exchangeAB/mail.contoso.com dienstkonto

Nun müssen sie noch etwas die Active Directory Replikation abwarten, damit die Daten vom KDC auch gefunden werden können und dann müssen Sie die Funktion natürlich noch prüfen. Dazu können Sie einfach Outlook nutzen, indem Die Anmeldung auf "Kerberos Only" umgestellt wird.

Allerdings müssen Sie hier aufpassen, weil Outlook bei einem Fehler auf RPC/HTTP wechselt. Entweder schalten Sie temporär diesen Zugang für diesen Client ab oder kontrollieren die IISLogs, dass der Client nichtüber diesen Weg kommt.

Über den Exchange Adressbuchdienst können Sie ebenfalls die verwendete Anmeldung ermitteln und auch mit einem Test-Commandlet können Sie mehr in Erfahrung bringen

$c = Get-Credential

Test-OutlookConnectivity `
   -Identity administrator `
   -MailboxCredential $c `
   -Protocol tcp

Die Anmeldung per Kerberos wird auf den CAS-Servern einfach zusätzlich aktiviert. Wenn Sie das Dienstkonto oder auch nur die SPNs löschen, kann der KDC keine Tickets mehr ausstellen und Kerberos wird einfach nicht mehr verwendet.

CASArray, Kerberos und vorgelagerte Load Balancer

Die CAS-Array-Adresse und der Name werden in Verbindung mit einem vorgelagerten LoadBalancer nicht mehr auf ein NLB der CAS-Server verbunden, sondern auf die IP-Adresse des LoadBalancer. für einen "einfachen LoadBalancer", der nur HTTP/HTTPS oder TCP-Verbindungen durchreicht, ändert sich bezüglicher der Kerberos-Konfiguration nichts. Der Client nutzt den virtuellen Namen und landet nun nicht per NLB sondern anders auf einem der CAS Server. Wenn Sie Outlook Web Access ohne die formularbasierte Anmeldung verwenden, können Sie auch hierbei Kerberos einsetzen. Zum Testen können Sie auf ihrem PC mittels ETC/HOSTS-Datei den Namen des CAS-Array ja nacheinander auf die verschiedenen CAS-Server einrichten und sehen, ob Sie per Browser auf ihr Postfach kommen und dabei Kerberos genutzt wird. Ob Kerberos zum Einsatz kommt, erkennt man daran, dass Sie ein Ticket (Kerbtray, KLIST, siehe Kerberos Debugging) bekommen haben oder z.B. mit Fiddler den HTTP-Traffic mitgeschnitten und die verwendete Authentifizierung kontrolliert haben.

Anders verhält es sich, wenn der LoadBalancer davor (z.B. TMG/ISA) eine Vorauthentifizierung durchführt. Ein TMG greift auf das CASArray normalerweise nicht über eine virtuelle NLB-Adresse des Array zu, weil dann NLB bei bestimmten Konfigurationen keine Lastverteilung mehr macht. Statt dessen "weiß" der LoadBalancer, dass es dahinter zwei oder mehr dedizierte Server gibt und wenn diese Kerberos zulassen und der TMG das Recht hat, sich für den Anwende rein Ticket zu besorgen, dann könnte er sich auf im Auftrag des Anwenders authentifizieren. Dies ist sogar eine interessante Option in Verbindung mit einer vorgelagerten Authentifizierung per TMG/ISA o.ä.. Dies funktioniert in Verbindung mit Kerberos und dem Einsatz von Constraint Delegation. Das vorgelagerte System bietet dem Anwender einfach "Kerberos" als Anmeldeverfahren an und bekommt vom Anwender ein entsprechendes Ticket. Zudem hat dieses System das "Recht", sich im Auftrag des Anwenders ein Tickt für das nachgelagerte System (hier eben die Exchange CAS-Rolle bzw. das CASARRAY) zu besorgen und damit "on Behalf" des Anwenders zu agieren. Auch wenn ich das technisch auf Constraint Delegation schon beschrieben habe, so funktioniert dies mit Exchange 2010 CAS-Servern offiziell erst seit Exchange 2010 SP1. Denn die CAS-Server haben bis dahin kein Kerberos unter einem virtuellen "Array-Namen" unterstützt.

In Verbindung mit einfachen Loadbalancern gibt es auch einige Hinweise zu beachten, die aber Produktspezifisch sind.

LoadMaster supports KCD as long as SSL is not being terminated at LoadMaster. There's a TechNet blog that covers some of the approaches and limitations of doing so. Figure 3 is most relevant to this.
http://forums.kemptechnologies.com/index.php?p=/discussion/10276

CASArray mit TMG

In Verbindung mit TMG ist mir erstmals ein "Problem" aufgefallen, was aber auch bei anderen Firewalls und IDS-Systemen der Fall sein könnte. Outlook verbindet sich ja zu erst per RPC mit dem Port 135 (Endpoint Mapper) um über den Weg die Ports für den Exchange Adressbuchdienst und Informationsspeicher zu erhalten. Nach dem "Drei-Wege-Handshake" kommt dann erst der Bind mit einem ACK und dann die Anfragen mit der Antwort. Das kann man hier in einem Mitschnitt gut sehen.

Ich habe aber hier rot markiert, wie sich die Pakete unterscheiden, wenn der CAS-Server (Hier ist 10.1.1.3) antwortet, aber die Source-IP durch den Loadbalancer natürlich wieder auf die IP-Adresse des CAS-Array gesetzt wird. Den Outlook Client interessiert dies nicht. Wer z.B. per IPv6 schon arbeitet, der wird sehen, dass Exchange da dann mit einem 0.0.0.0 antwortet.

Es gibt Systeme, die so tief in die RPC-Pakete reinschauen und diese unstimmigkeit erkennen und als "nicht gut" erkennen. Sogar das Microsoft Thread Management Gateway (TMG und UAG) überprüft diese Daten und blockiert eventuell den Zugriff. Diese "strikte RPC Prüfung" können Sie aber abschalten.

Per NETMON können Sie ja auf dem Client in der Regel schnell sehen, welche Pakete der Client sendet und wieder erhält.

Weitere Links