Microsoft 365 und Office 365 E-Mail-Migration und bewährte Methoden

Es gibt viele Pfade zum Migrieren von Daten aus einer lokalen E-Mail-Organisation Microsoft 365 oder Office 365. Bei der Planung einer Migration Microsoft 365 oder Office 365 fragen Sie sich häufig, wie Sie die Leistung der Datenmigration verbessern und die Migrationsgeschwindigkeit optimieren können.

Hinweis

Die in diesem Thema aufgeführten Leistungsinformationen gelten nicht für Microsoft 365 oder Office 365 für dedizierte Abonnementpläne. Weitere Informationen zu dedizierten Plänen finden Sie unter Microsoft 365 und Office 365 Dedicated Plans Service Descriptions.

Übersicht über die Migration von E-Mails zu Microsoft 365 oder Office 365

Microsoft 365 oder Office 365 unterstützt verschiedene Methoden zum Migrieren von E-Mail-, Kalender- und Kontaktdaten aus Ihrer vorhandenen Messagingumgebung zu Microsoft 365 oder Office 365, wie unter Methoden zum Migrieren mehrerer E-Mail-Konten zu Microsoft 365 oder Office 365 beschrieben.

Weitere Informationen zu Microsoft 365 oder Office 365 Netzwerk und Leistung finden Sie unter Netzwerkplanung und Leistungsoptimierungfür Microsoft 365 oder Office 365 .

Häufig verwendete Migrationsmethoden


Migrationsmethode Beschreibung Ressourcen
IMAP (Internet Message Access Protocol)-Migration Sie können das Exchange Admin Center oder Exchange Online PowerShell verwenden, um die Inhalte der Benutzerpostfächer von einem IMAP-Messagingsystem zu ihren Microsoft 365 oder Office 365 zu migrieren. Dies umfasst das Migrieren Ihrer Postfächer von anderen gehosteten E-Mail-Diensten wie Gmail oder Yahoo Mail. Migrieren Sie Ihre IMAP-Postfächer zu Microsoft 365 oder Office 365
Übernahmemigration Mithilfe einer Umstellungsmigration migrieren Sie alle lokalen Postfächer in Microsoft 365 oder Office 365 tagen. Verwenden Sie die Umstellungsmigration, wenn Sie planen, Ihre gesamte E-Mail-Organisation auf Microsoft 365 oder Office 365 zu verschieben und Benutzerkonten in Microsoft 365 oder Office 365. Sie können maximal 2.000 Postfächer aus Ihrer lokalen Exchange-Organisation mithilfe einer Microsoft 365 oder Office 365 migrieren. Die empfohlene Anzahl von Postfächern beträgt jedoch 150. Eine größere Anzahl wirkt sich negativ auf die Leistung aus. Die E-Mail-Kontakte und Verteilergruppen in Ihrer lokalen Exchange-Organisation werden ebenfalls migriert. Cutovermigration zu Microsoft 365 oder Office 365
Mehrstufige Migration Sie verwenden eine mehrstufige Migration, wenn Sie planen, alle Postfächer Ihrer Organisation zu Microsoft 365 oder Office 365. Mithilfe einer mehrstufigen Migration migrieren Sie Batches von lokalen Postfächern Microsoft 365 oder Office 365 einige Wochen oder Monate. Was Sie über eine mehrstufige E-Mail-Migration zu Microsoft 365 oder Office 365
Hybridbereitstellung Eine Hybridbereitstellung bietet Unternehmen die Möglichkeit, die funktionsreiche Erfahrung und administrative Kontrolle ihrer vorhandenen lokalen Exchange-Organisation auf die Cloud auszuweiten. Eine Hybridbereitstellung bietet das nahtlose Aussehen und Gefühl einer einzelnen Exchange-Organisation zwischen einer lokalen Exchange-Organisation und Exchange Online in Microsoft 365 oder Office 365. Darüber hinaus kann eine Hybridbereitstellung als Zwischenschritt zum vollständigen Wechsel zu einer Microsoft 365 oder Office 365 dienen. E-Mail-Migrationsratgeber

Exchange Bereitstellungsassistent für Exchange 2013/2016/2019

Exchange Server 2013-Hybridbereitstellungen

Minimale Hybridkonfiguration
Drittanbietermigration Es stehen viele Tools von Drittanbietern zur Verfügung. Sie verwenden unverkennbare Protokolle und Ansätze, um E-Mail-Migrationen von E-Mail-Plattformen wie IBM Lotus Notes und Novell GroupWise durchzuführen. 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 plattformübergreifender Messagingmigrations- und Koexistenzsoftware mit Produkten, die die Analyse und Koexistenz und Migration zwischen lokalen und Onlineumgebungen für Messaging und Zusammenarbeit in Unternehmen basierend auf IBM Lotus Notes und Domino und Exchange und SharePoint.

BitTitan: Anbieter von Migrationslösungen für Microsoft 365 oder Office 365.

CodeTwo: Anbieter von Microsoft 365 und Office 365 Migrationslösungen. Migrieren Sie Postfächer und öffentliche Ordner von lokalen Exchange und E-Mails von IMAP (Gmail, IBM Notes usw.) in die Cloud, oder führen Sie Mandantenmigrationen zu Mandanten durch. Übertragen Sie alle Daten gleichzeitig oder in Batches, und automatisieren Sie den gesamten Migrationsprozess ohne Ausfallzeiten.

Quadrotech: Anbieter von Migrationslösungen für Microsoft 365 oder Office 365.

Quest: Anbieter von Migrationslösungen von Exchange, Microsoft 365, Office 365, Gmail, GroupWise, Notes, POP/IMAP, Zimbra, Sun ONE/i Planet, PSTs und E-Mail-Archiven zu Microsoft 365 oder Office 365 und Exchange. Aufgabenlösungen synchronisieren Postfächer, öffentliche Ordner und Kalenderinformationen, während gleichzeitig die Koexistenz während der Migration beibehalten wird.

Transvault: Anbieter von Cloud-Office Migrationslösungen für Microsoft 365 von Exchange und Notizen. Transvault unterstützt 23 verschiedene Migrationsquellen und verfügt über Produkte, die jede Projektgröße, komplexe E-Mail-Archivmigrationen und pst-Verwaltung bereitstellen. Die Unternehmensmigrationslösungen sind sicher, kompatibel, effizient und benutzerorientiert und können sowohl lokal als auch in der Cloud ausgeführt werden.

