(0) exportieren Drucken
Alle erweitern

Exchange Online-Migrationsleistung und bewährte Methoden

Exchange Online
 

Gilt für: Exchange Server 2013, Exchange Server, Exchange Online

Letztes Änderungsdatum des Themas: 2014-06-12

Daten können auf unterschiedliche Weise aus einer lokalen E-Mail-Organisation zu Microsoft Exchange Online in Microsoft Office 365 migriert werden. Bei der Planung einer Migration zu Exchange Online stellt sich häufig die Frage nach einer Verbesserung der Datenmigrationsleistung sowie nach einer Optimierung der Migrationsgeschwindigkeit.

HinweisHinweis:
Die in diesem Thema angegebenen Leistungsdaten gelten nicht für dedizierte Abonnementpläne des Microsoft Office 365-Dienstes. Weitere Informationen zu dedizierten Plänen finden Sie unter Dienstbeschreibungen für dedizierte Office 365-Pläne.

Exchange Online ist Bestandteil von Office 365 und bietet Organisationen eine cloudbasierte Nachrichtenlösung, die auf Microsoft Exchange Server basiert. Exchange Online unterstützt verschiedene Methoden zum Migrieren von E-Mail-, Kalender- und Kontaktdaten von der vorhandenen Nachrichtenumgebung zu Office 365.

Häufig verwendete Migrationsmethoden

Migrationsmethode Beschreibung Ressourcen

IMAP-Migration

Sie können mit der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell den Inhalt der Benutzerpostfächer von einem IMAP-Nachrichtensystem zu den Exchange Online-Postfächern der Benutzer migrieren. Hierzu gehört auch das Migrieren der Postfächer von anderen gehosteten E-Mail-Diensten, z. B. Google Mail oder Yahoo Mail.

Weitere Informationen finden Sie unter IMAP-Migration.

Übernahmemigration

Mithilfe einer Übernahmemigration können Sie alle lokalen Postfächer innerhalb von wenigen Tagen zu Exchange Online migrieren. Dieser Migrationstyp bietet sich an, wenn Sie planen, Ihre gesamte E-Mail-Organisation zu Office 365 zu verschieben und Benutzerkonten in Office 365 zu verwalten. Bei einer Übernahmemigration können maximal 2.000 Postfächer aus der lokalen Exchange-Organisation zu Exchange Online migriert werden. Die E-Mail-Kontakte und Verteilergruppen in Ihrer lokalen Exchange-Organisation werden ebenfalls migriert.

Weitere Informationen finden Sie unter Exchange-Übernahmemigration.

Mehrstufige Migration

Verwenden Sie eine mehrstufige Migration, wenn Sie planen, sämtliche Postfächer Ihres Unternehmens nach und nach zu Exchange Online zu migrieren. Wenn Sie eine mehrstufige Migration verwenden, werden Batches lokaler Postfächer über einen Zeitraum von ein paar Wochen oder Monaten zu Exchange Online migriert. Ihr Ziel besteht darin, die E-Mail-Organisation dauerhaft in Office 365 zu verschieben

Weitere Informationen finden Sie unter Mehrstufige Exchange-Migration.

Hybridbereitstellung

Eine Hybridbereitstellung bietet Unternehmen die Möglichkeit, den Funktionsreichtum und die Verwaltungskontrolle, die die vorhandene lokale Microsoft Exchange-Organisation bietet, auf die Cloud auszudehnen. Eine Hybridbereitstellung bietet für eine lokale Exchange 2013 oder 2010-Organisation und Exchange Online in Microsoft Office 365 ein einheitliches Erscheinungsbild als nahtlose Exchange-Organisation. Darüber hinaus kann eine Hybridbereitstellung als Zwischenschritt vor dem vollständigen Wechsel zu einer Exchange Online-Organisation dienen.

Weitere Informationen finden Sie unter Hybridbereitstellungen mit Exchange 2013

Migration mit Drittanbietern

Es sind viele Tools von Drittanbietern erhältlich. Sie nutzen eigene Protokolle und Methoden für E-Mail-Migrationen von E-Mail-Plattformen wie IBM Lotus Notes und Novell GroupWise.

Unten sind einige Migrationstools von Drittanbietern und Partnerunternehmen aufgeführt, die Sie bei Exchange-Migrationen von Drittanbieter-Plattformen unterstützen können:

  • Binary Tree   Anbieter von Software für die plattformübergreifende Messagingmigration und Koexistenz. Die Produkte ermöglichen die Analyse und die Koexistenz und Migration zwischen lokalen Umgebungen und Onlineumgebungen für Messaging und Zusammenarbeit in Unternehmen, die auf IBM Lotus Notes und Domino sowie Microsoft Exchange und Microsoft SharePoint basieren.

  • BitTitan   Anbieter von Lösungen für die Migration zu Exchange Online.

  • Dell   Anbieter von Software für lokale und gehostete Migration und Koexistenz, einschließlich Software für die Analyse vor der Migration und umfassende Benutzer- und Anwendungskoexistenz. Umfassende Migrationen von lokalen Microsoft Exchange-, IBM Domino-, Novell GroupWise-, Zimbra- und anderen Umgebungen zu Microsoft Office 365, Exchange Online und SharePoint Online.

  • Metalogix   Anbieter von Lösungen für die Migration zu Exchange Online und SharePoint Online.

  • TransVault   Anbieter von Lösungen für die Migration zu Exchange Online.

Die folgende Tabelle enthält einen Vergleich der ermittelten Leistungsergebnisse der unterschiedlichen Migrationsmethoden für die Migration von Postfächern und Postfachdaten zu Exchange Online in Office 365. Die Ergebnisse basieren auf internen Tests und echten Kundenmigrationen zu Office 365.

WichtigWichtig:
Aufgrund der vielen Unterschiede bei Ausführungsart und -zeitpunkt dieser Migrationen kann die Migrationsgeschwindigkeit bei Ihnen auch geringer oder höher ausfallen.

 

Migrationsmethode Einschränkungen für Office 365-Benutzer Einschränkungen für den Office 365-Migrationsdienst Einschränkungen aufgrund der Office 365-Ressourcenintegrität Ermittelter durchschnittlicher Durchsatz pro Stunde und Client (sofern zutreffend)

IMAP-Migration

Nein

Ja

Ja

10 bis 15 GB (100 gleichzeitig)

Übernahmemigration

Nein

Ja

Ja

10 bis 15 GB (100 gleichzeitig)

Mehrstufige Migration

Nein

Ja

Ja

10 bis 15 GB (100 gleichzeitig)

Hybridmigration

Nein

Ja

Ja

10 bis 15 GB pro lokalem Exchange 2013- oder 2010-Clientzugriffsserver (MRS Proxy) mit 20 gleichzeitigen Verschiebungen1

Drittanbieter-MAPI-Migration

Ja

Nein

Ja

4 bis 12 GB (20 gleichzeitig) 3

Drittanbieter-EWS-Migration

Nein

Ja

Ja

5 bis10 GB (20 gleichzeitig) 2

Hochladen von Clientdaten (von Outlook PST)

Ja

Nein

Ja

0.5 GB

