Freigeben über

Leistung und bewährte Methoden für Microsoft 365- und Office 365-E-Mail-Migration

  • Artikel

Es gibt viele Pfade zum Migrieren von E-Mail-Daten für eine lokal gehostete Organisation zu Microsoft 365 oder Office 365. Wenn Sie eine Migration zu Microsoft 365 oder Office 365 planen, hilft ein klares Verständnis des Datenmigrationsprozesses und der Geschwindigkeit den Administratoren, besser zu planen.

Ü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-Mails, Kalendern und Kontaktdaten aus Ihrer vorhandenen Messagingumgebung zu Microsoft 365 oder Office 365, wie unter Möglichkeiten zum Migrieren mehrerer E-Mail-Konten zu Microsoft 365 oder Office 365 beschrieben.

Netzwerk- und Leistungsfragen zu Microsoft 365 oder Office 365 finden Sie unter Netzwerkplanung und Leistungsoptimierung fü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 den Inhalt der Postfächer der Benutzer von einem IMAP-Messagingsystem zu ihren Microsoft 365- oder Office 365-Postfächern zu migrieren. Dies umfasst das Migrieren Ihrer Postfächer von anderen gehosteten E-Mail-Diensten wie Gmail oder Yahoo Mail. Beachten Sie, dass Exchange Online jetzt einen hochspezialisierten Prozess im modernen EAC für die Migration von E-Mails aus einer Vorhandenen Gmail/G Suite/Google WorkSpace-Bereitstellung (GWS) zu Exchange Online bietet. Migrieren Ihrer IMAP-Postfächer zu Microsoft 365 oder Office 365
Übernahmemigration Verwenden Sie die Übernahmemigration, um alle lokalen Postfächer innerhalb weniger Tage zu Microsoft 365 oder Office 365 zu migrieren. Verwenden Sie die Übernahmemigration, wenn Sie planen, Ihre gesamte E-Mail-Organisation auf Microsoft 365 oder Office 365 zu verschieben und Benutzerkonten in Microsoft 365 oder Office 365 zu verwalten. Sie können maximal 2.000 Postfächer aus Ihrer lokalen Exchange-Organisation mithilfe einer Übernahmemigration zu Microsoft 365 oder Office 365 migrieren. Die empfohlene Anzahl von Postfächern beträgt jedoch 150. Die Leistung kann wahrscheinlich mit höheren Zahlen beeinträchtigt werden. Die E-Mail-Kontakte und Verteilergruppen in Ihrer lokalen Exchange-Organisation werden ebenfalls migriert. Übernahmemigration zu Microsoft 365 oder Office 365
Mehrstufige Migration Verwenden Sie die mehrstufige Migration, wenn Sie planen, im Laufe der Zeit alle Postfächer Ihrer Organisation zu Microsoft 365 oder Office 365 zu migrieren. Mithilfe einer mehrstufigen Migration migrieren Sie batches von lokalen Postfächern innerhalb weniger Wochen oder Monate zu Microsoft 365 oder Office 365. Was Sie über eine mehrstufige E-Mail-Migration zu Microsoft 365 oder Office 365 wissen müssen
Hybridbereitstellung Die Hybridbereitstellung bietet Organisationen die Möglichkeit, die funktionsreiche Erfahrung und die administrative Kontrolle, die sie mit ihrer vorhandenen lokalen Exchange-Organisation haben, auf die Cloud auszudehnen. Eine Hybridbereitstellung bietet das nahtlose Aussehen und Verhalten 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-Organisation dienen. Microsoft 365 und Office 365 Mail Migration Advisor

Hybridbereitstellungen in Exchange Server

E-Mail-Migrationsratgeber

Exchange-Bereitstellungs-Assistent für Exchange lokal 2013/2016/2019

Exchange Server 2013-Hybridbereitstellungen

