Fünf Exchange 2013-Migrationsprobleme, auf die Sie achten müssen

Exchange Server 2013 ist eine größere, komplexere Plattform, die einige der älteren Exchange-Funktionen hinterlässt …

zugunsten neuer zusammen mit einer besseren allgemeinen Zuverlässigkeit. Vor dem Upgrade auf die neueste Version ist es wichtig, dass Sie einige Faktoren kennen, die zu einer erfolgreichen Migration beitragen.

Exchange 2013-Migration Gotcha Nr. 1: Clients

So wie Exchange 2010 die Unterstützung für Outlook 2000 entfernt hat, entfernt Exchange 2013 die Unterstützung für Outlook 2003. Wenn es um Exchange 2013 geht, müssen Sie Outlook 2007, Outlook 2010 oder Outlook 2013 verwenden. Outlook 2007 muss Service Pack 3 zusammen mit November 2012 ausführen aktualisieren oder später, während Outlook 2010 Service Pack 1 zusammen mit November 2012 ausführen muss aktualisieren oder später.
Berücksichtigen Sie beim Patchen von Clients die Windows Server-Aktualisierungsdienste. Sie können auch das Microsoft Assessment and Planning-Toolkit sowie das Get-LogonStatistics Cmdlet in Exchange 2007 und Exchange Server User Monitor (ExMon) in Exchange 2010.
Und es ist nicht nur Outlook, über das Sie sich Sorgen machen müssen. Mit Exchange 2007 können Benutzer Outlook Web Access mit einer Version von Internet Explorer ab IE6 in seiner ganzen Pracht erleben. In Exchange 2010 ist IE7 die Mindestversion, die zum Ausführen der Premium Outlook-Webanwendung erforderlich ist. Daher sollte es niemanden überraschen, dass IE8 für Exchange 2013 erforderlich ist. Zum Zeitpunkt des Schreibens weist IE8 jedoch Leistungsprobleme beim Ausführen von Outlook Web App 2013 auf. Betrachten Sie daher IE9 als Basis. Es bietet Benutzern die beste OWA 2013-Erfahrung unter Vista und höher.
Für Windows XP und andere Betriebssysteme bieten Browser von Drittanbietern wie Firefox (v17 +), Chrome (v24 +) und Safari (v6 + auf Mac) ebenfalls hervorragende Unterstützung für Exchange 2013. In der Tabelle der unterstützten Clients im TechNet von Microsoft finden Sie Informationen Seite? ˅ für die aktuellsten Informationen.

Exchange 2013-Migration Gotcha Nr. 2: Outlook Web App-Umleitung

Dies betrifft Unternehmen, die von Exchange 2007 migrieren und die formularbasierte Authentifizierung (FBA) in Exchange verwenden. Zuvor funktionierte bei der Migration eines Unternehmens von Exchange 2003 oder Exchange 2007 zu Exchange 2010 die Legacy-Koexistenz mit FBA sehr gut. Wenn sich ein Benutzer bei OWA anmeldete, wurde er zum Legacy-Server umgeleitet, und der Benutzername und das Kennwort wurden zusammen mit der Umleitungsanforderung übergeben.
In einem Koexistenzszenario mit Exchange 2007 und Exchange 2013 (unter Verwendung von FBA) werden Benutzername und Kennwort nicht übergeben, wenn sich ein Exchange 2007-Benutzer anmeldet. Der Benutzer wird zu einem Exchange 2007-Server umgeleitet und muss sich ein zweites Mal anmelden. Wenn Sie eine längere Koexistenz erwarten, prüfen Sie, wie Sie dieses Problem umgehen können.
Wenn Sie Forefront TMG 2010 bereits zur Durchführung der Vorauthentifizierung und der formularbasierten Authentifizierung verwenden, können Sie es weiterhin verwenden. Alternativ bieten verschiedene Load Balancer von Drittanbietern eine integrierte Unterstützung vor der Authentifizierung.
Wenn Sie bereits Windows Integrated Authentication für Outlook Web App-Anmeldungen implementiert haben, sind Sie davon nicht betroffen.

