Exchange 2013: Wo ist das CAS-Array geblieben?

In der Exchange 2013 Preview konnte das CAS-Array mittels “new-clientaccessarray” noch angelegt werden. In der RTM Version von Exchange 2013 ist das CMDlet nun nicht mehr verfügbar. Der Grund ist einfach: Es wird kein CAS-Array mehr benötigt.

Bisherige Exchange Server Versionen nutzten zur Kommunikation mit Outlook im Netzwerk das MAPI-Protokoll welches RPCoverTCP nutzt. Leider hat dieses Protokoll den gravierenden Nachteil, dass es dynamische Ports verwendet. Der TCP Port wechselte also ständig, was es schwierig gemacht hat, Firewalls entsprechend zu konfigurieren.

Exchange 2013 verwendet nun RPCoverHTTPS. Die RPC Verbindungen werden also komplett über das HTTPS Protokoll getunnelt. Bisher kam diese Technik nur bei Outlook Anywhere zum Einsatz. Mit Exchange 2013 müssen die Clients RPCoverHTTPS nun auch im internen Netzwerk verwenden.

Großer Vorteil von RPCoverHTTPS ist, dass es nur den Port 443 nutzt, also keine dynamischen Ports zum Einsatz kommen. Des weiteren wird kein RPC-Endpunkt mehr benötigt (CAS-Array), da das Postfach über die GUID und den UPN angesprochen wird.

In der Praxis funktioniert das wie folgt:

Outlook erhält seine Informationen via Autodiscover. Outlook sendet MAILBOXGUID@UPN an einen CAS-Server, der per Autodiscover mitgeteilt wurde. Der CAS-Server sucht nun im Active Directory nach der MAILBOXGUID@UPN und erhält vom AD den entsprechenden Mailbox Server. Der CAS-Server leitet die Anfrage des Outlook Clients an den Mailbox Server weiter der das Postfach hosted.

Das CAS-Array als Endpunkt wird somit überflüssig. Weiterer Vorteil: Es können günstigere Loadbalancer für die Client Access Server eingesetzt werden Smiley

8 Gedanken zu „Exchange 2013: Wo ist das CAS-Array geblieben?“

    • Funktionieren wird das schon, aber Support wird es da wohl keinen für geben :-)
      Das RPC wird ja in HTTPS getunnelt. Was in dem HTTPS Paket steckt dürfte den Loadbalancer nicht weietr interessieren. Zumindest nicht auf Layer 4. Von daher sehe ich keinen Grund warum es nicht funktionieren sollte. Reverse Proxy wird wahrscheinlich nicht funktionieren, aber LB könnte klappen.
      Man könnte das ja mal testen ;-)

      Antworten
  1. Hi Frank,

    das mit den beiden Webservern, ist bis auf das RPC-Thema, schon am laufen, OWA- und AS- funktionieren ja super toll, wobei der Nginx die Daten schneller durchreicht als der Apache, nur halt das schöne Outlook-Anywhere halt net, aber dafür gibt es ja HA-Proxy.
    Wennste das mal sehen willst meld dich mal bei mir ;)

    Grüße Michael

    Antworten
  2. hi, es gibt keine RPC-Kommunikation mehr zw. outlook und dem CAS. Seit EX2013 wird alles durch HTTPs getunnelt. Hat den Vorteil, dass die Ports nicht mehr dynam. gestaltet werden, man sich also nur noch um 443 kümmern muss. So fallen CASArrays eh weg, da die Affinität zum CAS auch keine Rolle mehr spielt.

    Antworten
  3. Hallo zusammen,
    ich habe folgende Konstalation:
    2x CAS Server EX2013 über Loadbalancer gesteuert
    2x Mailbox Server EX2013
    2x DC
    Alles basierend auf W2K12R2.
    Mein öffenrliches Zertfikat ist auf eine Domain registriert.
    Wenn ich jetzt das Outlook Anywhere Konfiguriere und den CAS als Exchange Server angebe, kriege ich die Passwort abfrage des Users, kann mich aber nicht anmelden.
    Wenn ich den Mailbox Server als Exchange Server angebe, kann ich mich anmelden und Outlook funktioniert einwandfrei. Wie habt ihr das System aufgebaut. Wir haben ja Extra CAS Server für die Client Authenrifizierung.
    Mfg,
    Kai

    Antworten

Schreibe einen Kommentar