Minimale Hybridkonfiguration
Drittanbietermigration Es stehen viele Tools von Drittanbietern zur Verfügung. Sie verwenden unterschiedliche Protokolle und Ansätze, um E-Mail-Migrationen von E-Mail-Plattformen wie GWS, GoDaddy, Yahoo, 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:

Binäre Struktur / Quest / QuadroTech: Binary Tree und QuadroTech sind jetzt Teil von Quest. Quest ist ein Anbieter plattformübergreifender Messagingmigrations- und Koexistenzsoftware mit Produkten zur Analyse, Koexistenz und Migration zwischen mehreren Plattformen zu Exchange Online. Quest-Lösungen synchronisieren Postfächer, öffentliche Ordner und Kalenderinformationen, während die Koexistenz während der migration beibehalten wird.

BitTitan: Bietet eine automatisierte Lösung für Migrationen zu Microsoft 365 oder Office 365 von einer Vielzahl von Plattformen.

CodeTwo: Anbieter von Microsoft 365- und Office 365-Migrationslösungen für sichere und automatisierte Datenmigrationen zu Microsoft 365 (Office 365) von Exchange On-Prem, IMAP-Servern und zwischen Microsoft 365-Mandanten.

Transvault: Anbieter von Cloud Office-Migrationslösungen zu Microsoft 365 von Exchange und Notes. Transvault unterstützt Dutzende von Quellen für die Migration und bietet Produkte, die jede Projektgröße, komplexe E-Mail-Archivmigrationen und PST-Verwaltung bereitstellen. Die Unternehmensmigrationslösungen sind sicher, konform, effizient und benutzerorientiert und können sowohl lokal als auch in der Cloud ausgeführt werden.

SkyKick: Anbieter von automatisierten Migrationslösungen für den Wechsel von mehreren Quelltypen 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: Unterstützung von Unternehmen durch Unterstützung ihrer Migrationsstrategie für die Zusammenarbeit. Erstklassiger 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 Workloads für die Postfachmigration und die beobachteten Leistungsergebnisse für die verschiedenen Migrationsmethoden für die Migration von Postfächern und Postfachdaten zu Microsoft 365 oder Office 365 verglichen. 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.

Kundenmigrationsworkloads

In der folgenden Tabelle werden die verschiedenen Workloads, die an einer typischen Migration beteiligt sind, sowie die Herausforderungen und Optionen beschrieben.

Arbeitslast Hinweise
Onboarding (Migration zu Microsoft 365 oder Office 365) Microsoft bietet Datenmigrationsfunktionen und -tools, mit denen Kunden ihre Daten von Exchange Server lokal (über Cutover/Staged/Hybrid) oder von Gmail/S Suite/GWS alias Google Work Space (über EAC, PowerShell) oder von anderen IMAP-Quellen (PowerShell, Gmail über IMAP) oder mandantenübergreifenden Migrationen zu Exchange Online in Microsoft 365 oder Office 365 migrieren können.
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-Rechenzentrumsregionen (geografische Regionen) zu erstrecken, sodass Sie Exchange-Daten im Ruhezustand pro Benutzer in ihren ausgewählten geografischen Regionen speichern können. Weitere Informationen finden Sie unter Abrufen von globalen Datenspeicherortsteuerelementen auf Unternehmensniveau mit Multi-Geo.
Verschlüsselung Die Dienstverschlüsselung mit Kundenschlüssel ist ein Feature, mit dem ein Kunde die Stammschlüssel bereitstellen und verwalten kann, die zum Verschlüsseln ruhender Daten auf der Anwendungsebene in Microsoft 365 oder Office 365 verwendet werden. Damit ein Postfach beim ersten Mal verschlüsselt wird, ist eine Postfachverschiebung erforderlich. Weitere Informationen finden Sie unter Dienstverschlüsselung mit Microsoft Purview-Kundenschlüssel.
GoLocal Microsoft eröffnet weiterhin neue Rechenzentren in neuen Regionen oder geografischen Regionen. Bestehende Kunden können, wenn sie berechtigt sind, 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 Gesamtnachfrage für den Dienst. Beachten Sie, dass dieser Zeitraum, in dem Sie die Verschiebung Ihrer Kundendaten anfordern können, kürzer wird, sobald ein Rechenzentrum (DC) für den neuen geografischen Standort gestartet wird (zu diesem Zeitpunkt haben Sie ungefähr drei bis sechs Monate Zeit, um eine Verschiebung anzufordern). Ausführliche Informationen finden Sie unter Verschieben von Kerndaten in neue geografische Microsoft 365-Rechenzentren.

