Auf diese fünf Probleme stoßen Admins bei der Migration auf Exchange 2013

Bei der Migration auf Exchange Server 2013 gibt es einige Fallstricke. Dieser Artikel beschreibt fünf Punkte, die Administratoren beachten sollten.

Microsoft Exchange Server 2013 ist im Vergleich zu den Vorgängern eine größere, komplexere Plattform. Sie gibt einige der bestehenden Funktionen der bisherigen Versionen von Exchange auf und verbessert mit neuen Funktionen die Zuverlässigkeit des Gesamtsystems. Bevor Sie auf die neueste Version von Exchange Server aktualisieren, sollten Sie folgende Fallstricke bei der Migration kennen.

Fallstrick 1: Clients

Ähnlich wie bei Microsoft Exchange 2010, das Outlook 2000 nicht mehr unterstützte, fällt mit Exchange 2013 der Support für Outlook 2003 weg. Das heißt: Wenn Sie Exchange Server 2013 installieren, müssen Sie Outlook 2007 oder neuer verwenden. Outlook 2007 muss das Service Pack 3 mit Update ab November 2012 oder später unterstützen, Outlook 2010 das Service Pack 1 mit dem Update ab November 2012 oder später.

Beim Patchen der Clients sollten Sie die Windows Server Update Services nutzen. Sie können auch das Microsoft Assessment and Planning Toolkit, das Get-LogonStatistics cmdlet in Exchange 2007 und den Exchange Server User Monitor (ExMon) in Exchange 2010 verwenden.

Outlook ist nicht die einzige Baustelle, um die Sie sich sorgen müssen. Mit Exchange 2007 konnten Anwender noch mit dem Internet Explorer 6 Outlook Web Access verwenden. Ab Exchange 2010 stellt der IE 7den Mindeststandard dar, um Outlook Web App optimal benutzen zu können. Für Exchange 2013 ist der IE 8 erforderlich, noch besser sind aber neuere Versionen des Internet Explorer.

Externe Browser wie Firefox (v17 +), Chrome (V24 +) und Safari (v6 +) unterstützen Exchange 2013 in Microsoft Windows und anderen Betriebssystemen. Weitere Informationen und eine Kompatibilitätsliste finden Sie auf der Microsoft TechNet-Website.

Fallstrick 2: Weiterleitung zu Outlook Web App

Dieser Punkt betrifft Unternehmen, die von Exchange 2007 auf Exchange 2013 migrieren und die formularbasierte Authentifizierung (Forms Based Authentication, FBA) in Exchange verwenden. Als Unternehmen von Exchange 2003 oder Exchange 2007 auf Exchange 2010 migrierten, klappte die Zusammenarbeit der bestehenden Systeme mit FBA noch gut. Wenn sich ein Benutzer bei Outlook Web App anmeldete, wurde er an den bestehenden Server weitergeleitet. Der Benutzername und das Passwort wurden zusammen mit dem Redirection Request übergeben.

In einem Szenario, bei dem Exchange 2007 und Exchange 2013 (mit FBA) nebeneinander existieren, werden Benutzername und Kennwort nicht übergeben, wenn sich ein Benutzer von Exchange 2007 anmeldet. Der Benutzer wird auf einen Exchange 2007 Server umgeleitet und muss sich erneut anmelden. Dieses Problem sollten Sie lösen, wenn Sie eine längere Koexistenz der beiden Systeme erwarten.

Wenn Sie bereits Forefront TMG 2010 für die Pre-Authentifizierung und formularbasierte Authentifizierung einsetzen, können Sie das weiter tun. Alternativ bieten externe Anbieter von Load Balancern integrierte Pre-Authentifizierung. Wenn Sie die Windows Authentifizierung für Outlook Web App-Logins bereits implementiert haben, sind sie nicht davon betroffen.

Fallstrick 3: Outlook Anywhere

Die gesamte Kommunikation für Outlook-Clients in Exchange 2013 läuft über HTTPS, statt über die aus früheren Versionen bekannte Kombination von RPC / MAPI und HTTPS. Konkret bedeutet dies, dass Outlook Anywhere sowohl für interne als auch externe Clients verwendet wird. Postfächer, die sich während der Phase der Koexistenz immer noch auf Exchange 2007 und/ oder Exchange 2010 befinden, werden weiterhin intern über das traditionelle RPC/ MAPI verbunden.

Wenn Ihr Unternehmen Outlook Anywhere extern nutzt, stellen Sie sicher, dass Outlook Anywhere auch auf Exchange 2007 und/ oder Exchange 2010 aktiviert ist. Der Grund: Exchange 2013 leitet Anfragen von Outlook Anywhere an die Version von Outlook Anywhere weiter, die der Version von Exchange Server entspricht, auf der sich das Postfach befindet.

Es genügt nicht, Outlook Anywhere entweder zu aktivieren oder deaktiviert zu lassen. Sie müssen sicherstellen, dass die NTLM-Authentifizierung auf der IIS-Ebene sowohl für Exchange 2007 als auch für Exchange 2010 aktiviert ist. Ein weiterer Punkt: Wenn die Exchange 2007 Server, auf denen Outlook Anywhere läuft, auch die Client Access Server- und Mailbox Server-Rollen betreiben, und nicht ein globaler Katalog Server, müssen Sie IPv6 deaktivieren. Infos dazu finden Sie in Artikel 2794253 der Knowledge Base.

Fallstrick 4: Dimensionierung und Leistung