Exchange 2013-Migration Gotcha Nr. 3: Outlook Anywhere

Die gesamte Kommunikation für Outlook-Clients mit Exchange 2013 verwendet HTTPS anstelle der in früheren Versionen verwendeten Kombination aus RPC / MAPI und HTTPS. Dies bedeutet insbesondere, dass Outlook Anywhere sowohl für interne als auch für externe Clients verwendet wird. Postfächer, die sich während des Koexistenzzeitraums noch in Exchange 2007 und / oder Exchange 2010 befinden, werden weiterhin intern über herkömmliches RPC / MAPI verbunden.
Wenn Ihre Organisation Outlook Anywhere extern verwendet, stellen Sie sicher, dass Outlook Anywhere auch in Exchange 2007 und / oder Exchange 2010 aktiviert ist. Dies liegt daran, dass Exchange 2013 Outlook Anywhere-Anforderungen an die Version von Outlook Anywhere weiterleitet, die der Version von Exchange Server, dem Postfach, entspricht ist an.
Es ist nicht ganz so einfach, Outlook Anywhere nur zu aktivieren oder aktiviert zu lassen. Sie müssen sicherstellen, dass die NTLM-Authentifizierung auf IIS-Ebene sowohl für Exchange 2007 als auch für Exchange 2010 aktiviert ist.
Eine weitere Sache, wenn es um Outlook Anywhere geht: Wenn auf den Exchange 2007-Servern, auf denen Outlook Anywhere ausgeführt wird, auch die Rollen Clientzugriffsserver und Postfachserver ausgeführt werden – und kein globaler Katalogserver – müssen Sie IPv6 deaktivieren, wie in der Knowledge Base beschrieben Artikel 2794253

Exchange 2013-Migration Gotcha Nr. 4: Größe und Leistung

Leistung und Größe können sich bei jeder Exchange 2013-Migration als umstritten erweisen. Einsatz Orientierungshilfe wurde im Mai 2013 veröffentlicht, was bedeutet, dass frühe Bereitstellungen, die nicht von der Unterstützung von Microsoft profitiert haben, ihre Spezifikationen nicht neu bewerten müssen. Andere haben die vorhandenen Richtlinien für die Größenbestimmung von Exchange 2010 falsch betrachtet, um eine allgemeine Übersicht über die benötigte Hardware zu erhalten. Einige haben den Fehler gemacht, RAM und CPU zu verdoppeln.
Wenn Sie dies getan haben, geraten Sie nicht in Panik, sondern stellen Sie fest, dass Sie möglicherweise zusätzliche Hardware kaufen müssen. Die Größe von Exchange 2013 unterscheidet sich grundlegend und ist nicht so einfach wie ein bisschen mehr Leistung. Stattdessen müssen Sie überlegen, wie Sie Exchange 2013 am besten bereitstellen können.
JBOD (nur ein paar Festplatten) ist für viele Kunden eine großartige Option, dank der Funktionen zur automatischen Neueinstellung, die massive Festplatteneinsparungen ermöglichen. Die Exchange-Produktgruppe auch Befürworter die Verwendung von “Bausteinen”, bei denen es sich um Server handelt, die nur über lokalen Speicher verfügen. Beispielsweise haben Sie möglicherweise 12 interne vier TB-Festplatten als Exchange Server-Basis. Verwenden Sie diese anstelle teurer Add-On-Arrays. Möglicherweise wird die Anzahl der Benutzer pro Server geringer sein, Sie verwenden jedoch weniger Festplatten und profitieren von einer verbesserten Zuverlässigkeit.
Wie bei jeder Exchange Server 2013-Implementierung ist die Verwendung von JetStress ein wichtiger Schritt, um sicherzustellen, dass das Speichersubsystem die erwartete Last verarbeiten kann. JetStress wurde für Exchange 2013 aktualisiert und steht für zur Verfügung herunterladen — aber achten Sie auf. Wenn Sie JetStress noch nicht kennen oder die Best Practices von Microsoft befolgen möchten, werden Sie darauf hingewiesen, dass die aktualisierte Version des JetStress Field Guide noch nicht veröffentlicht wurde.
Darüber hinaus wurde LoadGen, das ergänzende Tool zum Testen einer realen Aktivitätssimulation, ebenfalls nicht veröffentlicht. Wenn diese Tools für Ihre Bereitstellung unerlässlich sind, müssen Sie sie möglicherweise – zumindest vorerst – festhalten.