1Der gemessene Durchsatz bei der Verschiebung einzelner Postfächer liegt im Bereich von 0,3 bis 1,0 GB/Stunde.. Zur Erzielung höherer Migrationsraten könnten mehr gleichzeitige Postfachmigrationen erfolgen. Bei 50 gleichzeitigen Verschiebungen liegt der Gesamtdurchsatz beispielsweise im Bereich 15 bis 50 GB/Stunde. Der Durchsatz bei der Verschiebung einzelner Postfächer verschlechtert sich, wenn der lokale Clientzugriffsserver (MRS-Proxy) die Grenzen seiner Hardwarekapazität erreicht. Erwägen Sie das Hinzufügen weiterer Server, um die Migration zu beschleunigen.

2Der gemessene Durchsatz bei einer einzelnen EWS-Migration liegt im Bereich von 0,2 bis 0,5 GB/Stunde. Zur Erzielung höherer Migrationsraten könnten mehr gleichzeitige Migrationen erfolgen. Bei 100 gleichzeitigen Migrationen liegt der Gesamtdurchsatz beispielsweise im Bereich 20 bis 50 GB/Stunde. Der Durchsatz bei einer einzelnen EWS-Migration verschlechtert sich, wenn lokale Server oder das Netzwerk die Kapazitätsgrenze erreichen.

3Der gemessene Durchsatz bei einer einzelnen MAPI-Migration liegt im Bereich von 0,1 bis 0,5 GB/Stunde. Zur Erzielung höherer Migrationsraten könnten mehr gleichzeitige Migrationen erfolgen. Der Durchsatz bei einer einzelnen MAPI-Migration verschlechtert sich, wenn lokale Server oder das Netzwerk die Kapazitätsgrenze erreichen.

Bei der E-Mail-Migration sind einige allgemeinen Faktoren gegeben, die sich auf die Migrationsleistung auswirken können.

Die folgende Tabelle enthält allgemeine Faktoren, die die Migrationsleistung beeinflussen. Weitere Details finden Sie in den Abschnitten zu den einzelnen Migrationsmethoden.

 

Faktor Beschreibung Beispiel

Datenquelle

Das Gerät oder der Dienst, von dem die zu migrierenden Daten gehostet werden. Bedingt durch Hardwarespezifikationen, Endbenutzerarbeitsauslastung und Back-End-Wartungsaufgaben können für Datenquellen unterschiedlichste Beschränkungen gelten.

Bei Google Mail wird die Menge der Daten beschränkt, die innerhalb eines bestimmten Zeitraums extrahiert werden können.

Datentyp und -dichte

Aufgrund der Einzigartigkeit von Kundenunternehmen ergeben sich große Unterschiede bei der Art und Zusammensetzung der E-Mail-Elemente innerhalb von Postfächern.

Ein Postfach mit einer Größe von 4 GB und 400 Elementen mit jeweils einer 10-MB-Anlage kann schneller migriert werden als ein Postfach der gleichen Größe und 100.000 kleineren Elementen.

Migrationsserver

Bei vielen Migrationslösungen kommt ein JumpBox-ähnlicher Migrationsserver bzw. eine entsprechende Arbeitsstation zum Einsatz, um die Migration abzuschließen.

Kunden verwenden oft einen leistungsschwachen virtuellen Computer zum Hosten des MRS-Proxys für Hybridbereitstellungen oder eines Client-PCs für Migrationen von Nicht-Hybridbereitstellungen.

Migrationsmodul

Das Datenmigrationsmodul, mit dem die Daten vom Quellserver abgerufen werden, konvertiert die Daten bei Bedarf, überträgt sie über das Netzwerk und fügt sie in das Exchange Online-Postfach ein.

Microsoft Exchange-Postfachreplikationsdienst (Mailbox Replication Service, MRS) weist eigene Fähigkeiten und Einschränkungen auf.

Lokale Netzwerkgeräte

Die Leistung des gesamten Netzwerks – von der Datenquelle bis hin zu den Exchange Online-Clientzugriffsservern – hat Auswirkungen auf die Migrationsleistung.

Firewallkonfiguration und Spezifikationen für die lokale Organisation.

Office 365-Dienst

Office 365 verfügt über integrierte Unterstützung sowie über Features zum Verwalten der Migrationsarbeitslast.

Die Benutzereinschränkungsrichtlinie begrenzt die maximale Datenübertragungsrate.

In diesem Abschnitt werden bewährte Methoden zur Verbesserung der Netzwerkleistung bei der Migration beschrieben. Die Informationen sind allgemein gehalten, da die größten Auswirkungen auf die Netzwerkleistung bei der Migration auf Drittanbieterhardware und Internetdienstanbieter (Internet Service Providers, ISPs) zurückzuführen sind.

Das Office 365-Netzwerkanalysetool wird bereitgestellt, um netzwerkbezogene Probleme vor der Bereitstellung der Office 365-Dienste zu analysieren:

 

Faktor Beschreibung Bewährte Methoden

Netzwerkkapazität

Die Zeit, die für das Migrieren der Postfächer zu Exchange Online benötigt wird, ist abhängig von der verfügbaren und der maximalen Kapazität des Netzwerks.

  • Ermitteln Sie die verfügbare Kapazität Ihres Netzwerks sowie die maximale Uploadkapazität.

  • Erkundigen Sie sich bei Ihrem ISP nach der zugewiesenen Bandbreite sowie nach Details zu Beschränkungen (beispielsweise nach der Gesamtmenge der Daten, die innerhalb eines bestimmten Zeitraums übertragen werden kann).

  • Ermitteln Sie Ihre tatsächliche Netzwerkkapazität mithilfe von Tools. Messen Sie dabei den kompletten Datenfluss – von der lokalen Datenquelle zu den Gatewayservern des Microsoft-Datenzentrums.

  • Ermitteln Sie andere Lasten in Ihrem Netzwerk (wie Sicherungsdienstprogramme und geplante Wartungsaufgaben), die möglicherweise Ihre Netzwerkkapazität beeinflussen.

Netzwerkstabilität

Ein schnelles Netzwerk führt nicht automatisch zu schnellen Migrationen. Ist das Netzwerk nicht stabil, nehmen Datenübertragungen aufgrund der Fehlerkorrektur mehr Zeit in Anspruch. Je nach Migrationstyp wird die Migrationsleistung durch die Fehlerkorrektur unter Umständen erheblich beeinträchtigt.

Probleme mit Netzwerkhardware oder Treibern sind eine häufige Ursache für Probleme mit der Netzwerkstabilität. Machen Sie sich mit Unterstützung der Hersteller Ihrer Hardware mit Ihren Netzwerkgeräten vertraut, und wenden Sie die aktuellen empfohlenen Treiber- und Softwareupdates des Herstellers an.

Netzwerkverzögerungen

Wenn für eine Firewall im Netzwerk die Angriffserkennung konfiguriert ist, führt dies häufig zu deutlichen Netzwerkverzögerungen. Dies wirkt sich negativ auf die Migrationsleistung aus.

Die Datenmigration zu Exchange Online-Postfächern ist von Ihrer Internetverbindung abhängig. Internetverzögerungen beeinflussen die Gesamtleistung der Migration.

Darüber hinaus verfügen Benutzer im gleichen Unternehmen unter Umständen über Cloudpostfächer, die sich in Datenzentren an unterschiedlichen geografischen Orten befinden. Je nach ISP des Kunden kann die Migrationsleistung unterschiedlich sein.

  • Ermitteln Sie die Netzwerkverzögerungen für alle potenziellen Datenzentren von Microsoft, und vergewissern Sie sich, dass das Ergebnis einheitlich ist. (Dadurch wird auch ein einheitliches Ergebnis für Endbenutzer sichergestellt.) Bearbeiten Sie internetbezogene Probleme zusammen mit Ihrem ISP.

  • Fügen Sie IP-Adressen von Microsoft-Datenzentrumsservern Ihrer Zulassungsliste hinzu oder umgehen Sie sämtlichen migrationsbezogenen Datenverkehr von Ihrer Netzwerkfirewall. Weitere Informationen zu den IP-Adressbereichen für Office 365 finden Sie unter URLs und IP-Adressbereiche für Office 365.