Leistung und Dimensionierung stellen einen kritischen Aspekt jeder Exchange 2013-Migration dar. Microsoft hat seinen Deployment Guide im Mai 2013 veröffentlicht. Das heißt: Bei früheren Upgrade-Projekten, die nicht von dieser Hilfestellung profitieren, dürften die Spezifikationen passen, sie sind nicht neu zu bewerten. In anderen Projekten bildeten möglicherweise vorhandene Exchange 2010-Anleitungen die Grundlage für die Dimensionierung der Hardware. Daher begingen einige Projektleiter den Fehler, Ressourcen wie CPU oder RAM zu verdoppeln.

Ist dies der Fall, besteht kein Grund zur Panik. Es kann aber sein, dass Sie zusätzliche Hardware kaufen müssen, da die Dimensionierung von Exchange 2013 grundlegend anders ist und es ist nicht genügt, einfach zusätzliche Ressourcen bereitzustellen. Es sind tiefergehende Überlegungen notwendig.

Viele Kunden denken, Just a Bunch Of Disks (JBOD) ist eine gute Option, da sie dank der Auto-Reseed Funktion den Bedarf an Speicherplatz massiv senken können. JBOD lässt mehrere Festplatten als eine große erscheinen, erreicht dies aber nur durch Kombination der Laufwerke zu einem größeren logischen Laufwerk. Die Exchange-Produktgruppe unterstützt den Einsatz von Bausteinen (Building Blocks), sprich Servern, die nur über lokalen Speicher verfügen. 

Ein Beispiel: Sie verfügen über zwölf interne 4 TB Festplatten als Basis für den Exchange Server. Nutzen Sie diese Festplatten statt zusätzlicher teurer Arrays. Es kann sein, dass sie weniger Anwender pro Server betreuen können, Sie benötigen aber weniger Speicherplatz und erhalten eine zuverlässigere Lösung.

Bei jeder Implementierung von Exchange Server 2013 spielt JetStress für Belastungs- und Stabilitätstest eine wichtige Rolle. Das Tool simuliert den Zugriff eines Exchange Servers auf die Speicher-Subsysteme und ist damit ein guter Gradmesser für die Leistung eines Systems. JetStress wurde für Exchange 2013 aktualisiert und steht zum Download zur Verfügung.

Fallstrick 5: Mehrdeutige Namensräume und Migrationen auf Exchange 2010

Was genau sind Namensräume? Beim Exchange Server bilden sie die Namen, die für die interne und externe Verbindung mit Exchange über HTTPS sowie die interne Verbindung zu Outlook-Clients mit RPC/ MAPI verwendet werden.

Mehr zum Thema Microsoft Exchange:

Probleme mit dem Microsoft Exchange Autoermittlungsdienst lösen.

Die zehn wichtigsten PowerShell Cmdlets für Microsoft Exchange 2013.

Eine Einführung in die Microsoft Exchange ActiveSync-Quarantäne-Funktion.

Häufige Probleme des Microsoft Exchange Hub-Transport-Servers beheben.

Microsoft Exchange: Probleme mit der Frei/Gebucht-Funktion beheben.

Während der Migration von Exchange 2010 auf Exchange 2013 existieren beide Systeme eine Zeit lang parallel. Daher müssen Sie die DNS-Einträge für interne und externe URLs aktualisieren, um sie an die Exchange 2013-Infrastruktur zu verweisen. Clients mit Exchange 2010 Postfächern werden via HTTPS Services auf Exchange 2010 Server geleitet.

Eine Exchange-Implementierung, die den Empfehlungen von Microsoft folgt, verwendet einen einzigen Namen für die internen und externen HTTPS-URLs (zum Beispiel mail.contoso.com) und einen eigenen Namen für das RPC-Client-Zugriff-Array (beispielsweise outlook.contoso.local). Während der HTTPS-Name zu Exchange 2013 verschoben wird, bleibt der Name des RPC-Client-Zugriffs-Arrays auf Exchange 2010.

Hier existiert ein Fallstrick für Unternehmen, die die Namensräume falsch implementiert haben. Einige Exchange 2010 Installationen verwenden einen externen HTTPS-Namensraum (zum Beispiel mail.contoso.com), nutzen aber intern den gleichen Namen für interne URLs und das RPC-Client-Zugriffs-Array (zum Beispiel outlook.contoso.com für RPC / MAPI und Services wie Outlook Web App).

Wenn Sie den internen Namen auf Exchange 2013 übertragen, bricht die Verbindung zu den bestehenden Outlook Clients ab. Der Trick: Aktualisieren Sie ihre internen HTTPS-URLs, um die externen HTTPS-URLs zu verwenden. Es ist auch möglich, während dieses Prozesses Split DNS oder Pinpoint DNS zu nutzen.

Wenige Unternehmen nutzen einen einzigen Namen sowohl für die internen und externen HTTPS-URLs als auch das RPC-Client-Zugriffs-Array. Trifft dies auf Ihre Umgebung zu, müssen Sie den Namen des RPC-Client-Zugriffs-Arrays ändern, damit er einzigartig ist. Diese Änderung wird aber nicht automatisch auf die Outlook-Clients übertragen. Die Lösung: Sie aktualisieren die Outlook Clients oder verlagern die internen Outlook-Clients von Exchange 2010 auf Outlook Anywhere. Microsoft empfiehlt letzteres.

Fazit

Einige der fünf beschriebenen Punkte hören sich wie ernste Probleme an. Lassen Sie sich davon nicht abschrecken. Mit den richtigen Informationen werden Sie erfolgreich auf Exchange 2013 migrieren.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Juli 2015 aktualisiert

Erfahren Sie mehr über Exchange-Management

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close