SkyKick: Anbieter automatisierter Migrationslösungen zum Verschieben von lokalen Exchange, Gmail, POP3, IMAP, Lotus Notes zu Microsoft 365 oder Office 365. Die End-to-End-Migrationstools unterstützen Partner bei den Vertriebs-, Planungs-, Migrations-, Verwaltungs- und Vor-Ort-Phasen des Migrationsprojekts.

BCC Collaboration Company: Unterstützung von Unternehmen durch Unterstützung ihrer Migrationsstrategie für die Zusammenarbeit. Der beste Anbieter von Migrationstools, die auf der Domino-Plattform basieren, für die Migration zu Microsoft Exchange, Microsoft 365 und Office 365.

Leistung für Migrationsmethoden

In den folgenden Abschnitten werden die Arbeitsauslastungen für die Postfachmigration und die beobachteten Leistungsergebnisse für die verschiedenen Migrationsmethoden zum Migrieren von Postfächern und Postfachdaten zu Microsoft 365 oder Office 365. Diese Ergebnisse basieren auf internen Tests und tatsächlichen Kundenmigrationen zu Microsoft 365 oder Office 365.

Wichtig

Aufgrund von Unterschieden in der Art und Weise, wie Migrationen ausgeführt werden und wann sie ausgeführt werden, kann ihre tatsächliche Migrationsgeschwindigkeit variieren.

Arbeitslasten für die Kundenmigration

In der folgenden Tabelle werden die verschiedenen Arbeitslasten einer typischen Migration sowie die Jeweiligen Herausforderungen und Optionen beschrieben.


Arbeitslast Anmerkungen
Onboarding (Migration zu Microsoft 365 oder Office 365) Microsoft bietet Funktionen und Tools für die Datenmigration, die Kunden verwenden können, um ihre Daten von Exchange Server lokalen zu Exchange Online in Microsoft 365 oder Office 365. Es gibt eine Reihe von Methoden zum Migrieren von Postfächern und Postfachdaten, beginnend mit Cutover-Migrationen und mehrstufigen Migrationen, die auf Zusammenführungs- und Synchronisierungsbewegungen basieren und die weiter oben in diesem Artikel beschrieben werden. Die andere Hauptmigrationsmethode umfasst Hybridbewegungen, die derzeit die gängigste Methode ist. Sie können genau entscheiden, wann Sie basierend auf Ihren Geschäftsanforderungen zu Microsoft 365 migrieren möchten.
Multi-Geo Multinationale Unternehmen mit Niederlassungen auf der ganzen Welt müssen ihre Mitarbeiterdaten häufig in bestimmten Regionen speichern, um ihre Anforderungen an die Datenresidenz zu erfüllen. Multi-Geo ermöglicht es einer einzelnen Microsoft 365- oder Office 365-Organisation, sich über mehrere Microsoft 365- oder Office 365-Datencentergeografien (Geos) zu erstreckt, wodurch Sie Exchange-Daten, ruhend, auf Benutzerbasis, in Ihren ausgewählten Geografischen speichern können. Weitere Informationen finden Sie unter Get enterprise-grade global data location controls with Multi-Geo.
Verschlüsselung Dienstverschlüsselung mit Kundenschlüssel ist ein Feature, mit dem ein Kunde die Stammschlüssel bereitstellen und verwalten kann, die zum Verschlüsseln von Ruhedaten auf der Anwendungsebene in Microsoft 365 oder Office 365. Damit ein Postfach das erste Mal verschlüsselt wird, ist eine Postfach verschieben erforderlich. Weitere Informationen finden Sie unter Dienstverschlüsselung mit Customer Key.
GoLocal Microsoft öffnet weiterhin neue Rechenzentren in neuen Regionen oder geografischen Regionen. Vorhandene Kunden können, wenn berechtigt, anfordern, dass ihre Kundendaten aus ihrem ursprünglichen Rechenzentrum in einen neuen geografischen Standort verschoben werden. Der Zeitraum, in dem Sie diese Anforderung stellen können, beträgt in der Regel ein oder zwei Jahre, abhängig von der Gesamtanforderung für den Dienst. Beachten Sie, dass dieser Zeitraum, in dem Sie anfordern können, dass Ihre Kundendaten verschoben werden, kürzer wird, sobald ein Datencenter (DC) für die neuen geografischen Starts (an diesem Punkt haben Sie ungefähr drei bis sechs Monate Zeit, um eine Bewegung an fordern). Details finden Sie unter Verschieben von Kerndaten in Microsoft 365 Datencenter-Geos.

Wenn Postfächer innerhalb der Microsoft 365 migriert werden, benötigt jede Postfachver- oder Massenpostfachmigration Zeit, bis der Vorgang abgeschlossen ist. Es gibt eine Reihe von Faktoren, z. B. Microsoft 365, die sich genau auf den Zeitraum auswirken können. Der Dienst wurde entwickelt, um diskretionäre Arbeitslasten wie Postfachbewegungen zu drosseln, um sicherzustellen, dass der Dienst für alle Benutzer optimal ausgeführt wird. Sie können weiterhin davon aus gehen, dass Postfachbewegungen verarbeitet werden, je nachdem, ob der Dienst über die Ressourcenverfügbarkeit nach eigenem Ermessen verfügbar ist. Weitere Details zur Ressourceneinschränkung finden Sie in diesem Blogbeitrag.

Geschätzte Migrationszeiten

Die folgenden Tabellen enthalten Richtlinien dazu, wann Massenpostfachmigrationen oder einzelne Migrationen abgeschlossen werden sollen, um Die Migration zu planen. Diese Schätzungen basieren auf einer Datenanalyse früherer Kundenmigrationen. Da jede Umgebung eindeutig ist, kann die genaue Migrationsgeschwindigkeit variieren.

Dauer der Postfachmigration basierend auf Postfachgrößenprofilen:

  1. Onboarding /PSTImport

Postfachgröße (GB) 50. Perzentildauer (Tage) 90. Perzentildauer (Tage)
< 1 1 7
1 - 10 1 7
10 - 50 3 14
50 - 100 3 30
100 - 200 8 45
> 200 Nicht unterstützt Nicht unterstützt
  1. Multi-Geo / GoLocal / Encryption

Postfachgröße (GB) 50. Perzentildauer (Tage) 90. Perzentildauer (Tage)
< 1 1 7
1 - 10 1 10
10 - 50 3 30
50 - 100 15 45
100 - 200 30 60
> 200 Nicht unterstützt Nicht unterstützt

Migrationsdauer zum Abschließen von 90 % der Postfachbewegungen basierend auf Mandantengrößenprofilen:


Mandantengröße (Anzahl der Postfächer) Dauer (Tage) Kann bis zu diesen vielen Tagen dauern
< 1,000 5 14
1,000 - 5,000 10 30
5,000 - 10,000 20 45
10,000 - 50,000 30 60
50,000 - 100,000 45 90
> 1000,000 60 180

Hinweis

Einige Ausreißerpostfächer würden basierend auf dem Postfachprofil länger dauern. Wenn ein Mandant durchschnittlich über größere Postfächer verfügt, kann dies auch zur längeren Dauer der Migration beitragen.

Migrationsleistungsfaktoren

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

Allgemeine Migrationsleistungsfaktoren

In der folgenden Tabelle ist eine Liste der allgemeinen Faktoren aufgeführt, die sich auf die Migrationsleistung auswirken können. Weitere Details werden in den Abschnitten behandelt, in denen die einzelnen Migrationsmethoden beschrieben sind.


Faktor Beschreibung Beispiel
Datenquelle Das Gerät oder der Dienst, das bzw. der die zu migrierenden Daten hostet. Für die Datenquelle gelten möglicherweise viele Einschränkungen aufgrund von Hardwarespezifikationen, Endbenutzerarbeitsauslastung und Back-End-Wartungsaufgaben. Gmail beschränkt die Menge der Daten, die während eines bestimmten Zeitraums extrahiert werden können.
Datentyp und -dichte Aufgrund der eindeutigen Eigenschaft des Unternehmens eines Kunden können Typ und Kombination von E-Mail-Elementen innerhalb der Postfächer stark variieren. Ein Postfach von 4 GB mit 400 Elementen, von denen jedes 10 MB an Anlagen umfasst, kann schneller migriert werden als ein Postfach von 4 GB mit 100.000 kleineren Elementen.
Migrationsserver Viele Migrationslösungen verwenden einen Migrationsserver vom Typ "Jump-Box" oder "Arbeitsstation", um die Migration durchzuführen. Kunden verwenden häufig einen virtuellen Computer mit geringer Leistung als Host für den MRSProxy-Dienst für Hybridbereitstellungen oder für nicht hybride Migrationen von Clientcomputern.
Migrationsmodul Das Datenmigrationsmodul, das für das Ziehen von Daten vom Quellserver verantwortlich ist, konvertiert bei Bedarf Daten. Das Modul überträgt die Daten dann über das Netzwerk und injiziert die Daten in das Microsoft 365 oder Office 365 Postfach. Postfach. Der MRSProxy-Dienst weist eigene Stärken und Schwächen auf.
Lokale Network Appliances Die End-to-End-Netzwerkleistung (von der Datenquelle Exchange Online Clientzugriffsserver) wirkt sich auf die Migrationsleistung aus. Firewallkonfiguration und -spezifikationen in der lokalen Organisation.
Microsoft 365 oder Office 365 Dienst Microsoft 365 und Office 365 verfügen über integrierte Unterstützung und Features zum Verwalten der Migrationsarbeitsauslastung. Die Benutzereinschränkungsrichtlinie weist Standardeinstellungen auf und beschränkt die maximale Gesamtübertragungsrate.

Netzwerkleistungsfaktoren

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.

Verwenden Sie Exchange Analyzer, um ein tieferes Verständnis Ihrer Netzwerkkonnektivität mit Microsoft 365 oder Office 365. Zum Ausführen der Exchange Analyzer-Tests im Support- und Wiederherstellungs-Assistenten wechseln Sie zu "Erweiterte Diagnosen" > "Exchange Online" > "Exchange Online-Netzwerkkonnektivität überprüfen" > "Ja". Weitere Informationen zu microsoft Support- und Wiederherstellungs-Assistent finden Sie unter Support- und Wiederherstellungs-Assistent.


Faktor Beschreibung Bewährte Methoden
Netzwerkkapazität Der Zeitraum für die Migration von Postfächern zu Microsoft 365 oder Office 365 wird durch die verfügbare und maximale Kapazität Ihres Netzwerks bestimmt. Identifizieren Sie die verfügbare Kapazität Ihres Netzwerk, und bestimmen Sie die maximale Kapazität für das Hochladen.
Wenden Sie sich an Ihren Internetdienstanbieter, um Ihre zugewiesene Bandbreite zu bestätigen sowie Details zu Einschränkungen zu erhalten, z. B. zur Gesamtmenge der Daten, die in einem bestimmten Zeitraum übertragen werden kann.
Verwenden Sie entsprechende Tools, um die tatsächliche Netzwerkkapazität auszuwerten. Stellen Sie sicher, dass Sie den End-to-End-Datenfluss von der lokalen Datenquelle zu den Microsoft Datacenter-Gatewayservern testen.
Identifizieren Sie andere Auslastungen in Ihrem Netzwerk (z. B. Sicherungsdienstprogramme und geplante Wartungen), die sich auf die Netzwerkkapazität auswirken können.
Netzwerkstabilität Schnelle Netzwerke führen nicht immer zu schnellen Migrationen. Wenn das Netzwerk nicht stabil ist, kann die Datenübertragung aufgrund der möglichen Fehlerkorrektur länger dauern. Je nach Migrationstyp kann die Fehlerkorrektur die Migrationsleistung erheblich beeinträchtigen. Netzwerkhardware- und Treiberprobleme können häufig die Stabilität des Netzwerks beeinträchtigen. Arbeiten Sie mit den Hardwareanbietern zusammen, um Ihre Netzwerkgeräte zu verstehen, und wenden Sie die neuesten empfohlenen Treiber des Herstellers sowie entsprechende Softwareupdates an.
Netzwerkverzögerungen Für eine Netzwerkfirewall konfigurierte Funktionen zur Angriffserkennung verursachen häufig erhebliche Netzwerkverzögerungen und beeinträchtigen die Migrationsleistung.
Das Migrieren von Daten Microsoft 365 oder Office 365 postfächern basiert auf Ihrer Internetverbindung. Verzögerungen im Internet beeinträchtigen die allgemeine Migrationsleistung.
Darüber hinaus verfügen Benutzer in derselben Firma möglicherweise über Cloudpostfächer, die sich in Datencentern an unterschiedlichen geografischen Standorten befinden. Je nach Internetdienstanbieter des Kunden kann die Migrationsleistung variieren.
Werten Sie Netzwerkverzögerungen für alle potenziellen Microsoft-Datencenter aus, um sicherzustellen, dass das Ergebnis konsistent ist. (Dies trägt auch dazu bei, eine konsistente Benutzererfahrung für Endbenutzer sicherzustellen.) Arbeiten Sie mit Ihrem Internetdienstanbieter zusammen, um internetbezogene Probleme zu beheben.
Fügen Sie ihrer Liste zulässiger Datencenterserver IP-Adressen hinzu, oder umgehen Sie den migrationsbezogenen Datenverkehr von Ihrer Netzwerkfirewall. Weitere Informationen zu den Microsoft 365 oder Office 365-IP-Bereichen finden Sie unter Microsoft 365 und Office 365 URLs und IP-Adressbereiche.