In Office 365 werden verschiedene Einschränkungsmechanismen zur Gewährleistung der Sicherheit und Dienstverfügbarkeit eingesetzt. Die drei folgenden Einschränkungstypen können sich auf die Migrationsleistung auswirken:

  • Benutzereinschränkung

  • Migrationsdiensteinschränkung

  • Einschränkung aufgrund der Ressourcenintegrität

HinweisHinweis:
Die drei Einschränkungstypen von Office 365 wirken sich nicht alle Migrationsmethoden aus.

Die Benutzereinschränkung wirkt sich auf die meisten Drittanbieter-Migrationstools sowie auf die Migrationsmethode für Clientuploads aus. Bei diesen Migrationsmethoden werden Clientzugriffsprotokolle wie "RPC über HTTP" verwendet, um Postfachdaten zu Exchange Online-Postfächern zu migrieren. Mit den Tools werden in der Regel Daten von Plattformen wie IBM Lotus Domino und Novell GroupWise migriert.

Die Benutzereinschränkung ist die restriktivste Einschränkungsmethode in Office 365. Da die Benutzereinschränkung für die Verwendung für einen bestimmten Endbenutzer eingerichtet ist, wird bei einer Nutzung auf Anwendungsebene schnell die Einschränkungsrichtlinie überschritten, was eine langsamere Datenmigration zur Folge hat.

Die Migrationsdiensteinschränkung betrifft alle systemeigenen Office 365-Migrationstools. Von der Migrationsdiensteinschränkung werden gleichzeitige Migrationen und die Zuordnung von Dienstressourcen für systemeigene Office 365-Migrationslösungen verwaltet.

Die Migrationsdiensteinschränkung wirkt sich auf Migrationen aus, bei denen folgende Migrationsmethoden zum Einsatz kommen:

  • IMAP-Migration

  • Exchange-Übernahmemigration

  • Mehrstufige Exchange-Migration

  • Hybridmigrationen (MRS-proxybasierte Verschiebungen in einer Hybridumgebung)

Ein Beispiel für die Migrationsdiensteinschränkung ist die Steuerung der Anzahl von Postfächern, die im Rahmen von einfachen Exchange-Migrationen und IMAP-Migrationen gleichzeitig migriert werden. Der Standardwert ist 3. Das bedeutet, dass bei der Migration immer maximal drei Postfächer migriert werden. Die Anzahl gleichzeitiger Postfachmigrationen für einen Migrationsbatch kann in der Exchange-Systemsteuerung sowie in Windows PowerShell erhöht werden. Weitere Informationen zum Optimieren dieser Einstellung finden Sie unter Verwalten von Migrationsbatches in Exchange Online.

Alle Migrationsmethoden unterliegen der Steuerung der Verfügbarkeitseinschränkung, aber die Office 365-Diensteinschränkung wirkt sich nicht so stark auf Office 365-Migrationen aus wie die anderen weiter oben beschriebenen Einschränkungstypen.

Die Einschränkung aufgrund der Ressourcenintegrität ist die am wenigsten aggressive Einschränkungsmethode und tritt nur auf, wenn ein Problem mit der Dienstverfügbarkeit vorliegt, das sich auf Endbenutzer und auf kritische Dienstvorgänge auswirkt.

Tritt beispielsweise bei einer Hybridmigration ein Dienstvorfall auf und wird der Dienst so stark beeinträchtigt, dass dies für den Endbenutzer eine Beeinträchtigung der Leistung zur Folge hat, wird die Hybridmigration in die Warteschlange eingereiht, bis das Leistungsproblem behoben wurde und der Dienst wieder eine Ebene unterhalb des Einschränkungsschwellenwerts erreicht.

Im Folgenden finden Sie ein Beispiel aus einem Bericht zur Exchange-Migrationsstatistik. Hier sehen Sie einen Eintrag, der bei einer Überschreitung des Schwellenwerts für die Diensteinschränkung erstellt wird:

  • 1/25/2012 12:56:01 AM [BL2PRD0410CA012] Copy progress: 723/1456 messages, 225.8 MB (236,732,045 bytes)/416.5 MB (436,712,733 bytes).

  • 1/25/2012 12:57:53 AM [BL2PRD0410CA012] Move for mailbox '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication). Failure Reason: Database edbf0766-1f2a-4552-9115-bb3a53a8380b doesn’t satisfy constraint SecondDatacenter. There are no available healthy database copies. Will wait until 1/25/2012 1:27:53 AM.

  • 1/25/2012 12:58:24 AM [BL2PRD0410CA012] Request is no longer stalled and will continue.

Lösung und Praxis

Warten Sie in einer solchen Situation auf die Wiederherstellung des Office 365-Diensts. Weitere Informationen finden Sie im Abschnitt "Dienststatus" im Office 365-Portal.

In diesem Abschnitt werden Faktoren beschrieben, die sich auf Migrationen auswirken, die mit der IMAP-, Übernahme- oder mehrstufigen Exchange-Migrationsmethode ausgeführt werden. Zudem finden Sie hier bewährte Methoden zum Verbessern der Migrationsleistung.

In der folgenden Tabelle werden die durch Quellserver in Ihrer aktuellen E-Mail-Organisation verursachten Auswirkungen auf die Migration sowie die bewährten Methoden zum Verringern dieser Auswirkungen beschrieben:

 

Prüfliste Beschreibung Bewährte Methoden

Systemleistung

Das Extrahieren von Daten ist eine aufwändige Aufgabe. Das Quellsystem muss über ausreichend Ressourcen wie CPU-Zeit und Arbeitsspeicher verfügen, um eine optimale Migrationsleistung zu erzielen. Während der Migration erreicht das Quellsystem bei der regulären Endbenutzerarbeitsauslastung häufig beinahe die Kapazitätsgrenze. Bei unzureichenden Systemressourcen kann sich die zusätzliche Arbeitsauslastung durch die Migration daher für die Endbenutzer negativ bemerkbar machen.

Überwachen Sie die Systemleistung im Rahmen einer Pilotmigration. Ist das System ausgelastet, wird von der Verwendung eines aggressiven Migrationsplans für dieses System abgeraten, da dies eine langsame Migration sowie Probleme mit der Dienstverfügbarkeit zur Folge haben kann. Verbessern Sie möglichst die Leistung des Quellsystems. Fügen Sie dazu Hardwareressourcen hinzu, und verringern Sie die Systemlast, indem Sie Aufgaben und Benutzer auf andere Server auslagern, die von der Migration nicht betroffen sind.

Weitere Informationen finden Sie unter:

Bei der Migration einer lokalen Exchange-Organisation mit mehreren Postfachservern empfiehlt sich die Erstellung einer Migrationsbenutzerliste, die gleichmäßig über die verschiedenen Postfachserver verteilt ist. Zur Maximierung des Durchsatzes kann diese Liste auf der Grundlage der Leistung des jeweiligen Servers noch weiter optimiert werden.