Exchange 2013-Migration Gotcha Nr. 5: Mehrdeutige Namespaces und Exchange 2010-Migrationen

Was genau sind Namespaces? Im Kontext von Exchange Server sind dies die Namen, die verwendet werden, um eine interne und externe Verbindung zu Exchange über HTTPS sowie eine interne Verbindung zu Outlook-Clients über RPC / MAPI herzustellen.
Während des Koexistenzzeitraums einer Migration von Exchange 2010 zu Exchange 2013 müssen Sie die DNS-Einträge für Ihre InternalURLs und ExternalURLs aktualisieren, um auf Ihre Exchange 2013-Infrastruktur zu verweisen. Clients mit Exchange 2010-Postfächern verfügen über HTTPS-Dienste, die hinter den Kulissen auf die Exchange 2010-Server übertragen werden.
Eine Exchange-Implementierung, die den Empfehlungen von Microsoft folgt, verwendet einen einzigen Satz von Namen für interne und externe HTTPS-URLs (z. B. mail.contoso.com) und einen separaten Namen für das RPC-Clientzugriffsarray (z. B. Outlook.contoso.local) ). Wenn der HTTPS-Name nach Exchange 2013 verschoben wird, bleibt der Name des RPC-Clientzugriffsarrays in Exchange 2010 erhalten.
Hier gibt es ein Problem für Organisationen, die Namespaces falsch implementiert haben. Einige Exchange 2010-Implementierungen verwenden einen externen HTTPS-Namespace (nennen Sie ihn erneut mail.contoso.com). Verwenden Sie jedoch intern denselben Namen für die internen URLs und das RPC-Clientzugriffsarray (z. B. Outlook.contoso.com für RPC /). MAPI und Dienste wie OWA).
Wenn Sie den internen Namen nach Exchange 2013 verschieben, wird die vorhandene Outlook-Clientkonnektivität unterbrochen. Der Trick hier besteht darin, Ihre internen HTTPS-URLs zu aktualisieren, um die externen HTTPs-URLs zu verwenden. Möglicherweise möchten Sie in Betracht ziehen, Split-DNS oder punktgenaue DNS in diesem Prozess zu implementieren.
Eine kleine Anzahl von Organisationen hat einen einzigen Namen implementiert, sowohl für interne als auch externe HTTPS-URLs und das RPC-Clientzugriffsarray. Wenn dies Ihr Setup beschreibt, müssen Sie wahrscheinlich den Namen Ihres RPC-Clientzugriffsarrays in einen eindeutigen Namen ändern. Leider wird dies nicht automatisch an Clients weitergegeben, und Sie müssen möglicherweise entweder die Aktualisierung von Outlook-Clients erzwingen oder die von Microsoft vorgeschlagenen internen Outlook-Clients in Exchange 2010 nach Outlook Anywhere verschieben.

Abschließende Gedanken

Einige dieser Fallstricke klingen vielleicht nach ernsthaften Problemen, aber lassen Sie sich nicht davon abhalten. Mit den richtigen Informationen können Sie problemlos eine erfolgreiche Exchange 2013-Bereitstellung abschließen.
Über den Autor:
Steve Goodman ist ein Exchange MVP und arbeitet als technischer Architekt für einen der führenden britischen Microsoft Gold-Partner, die Phoenix IT Group. Goodman ist seit 14 Jahren in der IT-Branche tätig und arbeitet seit Version 5.5 intensiv mit Microsoft Exchange zusammen.

Similar Posts

Leave a Reply