Eine eingehendere Analyse der Migrationen in Ihrer Umgebung finden Sie in unserem Blogbeitrag zur Verschiebungsanalyse. Der Beitrag umfasst ein Skript, das Sie beim Analysieren von Verschiebungsanforderungen unterstützt.

Microsoft 365 und Office 365 Drosselung

Microsoft 365 und Office 365 verwenden verschiedene Drosselungsmechanismen, um die Sicherheit und Dienstverfügbarkeit sicherzustellen. Die folgenden drei Arten von Einschränkungen können sich auf die Migrationsleistung auswirken:

  • Benutzereinschränkung
  • Migrationsdiensteinschränkung
  • Auf dem Ressourcenstatus basierende Einschränkung

Hinweis

Die drei Typen von Microsoft 365 und Office 365 wirken sich nicht auf alle Migrationsmethoden aus.

Microsoft 365 und Office 365 Benutzereinschränkung

Die Benutzereinschränkung wirkt sich auf die meisten Drittanbieter-Migrationstools sowie auf die Migrationsmethode für Clientuploads aus. Diese Migrationsmethoden verwenden Clientzugriffsprotokolle, z. B. den Remoteprozeduraufruf (RPC) über HTTP-Protokoll, um Postfachdaten zu Microsoft 365 oder Office 365 zu migrieren. Diese Tools werden zum Migrieren von Daten von Plattformen wie IBM Lotus Domino und Novell GroupWise verwendet.

Die Benutzereinschränkung ist die restriktivste Einschränkungsmethode in Microsoft 365 und Office 365. Da die Benutzereinschränkung eingerichtet wird, um einzelnen Endbenutzern entgegenzuwirken, überschreitet jede Nutzung auf Anwendungsebene die Einschränkungsrichtlinie und führt zu einer verlangsamten Datenmigration.

Microsoft 365 und Office 365 Migrationsdiensteinschränkung

Die Einschränkung des Migrationsdiensts wirkt sich auf Microsoft 365 oder Office 365 Migrationstools aus. Die Migrationsdienstdrosselung verwaltet die Parallelität der Migration und die Zuweisung von Dienstressourcen für Microsoft 365 oder Office 365 Migrationslösungen.

Die Migrationsdiensteinschränkung wirkt sich auf Migrationen aus, die mithilfe der folgenden Migrationsmethoden durchgeführt wurden:

  • IMAP-Migration
  • Exchange-Übernahmemigration
  • Mehrstufige Exchange-Migration
  • Hybridmigrationen (auf dem MRSProxy-Dienst basierende Verschiebungen in eine Hybridumgebung)

Wichtig

Die oben genannten Migrationsmethoden sind von der Benutzereinschränkung nicht betroffen.

Ein Beispiel für die Migrationsdiensteinschränkung ist das Kontrollieren der Anzahl der Postfächer, die während einfacher Exchange- und IMAP-Migrationen gleichzeitig migriert werden. Der Standardwert ist 10. Dies bedeutet, dass maximal 10 Postfächer aus allen Migrationsbatches zu einem bestimmten Zeitpunkt migriert werden. Sie können die Anzahl der parallelen Postfachmigrationen für einen Migrationsbatch entweder über die Exchange-Systemsteuerung oder über Windows PowerShell erhöhen. Weitere Informationen zum Optimieren dieser Einstellung finden Sie unter Manage migration batches in Microsoft 365 or Office 365.

Microsoft 365 oder Office 365 Ressourcenintegierungseinschränkung

Alle Migrationsmethoden unterliegen der Kontrolle durch die Verfügbarkeitseinschränkung. Microsoft 365 oder Office 365-Diensteinschränkung wirkt sich jedoch nicht auf Microsoft 365 oder Office 365 Migrationen aus wie die anderen zuvor beschriebenen Einschränkungstypen.

Die auf dem Ressourcenstatus basierende Einschränkung ist die am wenigsten offensive Einschränkungsmethode. Sie erfolgt, um ein Problem mit der Dienstverfügbarkeit zu verhindern, das die Endbenutzer und wichtige Dienstvorgänge beeinträchtigen könnte.

Bevor sich die Leistung des Dienstes so weit verschlechtert, dass die Leistung des Endbenutzers beeinträchtigt werden könnte, werden Hybridmigrationen verzögert, bis die Leistung wiederhergestellt ist und der Dienst zu einem Niveau unter dem Einschränkungsschwellenwert zurückkehrt.

Nachfolgend finden Sie Beispiele aus einem Exchange-Bericht zur Migrationsstatistik. Sie zeigen die Einträge, die bei Überschreitung des Schwellenwerts für die Diensteinschränkung protokolliert wurden.

1/25/2018 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/2018 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/2018 1:27:53 AM.

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

6/30/2017 00:03:58 [CY4PR19MB0056] Relinquishing job because of large delays due to unfavorable server health or budget limitations with a request throttling state 'StalledDueToTarget_DiskLatency'.

Lösung und Praxis:

Wenn eine ähnliche Situation vor sich geht, warten Sie, bis Microsoft 365 oder Office 365 zur Verfügung stehen.

Leistungsfaktoren und bewährte Methoden für Migrationen in Nicht-Hybridbereitstellungen

In diesem Abschnitt werden die Faktoren beschrieben, die sich auf Migrationen auswirken, die die IMAP-, Übernahme- oder mehrstufigen Migrationsmethoden verwenden. Darüber hinaus werden die bewährten Methoden zum Optimieren der Migrationsleistung bezeichnet.

Faktor 1: Datenquelle

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:


Checkliste Beschreibung Bewährte Methoden
Systemleistung Die Datenextrahierung stellt eine intensive Aufgabe dar. Das Quellsystem muss über geeignete Ressourcen verfügen, z. B. CPU-Zeit und Arbeitsspeicher, um optimale Migrationsleistungen bieten zu können. Während der Migration befindet sich das Quellsystem hinsichtlich der normalen Arbeitsauslastung durch den Endbenutzer häufig am Rande seiner Kapazität. Wenn die Systemressourcen unzureichend sind, kann sich die zusätzliche Arbeitsauslastung, die sich durch die Migration ergibt, auf die Endbenutzer auswirken. Überwachen Sie die Systemleistung während eines Migrationstests. Wenn das System ausgelastet ist, wird aufgrund potenzieller verringerter Migrationsgeschwindigkeiten und Dienstverfügbarkeitsproblemen empfohlen, einen offensiveren Migrationszeitplan für das System zu vermeiden. Erweitern Sie nach Möglichkeit die Quellsystemleistung durch Hinzufügen von Hardwareressourcen, und verringern Sie die Auslastung des Systems durch Verschieben von Aufgaben und Benutzern auf andere Server, die nicht an der Migration beteiligt sind.

Weitere Informationen finden Sie unter:
Exchange 2013 Serverinte health and performance
Grundlegendes Exchange 2010-Leistung
Exchange 2007: Überwachen von Postfachservern

Bei der Migration von einer lokalen Exchange-Organisation, die mehrere Postfachserver umfasst, wird empfohlen, dass Sie eine Liste der Migrationsbenutzer erstellen, die gleichmäßig auf die verschiedenen Postfachserver verteilt wird. Auf Grundlage der jeweiligen Serverleistung kann die Liste weiter optimiert werden, um den Durchsatz zu maximieren.

Wenn Server A z. B. über eine um 50 Prozent höhere Ressourcenverfügbarkeit als Server B aufweist, ist es sinnvoll, 50 Prozent mehr Benutzer von Server A in demselben Migrationsbatch zu verwenden. Ähnliche Methoden können auf andere Quellsysteme angewendet werden. Führen Sie die Migrationen aus, wenn die Server eine maximale Ressourcenverfügbarkeit aufweisen, z. B. nach Feierabend oder an Wochenenden oder Feiertagen.
Back-End-Aufgaben Andere Back-End-Aufgaben, die während der Migration ausgeführt werden. Da es sich um eine bewährte Methode zum Ausführen der Migration nach Geschäftszeiten handele, treten Migrationskonflikte mit Wartungsaufgaben (z. B. Datensicherung) auf ihren lokalen Servern auf. 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: Für Kunden, die lokale Exchange, sind die häufigen Back-End-Aufgaben Sicherungslösungen und Exchange Speicherwartung.
Einschränkungsrichtlinie Es ist allgemein üblich, E-Mail-Systeme mit einer Einschränkungsrichtlinie zu schützen, die einen bestimmten Grenzwert festlegt, wie schnell und wie viele Daten während einer bestimmten Zeitspanne aus dem System extrahiert werden können. Überprüfen Sie, welche Einschränkungsrichtlinie auf Ihr E-Mail-System angewendet wird. Google Mail beschränkt z. B. die Datenmenge, die in einem bestimmten Zeitraum extrahiert werden kann.

Je nach Version weist Exchange Richtlinien auf, die den IMAP-Zugriff auf den lokalen E-Mail-Server (verwendet von IMAP-Migrationen) und den RPC-über-HTTP-Protokollzugriff (verwendet von Exchange-Übernahmemigrationen und mehrstufigen Exchange-Migrationen) einschränkt.

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

Weitere Informationen zur IMAP-Einschränkung finden Sie unter Migrate your IMAP mailboxes to Microsoft 365 or Office 365

Weitere Informationen zur Einschränkung des RPC-über-HTTP-Protokolls finden Sie unter:
Exchange 2013 Workload Management
Exchange 2010: Grundlegendes zu Clienteinschränkungsrichtlinien
Exchange 2007: Grundlegendes zur Clientdrosselung

Faktor 2: Migrationsserver

IMAP-, Übernahme- und mehrstufige Migrationen sind über die Cloud eingeleitete Migrationsmethoden mit Datenabruf, daher sind keine dedizierten Migrationsserver erforderlich. Die mit dem Internet verbundenen Protokollhosts (IMAP oder RPC über HTTP-Protokoll) funktionieren jedoch als Migrationsserver zum Migrieren von Postfächern und Postfachdaten zu Microsoft 365 oder Office 365. Daher gelten die Migrationsleistungsfaktoren und bewährten Methoden, die im vorherigen Abschnitt über den Datenquellenserver für Ihre aktuelle E-Mail-Organisation beschrieben werden, auch für die Internet-Edgeserver. Für Exchange 2007-, Exchange Server 2010- und Exchange 2013-Organisationen fungiert der Clientzugriffsserver als Migrationsserver.

Weitere Informationen finden Sie unter:

Faktor 3: Migrationsmodul

IMAP-, Cutover- und mehrstufige Migrationen Exchange mithilfe des Migrationsdashboards im Exchange Admin Center durchgeführt. Dies unterliegt Microsoft 365 oder Office 365 Migrationsdiensteinschränkung.

Lösung und Praxis:

Kunden können jetzt mithilfe von Windows PowerShell die Migrationsparallelität angeben (z. B. die Anzahl der gleichzeitig zu migrierenden Postfächer). Der Standardwert ist 20 Postfächer. Nachdem Sie einen Migrationsbatch erstellt haben, können Sie diesen Wert mithilfe des folgenden Windows PowerShell-Cmdlets auf maximal 100 erhöhen.

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

Weitere Informationen finden Sie unter Manage migration batches in Microsoft 365 or Office 365.

Hinweis

Wenn Ihre Datenquelle nicht über ausreichend Ressourcen verfügt, um alle Verbindungen zu verwalten, wird empfohlen, die hohe Parallelität zu vermeiden. Beginnen Sie mit einem kleinen Wert für die Parallelität, z. B. mit 10. Erhöhen Sie diesen Wert während der Überwachung der Leistung der Datenquelle, um Probleme beim Endbenutzerzugriff zu vermeiden.

Faktor 4: Netzwerk

Überprüfungstests:

Je nach Migrationsmethode können Sie die folgenden Überprüfungstests ausprobieren:

  • IMAP-Migrationen: Ein Quellpostfach mit Beispieldaten vorab aufgefüllt. Stellen Sie dann über das Internet (außerhalb Ihres lokalen Netzwerks) eine Verbindung mit dem Quellpostfach mithilfe eines standardmäßigen IMAP-E-Mail-Clients wie Microsoft Outlook bereit, und messen Sie dann die Netzwerkleistung, indem Sie bestimmen, wie lange es dauert, alle Daten aus dem Quellpostfach herunterzuladen. Der Durchsatz sollte mit dem, was Kunden mithilfe des IMAP-Migrationstools in Microsoft 365 oder Office 365 erhalten können, ähnlich sein, da keine anderen Einschränkungen gegeben sind.

  • Umschalt- und mehrstufige Exchange: Ein Quellpostfach mit Beispieldaten vorab aufgefüllt. Stellen Sie dann über das Internet (außerhalb Ihres lokalen Netzwerks) eine Verbindung mit dem Quellpostfach mit Outlook mithilfe des RPC-über-HTTP-Protokolls. Stellen Sie sicher, dass Sie eine Verbindung über den zwischengespeicherten Modus herstellen. Messen Sie die Leistung des Netzwerks, indem Sie überprüfen, wie lange es dauert, alle Daten aus dem Quellpostfach zu synchronisieren. Der Durchsatz sollte mit dem vergleichbar sein, was Kunden mithilfe der einfachen Exchange-Migrationstools in Microsoft 365 oder Office 365 erhalten können, da es keine anderen Einschränkungen gibt.