Verfügt Server A beispielsweise über eine um 50 Prozent höhere Ressourcenverfügbarkeit als Server B, bietet es sich an, in einem Migrationsbatch den Benutzeranteil von Server A um 50 Prozent zu erhöhen. Ähnliche Methoden können auch für andere Quellsysteme angewendet werden. Migrationen sollten bei maximaler Ressourcenverfügbarkeit der Server ausgeführt werden, also beispielsweise außerhalb der Geschäftszeiten, an Wochenenden oder an Feiertagen.

Back-End-Aufgaben

Andere Back-End-Aufgaben, die während der Migration ausgeführt werden. Da Migrationen üblicherweise außerhalb der Geschäftszeiten durchgeführt werden, kommt es oftmals zu Konflikten mit anderen Wartungsaufgaben, die auf den lokalen Servern ausgeführt werden (beispielsweise Datensicherungen).

Prüfen Sie, welche anderen Systemaufgaben möglicherweise während der Migration ausgeführt werden. Es wird empfohlen, die Datenmigration zu einer Zeit auszuführen, in der keine anderen ressourcenintensiven Aufgaben erledigt werden.

Hinweis   Bei Kunden mit einem lokalen Microsoft Exchange-System handelt es sich bei den Back-End-Aufgaben häufig um Datensicherungslösungen sowie um die Wartung von Exchange-Informationsspeichern.

Einschränkungsrichtlinie

E-Mail-Systeme werden häufig mit einer Einschränkungsrichtlinie geschützt, die festlegt, welche Datenmenge innerhalb einer bestimmten Zeit wie schnell aus dem System extrahiert werden kann.

Überprüfen Sie, welche Einschränkungsrichtlinie für Ihr E-Mail-System bereitgestellt wurde. Bei Google Mail wird beispielsweise die Menge an Daten beschränkt, die innerhalb eines bestimmten Zeitraums extrahiert werden kann.

Je nach Version verfügt Microsoft Exchange über Richtlinien zum Beschränken des IMAP-Zugriffs auf den lokalen E-Mail-Server (bei IMAP-Migrationen) sowie zum Beschränken des RPC-über-HTTP-Zugriffs (bei Exchange-Übernahmemigrationen und mehrstufigen Exchange-Migrationen).

Führen Sie zum Überprüfen der Einschränkungseinstellungen in einer Exchange 2013-Organisation das Cmdlet Get-ThrottlingPolicy aus. Weitere Informationen finden Sie unter Verwaltung der Arbeitsauslastung in Exchange.

Weitere Informationen zu IMAP-Einschränkungen finden Sie unter Migrieren von E-Mails von einem IMAP-Server zu Exchange-Onlinepostfächern

Weitere Informationen zur RPC-über-HTTP-Einschränkung finden Sie hier:

Da es sich bei der IMAP-, der Übernahme- und der mehrstufigen Exchange-Migration um von der Cloud initiierte Migrationsmethoden mit Datenübertragung per Pull handelt, wird kein dedizierter Migrationsserver benötigt. Die Protokollhosts ("IMAP" oder "RPC über HTTP") mit Internetverbindung fungieren allerdings als Migrationsserver für die Migration von Postfächern und Postfachdaten zu Office 365. Daher gelten die Leistungsfaktoren und die bewährten Methoden, die im vorherigen Abschnitt über den Datenquellenserver für Ihre aktuelle E-Mail-Organisation beschrieben wurden, auch für die Internet-Edgeserver. Bei Exchange 2013-, Exchange 2010- und Exchange 2007-Organisationen fungiert der Clientzugriffsserver als Migrationsserver.

Weitere Informationen finden Sie unter:

  1. Verwaltung der Arbeitsauslastung in Exchange 2013

  2. Exchange 2010: Leistungsindikatoren für Clientzugriffsserver

  3. Exchange 2007: Überwachen von Clientzugriffsservern

Lösung und Praxis

Wenden Sie zur Verbesserung der Migrationsleistung die bewährten Methoden an, die oben beschrieben wurden.

IMAP-Migrationen, Übernahmemigrationen sowie mehrstufige Exchange-Migrationen werden mit dem Migrationsdashboard in der Exchange-Verwaltungskonsole in Exchange Online ausgeführt. Dieses Tool unterliegt der Office 365-Migrationsdiensteinschränkung.

Lösung und Praxis

Kunden können nun mithilfe von Windows PowerShell die Migrationsparallelität (beispielsweise die Anzahl der gleichzeitig zu migrierenden Postfächer) angeben. Der Standardwert ist 20. Nach der Erstellung des Migrationsbatches können Sie den Wert mithilfe des folgenden Windows PowerShell-Befehls auf maximal „100“ festlegen:

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

Weitere Informationen finden Sie unter Verwalten von Migrationsbatches in Exchange Online.

HinweisHinweis:
Verfügt die Datenquelle nicht über genügend Ressourcen für alle Verbindungen, wird von der Verwendung einer hohen Parallelität abgeraten. Beginnen Sie mit dem Wert "10", und erhöhen Sie ihn nach und nach. Überwachen Sie dabei die Leistung der Datenquelle, um Zugriffsprobleme für Endbenutzer zu vermeiden.

Überprüfungstests

Je nach Migrationsmethode können Sie folgende Überprüfungstests ausführen:

  • IMAP-Migrationen   Füllen Sie ein Quellpostfach vorab mit Beispieldaten auf. Stellen Sie anschließend mithilfe eines standardmäßigen IMAP-E-Mail-Clients wie Microsoft Outlook über das Internet (also von außerhalb des lokalen Netzwerks) eine Verbindung mit dem Quellpostfach her, und ermitteln Sie dann die Netzwerkleistung anhand der Downloaddauer für alle Daten aus dem Quellpostfach. Der Durchsatz liegt in der Größenordnung, die Kunden bei Verwendung des IMAP-Migrationstools in Office 365 erhalten, sofern keine weiteren Einschränkungen vorliegen.

  • Übernahme- und mehrstufige Exchange-Migrationen   Füllen Sie ein Quellpostfach vorab mit Beispieldaten auf. Stellen Sie anschließend über das Internet (also von außerhalb des lokalen Netzwerks) mit Microsoft Outlook per „RPC über HTTP“ eine Verbindung mit dem Quellpostfach her. Stellen Sie sicher, dass für die Verbindung der Cache-Modus verwendet wird. Ermitteln Sie die Netzwerkleistung, indem Sie prüfen, wie lange die Synchronisierung aller Daten aus dem Quellpostfach dauert. Der Durchsatz liegt in der Größenordnung, die Kunden bei Verwendung des IMAP-Migrationstools in Office 365 erhalten, sofern keine weiteren Einschränkungen vorliegen.

HinweisHinweis:
Bei richtigen IMAP-, Übernahme- oder mehrstufigen Exchange-Migrationen fällt zwar ein gewisser Mehraufwand an, der tatsächliche Durchsatz entspricht aber ungefähr den Ergebnissen dieser Überprüfungstests.

Office 365-Einschränkung aufgrund der Ressourcenintegrität betrifft Migrationen, die mit systemeigenen einfachen Office 365-Migrationstools ausgeführt werden. Weitere Informationen finden Sie im Abschnitt zur Office 365-Einschränkung aufgrund der Ressourcenintegrität.

Die Migration von Hybridbereitstellungen unterstützt die reibungslose Migration zwischen lokalen Servern mit Exchange 2003, Exchange 2007, Exchange 2010 oder Exchange 2013 und Exchange Online in Office 365.

