Exchange 2010 Migration: Public Folder Proxy Mailbox Problem

Bei meiner letzten Migration von Exchange 2010 auf Exchange 2016 konnten die Postfächer nach erfolgter Umstellung nicht mehr auf die Öffentlichen Ordner zugreifen. Obwohl zuvor eine Public Folder Proxy Mailbox angelegt und auch mittels Autodiscover erfolgreich verteilt wurde, schlug die Verbindung fehl. Benutzer bekamen nur die Fehlermeldung „Anmeldung am Exchange Server fehlgeschlagen“ in verschiedensten Ausführungen. Wie man das Problem in den Griff bekommt und wie der Migrations-Aufbau genau ausgeschaut hat, beschreibe ich in den nächsten Kapiteln genauer.

Exchange Konstellation

Der Aufbau

Da die Konstellation, damit das angesprochene Problem zutrifft, relativ speziell ist, führe ich diese hier noch einmal genauer aus. Die Exchange Infrastruktur befindet sich im Migrationsprozess von Exchange 2010 auf 2016. Die ersten Benutzerpostfächer wurden bereits auf den neuen Cluster migriert. Nun gibt es zwei unterschiedliche Fehlerbilder:

• Variante 1: Der Public Folder Zugriff funktioniert nach der Migration nur sporadisch. Teilweise kann auf die Öffentlichen Ordner zugegriffen werden, teilweise kommt aber eine Fehlermeldung.
• Variante 2: Der Zugriff auf die Public Folder funktioniert überhaupt nicht. Auch mit verschiedenen Clients und Postfächern kann keine Verbindung hergestellt werden.

Je nachdem, welche Variante auf eurer Problem zutrifft, müssen wir am Ende leicht veränderte Aktionen setzen. Doch fahren wir zuerst mit dem allgemeinen Debugging fort.

Wir haben auch bereits zuvor die Public Folder Proxy Mailbox nach folgendem Schema von Microsoft am Exchange eingerichtet. Weiters haben wir sichergestellt, dass die Public Folder Proxy Mailbox auch tatsächlich über den Autodiscover an den Client weitergereicht wird. Falls es nicht bekannt sein sollte, wie man diesen Schritt vollführt, hier eine kurze Anleitung:

Dazu öffnet man im Outlook die „E-Mail Konfiguration testen“ Schnittstelle (wie das gemacht wird zeige ich dir hier) und trägt die jeweilige SMTP-Adresse des Postfaches ein. Anschließend lässt man einen Testlauf starten und überprüft das Ergebnis. Im XML-Reiter muss am Ende der Config eine „PublicFolderInformation“ mitgegeben werden. Dort muss die SMTP-Adresse der zuvor angelegten Public Folder Proxy Mailbox erscheinen.

Dabei ist es unter anderem essentiell, dass die hier aufgeführte SMTP-Adresse valide und öffentlich abfragbar ist. Ein externer Client wäre beispielsweise nicht dazu in der Lage, die Adresse PFMailbox@exchange.local abzufragen. Bitte achtet darauf, dass beim Anlegen der Proxy Mailbox die Hauptdomäne als Adresse gewählt wird.

Exchange 2010 Eigenheiten

Waren die oben genannten Tests erfolgreich und ihr bekommt beim Öffnen der Public Folder trotzdem eine Fehlermeldung („Anmeldung fehlgeschlagen“), könnte der folgende Fehler bei euch ebenfalls zutreffen. Doch von welchem Fehler sprechen wir? Schauen wir uns dafür zuerst den Aufbau an: Bei Exchange 2010 konnte man die Client Access (CAS) und Postfachrolle auf verschiedenen Servern installieren. So war es durchaus üblich und von Microsoft empfohlen, dies auch so umzusetzen. Grob sieht der Zugriff auf eine typische Exchange 2010 Umgebung wie folgt aus.

Und genau hier entsteht das Problem. Bei der Migration von 2010 auf 2016 terminiert ab einem gewissen Punkt jeglicher Traffic am Exchange 2016 Cluster und wird anschließend (falls nötig) auf den 2010er geproxied. Wurde beim Exchange 2010 allerdings die CAS- und MB-Rolle auf unterschiedlichen Servern installiert, kann der EX2016-Proxy die Anfragen an die Public Folder nicht weiterleiten und der Zugriff scheitert. Die Voraussetzung lautet, dass sowohl die Client Access, als auch die Mailbox-Rolle auf dem selben Server installiert sind.

Die Lösung

Die nächsten Schritte unterscheiden sich nun davon, welche Problem-Variante aus dem ersten Kapitel bei euch zutrifft. Kann euer Outlook gar keine Verbindung zu den auf Exchange 2010 gehosteten Public Foldern herstellen (Variante 1), so läuft auf eurem Exchange 2010 Mailboxserver wohl höchstwahrscheinlich keine Client Access Rolle. Ihr müsst daher eine vollwertige Installation und Konfiguration der CAS-Rolle am Mailboxserver nachholen. Achtet darauf, dass alle Endpunkte (Virtual Directories) unter dem richtigen Namen erreichbar sind und ihr ein valides SSL-Zertifikat eingespielt habt. Ansonsten werden eure Clients nach und nach mit Warnings und Zertifikatsfehlern überschüttet. Die HUB-Rolle wird nicht benötigt.

Damit aber noch nicht genug, denn jetzt kommen wir zur Variante 2. Auch ich habe zuerst die CAS-Rolle am Mailboxserver nachinstalliert. Danach hat der Zugriff partiell funktioniert, allerdings eben nur teilweise und es kam immer wieder zu Problemen. Nach längerer Fehlersuche durch die verschiedensten Logs konnte ich ein Muster feststellen: Der EX2016 hat die Public Folder Verbindungen nicht nur auf den neuen CAS (mit Mailboxserver), sondern auch auf den Alten (ohne Mailboxserver) weitergeleitet. Wie wir bereits gelernt haben, kann der Client Access Server ohne Postfachrolle keine Verbindung zu den Public Foldern herstellen.

Der EX2016 ist also nicht schlau genug, die Verbindungen an die richtige Stelle weiterzuleiten. Auch ein Anpassen der CASArray DNS-Records auf einen Server hat keine Besserung gebracht. Also bleiben an dieser Stelle zwei Möglichkeiten:

• Man deprovisioniert den CAS Server, sodass nur noch der Mailboxserver + CAS Rolle übrig bleibt
• Man teilt dem EX2016 mit, dass er ausschließlich an den von uns definierten Server Connections weiterleitet

Option 2 ist wohl die elegantere, da sie sich mittels einem Powershell CMDLET abbilden lässt. Dazu führt man einfach folgenden Befehl aus:

Set-ClientAccessServer <CAS> -IsOutOfService $true

Ein anschließender IISReset am EX2016 reicht aus. Somit werden zukünftige Verbindungen ausschließlich an den richtigen Server verteilt. Problem behoben.