Während einer tatsächlichen IMAP-, Übernahme- oder mehrstufigen Exchange-Migration kommt es zu einem gewissen Mehraufwand. Der tatsächliche Durchsatz sollte jedoch den Ergebnissen dieser Überprüfungstest ähnlich sein.

Faktor 5: Microsoft 365 und Office 365 Dienst

Microsoft 365 oder Office 365 ressourceninte health-basierte Drosselung wirkt sich auf Migrationen mithilfe der systemeigenen Microsoft 365 oder Office 365 Migrationstools aus. Weitere Informationen finden Microsoft 365 oder Office 365 Ressourcenintektionsbasierte Einschränkung.

Verschieben von Anforderungen im Microsoft 365 oder Office 365 Dienst

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

Im Microsoft 365 oder Office 365 werden die Migrationswarteschlange und die für Migrationen zugewiesenen Dienstressourcen im Gegensatz zu lokalen Exchange 2010 von Mandanten gemeinsam genutzt. Diese Freigabe wirkt sich darauf aus, wie Verschiebungsanforderungen in den einzelnen Phasen der Verschiebung behandelt werden.

Es gibt zwei Arten von Verschiebeanforderungen in Microsoft 365 und Office 365:

  • Onboarding move requests: Neue Kundenmigrationen werden als Onboarding move requests betrachtet. Diese Anforderungen weisen eine normale Priorität auf.

  • Interne Datencenter-Verschiebeanforderungen: Dies sind Postfach verschiebenanforderungen, die von Datencenterbetriebsteams initiiert wurden. Diese Anforderungen haben eine geringere Priorität, da die Endbenutzererfahrung nicht betroffen ist, wenn die Verschiebungsanforderung verzögert wird.

Potenzielle Auswirkungen und Verzögerungen für Verschiebungsanforderungen mit dem Status „In Warteschlange eingereiht“ und „Wird ausgeführt“

  • Verschiebeanforderungen in der Warteschlange: Dieser Status gibt an, dass die Bewegung in die Warteschlange gestellt wurde und darauf wartet, vom Exchange Postfachreplikationsdienst aufgenommen zu werden. Für Exchange 2003-Verschiebungsanforderungen können Benutzer in dieser Phase weiterhin auf ihre Postfächer zugreifen.

    Zwei Faktoren beeinflussen, welche Anforderung vom Postfachreplikationsdienst ausgewählt wird:

    • Priorität: Verschiebeanforderungen mit einer höheren Priorität in der Warteschlange werden vor Verschiebeanforderungen mit niedrigerer Priorität aufgenommen. Dadurch wird sichergestellt, dass Verschiebungsanforderungen von Kundenmigrationen immer vor internen Verschiebungsanforderungen von Datencentern verarbeitet werden.

    • Position in der Warteschlange : Wenn Verschiebensanforderungen die gleiche Priorität haben, wird die Anforderung früher in die Warteschlange aufgenommen, um so früher wird sie vom Postfachreplikationsdienst aufgenommen. Da möglicherweise mehrere Kunden gleichzeitig Postfachmigrationen durchführen, ist es normal, dass neue Verschiebungsanforderungen in der Warteschlange verbleiben, bevor sie verarbeitet werden.

Häufig wird die Zeit, die Postfachanforderungen vor der Verarbeitung in der Warteschlange warten, während der Migrationsplanung nicht berücksichtigt. Dies führt zu Kunden, für die nicht genügend Zeit reserviert wurde, um alle geplanten Migrationen abzuschließen.

  • In-Progress-Move-Anforderungen: Dieser Status gibt an, dass die Bewegung noch ausgeführt wird. Wenn es sich hierbei um die Verschiebung eines Onlinepostfachs handelt, kann der Benutzer weiterhin auf sein Postfach zugreifen. Bei der Verschiebung von Offlinepostfächern ist das Postfach des Benutzers nicht mehr verfügbar.

Nachdem die Verschiebungsanforderung für das Postfach den Status "In Bearbeitung" aufweist, hat die Priorität keine Bedeutung mehr und neue Verschiebungsanforderungen werden nicht verarbeitet, bis eine vorhandene Verschiebungsanforderung mit dem Status "In Bearbeitung" abgeschlossen wird, auch wenn die neue Verschiebungsanforderung eine höhere Priorität aufweist.

Bewährte Methoden

Planung: Da Exchange 2003-Benutzern während einer Hybridmigration der Zugriff verloren geht, machen sich Exchange 2003-Kunden in der Regel mehr Gedanken darüber, wann Migrationen geplant werden und wie lange sie dauern werden.

Bei der Planung der Anzahl der zu migrierenden Postfächer während eines bestimmten Zeitraums, sollten Sie Folgendes berücksichtigen:

  • Beziehen Sie die Zeitspanne mit ein, die die Verschiebungsanforderung in der Warteschlange wartet. Diese kann wie folgt berechnet werden:

    (Gesamtzahl der zu migrierenden Postfächer) = ((Gesamtzeit) - (durchschnittliche Wartezeit)) * (Migrationsdurchsatz)

    Dabei entspricht der Migrationsdurchsatz der Gesamtzahl der Postfächer, die pro Stunde migriert werden können.

Nehmen Sie beispielsweise an, Sie verfügen für die Migration von Postfächern über ein Zeitfenster von sechs Stunden. Wenn die durchschnittliche Zeit in der Warteschlange eine Stunde beträgt, und Sie einen Migrationsdurchsatz von 100 Postfächern pro Stunde erreichen, können Sie innerhalb von sechs Stunden 500 Postfächer migrieren: 500 = (6 - 1) * 100.

  • Starten Sie die Migration früher als anfänglich geplant, um die Zeit in der Warteschlange zu verringern. Wenn sich die Postfächer in der Warteschlange befinden, können Exchange 2003-Benutzer weiterhin auf ihre Postfächer zugreifen.

Bestimmen der Warteschlangenzeit: Die Warteschlangenzeit ändert sich immer, da Microsoft die Migrationszeitpläne der Kunden nicht verwaltet.

Um die potenzielle Wartezeit zu ermitteln, kann ein Kunde versuchen, mehrere Stunden vor dem Start der eigentlichen Migration eine Testverschiebung zu planen. Der Kunde kann dann auf Grundlage der ermittelten Dauer, die die Anforderung in der Warteschlange verweilt, besser einschätzen, wann die Migration gestartet werden muss. Zudem kann er besser beurteilen, wie viele Postfächer im angegebenen Zeitraum verschoben werden können.

Wenn eine Testmigration z. B. vier Stunden vor dem Start einer geplanten Migration abgeschlossen wurde. Der Kunde hat ermittelt, dass die Warteschlangenzeit für die Testmigration ungefähr eine Stunde ergibt. Dann sollte der Kunden erwägen, die Migration eine Stunde früher zu starten als ursprünglich geplant, um sicherzustellen, dass ausreichend Zeit zum Abschließen aller Migrationen verfügbar ist.

Tools von Drittanbietern für Microsoft 365 oder Office 365 Migrationen

Tools von Drittanbietern werden hauptsächlich in Migrationsszenarien verwendet, die keine Exchange, z. B. in Google Mail, IBM Lotus, Domino und Novell GroupWise. 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 Microsoft 365 oder Office 365 gelten.

Wichtig

Bei Problemen mit der Datenkonsistenz oder -integrität nach der Migration mithilfe von Tools von Drittanbietern wenden Sie sich an den Anbieter, der das Tool bereitgestellt hat.

Faktor 1: Datenquelle


Checkliste Beschreibung Bewährte Methoden
Systemleistung Die Datenextrahierung stellt eine intensive Aufgabe dar. Das Quellsystem muss über geeignete Ressourcen verfügen, z. B. CPU-Zeit und Arbeitsspeicher, um optimale Migrationsleistungen bieten zu können. Während der Migration befindet sich das Quellsystem hinsichtlich der normalen Arbeitsauslastung durch den Endbenutzer häufig am Rande seiner Kapazität. Wenn die Systemressourcen unzureichend sind, kann sich die zusätzliche Arbeitsauslastung, die sich durch die Migration ergibt, auf die Endbenutzer auswirken. Überwachen Sie die Systemleistung während eines Migrationstests. Wenn das System ausgelastet ist, wird aufgrund potenzieller verringerter Migrationsgeschwindigkeiten und Dienstverfügbarkeitsproblemen empfohlen, einen offensiveren Migrationszeitplan für das System zu vermeiden. Erhöhen Sie nach Möglichkeit die Leistung des Quellsystems durch Hinzufügen von Hardwareressourcen und Verringern der Arbeitsauslastung des Systems. Die Arbeitsauslastung des Systems kann durch Verschieben von Aufgaben und Benutzern auf andere Server verringert werden, die nicht in die Migration einbezogen sind.

Weitere Informationen finden Sie unter:
Exchange 2013 Serverinte health and performance
Grundlegendes Exchange 2010-Leistung
Exchange 2007: Überwachen von Postfachservern

Bei der Migration von einer lokalen Exchange-Organisation, die mehrere Postfachserver umfasst, wird empfohlen, dass Sie eine Liste der Migrationsbenutzer erstellen, die gleichmäßig auf die verschiedenen Postfachserver verteilt wird. Auf Grundlage der jeweiligen Serverleistung kann die Liste weiter optimiert werden, um den Durchsatz zu maximieren.

Wenn Server A z. B. über eine um 50 Prozent höhere Ressourcenverfügbarkeit als Server B aufweist, ist es sinnvoll, 50 Prozent mehr Benutzer von Server A in demselben Migrationsbatch zu verwenden. Eine ähnliche Methode kann auf andere Quellsysteme angewendet werden.

Führen Sie die Migrationen aus, wenn das System eine maximale Ressourcenverfügbarkeit aufweist, z. B. nach Feierabend oder an Wochenenden oder Feiertagen.
Back-End-Aufgaben Andere Back-End-Aufgaben, die in der Regel während der Migrationszeit ausgeführt werden. Da es sich als bewährte Methode erweist, die Migration außerhalb der Geschäftszeiten durchzuführen, kommt es häufig vor, dass Migrationen mit anderen Wartungsaufgaben in Konflikt geraten, die auf den lokalen Servern ausgeführt werden, z. B. Datensicherungen. Überprüfen Sie andere Systemaufgaben, die während der Migration ausgeführt werden. Es wird empfohlen, dass Sie ein ausschließlich für die Datenmigration vorgesehenes Zeitfenster erstellen, wenn keine anderen ressourcenintensiven Aufgaben ausgeführt werden.

Für lokale Exchange-Kunden sind die allgemeinen Aufgaben Sicherungslösungen. Weitere Informationen finden Sie unter Wartung des Exchange-Informationsspeichers.
Einschränkungsrichtlinie Es ist allgemein üblich, E-Mail-Systeme mit einer Einschränkungsrichtlinie zu schützen, die einen bestimmten Grenzwert festlegt, wie schnell und wie viele Daten während einer bestimmten Zeitspanne und mithilfe einer bestimmten Migrationsmethode aus dem System extrahiert werden können. Überprüfen Sie, welche Einschränkungsrichtlinie auf Ihr E-Mail-System angewendet wird. Google Mail beschränkt z. B. die Datenmenge, die in einem bestimmten Zeitraum extrahiert werden kann.

Je nach Version weist Exchange Richtlinien auf, die den IMAP-Zugriff auf den lokalen E-Mail-Server (verwendet von IMAP-Migrationen) und den RPC-über-HTTP-Protokollzugriff (verwendet von Exchange-Übernahmemigrationen und mehrstufigen Exchange-Migrationen) einschränkt.

Weitere Informationen zur IMAP-Einschränkung finden Sie unter Tipps zum Optimieren von IMAP-Migrationen.

Weitere Informationen zur Einschränkung des RPC-über-HTTP-Protokolls finden Sie unter:
Exchange 2013 Workload Management
Exchange 2010: Grundlegendes zu Clienteinschränkungsrichtlinien
Exchange 2007: Grundlegendes zur Clientdrosselung

Weitere Informationen zum Konfigurieren der Einschränkung von Exchange-Webdiensten finden Sie unter Exchange 2010: Informationen zu Richtlinien zur Clienteinschränkung.