Die Hybridbereitstellungsmigration ist mit Abstand die schnellste Methode für die Migration von Postfachdaten zu Office 365. Bei echten Kundenbereitstellungen wurden bereits Durchsatzraten von 100 GB/Stunde gemessen. Die folgende Tabelle enthält eine Auflistung der Faktoren, die für systemeigene Office 365-Hybridmigrationsszenarien gelten.

 

Prüfliste Beschreibung Bewährte Methoden

Systemleistung

Das Extrahieren von Daten ist eine aufwändige Aufgabe. Das Quellsystem muss über ausreichend Ressourcen wie CPU-Zeit und Arbeitsspeicher verfügen, um eine bessere Migrationsleistung zu erzielen. Während der Migration erreicht das Quellsystem bei der Bereitstellung der regulären Benutzerarbeitsauslastung häufig beinahe die Kapazitätsgrenze. Manchmal beeinträchtigt die zusätzliche Migrationsarbeitsauslastung sogar den Endbenutzerzugriff, da nicht genügend Systemressourcen zur Verfügung stehen.

Überwachen Sie die Systemleistung im Rahmen einer Pilotmigration. Ist das System ausgelastet, wird von der Verwendung eines aggressiven Migrationsplans für dieses System abgeraten, da dies eine langsame Migration sowie Probleme mit der Dienstverfügbarkeit zur Folge haben kann. Verbessern Sie möglichst die Leistung des Quellsystems. Fügen Sie dazu Hardwareressourcen hinzu, und verringern Sie die Systemlast, indem Sie Aufgaben und Benutzer auf andere Server auslagern, die von der Migration nicht betroffen sind.

Weitere Informationen finden Sie unter:

Bei der Migration einer lokalen Exchange-Organisation mit mehreren Postfachservern und Datenbanken empfiehlt sich die Erstellung einer Migrationsbenutzerliste, die gleichmäßig über die verschiedenen Postfachserver und Datenbanken verteilt ist. Zur Maximierung des Durchsatzes kann diese Liste auf der Grundlage der Leistung des jeweiligen Servers noch weiter optimiert werden.

Verfügt Server A beispielsweise über eine um 50 Prozent höhere Ressourcenverfügbarkeit als Server B, bietet es sich an, in einem Migrationsbatch den Benutzeranteil von Server A um 50 Prozent zu erhöhen. Ähnliche Methoden können auch für andere Quellsysteme angewendet werden.

Migrationen sollten bei maximaler Ressourcenverfügbarkeit der Server ausgeführt werden, also beispielsweise außerhalb der Geschäftszeiten, an Wochenenden oder an Feiertagen.

Back-End-Aufgaben

Andere Back-End-Aufgaben, die während der Migration ausgeführt werden. Da Migrationen üblicherweise außerhalb der Geschäftszeiten durchgeführt werden, kommt es oftmals zu Konflikten mit anderen Wartungsaufgaben, die auf den lokalen Servern ausgeführt werden (beispielsweise Datensicherungen).

Prüfen Sie, welche anderen Systemaufgaben möglicherweise während der Migration ausgeführt werden. Es wird empfohlen, die Datenmigration zu einer Zeit auszuführen, in der keine anderen ressourcenintensiven Aufgaben erledigt werden.

Hinweis   Bei Kunden mit einem lokalen Microsoft Exchange-System handelt es sich bei den Back-End-Aufgaben häufig um Datensicherungslösungen sowie um die Wartung von Exchange-Informationsspeichern.

Bei der Hybridbereitstellungsmigration handelt es sich um eine von der Cloud initiierte Migrationsmethode mit Datenübertragung per Pull/Push, bei der ein Hybridserver mit Exchange 2013 oder Exchange 2010 SP3 als Migrationsserver fungiert. Dies wird häufig nicht berücksichtigt, und Kunden verwenden einen virtuellen Computer mit geringer Leistung als Migrationsserver. Das Ergebnis ist eine nicht zufriedenstellende Migrationsleistung.

Bewährte Methode

Neben den oben beschriebenen bewährten Methoden wurden folgende bewährte Methoden getestet, mit denen bei tatsächlichen Kundenmigrationen die Migrationsleistung verbessert werden konnte:

  • Verwenden Sie für die Exchange 2013- und Exchange 2010-Hybridserver leistungsstarke physische Computer auf Serverniveau statt virtueller Computer.

  • Verwenden Sie mehrere Hybridserver, die hinter dem Netzwerklastenausgleichsmodul des Kunden angeordnet sind.

So wurde beispielsweise bei tatsächlichen Kundenmigrationen mit der folgenden Konfiguration ein konstanter Durchsatz von 30 GB/Stunde erreicht:

  • Netzwerk   Ausgehende Pipe an das Internet mit 500 MB; internes Netzwerk mit 1 GB und Glasfaser-Backbone mit 10 GB.

  • Hardware   Spezifikationen für die beiden Clientzugriffsserver/HUB-Server (physisch):

    • CPU: Intel® Xeon® CPU E5520 @ 2,27 GHz 2,26 GHz (zwei Prozessoren).

    • RAM: 24 GB.

    • Datenträger: Acht mit jeweils 146 GB. RAID-5-Konfiguration = 960 GB insgesamt (Rohspeicher).

  • MRSProxy   Mit dem Parallelitätswert von "100" konfiguriert.

Bei der Hybridbereitstellungsmigration werden die systemeigenen Office 365-Tools verwendet. Die Office 365-Migrationsdiensteinschränkung wird angewandt.

Exchange 2003 im Vergleich zu Exchange 2007 SP2, Exchange 2010 SP3 und Exchange 2013 SP1

Bei der Migration von Exchange 2003 gibt es einen bedeutenden Unterschied für die Endbenutzer. Im Gegensatz zu Exchange 2007 SP2-, Exchange 2010 SP3- und Exchange 2013 SP1-Endbenutzern können Exchange 2003-Endbenutzer während der Datenmigration nicht auf ihre Postfächer zugreifen. Daher müssen Kunden mit Exchange 2003 üblicherweise genauer darauf achten, wann sie Migrationen ausführen und wie viel Zeit für die Migration benötigt wird. Dies gilt insbesondere bei geringer Migrationsleistung aufgrund von großen Postfächern oder geringer Netzwerkgeschwindigkeit.

Die Exchange 2003-Migration sind auch sehr empfindlich im Hinblick auf Unterbrechungen. Beispiel: Bei einer tatsächlichen Kundenmigration trat während der Migration eines 10-GB-Postfachs ein Dienstvorfall auf, als die Migration des Postfachs erst zur Hälfte abgeschlossen war. Der Office 365-Clientzugriffsserver, von dem die Datenmigration verarbeitet wurde, musste zur Behebung des Problems neu gestartet werden. In diesem Fall musste die Migration des Postfachs neu gestartet werden, sodass die gesamten 10 GB an Daten noch einmal migriert werden mussten. Die Migration konnte nicht an dem Punkt fortgesetzt werden, an dem sie unterbrochen wurde. Bei Exchange 2007 SP2, Exchange 2010 SP3 und Exchange 2013 SP1 können Migrationen dagegen nach Unterbrechungen fortgesetzt werden.

Bewährte Methode

Einige Kunden entscheiden sich bei der Migration umfangreicher Exchange 2003-Postfächer mit vertraulichen Daten für eine Migration in zwei Etappen:

  • Erste Etappe   Migrieren Sie die Postfächer aus Exchange 2003 zu einem Exchange 2010 SP3-Server (üblicherweise der Hybridserver). Beim ersten Hop handelt es sich zwar um eine Offlineverschiebung, es ist jedoch üblicherweise eine sehr schnelle Migration in einem lokalen Netzwerk.

  • Zweite Etappe   Migrieren Sie die Postfächer aus Exchange 2010 SP3 zu Office 365.