Wenn Postfächer innerhalb von Microsoft 365-Rechenzentren migriert werden, erfordert jede Postfachverschiebung oder massenweise Verschiebung von Postfächern Zeit, bis der Vorgang abgeschlossen ist. Es gibt eine Reihe von Faktoren, z. B. die Microsoft 365-Dienstaktivität, die sich auf die genaue Dauer auswirken können. Der Dienst ist so konzipiert, dass er willkürliche Workloads wie Postfachverschiebungen drosselt, um sicherzustellen, dass der Dienst für alle Benutzer optimal ausgeführt wird. Sie können jedoch weiterhin davon ausgehen, dass Postfachverschiebungen verarbeitet werden, abhängig von der verfügbarkeit von Ressourcen nach Eigenem Ermessen des Diensts. Weitere Informationen zur Ressourcendrosselung finden Sie in diesem Blogbeitrag.

Geschätzte Dauer für die Postfachmigration in Exchange Online

Um Ihnen bei der Planung Ihrer Migration zu helfen, enthalten die folgenden Tabellen Richtlinien dazu, wann Massenpostfachmigrationen oder einzelne Migrationen zu erwarten sind. Diese Schätzungen basieren auf einer Datenanalyse früherer Kundenmigrationen. Da jede Umgebung einzigartig ist, kann ihre genaue Migrationsgeschwindigkeit variieren.

Dauer der Postfachmigration basierend auf Postfachgrößenprofilen:

  • GoLocal/Multi-Geo/Verschlüsselung in Exchange Online

    Arbeitslast Postfachgröße (GB) P50 (Dauer des 50. Perzentils) (Tage) P90 (Dauer des 90. Perzentils) (Tage)
    GoLocal/Multi-Geo/Encryption 0 - 10 1 1
    GoLocal/Multi-Geo/Encryption 10 - 50 2 6
    GoLocal/Multi-Geo/Encryption 50 - 100 4 11
    GoLocal/Multi-Geo/Encryption 100 - 200 6 14
    GoLocal/Multi-Geo/Encryption > 200 Nicht unterstützt Nicht unterstützt

  • Onboarding von lokalen Exchange-Servern in Exchange Online (Hybrid für Übernahmephasen//)

    Arbeitslast Postfachgröße (GB) P50 (Dauer des 50. Perzentils) (Tage) P90 (Dauer des 90. Perzentils) (Tage)
    Onboarding aus der lokalen Umgebung 0 - 10 1 3
    Onboarding aus der lokalen Umgebung 10 - 50 2 6
    Onboarding aus der lokalen Umgebung 50 - 100 4 13
    Onboarding aus der lokalen Umgebung 100 - 200 10 31
    Onboarding aus der lokalen Umgebung > 200 Nicht unterstützt Nicht unterstützt

  • Mandantenübergreifende Migration zu Exchange Online (verwenden Sie die Microsoft-Erstanbieterlösung , oder verwenden Sie Lösungen von Drittanbietern).

    Arbeitslast Postfachgröße (GB) P50 (Dauer des 50. Perzentils) (Tage) P90 (Dauer des 90. Perzentils) (Tage)
    Mandantenübergreifend 0 - 10 1 1
    Mandantenübergreifend 10 - 50 1 2
    Mandantenübergreifend 50 - 100 2 5
    Mandantenübergreifend 100 - 200 3 6
    Mandantenübergreifend > 200 Nicht unterstützt Nicht unterstützt

  • Spezialisiertes Onboarding in Exchange Online von Gmail/G Suite/GWS (EAC, PowerShell)

    Arbeitslast Postfachgröße (GB) P50 (Dauer des 50. Perzentils) (Tage) P90 (Dauer des 90. Perzentils) (Tage)
    Spezialisiertes Gmail-Onboarding 0 - 10 1 2
    Spezialisiertes Gmail-Onboarding 10 - 50 1 8
    Spezialisiertes Gmail-Onboarding 50 - 100 3 12
    Spezialisiertes Gmail-Onboarding 100 - 200 5 19
    Spezialisiertes Gmail-Onboarding > 200 Nicht unterstützt Nicht unterstützt

  • Onboarding in Exchange Online aus IMAP-Quellen (andere IMAP-Quellen, PowerShell, Gmail über IMAP)

    Arbeitslast Postfachgröße (GB) P50 (Dauer des 50. Perzentils) (Tage) P90 (Dauer des 90. Perzentils) (Tage)
    Generisches IMAP-Onboarding 0 - 10 1 1
    Generisches IMAP-Onboarding 10 - 50 1 2
    Generisches IMAP-Onboarding 50 - 100 1 8
    Generisches IMAP-Onboarding 100 - 200 3 29
    Generisches IMAP-Onboarding > 200 Nicht unterstützt Nicht unterstützt

  • Onboarding in Exchange Online per PST-Import

    Arbeitslast Postfachgröße (GB) P50 (Dauer des 50. Perzentils) (Tage) P90 (Dauer des 90. Perzentils) (Tage)
    PST-Import 0 - 10 1 1
    PST-Import 10 - 50 1 3
    PST-Import 50 - 100 2 5
    PST-Import 100 - 200 3 6
    PST-Import > 200 Nicht unterstützt Nicht unterstützt

Hinweis

Einige Ausreißerpostfächer würden je nach 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

Die Postfach-/E-Mail-Migration hat mehrere allgemeine Faktoren, die sich auf die Migrationsleistung auswirken.

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, 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. 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 Die Datenmigrations-Engine, die für das Pullen von Daten vom Quellserver verantwortlich ist, konvertiert Daten bei Bedarf. Die Engine überträgt die Daten dann über das Netzwerk und fügt die Daten in das Microsoft 365- oder Office 365-Postfach ein. Postfach. Der MRSProxy-Dienst weist eigene Stärken und Schwächen auf.
Lokale Network Appliances Die End-to-End-Netzwerkleistung (von der Datenquelle bis hin zu Exchange Online-Clientzugriffsservern) 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 Migrationsworkload. 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 Diskussion ist allgemein ausgerichtet, da die Hardware von Drittanbietern und Internetdienstanbieter (ISPs) während der Migration die größte Auswirkung auf die Leistung des Netzwerks haben.

Verwenden Sie Exchange Analyzer, um ein tieferes Verständnis Ihrer Netzwerkkonnektivität mit Microsoft 365 oder Office 365 zu erhalten. Um die Exchange Analyzer-Tests im Microsoft Support- und Wiederherstellungs-Assistenten auszuführen, wechseln Sie zu Erweiterte Diagnose > Exchange Online > Überprüfen der Exchange Online-Netzwerkkonnektivität > Ja. Lesen Sie den Microsoft-Support- und Wiederherstellungs-Assistenten, um mehr über den Microsoft-Support- und Wiederherstellungs-Assistenten zu erfahren.

Faktor Beschreibung Bewährte Methoden
Netzwerkkapazität Die Zeit, die zum Migrieren von Postfächern zu Microsoft 365 oder Office 365 benötigt wird, hängt von der verfügbaren und maximalen Kapazität Ihres Netzwerks ab. 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.
Die Migration von Daten zu 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 Erfahrung für Endbenutzer zu gewährleisten.) Arbeiten Sie mit Ihrem Internetdienstanbieter zusammen, um Probleme im Zusammenhang mit dem Internet zu beheben.
Fügen Sie IP-Adressen für Microsoft-Rechenzentrumsserver zu Ihrer Zulassungsliste hinzu, oder umgehen Sie den gesamten migrationsbezogenen Datenverkehr von Ihrer Netzwerkfirewall. Weitere Informationen zu den MICROSOFT 365- oder Office 365-IP-Adressbereichen finden Sie unter URLs und IP-Adressbereiche von Microsoft 365 und Office 365.

Eine ausführlichere Analyse der Migrationen in Ihrer Umgebung finden Sie in unserer Leistungsanalyse zur Postfachmigration. 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 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 Arten der Microsoft 365- und Office 365-Drosselung 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 wie remote procedure call (RPC) über HTTP-Protokoll, um Postfachdaten zu Microsoft 365- oder Office 365-Postfächern zu migrieren. Diese Tools werden verwendet, um Daten von Plattformen wie IBM Lotus Domino und Novell GroupWise zu migrieren.

Die Benutzerdrosselung ist die restriktivste Drosselungsmethode 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.

Drosselung des Microsoft 365- und Office 365-Migrationsdiensts

Die Drosselung des Migrationsdiensts wirkt sich auf alle 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 Benutzerdrosselung 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 20. Dies bedeutet, dass jederzeit maximal 20 Postfächer aus allen Migrationsbatches migriert werden. Sie können die Anzahl gleichzeitiger Postfachmigrationen für einen Migrationsbatch entweder im Exchange Admin Center oder in Windows PowerShell erhöhen. Weitere Informationen zum Optimieren dieser Einstellung finden Sie unter Verwalten von Migrationsbatches in Microsoft 365 oder Office 365.

Microsoft 365- oder Office 365-Ressourcenintegritätsdrosselung

Alle Migrationsmethoden unterliegen der Kontrolle durch die Verfügbarkeitseinschränkung. Die Drosselung des Microsoft 365- oder Office 365-Diensts wirkt sich jedoch nicht so stark auf Microsoft 365- oder Office 365-Migrationen aus wie die anderen zuvor beschriebenen Drosselungstypen.

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.

Im Folgenden wird gezeigt, was den Kunden in Bezug auf die Dauer von Stags mithilfe des Get-MoveRequestStatistics - <> -IncludeReport Cmdlets angezeigt wird:

$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632

$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00

CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00

Lösung und Praxis:

Wenn eine vergleichbare Situation vorliegt, warten Sie, bis die Microsoft 365- oder Office 365-Ressourcen verfügbar sind.

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 für Nicht-Hybridbereitstellungsmigrationen

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 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 Serverintegrität und -leistung von Exchange Server (2007, 2010, 2013, 2016, 2019)

Hinweis: Exchange Server 2007 und 2010 werden nicht mehr aktiv unterstützt. Das Ende des Supports für Exchange 2013 Server ist für April 2023 geplant. Exchange Server 2016 und 2019 werden bis Oktober 2025 erweitert unterstützt. Weitere Informationen finden Sie in der Exchange Server-Unterstützungsmatrix .

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. 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. Führen Sie Migrationen durch, wenn Server über eine maximale Ressourcenverfügbarkeit verfügen, z. B. nach Feierabend oder an Wochenenden und Feiertagen.
Back-End-Aufgaben Andere Back-End-Aufgaben, die während der Migration ausgeführt werden. Da es eine bewährte Methode ist, die Migration nach Feierabend durchzuführen, kommt es häufig vor, dass Migrationen mit Wartungstasks (z. B. Datensicherung) in Konflikt geraten, die auf Ihren lokalen Servern ausgeführt werden. 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 lokales Exchange verwenden, sind die gängigen Back-End-Aufgaben Sicherungslösungen und Exchange-Speicherwartung (2013, 2016, 2019).
Einschränkungsrichtlinie Es ist eine gängige Praxis, E-Mail-Systeme mit einer Drosselungsrichtlinie zu schützen, die einen bestimmten Grenzwert dafür festlegt, wie schnell und wie viele Daten während eines bestimmten Zeitraums aus dem System extrahiert werden können. Überprüfen Sie die für Ihr E-Mail-System bereitgestellte Drosselungsrichtlinie. Google Mail schränkt beispielsweise ein, wie viele Daten in einem bestimmten Zeitraum extrahiert werden können. 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.

Um die Drosselungseinstellungen zu überprüfen, führen Sie das Cmdlet Get-ThrottlingPolicy aus. Weitere Informationen zur Drosselung finden Sie unter (2007, 2010, 2013, 2016, 2019).

Weitere Informationen zur IMAP-Drosselung finden Sie unter Migrieren Ihrer IMAP-Postfächer zu Microsoft 365 oder Office 365.

Faktor 2: Migrationsserver für Nicht-Hybridbereitstellungsmigrationen

IMAP-, Übernahme- und mehrstufige Migrationen sind über die Cloud eingeleitete Migrationsmethoden mit Datenabruf, daher sind keine dedizierten Migrationsserver erforderlich. Die Protokollhosts mit Internetzugriff (IMAP oder RPC über HTTP-Protokoll) fungieren jedoch als Migrationsserver für die Migration von Postfächern und Postfachdaten zu Microsoft 365 oder Office 365. Daher gelten die Im vorherigen Abschnitt über den Datenquellenserver für Ihre aktuelle E-Mail-Organisation beschriebenen Leistungsfaktoren und bewährten Methoden für die Migration 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: Migrations-Engine für Nicht-Hybridbereitstellungsmigrationen

IMAP-, Übernahme- und mehrstufige Exchange-Migrationen werden mithilfe des Migrationsdashboards im Exchange Admin Center durchgeführt. Dies unterliegt der Drosselung des Microsoft 365- oder Office 365-Migrationsdiensts.

Lösung und Praxis:

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

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

Weitere Informationen finden Sie unter Verwalten von Migrationsbatches in Microsoft 365 oder Office 365.

Hinweis

Wenn Ihre Datenquelle nicht über genügend Ressourcen zum Verwalten aller Verbindungen verfügt, wird empfohlen, eine hohe Parallelität zu vermeiden. Beginnen Sie mit einem kleinen Parallelitätswert, z. B. 10. Erhöhen Sie diese Anzahl, während Sie die Leistung der Datenquelle überwachen, um Probleme mit dem Endbenutzerzugriff zu vermeiden.

Faktor 4: Netzwerk für Nicht-Hybridbereitstellungsmigrationen

Überprüfungstests:

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

  • IMAP-Migrationen: Füllen Sie ein Quellpostfach vorab mit Beispieldaten auf. Stellen Sie dann über das Internet (außerhalb Ihres lokalen Netzwerks) mithilfe eines standardmäßigen IMAP-E-Mail-Clients wie Microsoft Outlook eine Verbindung mit dem Quellpostfach her, und messen Sie dann die Netzwerkleistung, indem Sie bestimmen, wie lange es dauert, alle Daten aus dem Quellpostfach herunterzuladen. Der Durchsatz sollte dem entsprechen, den Kunden mit dem IMAP-Migrationstool in Microsoft 365 oder Office 365 erhalten können, da es keine anderen Einschränkungen gibt.

  • Übernahme- und mehrstufige Exchange-Migrationen: Füllen Sie ein Quellpostfach vorab mit Beispieldaten auf. Stellen Sie dann über das Internet (außerhalb Ihres lokalen Netzwerks) mithilfe von RPC über HTTP-Protokoll eine Verbindung mit dem Quellpostfach mit Outlook her. Stellen Sie sicher, dass Sie die Verbindung im Cachemodus 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 dem entsprechen, den Kunden mit den 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 für Nicht-Hybridbereitstellungsmigrationen

Die auf der Ressourcenintegrität basierende Drosselung von Microsoft 365 oder Office 365 wirkt sich auf Migrationen aus, die die nativen einfachen Microsoft 365- oder Office 365-Migrationstools verwenden. Weitere Informationen finden Sie im Abschnitt Microsoft 365- oder Office 365-Ressourcenintegritätsbasierte Einschränkung .

Verschieben von Anforderungen in Microsoft 365 oder Office 365

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

  • Move-Mailbox

  • [Get-MoveRequestStatistics]] (/powershell/module/exchange/get-moverequeststatistics)

Im Microsoft 365- oder Office 365-Dienst werden die Migrationswarteschlange und die für Migrationen zugeordneten Dienstressourcen auf die Mandanten verteilt und beeinflussen, wie Verschiebungsanforderungen in jeder Phase des Verschiebungsprozesses verwaltet werden.

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

  • Onboarding von "Verschiebungsanforderungen": Die Migrationen neuer Kunden werden als Onboarding von Verschiebungsanforderungen betrachtet. Diese Anforderungen weisen eine normale Priorität auf.

  • Interne "Verschiebungsanforderungen" des Rechenzentrums: Dies sind Anforderungen zur Verschiebung von Postfächern, die von Den Rechenzentrumsbetriebsteams 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“

  • Verschiebungsanforderungen in der Warteschlange: Dieser Status gibt an, dass die Verschiebung in die Warteschlange eingereiht wurde und darauf wartet, dass der Exchange-Postfachreplikationsdienst sie übernimmt. 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: Verschiebungsanforderungen in der Warteschlange mit einer höheren Priorität werden vor Verschiebungsanforderungen 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 Verschiebungsanforderungen die gleiche Priorität haben, wird sie je früher die Anforderung in die Warteschlange gelangt, desto 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 Bearbeitung ausgeführte Verschiebungsanforderungen: Dieser Status gibt an, dass die Verschiebung noch ausgeführt wird. Wenn es sich hierbei um die Verschiebung eines Onlinepostfachs handelt, kann der Benutzer weiterhin auf sein Postfach zugreifen.

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-Benutzer während einer Hybridmigration den Zugriff verlieren, haben Exchange 2003-Kunden in der Regel mehr Bedenken darüber, wann Migrationen geplant werden und wie lange sie dauern.

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:

    (Gesamtanzahl der zu migrierenden Postfächer) = ((Gesamtzeit) – (durchschnittliche Warteschlangenzeit)) * (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 Warteschlangenzeit eine Stunde beträgt und Sie über einen Migrationsdurchsatz von 100 Postfächern pro Stunde verfügen, können Sie 500 Postfächer im Sechs-Stunden-Zeitrahmen 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 von Kunden nicht verwaltet.

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.

Beispiel: Eine Testmigration wurde vier Stunden vor dem Start einer geplanten Migration abgeschlossen. Bei dieser Testmigration hat der Kunde eine Warteschlangenzeit von etwa einer Stunde ermittelt. Anschließend sollte der Kunde erwägen, die Migration eine Stunde früher als ursprünglich geplant zu starten, um sicherzustellen, dass genügend Zeit für alle Migrationen verfügbar ist.

Drittanbietertools für Microsoft 365- oder Office 365-Migrationen

Tools von Drittanbietern werden hauptsächlich in Migrationsszenarien verwendet, die Exchange nicht umfassen, z. B. in Gmail/G Suite/GWS (Google Workspace), 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-Migrationsszenarien gelten.

Wichtig

Wenden Sie sich bei Problemen mit der Datenkonsistenz oder -integrität nach einer Migration mithilfe von Drittanbietertools an den Anbieter, der das Tool zur Unterstützung bereitgestellt hat.

Faktor 1: Datenquelle für Toolmigrationen von Drittanbietern

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 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 Serverintegrität und -leistung von Exchange Server (2007, 2010, 2013, 2016, 2019).

Hinweis: Exchange Server 2007 und 2010 werden nicht mehr aktiv unterstützt. Das Ende des Supports für Exchange 2013 Server ist für April 2023 geplant. Exchange Server 2016 und 2019 werden bis Oktober 2025 erweitert unterstützt. Weitere Informationen finden Sie in der Exchange Server-Unterstützungsmatrix .

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. 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.

Führen Sie Migrationen durch, wenn Server über eine maximale Ressourcenverfügbarkeit verfügen, z. B. nach Feierabend oder an Wochenenden und 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 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 lokales Exchange verwenden, sind die gängigen Back-End-Aufgaben Sicherungslösungen und Exchange-Speicherwartung (2013, 2016, 2019).
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 die für Ihr E-Mail-System bereitgestellte Drosselungsrichtlinie. Google Mail schränkt beispielsweise ein, wie viele Daten in einem bestimmten Zeitraum extrahiert werden können. 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.

Um die Drosselungseinstellungen zu überprüfen, führen Sie das Cmdlet Get-ThrottlingPolicy aus. Weitere Informationen zur Drosselung finden Sie unter (2007, 2010, 2013, 2016, 2019).

Weitere Informationen zur IMAP-Drosselung finden Sie unter Migrieren Ihrer IMAP-Postfächer zu Microsoft 365 oder Office 365.

Faktor 2: Migrationsserver für Toolmigrationen von Drittanbietern

Die meisten Drittanbietertools für Microsoft 365- oder Office 365-Migrationen sind vom Client initiiert und übertragen 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 verwendung eines Migrationsservers zu verbessern, wenden Sie dieselben bewährten Methoden an, die im Abschnitt Faktor 1: Datenquelle für Migrationen von Drittanbietertools beschrieben sind.

Faktor 3: Migrations-Engine für Toolmigrationen von Drittanbietern

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

Exchange-Webdienste:

Exchange-Webdienste sind 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. Bei Verwendung im Identitätswechselmodus in Microsoft 365 oder Office 365 verbrauchen Migrationen mit Exchange-Webdiensten nicht die budgetierte Menge an Microsoft 365- oder Office 365-Exchange-Webdienstressourcen des Benutzers und verbrauchen stattdessen 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.

  • Die Einschränkungsrichtlinie für Exchange-Webdienste kann im Mandanten vorübergehend geändert werden (für eine Dauer von 30, 60 oder 90 Tagen), um den Abschluss der Migration zu ermöglichen. Dies kann im Hilfebereich des Microsoft 365 Admin Centers 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:

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 Nutzung durch einen Benutzer statt durch eine Anwendung erfolgt.

Bewährte Methoden:

  • Bei Migrationstools, die RPC über HTTP-Protokoll verwenden, ist es üblich, den Migrationsdurchsatz zu erhöhen, indem sie weitere Migrationsserver hinzufügen und mehrere Microsoft 365- oder Office 365-Administratorbenutzerkonten verwenden. Diese Vorgehensweise kann zu paralleler Dateneinschleusung und zu einem höheren Datendurchsatz führen, da jeder Administrator der Microsoft 365- und Office 365-Benutzerdrosselung 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 verwendet werden. 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 verglichen. 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, lösung A erfordert jedoch viel mehr RPC-Vorgänge, um Daten zu migrieren. Da jeder Vorgang Clientlatenz- und Serverprozesszeit in Anspruch nimmt, ist lösung A wesentlich langsamer bei der Migration derselben Datenmenge im Vergleich zu Lösung B und Outlook.

Faktor 4: Netzwerk für Toolmigrationen von Drittanbietern

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 über den Migrationsserver mithilfe des RPC-über-HTTP-Protokolls eine Verbindung mit dem Microsoft 365- oder Office 365-Postfach mit Outlook her. Stellen Sie sicher, dass Sie keine Verbindung im Cachemodus 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-Ressourcenintegritätsdrosselung wirkt sich auf Migrationen mit Migrationstools von Drittanbietern aus. Weitere Informationen finden Sie unter Ressourcenintegritätsbasierte Drosselung von Microsoft 365 und Office 365 .