Faktor 2: Migrationsserver

Die meisten Tools von Drittanbietern für Microsoft 365- oder Office 365 Migrationen werden vom Client initiiert und pushen Daten an Microsoft 365 oder Office 365. Diese Tools erfordern in der Regel einen Migrationsserver. Für diese Migrationsserver gelten Faktoren wie Systemleistung, Back-End-Aufgaben und Einschränkungsrichtlinien für die Quellserver.

Hinweis

Einige Migrationslösungen von Drittanbietern werden im Internet als cloudbasierte Dienste gehostet und erfordern keinen lokalen Migrationsserver.

Lösung und Praxis:

Um die Migrationsleistung bei der Verwendung eines Migrationsservers zu verbessern, wenden Sie dieselben bewährten Methoden an, die auch im Abschnitt Faktor 1: Datenquelle beschrieben werden.

Faktor 3: Migrationsmodul

Für Migrationstools von Drittanbietern werden am häufigsten die Exchange-Webdienste und das RPC-über-HTTP-Protokoll verwendet.

Exchange Webdienste:

Exchange Webdienste ist das empfohlene Protokoll für die Migration zu Microsoft 365 oder Office 365 da es große Datenbatches unterstützt und eine bessere dienstorientierte Drosselung bietet. In Microsoft 365 oder Office 365 verbrauchen Migrationen mit Exchange-Webdiensten bei Verwendung im Identitätswechselmodus nicht die budgetierte Menge von Microsoft 365- oder Office 365 Exchange-Webdienstressourcen des Benutzers, sondern eine Kopie der budgetierten Ressourcen:

  • Alle Identitätswechselaufrufe der Exchange-Webdienste, die über dasselbe Administratorkonto getätigt werden, werden separat vom Budget berechnet, das diesem Administratorkonto zugewiesen ist.

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

  • Die Einschränkung bei einem Identitätswechsel ist auf die einzelne Benutzermigrationssitzung begrenzt.

  • Exchange Die Einschränkungsrichtlinie für Webdienste kann im Mandanten (für eine Dauer von 30, 60 oder 90 Tagen) vorübergehend geändert werden, damit die Migration abgeschlossen werden kann. Dies kann im Abschnitt Hilfe des Microsoft 365 angefordert werden.

Bewährte Methoden:

  • Die Migrationsleistung für Kunden, die Migrationstools von Drittanbietern mit EWA-Identitätswechsel verwenden, konkurriert mit auf Exchange-Webdiensten basierenden Migrationen und der Dienstressourcennutzung durch andere Mandanten. Daher variiert die Migrationsleistung.

  • Kunden sollten nach Möglichkeit Migrationstools von Drittanbietern verwenden, die den Identitätswechsel mit Exchange-Webdiensten verwenden, da diese in der Regel schneller und effizienter sind als die Verwendung von Clientprotokollen, z. B. als das RPC-über-HTTP-Protokoll.

RPC über HTTP-Protokoll:

Viele herkömmliche Migrationslösungen verwenden das RPC-über-HTTP-Protokoll. Diese Methode basiert vollständig auf einem Clientzugriffsmodell wie dem von Outlook, und Skalierbarkeit und Leistung sind eingeschränkt, da der Microsoft 365- oder Office 365-Dienst den Zugriff unter der Annahme drosselt, dass die Verwendung durch einen Benutzer statt durch eine Anwendung ausgeführt wird.

Bewährte Methoden:

  • Für Migrationstools, die RPC über HTTP-Protokoll verwenden, ist es üblich, den Migrationsdurchsatz zu erhöhen, indem sie mehr Migrationsserver hinzufügen und mehrere Microsoft 365 oder Office 365 verwenden. Diese Vorgehensweise kann zu Parallelität bei der Dateneinspritzung führen und einen höheren Datendurchsatz erzielen, da jeder administrative Benutzer einer Microsoft 365 und Office 365 unterliegt. Es liegen entsprechende Berichte vor, dass viele Unternehmenskunden mehr als 40 Migrationsserver einrichten mussten, um einen Migrationsdurchsatz von 20 bis 30 GB pro 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. Um dies zu veranschaulichen, haben wir Protokolle gesammelt, die von Microsoft 365- oder Office 365-Diensten für zwei Migrationslösungen von Drittanbietern (entwickelt von Drittanbietern) erfasst wurden, die von Kunden zum Migrieren von Postfächern zu Microsoft 365 oder Office 365. Wir haben die beiden von Drittanbietern entwickelten Migrationslösungen verglichen. Wir haben die Migration von zwei Postfächern für jede Migrationslösung verglichen und sie auch mit dem Hochladen einer PST-Datei in Outlook. 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

Hinweis

Die Client- und Dienstprozesszeiten sind ähnlich, aber Lösung A benötigt viel mehr RPC-Vorgänge, um Daten zu migrieren. Da für jeden Vorgang Clientlatenzzeit und Serverprozesszeit beansprucht werden, ist Lösung A wesentlich langsamer, um die gleiche Datenmenge zu migrieren als Lösung B und zu Outlook.

Faktor 4: Netzwerk

Bewährte Methode:

Für die Migrationslösungen von Drittanbietern, die das RPC-über-HTTP-Protokoll verwenden, folgt hier eine geeignete Möglichkeit zum Messen der potenziellen Migrationsleistung:

  1. Stellen Sie auf dem Migrationsserver eine Verbindung mit dem Microsoft 365 oder Office 365 mit Outlook mithilfe des RPC-über-HTTP-Protokolls. Stellen Sie sicher, dass Sie keine Verbindung über den zwischengespeicherten Modus herstellen.

  2. Importieren Sie eine große PST-Datei mit Beispieldaten in das Microsoft 365 oder Office 365 Postfach.

  3. Messen Sie die Migrationsleistung, indem Sie die Zeit für das Hochladen der PST-Datei nehmen. Der Migrationsdurchsatz sollte dem ähneln, den Kunden über ein Migrationstool von Drittanbietern erzielen können, das das RPC-über-HTTP-Protokoll verwendet, vorausgesetzt, es gibt keine weiteren Einschränkungen. Während einer tatsächlichen Migration kommt es zu einem Mehraufwand, daher kann der Durchsatz leicht abweichen.

Faktor 5: Microsoft 365 und Office 365 Dienst

Microsoft 365 und Office 365 ressourceninte health-basierte Drosselung wirkt sich auf Migrationen mit Migrationstools von Drittanbietern aus. Weitere Informationen finden Microsoft 365 und Office 365 ressourcenintehierungsbasierte Drosselung.