Die zweite Etappe ist eine Onlineverschiebung mit höherer Benutzerfreundlichkeit und Fehlertoleranz. Bei diesem Ansatz mit zwei Etappen wird für das temporäre lokale Exchange 2010-Benutzerpostfach eine Exchange 2010-Lizenz benötigt.

Proxy für den Postfachreplikationsdienst (MRSProxy)

Der MRS-Proxy ist das lokale Migrationsfeature, das auf der Office 365-Seite mit dem Postfachreplikationsdienst zusammenarbeitet. Weitere Informationen finden Sie unter Grundlegendes zu Verschiebungsanforderungen.

Bewährte Methode

Die maximale Anzahl von MRS-Proxyverbindungen kann für das lokale Exchange 2010 SP3-System konfiguriert werden. Führen Sie den folgenden Windows PowerShell-Befehl aus.

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
HinweisHinweis:
Bei den meisten Kundenmigrationen muss der Standardwert für "MRSMaxConnections" nicht geändert werden. Falls der Quellserver vor einer Überbeanspruchung durch die Migrationslast geschützt werden muss, können Kunden die Verbindungsanzahl verringern. Diese Einstellung gilt pro MRS-Proxyserver. Verfügt ein Kunde über zwei MRS-Proxyserver, von denen jeder auf zehn Verbindungen festgelegt ist, erhalten sie 20 (2 x 10) Verbindungen als Gesamtanzahl für die MRS-Proxyverbindungen. Weitere Informationen zum Konfigurieren des MRS-Proxydiensts in der lokalen Exchange 2010-Organisation finden Sie unter Starten des MRSProxy-Diensts auf einem Remote-Clientzugriffsserver.

HinweisHinweis:
Bei den meisten Kundenmigrationen muss der Standardwert für "MRSMaxConnections" nicht geändert werden. Falls der Quellserver vor einer Überbeanspruchung durch die Migrationslast geschützt werden muss, können Kunden die Verbindungsanzahl verringern. Diese Einstellung gilt pro MRS-Proxyserver. Verfügt ein Kunde über zwei MRS-Proxyserver, von denen jeder auf zehn Verbindungen festgelegt ist, erhalten sie 20 (2 x 10) Verbindungen als Gesamtanzahl für die MRS-Proxyverbindungen. Weitere Informationen zum Konfigurieren des MRS-Proxydiensts in der lokalen Exchange 2010-Organisation finden Sie unter Starten des MRSProxy-Diensts auf einem Remote-Clientzugriffsserver.

Überprüfungstests

Bei Kunden mit Exchange 2010 und Exchange 2013 kann die Netzwerkleistung für Hybridmigrationen durch Ausführen mehrerer Testpostfachmigrationen getestet werden. Alternativ können Sie tatsächliche Benutzerpostfächer mit der Option „-SuspendWhenReadyToComplete“ migrieren, um einen Eindruck von der Migrationsleistung zu erhalten. Entfernen Sie nach Abschluss des Tests die Verschiebungsanforderung, um negative Auswirkungen für die Endbenutzer zu vermeiden.

Weitere Informationen zu Exchange 2013-Verschiebungsanforderungen finden Sie unter New-MoveRequest.

Weitere Informationen zu Exchange 2010-Verschiebungsanforderungen finden Sie unter New-MoveRequest.

Office 365-Einschränkung aufgrund der Ressourcenintegrität betrifft Migrationen, die mit Office 365-Hybridbereitstellungsmigrationen ausgeführt werden. Weitere Einzelheiten finden Sie weiter oben im Abschnitt zur Office 365-Einschränkung aufgrund der Ressourcenintegrität.

Allgemeine Informationen zum Abrufen von Statusinformationen für Verschiebungsanforderungen finden Sie unter Anzeigen der Eigenschaften von Verschiebungsanforderungen.

Beim Ausführen von Verschiebungsanforderungen gibt es im Office 365-Dienst einen bedeutenden Unterschied zur normalen lokalen Exchange 2010-Organisation. In Office 365 werden die Migrationswarteschlange und die für Migrationen zugeordneten Dienstressourcen gemeinsam von den Mandanten genutzt. Dies hat Auswirkungen darauf, wie Verschiebungsanforderungen in den einzelnen Phasen des Verschiebungsprozesses behandelt werden.

In Office 365 stehen zwei Typen von Verschiebungsanforderungen zur Verfügung:

  • Onboarding-Verschiebungsanforderungen   Neue Kundenmigrationen werden als Onboarding-Verschiebungsanforderungen betrachtet. Anforderungen dieser Art weisen eine normale Priorität auf.

  • Interne Verschiebungsanforderungen im Datenzentrum   Hierbei handelt es sich um Postfachverschiebungsanforderungen, die von Datenzentrumsbetriebsteams initiiert werden. Die Priorität dieser Anforderungen ist geringer, da sich keine Nachteile für die Endbenutzer ergeben, wenn bei der Verschiebungsanforderung eine Verzögerung auftritt.

  • Verschiebungsanforderungen in der Warteschlange   Mit diesem Status wird angegeben, dass die Verschiebung der Warteschlange hinzugefügt wurde und gewartet wird, dass sie vom Microsoft Exchange-Postfachreplikationsdienst bearbeitet wird. Bei Exchange 2003-Verschiebungsanforderungen können die Benutzer in dieser Phase weiterhin auf Postfächer zugreifen.

    Welche Anforderung vom Postfachreplikationsdienst bearbeitet wird, hängt von zwei Faktoren ab:

    • Priorität   In der Warteschlange befindliche Verschiebungsanforderungen mit höherer Priorität werden vor Verschiebungsanforderungen mit geringerer Priorität bearbeitet. Dadurch wird sichergestellt, dass Verschiebungsanforderungen von Kundenmigrationen stets vor internen Verschiebungsanforderungen im Datenzentrum verarbeitet werden.

    • Position in der Warteschlange   Bei Verschiebungsanforderungen mit gleicher Priorität gilt: Je früher die Anforderung der Warteschlange hinzugefügt wurde, desto früher wird sie vom Postfachreplikationsdienst bearbeitet. Da Postfachmigrationen unter Umständen von mehreren Kunden gleichzeitig ausgeführt werden, ist es normal, dass neue Verschiebungsanforderungen vor der Verarbeitung in der Warteschlange verbleiben.

      Die Wartezeit in der Warteschlange bis zur Verarbeitung von Postfachanforderungen wird bei der Migrationsplanung häufig nicht berücksichtigt. Dies führt dazu, dass den Kunden nicht genügend Zeit für alle geplanten Migrationen zur Verfügung steht.

  • Verschiebungsanforderungen in Bearbeitung   Mit diesem Status wird angegeben, dass die Verschiebungsanforderung noch bearbeitet wird. Bei einer Onlinepostfachverschiebung kann der Benutzer weiterhin auf das Postfach zugreifen. Bei Offlinepostfachverschiebungen ist das Postfach des Benutzers nicht verfügbar.

    Sobald die Postfachverschiebungsanforderung den Status „Wird ausgeführt“ aufweist, spielt die Priorität keine Rolle mehr. Neue Verschiebungsanforderungen werden erst nach Abschluss einer in Bearbeitung befindlichen Verschiebungsanforderung verarbeitet. Dabei ist es unerheblich, ob die neue Verschiebungsanforderung eine höhere Priorität aufweist.

