Möglicher Stolperstein bei Migrationen auf Exchange 2013 CU11

Mitte Dezember 2015 hat Microsoft das Cumulative Update 11 (CU11) für Exchange 2013 veröffentlicht. Geändert hat sich darin u.a. die Art der Verbindung der Exchange Management Shell (EMS) mit den zu verwaltenden Servern. Welche Probleme dabei auftreten können und wie diese umgangen werden, zeigt Markus Hengstler in seinem Beitrag.

Autor Markus Hengstler
Datum 20.01.2016
Lesezeit 5 Minuten

Am 10.12.2015 hat Microsoft das Cumulative Update 11 (CU11) für Exchange 2013 veröffentlicht. Wer sich die Mühe macht, die Release Notes zu lesen, kann nachlesen, wie sich die Art der Verbindung der Exchange Management Shell (EMS) mit den zu verwaltenden Servern geändert hat. Da dies bei Migrationen von Exchange 2007 und 2010 zu 2013 problematisch sein kann, erkläre ich in diesem Artikel die Auswirkungen und mögliche Workarounds.

Was wurde geändert?

In Exchange 2007 bis und mit 2013 CU10 verbindet sich die Exchange Management Shell über ein virtuelles Verzeichnis auf dem Webserver des lokalen Servers. Nur wenn dies nicht möglich ist, weicht die Logik auf einen anderen verfügbaren Client Access Server aus.

Hier das Beispiel eines Exchange 2010 Servers:

exchange-2013-migration-cu11-1

Die Änderung in CU11 (und später auch in Exchange 2016 CU1) besteht darin, dass die Verbindung nun auf den Server geleitet wird, auf dem sich die aktive Datenbankkopie mit der Mailbox des administrativen Benutzers befindet. Sollte dieser keine Mailbox konfiguriert haben, wird stattdessen die Arbitration-Mailbox SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} verwendet bzw. falls diese nicht verfügbar ist, eine der anderen System-Mailboxen. Dieses Verfahren nennt sich Mailbox Anchoring.

Warum wurde diese Änderung eingeführt?

Da die Zugriffe auf die Powershell-Verzeichnisse in IIS meist über einen Loadbalancer geführt werden, der diese dann auf die Server verteilt, kann es insbesondere in einer Kombination von Exchange 2013 und 2016 Servern geschehen, dass nicht die neueste Exchange-Version für die Verwaltung verwendet wird und somit neuere Cmdlets eventuell nicht funktionieren. Mailbox Anchoring für die EMS löst dieses spezifische Problem – ich nehme an, dies wurde vor allem für Microsofts Office-365-Umgebung eingeführt.

Was sind mögliche Probleme?

Es gibt zwei Fälle, in denen das neue Verhalten des Verbindungsaufbaus Probleme bereiten kann:

  1. Während einer Migration von Exchange 2007 oder 2010
    Will ich die Exchange 2013 CU11 oder 2016 CU1 Server verwalten und rufe die EMS auf, sieht es zwar aus, als ob ich lokal verbunden wäre – das ist aber nicht so. Es führt zu falschen Ausgaben in der Shell oder Befehle funktionieren schlicht nicht. Hier ein Beispiel:
    exchange-2013-migration-cu11-2

    Obwohl scheinbar lokal verbunden, kann die Shell nur den Exchange 2010 Server anzeigen – der 2013 wird nur angezeigt, wenn der Wildcard-Charakter in der Abfrage verwendet wird:exchange-2013-migration-cu11-3

    Das gleiche Problem tritt bei Datenbanken auf:exchange-2013-migration-cu11-4

    Hier sehen wir auch, dass der Datenbankpfad – obwohl wir vermeintlich mit Exchange 2013 verbunden sind – nicht geändert werden kann, da wir gemäss Fehlermeldung remote sind.
  2. Wenn alle Datenbanken entweder mit Admin-Mailboxen oder System-Mailboxen dismountet sind, kann die EMS gar nicht verbinden:
    exchange-2013-migration-cu11-5

Wie können die Probleme umgangen werden?

Zunächst sollten die Mailboxen des Systems und der Admins so früh wie möglich auf Datenbanken der neuesten Exchange-Version verschoben werden. Dies muss aber auch auf einem der neuen Server initiiert werden. Die EMS verbindet aber automatisch auf die Legacy Server, wie wir gesehen haben. Ist das ein Huhn-Ei-Problem?

Die Lösung liegt darin, entweder das EAC zu verwenden … 

exchange-2013-migration-cu11-6

… oder die lokale PowerShell zu öffnen und die Exchange Snap-Ins manuell zu laden:

exchange-2013-migration-cu11-7

Achtung: Dies ist wirklich nur für diesen speziellen Fall unterstützt, da Role Based Access Control (RBAC) nicht korrekt funktioniert und Berechtigungsprobleme wahrscheinlich sind, wenn die Shell nicht über das PowerShell virtual Directory verbindet.

Zusätzliche administrative Accounts mit Postfächern in Umgebungen mit mehreren Standorten erlauben den Zugriff auf die EMS, auch wenn WAN-Links ausfallen oder einzelne Datenbanken nicht mehr gemountet werden können.

Microsoft Exchange Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings


Über den Autor

Markus Hengstler

Markus Hengstler arbeitet bei der UMB AG als Senior Systems Engineer in den Bereichen Exchange, Windows und Citrix. Dank seiner Erfahrungen in diesen Bereichen ist er zertifizierter «MCSE: Server Infrastructure». Ausserdem ist er einer von drei «MCSM: Messaging» in der Schweiz. Seit 2001 unterrichtet er als Microsoft Certified Trainer und seit 2010 als Citrix Certified Instructor bei Digicomp.