Planung   Wie bereits weiter oben erwähnt, müssen Kunden mit Exchange 2003 üblicherweise genauer darauf achten, für wann sie Migrationen planen und wie lange die jeweilige Migration dauert, da Exchange 2003-Benutzer während einer Hybridmigration keinen Zugriff haben.

Berücksichtigen Sie beim Planen der Menge an Postfächern, die in einem bestimmten Zeitraum migriert werden sollen, Folgendes:

  • Beziehen Sie die Wartezeit der Verschiebungsanforderung in der Warteschlange mit ein. Berechnungsformel:

    (Gesamtanzahl der zu migrierenden Postfächer) = ((Gesamtzeit) – (durchschnittliche Zeit in der Warteschlange)) * (Migrationsdurchsatz)

    Der Migrationsdurchsatz entspricht hierbei der Gesamtanzahl von Postfächern, die pro Stunde migriert werden können.

    Beispiel: Angenommen, für die Migration der Postfächer steht ein Zeitfenster von sechs Stunden zur Verfügung. Wenn die durchschnittliche Zeit in der Warteschlange eine Stunde beträgt und ein Migrationsdurchsatz von 100 Postfächern pro Stunde möglich ist, können innerhalb von sechs Stunden 500 Postfächer migriert werden: 500 = (6 – 1) * 100.

  • Starten Sie die Migration früher als ursprünglich geplant, um die Zeit in der Warteschlange zu berücksichtigen. Wenn sich Postfächer in der Warteschlange befinden, können Exchange 2003-Benutzer auch weiterhin darauf zugreifen.

Ermitteln der Zeit in der Warteschlange   Die Zeit in der Warteschlange bleibt nie konstant, da die Migrationspläne von Kunden nicht von Microsoft verwaltet werden.

Um die potenzielle Zeit in der Warteschlange zu ermitteln, können Kunden eine Testverschiebung für einen Zeitpunkt ansetzen, der mehrere Stunden vor dem Beginn der eigentlichen Migration liegt. Anhand der Zeit, die sich die Anforderung in der Warteschlange befand, können Kunden dann besser einschätzen, wann die Migration gestartet werden sollte und wie viele Postfächer innerhalb eines bestimmten Zeitraums verschoben werden können.

Nehmen wir beispielsweise an, dass vier Stunden vor Beginn einer geplanten Migration eine Testmigration beendet wurde. Bei dieser Testmigration hat der Kunde eine Warteschlangenzeit von etwa einer Stunde ermittelt. In diesem Fall empfiehlt es sich für den Kunden, den Start der Migration um eine Stunde vorzuziehen, um sicherzustellen, dass genügend Zeit zum Abschließen aller Migrationen zur Verfügung steht.

Drittanbietertools werden hauptsächlich in Migrationsszenarien ohne Exchange wie Google Mail, IBM Lotus Domino oder Novell GroupWise verwendet. In diesem Abschnitt stehen die Migrationsprotokolle der Drittanbieter-Migrationstools im Mittelpunkt und weniger die eigentlichen Produkte und Migrationstools. Die folgende Tabelle enthält eine Liste der Faktoren, die für Drittanbietertools für Office 365-Hybridmigrationsszenarien gelten.

 

Prüfliste Beschreibung Bewährte Methoden

Systemleistung

Das Extrahieren von Daten ist eine aufwändige Aufgabe. Das Quellsystem muss über ausreichend Ressourcen wie CPU-Zeit und Arbeitsspeicher verfügen, um eine optimale Migrationsleistung zu erzielen. Während der Migration erreicht das Quellsystem bei der regulären Endbenutzerarbeitsauslastung häufig beinahe die Kapazitätsgrenze. Bei unzureichenden Systemressourcen kann sich die zusätzliche Arbeitsauslastung durch die Migration daher für die Endbenutzer negativ bemerkbar machen.

Überwachen Sie die Systemleistung im Rahmen einer Pilotmigration. Ist das System ausgelastet, wird von der Verwendung eines aggressiven Migrationsplans für dieses System abgeraten, da dies eine langsame Migration sowie Probleme mit der Dienstverfügbarkeit zur Folge haben kann. Verbessern Sie möglichst die Leistung des Quellsystems. Fügen Sie dazu Hardwareressourcen hinzu, und verringern Sie die Systemlast, indem Sie Aufgaben und Benutzer auf andere Server auslagern, die von der Migration nicht betroffen sind.

Weitere Informationen finden Sie unter:

Bei der Migration einer lokalen Exchange-Organisation mit mehreren Postfachservern empfiehlt sich die Erstellung einer Migrationsbenutzerliste, die gleichmäßig über die verschiedenen Postfachserver verteilt ist. Zur Maximierung des Durchsatzes kann diese Liste auf der Grundlage der Leistung des jeweiligen Servers noch weiter optimiert werden.

Verfügt Server A beispielsweise über eine um 50 Prozent höhere Ressourcenverfügbarkeit als Server B, bietet es sich an, in einem Migrationsbatch den Benutzeranteil von Server A um 50 Prozent zu erhöhen. Eine ähnliche Methode kann auch für andere Quellsysteme angewendet werden.

Die Migration sollte bei maximaler Ressourcenverfügbarkeit des Systems ausgeführt werden, also beispielsweise außerhalb der Geschäftszeiten, an Wochenenden oder an Feiertagen.

Back-End-Aufgaben

In der Regel werden andere Back-End-Aufgaben während der Migration ausgeführt. Da Migrationen üblicherweise außerhalb der Geschäftszeiten durchgeführt werden, kommt es oftmals zu Konflikten mit anderen Wartungsaufgaben, die auf den lokalen Servern ausgeführt werden (beispielsweise Datensicherungen).

Prüfen Sie, welche anderen Systemaufgaben während der Migration ausgeführt werden. Es wird empfohlen, ein spezielles Zeitfenster für die Migration zu schaffen, in dem keine anderen ressourcenintensiven Aufgaben ausgeführt werden.

Bei Kunden mit einem lokalen Microsoft Exchange-System handelt es sich bei den Aufgaben häufig um Datensicherungslösungen. Weitere Informationen finden Sie unter Wartung von Exchange-Informationsspeichern.

Einschränkungsrichtlinie

E-Mail-Systeme werden häufig mit einer Einschränkungsrichtlinie geschützt, die festlegt, welche Datenmenge innerhalb einer bestimmten Zeit wie schnell aus dem System extrahiert werden kann. Auch wird häufig eine bestimmte Migrationsmethode verwendet.

Überprüfen Sie, welche Einschränkungsrichtlinie für Ihr E-Mail-System bereitgestellt wurde. Bei Google Mail wird beispielsweise die Menge an Daten beschränkt, die innerhalb eines bestimmten Zeitraums extrahiert werden kann.

Je nach Version verfügt Microsoft Exchange über Richtlinien zum Beschränken des IMAP-Zugriffs auf den lokalen E-Mail-Server (bei IMAP-Migrationen) sowie zum Beschränken des RPC-über-HTTP-Zugriffs (bei Exchange-Übernahmemigrationen und mehrstufigen Exchange-Migrationen).

Weitere Informationen zu IMAP-Einschränkungen finden Sie unter Migrieren von E-Mails von einem IMAP-Server zu Exchange-Onlinepostfächern

Weitere Informationen zur RPC-über-HTTP-Einschränkung finden Sie hier:

Weitere Informationen zum Konfigurieren der EWS-Einschränkung finden Sie unter Exchange 2010: Grundlegendes zu Clienteinschränkungsrichtlinien.

Die meisten Drittanbietertools für Office 365-Migrationen werden vom Client initiiert und übertragen Daten per Push an Office 365. Für diese Tools wird in der Regel ein Migrationsserver benötigt. Für diese Migrationsserver gelten Faktoren wie Systemleistung, Back-End-Aufgaben und Einschränkungsrichtlinien für die Quellserver.

HinweisHinweis:
Einige Drittanbieter-Migrationslösungen werden als cloudbasierte Dienste im Internet gehostet und erfordern keinen lokalen Migrationsserver.

Lösung und Praxis

Wenden Sie zur Verbesserung der Leistung bei Verwendung eines Migrationsservers die im Abschnitt zu Datenquellenserver beschriebenen bewährten Methoden an.

Für Drittanbieter-Migrationstools werden am häufigsten die Protokolle "Exchange-Webdienst" und "RPC über HTTP" verwendet.

Exchange-Webdienst

Für Migrationen zu Office 365 wird das Protokoll "Exchange-Webdienst" (Exchange Web Service, EWS) empfohlen, da es umfangreiche Datenbatches unterstützt und über eine bessere dienstorientierte Einschränkung verfügt. In Office 365 (im Identitätswechselmodus) beanspruchen Migrationen mit EWS nicht die budgetierte Menge an Office 365-EWS-Ressourcen des Benutzers, sondern eine Kopie der budgetierten Ressourcen:

  • Alle EWS-Identitätswechselaufrufe, die mit dem gleichen Administratorkonto ausgeführt werden, werden unabhängig vom Budget für dieses Administratorkonto berechnet.

  • Für jede Identitätswechselsitzung wird eine Schattenkopie des tatsächlichen Budgets des Benutzers erstellt. Alle Migrationen für diese bestimmte Sitzung beanspruchen diese Schattenkopie.

  • Einschränkungen mit Identitätswechsel werden für jede Benutzermigrationssitzung isoliert.

Bewährte Methoden

  • Die Migrationsleistung für Kunden, die Drittanbieter-Migrationstools mit EWA-Identitätswechsel verwenden, wird durch EWS-basierte Migrationen und die Dienstressourcennutzung anderer Mandanten beeinflusst. Daher ist die Migrationsleistung nicht einheitlich.

  • Kunden sollten nach Möglichkeit Drittanbieter-Migrationstools mit EWS-Identitätswechsel verwenden, da diese in der Regel schneller und effizienter sind als die Verwendung von Clientprotokollen wie „RPC über HTTP“.

RPC über HTTP

Bei vielen traditionellen Migrationslösungen kommt das Protokoll "RPC über HTTP" zum Einsatz. Diese Methode basiert vollständig auf dem Clientzugriffsmodell wie Outlook. Zudem sind Skalierbarkeit und Leistung begrenzt, da der Zugriff vom Office 365-Dienst unter der Annahme eingeschränkt wird, dass die Nutzung auf einen Benutzer und nicht auf eine Anwendung zurückzuführen ist.

Bewährte Methoden

  • Bei Migrationstools mit "RPC über HTTP" wird häufig der Migrationsdurchsatz erhöht, indem mehr Migrationsserver hinzugefügt und mehrere Office 365-Administratorbenutzerkonten verwendet werden. Dadurch lassen sich eine parallele Dateneinfügung sowie ein höherer Datendurchsatz erzielen, da jeder Administratorbenutzer der Office 365-Benutzereinschränkung unterliegt. Viele Unternehmenskunden mussten mehr als 40 Migrationsserver einrichten, um einen Migrationsdurchsatz von 20 bis 30 GB/Stunde zu erreichen.

  • In der Entwicklungsphase für ein Migrationstool muss die Anzahl der RPC-Vorgänge berücksichtigt werden, die zum Migrieren einer Nachricht erforderlich sind. Zur Veranschaulichung haben wir für zwei (von Drittanbietern entwickelte) Migrationslösungen, mit denen Kunden Postfächer zu Office 365 migrieren, Protokolle gesammelt, die von den Office 365-Diensten erstellt wurden. Wir haben die beiden von Drittanbietern entwickelten Migrationslösungen verglichen. und dabei die Migration von zwei Postfächern für jede Migrationslösung gegenübergestellt und auch einen Vergleich mit dem Hochladen einer PST-Datei in Microsoft Outlook angestellt. Die Ergebnisse sind hier aufgeführt.

     

    Methode Postfachgröße Anzahl der Elemente Migrationszeit RPC-Transaktionen gesamt Durchschnittliche Clientlatenzzeit (ms) Durchschnittliche CAS-RPC-Verarbeitungszeit (ms)

    Lösung A (Postfach 1)

    376,9 MB

    4.115

    4:24:33

    132.040

    48.4395

    18.0807

    Lösung A (Postfach 2)

    249.3 MB

    12.779

    10:50:50

    423.188

    44.1678

    4.8444

    Lösung B (Postfach 1)

    618.1 MB

    4.322

    1:54:58

    12.196

    37.2931

    8.3441

    Lösung B (Postfach 2)

    56.7 MB

    2.748

    0:47:08

    5.806

    42.1930

    7.4439

    Outlook

    201,9 MB

    3.297

    0:29:47

    15.775

    36.9987

    5.6447

    Beachten Sie, dass die Client- und die Dienstverarbeitungszeiten zwar ähnlich sind, bei Lösung A jedoch deutlich mehr RPC-Vorgänge erforderlich sind, um die Daten zu migrieren. Da jeder Vorgang eine Zunahme der Clientlatenzzeit und der Serververarbeitungszeit bedeutet, ist die Migration der gleichen Datenmenge bei Lösung A wesentlich langsamer als bei Lösung B und Outlook.

Bewährte Methode

Im Folgenden finden Sie eine empfehlenswerte Methode zum Ermitteln der potenziellen Migrationsleistung von Drittanbieter-Migrationslösungen mit dem Protokoll „RPC über HTTP“:

  1. Stellen Sie auf dem Migrationsserver mithilfe von Microsoft Outlook und unter Verwendung von "RPC über HTTP" eine Verbindung mit dem Office 365-Postfach her. Vergewissern Sie sich, dass die Verbindung nicht im Cache-Modus hergestellt wird.

  2. Importieren Sie eine große PST-Datei mit Beispieldaten in das Exchange Online-Postfach

  3. Ermitteln Sie die Migrationsleistung, indem Sie die Zeit messen, die zum Hochladen der PST-Datei benötigt wird. Der Migrationsdurchsatz bewegt sich voraussichtlich in der Größenordnung, die Kunden erhalten, die ein Drittanbieter-Migrationstool mit „RPC über HTTP“ verwenden – vorausgesetzt, es liegen keine weiteren Einschränkungen vor. Aufgrund eines gewissen Mehraufwands bei der tatsächlichen Migration ist der Durchsatz unter Umständen nicht genau gleich.

Die Office 365-Einschränkung aufgrund der Ressourcenintegrität betrifft Migrationen, die mit Migrationstools von Drittanbietern ausgeführt werden. Weitere Einzelheiten finden Sie weiter oben im Abschnitt zur Office 365-Einschränkung aufgrund der Ressourcenintegrität.

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft