Validierungs- und Importprozesse

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Dieser Artikel führt Sie durch die Vorbereitung, die erforderlich ist, um einen Import in Azure DevOps Services vorzubereiten. Wenn während des Prozesses Fehler auftreten, lesen Sie Problembehandlung bei Import- und Migrationsfehlern.

Voraussetzungen

  • Sie müssen einen Microsoft Entra-Mandanten einrichten, wie in Microsoft Entra Verbinden Sync beschrieben: Nehmen Sie eine Änderung an der Standardkonfiguration vor. Das Datenmigrationstool richtet einen Link zu Ihrem Microsoft Entra-Mandanten ein, wenn Ihre Azure DevOps Services-Organisation als Teil des Importvorgangs erstellt wird. Wenn Sie Ihre lokales Active Directory mit Microsoft Entra-ID synchronisieren, können Ihre Teammitglieder dieselben Anmeldeinformationen verwenden, um sich zu authentifizieren, und Ihre Azure DevOps Services-Administratoren können Ihre Active Directory-Gruppen zum Festlegen von Berechtigungen innerhalb Ihrer Azure DevOps Services-Organisation verwenden. Verwenden Sie zum Einrichten der Synchronisierung die Microsoft Entra Verbinden Technologie.
  • Bevor Sie mit den Importtasks beginnen, überprüfen Sie, ob Sie eine unterstützte Version von Azure DevOps Server ausführen.
  • Es wird empfohlen, den Schritt-für-Schritt-Migrationsleitfaden zu verwenden, um den Import fortzufahren. Der Leitfaden enthält Links zu technischen Dokumentationen, Tools und bewährten Methoden.

Überprüfen einer Sammlung

Überprüfen Sie jede Sammlung, die Sie zu Azure DevOps Services migrieren möchten. Der Validierungsschritt untersucht verschiedene Aspekte Ihrer Sammlung, einschließlich, aber nicht beschränkt auf, Größe, Sortierung, Identität und Prozesse.

Führen Sie die Überprüfung mithilfe des Datenmigrationstools aus.

  1. Herunterladen des Tools

  2. Kopieren der ZIP-Datei in eine Ihrer Azure DevOps Server-Anwendungsebenen

  3. Entzippen Sie die Datei. Sie können das Tool auch von einem anderen Computer ausführen, ohne Azure DevOps Server installiert zu haben, solange der Computer eine Verbindung mit der Konfigurationsdatenbank der Azure DevOps Server-Instanz herstellen kann.

  4. Öffnen Sie ein Eingabeaufforderungsfenster auf dem Server, und geben Sie einen cd-Befehl ein, um in das Verzeichnis zu wechseln, in dem das Datenmigrationstool gespeichert ist. Nehmen Sie sich einen Moment Zeit, um den Hilfeinhalt für das Tool zu überprüfen.

    a. Führen Sie den folgenden Befehl aus, um die Hilfe und Anleitung der obersten Ebene anzuzeigen:

     Migrator /help
    

    b. Zeigen Sie den Hilfetext für den Befehl an:

     Migrator validate /help 
    
  5. Wenn Sie eine Sammlung zum ersten Mal überprüfen, lassen Sie uns dies einfach halten. Ihr Befehl sollte die folgende Struktur aufweisen:

     Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
    

    Hier {name} wird der Name Ihres Microsoft Entra-Mandanten bereitgestellt, z. B. zum Ausführen für die DefaultCollection und den Fabrikam-Mandanten , der Befehl wie das Beispiel:

     Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
    
  6. Zum Ausführen des Tools auf einem anderen Computer als dem Azure DevOps Server benötigen Sie den Parameter /connectionString. Der Verbindungszeichenfolgenparameter verweist auf Ihre Azure DevOps Server Konfigurationsdatenbank. Wenn beispielsweise der überprüfte Befehl von der Fabrikam Corporation ausgeführt wird, würde der Befehl wie folgt aussehen:

     Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
    

    Wichtig

    Das Datenmigrationstool bearbeitet keine Daten oder Strukturen in der Sammlung. Die Sammlung wird nur gelesen, um Probleme zu identifizieren.

  7. Nach Abschluss der Überprüfung können Sie die Protokolldateien und Ergebnisse anzeigen.

    Screenshot of the validation results and logs in the Command Prompt window.

    Während der Überprüfung erhalten Sie eine Warnung, wenn einige Ihrer Pipelines Aufbewahrungsregeln pro Pipeline enthalten. Azure DevOps Services verwendet ein projektbasiertes Aufbewahrungsmodell und unterstützt keine Aufbewahrungsrichtlinien pro Pipeline. Wenn Sie mit der Migration fortfahren, werden die Richtlinien nicht an die gehostete Version übertragen. Stattdessen gelten die standardmäßigen Aufbewahrungsrichtlinien auf Projektebene. Bewahren Sie Builds wichtig auf, um deren Verlust zu vermeiden.

Nachdem alle Überprüfungen bestanden haben, können Sie zum nächsten Schritt des Importvorgangs wechseln. Wenn das Datenmigrationstool Fehler kennzeichnet, korrigieren Sie sie, bevor Sie fortfahren. Anleitungen zum Korrigieren von Validierungsfehlern finden Sie unter Problembehandlung bei Import- und Migrationsfehlern.

Importieren von Protokolldateien

Wenn Sie das Protokollverzeichnis öffnen, bemerken Sie möglicherweise mehrere Protokollierungsdateien.

Die Standard Protokolldatei heißt DataMigrationTool.log. Es enthält Details zu allem, was ausgeführt wurde. Damit Sie sich leichter auf bestimmte Bereiche konzentrieren können, generiert ein Protokoll für jeden wichtigen Überprüfungsvorgang.

Wenn TfsMigrator beispielsweise einen Fehler im Schritt "Projektprozesse überprüfen" meldet, können Sie die Datei ProjectProcessMap.log öffnen, um alles anzuzeigen, was für diesen Schritt ausgeführt wurde, anstatt durch das gesamte Protokoll scrollen zu müssen.

Überprüfen Sie die TryMatchOobProcesses.log-Datei nur, wenn Sie versuchen, Ihre Projektprozesse zu importieren, um das geerbte Modell zu verwenden. Wenn Sie das geerbte Modell nicht verwenden möchten, können Sie diese Fehler ignorieren, da sie nicht daran hindern, in Azure DevOps Services zu importieren.

Generieren von Importdateien

Das Datenmigrationstool hat die Sammlung überprüft und gibt ein Ergebnis von "Alle bestandenen Sammlungsüberprüfungen" zurück. Bevor Sie eine Sammlung offline schalten, um sie zu migrieren, generieren Sie die Importdateien. Wenn Sie den prepare Befehl ausführen, generieren Sie zwei Importdateien:

  • IdentityMapLog.csv: Beschreibt Ihre Identitätszuordnung zwischen Active Directory und Microsoft Entra ID.
  • import.json: Erfordert, dass Sie die Importspezifikation ausfüllen, die Sie zum Starten der Migration verwenden möchten.

Befehl "Vorbereiten"

Der prepare Befehl hilft beim Generieren der erforderlichen Importdateien. Im Wesentlichen durchsucht dieser Befehl die Sammlung, um eine Liste aller Benutzer zu finden, um das Identitätszuordnungsprotokoll, IdentityMapLog.csv, aufzufüllen, und versucht dann, eine Verbindung mit Microsoft Entra-ID herzustellen, um die Übereinstimmung der einzelnen Identitäten zu finden. Dazu muss Ihr Unternehmen das Tool Microsoft Entra Verbinden (früher als Verzeichnissynchronisierungstool, Verzeichnissynchronisierungstool oder DirSync.exe-Tool bezeichnet) verwenden.

Wenn die Verzeichnissynchronisierung eingerichtet ist, sollte das Datenmigrationstool die übereinstimmenden Identitäten finden und sie als "Aktiv" markieren. Wenn keine Übereinstimmungen vorhanden sind, wird die Identität im Identitätszuordnungsprotokoll als "Historisch " markiert, daher müssen Sie untersuchen, warum der Benutzer nicht in der Verzeichnissynchronisierung enthalten ist. Die Importspezifikationsdatei " import.json" sollte vor dem Import aufgefüllt werden.

validate Im Gegensatz zum Befehl prepare ist eine Internetverbindung erforderlich, da eine Verbindung mit der Microsoft Entra-ID hergestellt werden muss, um die Identitätszuordnungsprotokolldatei aufzufüllen. Wenn Ihre Azure DevOps Server-Instanz keinen Internetzugang hat, führen Sie das Tool von einem Computer aus aus, der ausgeführt wird. Solange Sie einen Computer mit einer Intranetverbindung mit Ihrem Azure DevOps Server instance und einer Internetverbindung finden, können Sie diesen Befehl ausführen. Wenn Sie Hilfe zum prepare Befehl benötigen, führen Sie den folgenden Befehl aus:

Migrator prepare /help

In der Hilfedokumentation finden Sie Anweisungen und Beispiele für die Ausführung des Migrator Befehls über den Azure DevOps Server instance selbst und einen Remotecomputer. Wenn Sie den Befehl über eine der Anwendungsebenen der Azure DevOps Server instance ausführen, sollte Ihr Befehl die folgende Struktur aufweisen:

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}
Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

Der connectionString-Parameter ist ein Zeiger auf die Konfigurationsdatenbank Ihres Azure DevOps Server instance. Wenn beispielsweise die Fabrikam Corporation den prepare Befehl ausführt, sieht der Befehl wie im folgenden Beispiel aus:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Wenn das Datenmigrationstool den prepare Befehl ausführt, wird eine vollständige Überprüfung ausgeführt, um sicherzustellen, dass sich seit der letzten vollständigen Überprüfung nichts mit Ihrer Sammlung geändert hat. Wenn neue Probleme erkannt werden, werden keine Importdateien generiert.

Kurz nach dem Ausführen des Befehls wird ein Microsoft Entra-Anmeldefenster angezeigt. Melden Sie sich mit einer Identität an, die zum Mandanten gehört Standard, der im Befehl angegeben ist. Stellen Sie sicher, dass der angegebene Microsoft Entra-Mandant der ist, mit dem Ihre zukünftige Organisation gesichert werden soll. In unserem Fabrikam-Beispiel gibt ein Benutzer Anmeldeinformationen ein, die dem folgenden Beispielfoto ähneln.

Wichtig

Verwenden Sie keinen Microsoft Entra-Testmandanten für einen Testimport und Ihren Microsoft Entra-Produktionsmandanten für die Produktionsausführung. Die Verwendung eines Microsoft Entra-Testmandanten kann zu Identitätsimportproblemen führen, wenn Sie mit dem Produktionsbetrieb Ihrer Organisation mit dem Microsoft Entra-Produktionsmandanten Ihrer Organisation beginnen.

Wenn Sie den prepare Befehl erfolgreich im Datenmigrationstool ausführen, werden im Ergebnisfenster eine Reihe von Protokollen und zwei Importdateien angezeigt. Suchen Sie im Protokollverzeichnis nach einem Protokollordner und zwei Dateien:

  • import.json ist die Importspezifikationsdatei. Es wird empfohlen, sich Zeit zu nehmen, ihn auszufüllen.
  • IdentityMapLog.csv enthält die generierte Zuordnung von Active Directory zu Microsoft Entra-Identitäten. Überprüfen Sie ihn auf Vollständigkeit, bevor Sie einen Import starten.

Die beiden Dateien werden in den nächsten Abschnitten ausführlicher beschrieben.

Die Importspezifikationsdatei

Die Importspezifikation import.json ist eine JSON-Datei, die Importeinstellungen bereitstellt. Sie enthält den gewünschten organization Namen, Speicherkontoinformationen und andere Informationen. Die meisten Felder werden automatisch aufgefüllt, und einige Felder erfordern Ihre Eingabe, bevor Sie einen Import versuchen.

Screenshot of a newly generated import specification file.

Die angezeigten Felder und erforderlichen Aktionen der Datei import.json werden in der folgenden Tabelle beschrieben:

Feld BESCHREIBUNG Erforderliche Maßnahme
`Source` Informationen zum Speicherort und den Namen der Quelldatendateien, die für den Import verwendet werden. Keine weiteren Maßnahmen erforderlich. Überprüfen Sie die Informationen zu den zu befolgenden Unterfeldaktionen.
Standort Der Shared Access Signature-Schlüssel für das Azure-Speicherkonto, das das Datenebenenanwendungspaket (DACPAC) hostet. Keine Aktion erforderlich. Dieses Feld wird in einem späteren Schritt behandelt.
Dateien Die Namen der Dateien, die Importdaten enthalten. Keine weiteren Maßnahmen erforderlich. Überprüfen Sie die Informationen zu den zu befolgenden Unterfeldaktionen.
DACPAC Eine DACPAC-Datei, die die Sammlungsdatenbank packt, die zum Einbinden der Daten während des Imports verwendet werden soll. Keine Aktion erforderlich. In einem späteren Schritt erstellen Sie diese Datei mithilfe Ihrer Sammlung und laden sie dann in ein Azure-Speicherkonto hoch. Aktualisieren Sie die Datei basierend auf dem Namen, den Sie verwenden, wenn Sie sie später in diesem Prozess generieren.
Ziel Eigenschaften der neuen organization, in die importiert werden soll. Keine weiteren Maßnahmen erforderlich. Überprüfen Sie die Informationen zu den zu befolgenden Unterfeldaktionen.
Name Der Name der organization, die während des Imports erstellt werden soll. Geben Sie einen Namen ein. Der Name kann später nach Abschluss des Imports schnell geändert werden.
HINWEIS: Erstellen Sie keine Organisation mit diesem Namen, bevor Sie den Import ausführen. Die Organisation wird als Teil des Importvorgangs erstellt.
ImportType Der Typ des Imports, den Sie ausführen möchten. Keine Aktion erforderlich. Wählen Sie in einem späteren Schritt den Typ des auszuführenden Imports aus.
Validierungsdaten Informationen, die erforderlich sind, um ihre Importerfahrung voranzutreiben. Das Datenmigrationstool generiert den Abschnitt "ValidationData". Es enthält Informationen, die Ihnen helfen sollen, Ihre Importerfahrung zu fördern. Bearbeiten Sie die Werte in diesem Abschnitt nicht* oder der Import konnte nicht gestartet werden.

Nachdem Sie den vorherigen Prozess abgeschlossen haben, sollten Sie eine Datei haben, die wie im folgenden Beispiel aussieht.

Screenshot of a partially completed import specification file.

In der vorherigen Abbildung hat der Planer des Fabrikam-Imports den Namen fabrikam-import und ausgewählte CUS (Central USA) als geografischen Standort für den Import hinzugefügt. Andere Werte wurden so belassen, dass geändert werden soll, bevor der Planer die Sammlung für die Migration offline geschaltet hat.

Hinweis

Bei Trockenlaufimporten wird automatisch ein "-dryrun" am Ende des Organisationsnamens angefügt, den Sie nach dem Import ändern können.

Unterstützte geografische Azure-Standorte für den Import

Azure DevOps Services ist an mehreren geografischen Standorten in Azure verfügbar. Aber nicht alle Speicherorte, an denen Azure DevOps Services verfügbar ist, werden für den Import unterstützt. In der folgenden Tabelle sind die geografischen Azure-Standorte aufgeführt, die Sie für den Import auswählen können. Außerdem ist der Wert enthalten, den Sie in der Importspezifikationsdatei platzieren müssen, um diese Geografie für den Import festzulegen.

Geografischer Standort Geografischer Azure-Standort Importspezifikationswert
USA Zentrale USA CUS
Europa Europa, Westen WEU
United Kingdom Vereinigtes Königreich, Süden UKS
Australien Australien (Osten) EAU
Südamerika Brasilien Süd SBR
Asien-Pazifik Indien (Süden) NI
Asien-Pazifik Asien, Südosten (Singapur) SEA
Canada Kanada, Mitte CC

Das Identitätszuordnungsprotokoll

Das Identitätszuordnungsprotokoll ist für die tatsächlichen Daten, die Sie zu Azure DevOps Services migrieren, von gleicher Bedeutung. Während Sie die Datei überprüfen, ist es wichtig zu verstehen, wie der Identitätsimport funktioniert und was die potenziellen Ergebnisse mit sich bringen können. Wenn Sie eine Identität importieren, kann sie entweder aktiv oder historisch sein. Aktive Identitäten können sich bei Azure DevOps Services anmelden, historische Identitäten können jedoch nicht.

Aktive Identitäten

Aktive Identitäten beziehen sich auf Benutzeridentitäten in Azure DevOps Services nach dem Import. In Azure DevOps Services werden diese Identitäten lizenziert und im organization als Benutzer angezeigt. Die Identitäten werden in der Identitätszuordnungsprotokolldatei in der Spalte Erwarteter Importstatus als aktiv markiert.

Historische Identitäten

Historische Identitäten werden als solche in der Spalte Erwarteter Importstatus in der Identitätszuordnungsprotokolldatei zugeordnet. Identitäten ohne Zeileneintrag in der Datei werden ebenfalls historisch. Ein Beispiel für eine Identität ohne Zeileneintrag kann ein Mitarbeiter sein, der nicht mehr in einem Unternehmen arbeitet.

Im Gegensatz zu aktiven Identitäten, historische Identitäten:

  • Nach der Migration haben Sie keinen Zugriff auf eine organization.
  • Sie verfügen nicht über Lizenzen.
  • Werden Sie nicht als Benutzer im organization angezeigt. Es bleibt nur die Vorstellung des Namens dieser Identität im organization erhalten, damit derEn Verlauf später durchsucht werden kann. Es wird empfohlen, historische Identitäten für Benutzer zu verwenden, die nicht mehr im Unternehmen arbeiten oder keinen weiteren Zugriff auf die Organisation benötigen.

Hinweis

Nachdem eine Identität als Verlauf importiert wurde, kann sie nicht aktiv werden.

Grundlegendes zur Identitätszuordnungsprotokolldatei

Die Identitätszuordnungsprotokolldatei ähnelt dem hier gezeigten Beispiel:

Screenshot of an identity map log file that's generated by the data migration tool.

Die Spalten in der Identitätszuordnungsprotokolldatei werden in der folgenden Tabelle beschrieben:

Sie und Ihr Microsoft Entra-Administrator müssen Benutzer untersuchen, die als "Keine Übereinstimmung gefunden" gekennzeichnet sind (Microsoft Entra ID-Synchronisierung überprüfen), um zu verstehen, warum sie nicht Teil Ihrer Microsoft Entra Verbinden Sync sind.

Spalte BESCHREIBUNG
Active Directory: Benutzer (Azure DevOps Server) Der Anzeigename, der von der Identität in Azure DevOps Server verwendet wird. Dieser Name erleichtert die Identifizierung, auf welchen Benutzer die Zeile in der Karte verweist.
Active Directory: Sicherheitsbezeichner Der eindeutige Bezeichner für die lokales Active Directory Identität in Azure DevOps Server. Diese Spalte wird verwendet, um Benutzer in der Sammlung zu identifizieren.
Microsoft Entra-ID: Importbenutzer erwartet (Azure DevOps Services) Entweder die erwartete Anmeldeadresse des abgeglichenen bald zu aktiven Benutzers oder keine Übereinstimmung gefunden (Microsoft Entra ID-Synchronisierung überprüfen), was angibt, dass die Identität während der Microsoft Entra-ID-Synchronisierung nicht gefunden und als Verlauf importiert wird.
Erwarteter Importstatus Der erwartete Benutzerimportstatus: Entweder aktiv , wenn eine Übereinstimmung zwischen Active Directory und Microsoft Entra-ID vorhanden ist, oder "Historisch ", wenn keine Übereinstimmung vorhanden ist.
Überprüfungsdatum Die letzte Überprüfung des Identitätszuordnungsprotokolls.

Beachten Sie beim Lesen der Datei, ob der Wert in der Spalte Erwarteter ImportstatusAktiv oder Verlauf ist. Aktiv gibt an, dass die Identität in dieser Zeile beim Import ordnungsgemäß zugeordnet wird. Historisch bedeutet, dass die Identitäten beim Import historisch werden. Es ist wichtig, die generierte Zuordnungsdatei auf Vollständigkeit und Richtigkeit zu überprüfen.

Wichtig

Der Import schlägt fehl, wenn wichtige Änderungen an Ihrer Microsoft Entra Verbinden Sicherheits-ID-Synchronisierung zwischen Importversuchen auftreten. Sie können neue Benutzer zwischen Trockenläufen hinzufügen und Korrekturen vornehmen, um sicherzustellen, dass zuvor importierte Verlaufsidentitäten aktiv werden. Das Ändern eines vorhandenen Benutzers, der zuvor als aktiv importiert wurde, wird derzeit jedoch nicht unterstützt. Dies bewirkt, dass der Import fehlschlägt. Ein Beispiel für eine Änderung ist möglicherweise das Abschließen eines Trockenlaufimports, das Löschen einer Identität aus Ihrer Microsoft Entra-ID, die aktiv importiert wurde, das erneute Erstellen eines neuen Benutzers in der Microsoft Entra-ID für dieselbe Identität und dann den Versuch eines anderen Imports. In diesem Fall versucht ein aktiver Identitätsimport zwischen Active Directory und neu erstellter Microsoft Entra-Identität, verursacht jedoch einen Importfehler.

  1. Überprüfen Sie die korrekt übereinstimmenen Identitäten. Sind alle erwarteten Identitäten vorhanden? Sind die Benutzer der richtigen Microsoft Entra-Identität zugeordnet?

    Wenn Werte geändert werden müssen, wenden Sie sich an Ihren Microsoft Entra-Administrator, um zu überprüfen, ob die lokales Active Directory Identität Teil der Synchronisierung mit Microsoft Entra-ID ist und ordnungsgemäß eingerichtet ist. Weitere Informationen finden Sie unter Integrieren Ihrer lokalen Identitäten in die Microsoft Entra-ID.

  2. Überprüfen Sie als Nächstes die Identitäten, die als historisch gekennzeichnet sind. Diese Bezeichnung impliziert, dass aus einem der folgenden Gründe eine übereinstimmende Microsoft Entra-Identität nicht gefunden werden konnte:

    • Die Identität ist nicht für die Synchronisierung zwischen lokales Active Directory und Microsoft Entra ID eingerichtet.
    • Die Identität wird noch nicht in Ihrer Microsoft Entra-ID ausgefüllt (z. B. ein neuer Mitarbeiter).
    • Die Identität ist in Ihrer Microsoft Entra-Instanz nicht vorhanden.
    • Der Benutzer, der diese Identität besitzt, arbeitet nicht mehr im Unternehmen.

Um die ersten drei Gründe zu beheben, richten Sie die beabsichtigte lokales Active Directory Identität für die Synchronisierung mit Microsoft Entra ID ein. Weitere Informationen finden Sie unter Integrieren Ihrer lokalen Identitäten in die Microsoft Entra-ID. Sie müssen Microsoft Entra Verbinden einrichten und ausführen, damit Identitäten in Azure DevOps Services als aktiv importiert werden.

Sie können den vierten Grund ignorieren, da Mitarbeiter, die nicht mehr im Unternehmen sind, als historisch importiert werden sollten.

Historische Identitäten (kleine Teams)

Hinweis

Die in diesem Abschnitt vorgeschlagene Strategie für den Identitätsimport sollte nur von kleinen Teams berücksichtigt werden.

Wenn Microsoft Entra Verbinden nicht konfiguriert ist, werden alle Benutzer in der Identitätszuordnungsprotokolldatei als historisch markiert. Das Ausführen eines Imports auf diese Weise führt dazu, dass alle Benutzer als Verlauf importiert werden. Es wird dringend empfohlen, Microsoft Entra Verbinden zu konfigurieren, um sicherzustellen, dass Ihre Benutzer als aktiv importiert werden.

Das Ausführen eines Imports mit allen historischen Identitäten hat Konsequenzen, die sorgfältig geprüft werden müssen. Nur Teams mit wenigen Benutzern und für die die Kosten für die Einrichtung von Microsoft Entra Verbinden als zu hoch eingestuft werden sollten.

Um alle Identitäten als Verlauf zu importieren, führen Sie die in den späteren Abschnitten beschriebenen Schritte aus. Wenn Sie einen Import in die Warteschlange stellen, wird die identität, mit der der Import in die Warteschlange gestellt wird, als Organisationsbesitzer in der Organisation gestartet. Alle anderen Benutzer werden als Verlauf importiert. Organisationsbesitzer können dann die Benutzer wieder hinzufügen, indem sie ihre Microsoft Entra-Identität verwenden. Die hinzugefügten Benutzer werden als neue Benutzer behandelt. Sie besitzen keinen ihrer Geschichte, und es gibt keine Möglichkeit, diesen Verlauf der Microsoft Entra-Identität erneut zu machen. Benutzer können jedoch weiterhin ihren Vorimportverlauf nachschlagen, indem Sie nach ihrer <Do Standard>< Aktiven Verzeichnisbenutzername> suchen.

Das Datenmigrationstool zeigt eine Warnung an, wenn es das vollständige Szenario für historische Identitäten erkennt. Wenn Sie sich für diesen Migrationspfad entscheiden, müssen Sie im Tool den Einschränkungen zustimmen.

Visual Studio-Abonnements

Das Datenmigrationstool kann Visual Studio-Abonnements (früher als MSDN-Vorteile bezeichnet) nicht erkennen, wenn es die Protokolldatei für die Identitätszuordnung generiert. Stattdessen empfiehlt es sich, nach dem Import das Feature für das Automatische Lizenzupgrade anzuwenden. Solange die Geschäftskonten der Benutzer ordnungsgemäß verknüpft sind, wendet Azure DevOps Services automatisch ihre Visual Studio-Abonnementvorteile bei der ersten Anmeldung nach dem Import an. Sie werden niemals Lizenzen in Rechnung gestellt, die während des Imports zugewiesen werden, damit Sie Abonnements später sicher verarbeiten können.

Sie müssen keinen Import mit trockener Ausführung wiederholen, wenn die Visual Studio-Abonnements der Benutzer nicht automatisch in Azure DevOps Services aktualisiert werden. Die Visual Studio-Abonnementverknüpfung erfolgt außerhalb des Bereichs eines Imports. Solange ihr Geschäftskonto vor oder nach dem Import ordnungsgemäß verknüpft ist, werden die Lizenzen der Benutzer bei der nächsten Anmeldung automatisch aktualisiert. Nachdem ihre Lizenzen erfolgreich aktualisiert wurden, werden die Benutzer bei der nächsten Ausführung eines Imports automatisch bei der ersten Anmeldung bei der Organisation aktualisiert.

Vorbereiten des Imports

Jetzt haben Sie alles bereit, um den Import auszuführen. Planen Sie Ausfallzeiten mit Ihrem Team, um die Sammlung für die Migration offline zu schalten. Wenn Sie sich auf eine Zeit zum Ausführen des Imports einigen, laden Sie die erforderlichen Ressourcen hoch, die Sie generiert haben, und eine Kopie der Datenbank in Azure. Die Vorbereitung für den Import besteht aus den folgenden fünf Schritten.

Schritt 1: Schalten Sie die Sammlung offline, und trennen Sie sie.

Die Sammlungsgröße für die DACPAC-Methode beträgt 150 GB. Wenn das Datenmigrationstool eine Warnung anzeigt, dass Sie die DACPAC-Methode nicht verwenden können, müssen Sie den Import mithilfe der SQL Azure VM-Methode ausführen. Überspringen Sie in diesem Fall die Schritte 2 bis 5, und befolgen Sie die Anweisungen unter Importieren großer Sammlungen , und fahren Sie dann mit dem Abschnitt Bestimmen des Importtyps fort.

Schritt 2: Generieren Sie eine DACPAC-Datei aus der Sammlung, die Sie importieren möchten.
Schritt 3: Laden Sie die DACPAC-Datei hoch, und importieren Sie Dateien in ein Azure-Speicherkonto.
Schritt 4: Generieren eines SAS-Tokens für den Zugriff auf das Speicherkonto.
Schritt 5: Füllen Sie die Importspezifikation aus.

Hinweis

Bevor Sie einen Produktionsimport durchführen, wird dringend empfohlen, einen Trockenlaufimport durchzuführen. Mit einem Trockenlauf können Sie überprüfen, ob der Importprozess für Ihre Sammlung funktioniert und dass keine eindeutigen Datenformen vorhanden sind, die zu einem Fehler beim Import der Produktion führen können.

Schritt 1: Trennen Der Sammlung

Das Trennen der Sammlung ist ein wichtiger Schritt im Importprozess. Identitätsdaten für die Sammlung befinden sich in der Konfigurationsdatenbank des Azure DevOps Server instance, während die Sammlung angefügt und online ist. Wenn eine Sammlung von der Azure DevOps Server instance getrennt wird, nimmt sie eine Kopie dieser Identitätsdaten an und verpackt sie mit der Auflistung für den Transport. Ohne diese Daten kann der Identitätsteil des Imports nicht ausgeführt werden. Es wird empfohlen, die Auflistung so lange getrennt zu lassen, bis der Import abgeschlossen ist, da es keine Möglichkeit gibt, die änderungen zu importieren, die während des Imports aufgetreten sind.

Für einen Trockenlaufimport (Test) wird empfohlen, die Sammlung nach der Sicherung für den Import erneut anzuordnen, sodass Sie sich keine Gedanken darüber machen, die neuesten Daten für diesen Importtyp zu erhalten. Um Offlinezeit insgesamt zu vermeiden, können Sie auch eine Offlineablösung für Trockenläufe verwenden.

Es ist wichtig, die Kosten für die Auswahl von null Ausfallzeiten für einen Trockenlauf abzuwägen. Sie erfordert das Erstellen von Sicherungen der Sammlungs- und Konfigurationsdatenbank, deren Wiederherstellung auf einer SQL-instance und das anschließende Erstellen einer getrennten Sicherung. Eine Kostenanalyse könnte belegen, dass es am Ende besser ist, nur ein paar Stunden Ausfallzeiten zu nehmen, um die getrennten Sicherungen direkt zu nehmen.

Schritt 2: Generieren einer DACPAC-Datei

DACPACs bieten eine schnelle und relativ einfache Methode zum Verschieben von Sammlungen in Azure DevOps Services. Nachdem die Größe einer Sammlungsdatenbank jedoch einen bestimmten Schwellenwert überschreitet, beginnen sich die Vorteile der Verwendung einer DACPAC-Datei zu verringern.

Hinweis

Wenn das Datenmigrationstool eine Warnung anzeigt, dass Sie die DACPAC-Methode nicht verwenden können, müssen Sie den Import mithilfe der SQL Azure VM-Methode ausführen, die unter Importieren großer Sammlungen bereitgestellt wird.

Wenn das Datenmigrationstool keine Warnung anzeigt, verwenden Sie die in diesem Schritt beschriebene DACPAC-Methode.

DACPAC ist ein Feature von SQL Server, mit dem Datenbanken in eine einzelne Datei verpackt und in anderen Instanzen von SQL Server bereitgestellt werden können. Eine DACPAC-Datei kann auch direkt in Azure DevOps Services wiederhergestellt werden, sodass Sie sie als Paketerstellungsmethode zum Abrufen der Daten Ihrer Sammlung in der Cloud verwenden können.

Wichtig

  • Wenn Sie SqlPackage.exe verwenden, müssen Sie die .NET Framework-Version von SqlPackage.exe verwenden, um die DACPAC vorzubereiten. Der MSI-Installer muss zum Installieren der .NET Framework-Version von SqlPackage.exe verwendet werden. Verwenden Sie nicht die Dotnet CLI- oder ZIP-Versionen (Windows .NET 6) von SqlPackage.exe, da diese Versionen DACPACs generieren können, die mit Azure DevOps Services nicht kompatibel sind.
  • Version 161 von SqlPackage verschlüsselt standardmäßig Datenbankverbindungen und stellt möglicherweise keine Verbindung her. Wenn sie einen Anmeldevorgangsfehler erhalten, fügen Sie der Verbindungszeichenfolge der SqlPackage-Anweisung hinzu;Encrypt=False;TrustServerCertificate=True.

Laden Sie SqlPackage.exe mit dem neuesten MSI Installer aus den Versionshinweisen von SqlPackage herunter, und installieren Sie sie.

Nachdem Sie den MSI Installer verwendet haben, installiert SqlPackage.exe in einem Pfad ähnlich wie %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Beachten Sie beim Generieren eines DACPAC zwei Überlegungen: den Datenträger, auf dem DACPAC gespeichert ist, und den Speicherplatz auf dem Computer, auf dem DACPAC generiert wird. Sie möchten sicherstellen, dass genügend Speicherplatz vorhanden ist, um den Vorgang abzuschließen.

Während das Paket erstellt wird, speichert SqlPackage.exe vorübergehend Daten aus Ihrer Sammlung im temporären Verzeichnis auf Laufwerk C des Computers, von dem Sie die Paketanforderung initiieren.

Möglicherweise stellen Sie fest, dass Laufwerk C zu klein ist, um die Erstellung einer DACPAC-Datei zu unterstützen. Sie können den benötigten Speicherplatz schätzen, indem Sie nach der größten Tabelle in Ihrer Sammlungsdatenbank suchen. DACPACs werden nacheinander erstellt. Der maximale Speicherplatzbedarf zum Ausführen der Generierung entspricht in etwa der Größe der größten Tabelle in der Sammlungsdatenbank. Wenn Sie den generierten DACPAC auf Laufwerk C speichern, sollten Sie die Größe der Sammlungsdatenbank berücksichtigen, wie in der DataMigrationTool.log-Datei aus einer Überprüfungsausführung angegeben.

Die Datei DataMigrationTool.log stellt eine Liste der größten Tabellen in der Auflistung bei jeder Ausführung des Befehls bereit. Ein Beispiel für Tabellengrößen für eine Auflistung finden Sie in der folgenden Ausgabe. Vergleichen Sie die Größe der größten Tabelle mit dem freien Speicherplatz auf dem Laufwerk, auf dem Ihr temporäres Verzeichnis gehostet wird.

Wichtig

Bevor Sie mit dem Generieren einer DACPAC-Datei fortfahren, stellen Sie sicher, dass Ihre Sammlung getrennt ist.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

Stellen Sie sicher, dass das Laufwerk, auf dem Ihr temporäres Verzeichnis gehostet wird, über mindestens so viel freien Speicherplatz verfügt. Wenn dies nicht der Fall ist, müssen Sie das temporäre Verzeichnis umleiten, indem Sie eine Umgebungsvariable festlegen.

SET TEMP={location on disk}

Ein weiterer Aspekt ist, wo die DACPAC-Daten gespeichert werden. Das Verweisen auf den Speicherort auf ein ferngesteuertes Remotelaufwerk kann zu längeren Generationen führen. Wenn ein schnelles Laufwerk wie ein Solid State Drive (SSD) lokal verfügbar ist, wird empfohlen, das Laufwerk als DACPAC-Speicherort zu verwenden. Andernfalls ist es immer schneller, einen Datenträger zu verwenden, der sich auf dem Computer befindet, auf dem sich die Sammlungsdatenbank befindet, und nicht ein Remotelaufwerk.

Nachdem Sie den Zielspeicherort für DACPAC identifiziert und sichergestellt haben, dass genügend Speicherplatz vorhanden ist, ist es an der Zeit, die DACPAC-Datei zu generieren.

Öffnen Sie ein Eingabeaufforderungsfenster, und wechseln Sie zum SqlPackage.exe Speicherort. Ersetzen Sie zum Generieren der DACPAC die Platzhalterwerte durch die erforderlichen Werte, und führen Sie dann den folgenden Befehl aus:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
  • Datenquelle: Die SQL Server instance, die Ihre Azure DevOps Server-Sammlungsdatenbank hostet.
  • Anfangskatalog: Der Name der Sammlungsdatenbank.
  • targetFile: Der Speicherort auf dem Datenträger und der DACPAC-Dateiname.

Ein DACPAC-Generierungsbefehl, der auf der Azure DevOps Server Datenebene selbst ausgeführt wird, wird im folgenden Beispiel gezeigt:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

Die Ausgabe des Befehls ist eine DACPAC-Datei, die aus der Sammlungsdatenbank Foo namens Foo.dacpac generiert wird.

Konfigurieren Der Sammlung für den Import

Nachdem Ihre Sammlungsdatenbank auf Ihrem virtuellen Azure-Computer wiederhergestellt wurde, konfigurieren Sie eine SQL-Anmeldung, damit Azure DevOps Services eine Verbindung mit der Datenbank herstellen kann, um die Daten zu importieren. Diese Anmeldung ermöglicht nur Lesezugriff auf eine einzelne Datenbank.

Öffnen Sie zunächst SQL Server Management Studio auf dem virtuellen Computer, und öffnen Sie dann ein neues Abfragefenster für die zu importierende Datenbank.

Legen Sie die Wiederherstellung der Datenbank auf einfach fest:

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

Erstellen Sie eine SQL-Anmeldung für die Datenbank, und weisen Sie diese Anmeldung bei "TFSEXECROLE" zu:

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Im Anschluss an unser Fabrikam-Beispiel würden die beiden SQL-Befehle wie im folgenden Beispiel aussehen:

ALTER DATABASE [Foo] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Hinweis

Achten Sie darauf, SQL Server und Windows-Authentifizierung Modus in SQL Server Management Studio auf der VM zu aktivieren. Wenn Sie den Authentifizierungsmodus nicht aktivieren, schlägt der Import fehl.

Konfigurieren der Importspezifikationsdatei für die VM

Aktualisieren Sie die Importspezifikationsdatei, um Informationen zum Herstellen einer Verbindung mit der SQL Server-Instanz einzuschließen. Öffnen Sie Die Importspezifikationsdatei, und nehmen Sie die folgenden Aktualisierungen vor.

  1. Entfernen Sie den DACPAC-Parameter aus dem Quelldateiobjekt.

    Die Importspezifikation vor der Änderung wird im folgenden Code angezeigt.

    Screenshot of the import specification before the change.

    Die Importspezifikation nach der Änderung wird im folgenden Code angezeigt.

    Screenshot of the import specification after the change.

  2. Füllen Sie die erforderlichen Parameter aus, und fügen Sie das folgende Eigenschaftenobjekt in Ihrem Quellobjekt in der Spezifikationsdatei hinzu.

    "Properties":
    {
        "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
    }
    

Nachdem Sie die Änderungen angewendet haben, sieht die Importspezifikation wie im folgenden Beispiel aus.

Screenshot of the import specification referencing a SQL Azure VM.

Ihre Importspezifikation ist jetzt für die Verwendung eines SQL Azure virtuellen Computers für den Import konfiguriert. Fahren Sie mit den restlichen Vorbereitungsschritten fort, um sie in Azure DevOps Services zu importieren. Achten Sie nach Abschluss des Imports darauf, die SQL-Anmeldung zu löschen oder das Kennwort zu drehen. Microsoft behält die Anmeldeinformationen nach Abschluss des Imports nicht bei.

Schritt 3: Hochladen der DACPAC-Datei

Hinweis

Wenn Sie die SQL Azure VM-Methode verwenden, müssen Sie nur die Verbindungszeichenfolge angeben. Sie müssen keine Dateien hochladen, und Sie können diesen Schritt überspringen.

Ihr DACPAC muss in einem Azure-Speichercontainer platziert werden, bei dem es sich um einen vorhandenen Container oder einen container handelt, der speziell für Ihren Migrationsaufwand erstellt wurde. Es ist wichtig, sicherzustellen, dass Ihr Container an den richtigen geografischen Standorten erstellt wird.

Azure DevOps Services ist an mehreren geografischen Standorten verfügbar. Wenn Sie an diese Speicherorte importieren, ist es wichtig, die Daten korrekt zu platzieren, um sicherzustellen, dass der Import erfolgreich gestartet werden kann. Ihre Daten müssen sich an demselben geografischen Ort befinden, in den Sie importieren. Wenn Die Daten an einer anderen Stelle platziert werden, kann der Import nicht gestartet werden. In der folgenden Tabelle sind die zulässigen geografischen Standorte für das Erstellen Ihres Speicherkontos und das Hochladen Ihrer Daten aufgeführt.

Gewünschter geografischer Importstandort Geografischer Standort des Speicherkontos
Zentrale USA Zentrale USA
Europa, Westen Europa, Westen
United Kingdom Vereinigtes Königreich, Süden
Australien (Osten) Australien (Osten)
Brasilien Süd Brasilien Süd
Indien, Süden Indien, Süden
Kanada, Mitte Kanada, Mitte
Asien-Pazifik, (Singapur) Asien-Pazifik, (Singapur)

Obwohl Azure DevOps Services an mehreren geografischen Standorten in den USA verfügbar ist, akzeptiert nur der zentrale USA Standort neue Azure DevOps Services. Sie können Ihre Daten zurzeit nicht in andere US-Azure-Standorte importieren.

Sie können einen Blobcontainer aus dem Azure-Portal erstellen. Laden Sie nach dem Erstellen des Containers die Sammlungs-DACPAC-Datei hoch.

Löschen Sie nach Abschluss des Imports den BLOB-Container und das zugehörige Speicherkonto mit Verwendungstools wie AzCopy oder einem anderen Azure Storage Explorer-Tool, z. B. Azure Storage-Explorer.

Hinweis

Wenn Ihre DACPAC-Datei größer als 10 GB ist, wird empfohlen, AzCopy zu verwenden. AzCopy unterstützt Multithreaduploads für schnellere Uploads.

Schritt 4: Generieren eines SAS-Tokens

Ein SAS-Token (Shared Access Signature) ermöglicht delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit dem Token können Sie Microsoft die niedrigste Berechtigungsstufe erteilen, die erforderlich ist, um auf Ihre Daten zuzugreifen, um den Import auszuführen.

SAS-Token können mithilfe des Azure-Portal generiert werden. Aus Sicherheitsgründen empfehlen wir Folgendes:

  1. Wählen Sie nur "Lesen " und "Liste" als Berechtigungen für Ihr SAS-Token aus. Es sind keine weiteren Berechtigungen erforderlich.
  2. Legen Sie eine Ablaufzeit nicht mehr als sieben Tage in die Zukunft fest.
  3. Beschränken sie den Zugriff nur auf Azure DevOps Services-IPs.
  4. Platzieren Sie das SAS-Token an einem sicheren Speicherort.

Schritt 5: Ausfüllen der Importspezifikation

Weiter oben im Prozess haben Sie die Importspezifikationsdatei, die als import.json bezeichnet wird, teilweise ausgefüllt. An diesem Punkt verfügen Sie über genügend Informationen, um alle verbleibenden Felder mit Ausnahme des Importtyps auszufüllen. Der Importtyp wird später im Importabschnitt behandelt.

Füllen Sie in der Spezifikationsdatei "import.json " unter "Source" die folgenden Felder aus.

  • Speicherort: Fügen Sie den SAS-Schlüssel ein, den Sie aus dem Skript generiert und dann im vorherigen Schritt kopiert haben.
  • Dacpac: Stellen Sie sicher, dass die Datei, einschließlich der Dateierweiterung .dacpac , denselben Namen wie die DACPAC-Datei hat, die Sie in das Speicherkonto hochgeladen haben.

Die endgültige Importspezifikationsdatei sollte wie im folgenden Beispiel aussehen.

Screenshot of the completed import specification file.

Beschränken des Zugriffs auf Azure DevOps Services IP-Adressen

Weitere Informationen finden Sie unter Einschränken des Zugriffs auf Azure DevOps Services-IPs nur.

Option 1: Verwenden von Diensttags

Sie können verbindungen von allen geografischen Standorten von Azure DevOps Services ganz einfach zulassen, indem Sie das azuredevopsDiensttag zu Ihren Netzwerksicherheitsgruppen oder Firewalls entweder über das Portal oder programmgesteuert hinzufügen.

Option 2: Verwenden von IpList

Verwenden Sie den IpList Befehl, um die Liste der Ip-Adressen abzurufen, denen Zugriff gewährt werden muss, um Verbindungen von einem bestimmten geografischen Standort von Azure DevOps Services zuzulassen.

In der Hilfedokumentation finden Sie Anweisungen und Beispiele für die Ausführung von Migrator vom Azure DevOps Server instance selbst und einem Remotecomputer aus. Wenn Sie den Befehl über eine der Anwendungsebenen der Azure DevOps Server instance ausführen, sollte Ihr Befehl die folgende Struktur aufweisen:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Sie können die Liste der Ip-Adressen entweder über das Portal oder programmgesteuert zu Ihren Netzwerksicherheitsgruppen oder Firewalls hinzufügen.

Bestimmen des Importtyps

Importe können entweder als Trockenlauf oder als Produktionsausführung in die Warteschlange gestellt werden. Der ImportType-Parameter bestimmt den Importtyp:

  • DryRun: Verwenden Sie einen Trockenlauf zu Testzwecken. Das System löscht Trockenläufe nach 21 Tagen.
  • ProductionRun: Verwenden Sie eine Produktionsausführung, wenn Sie den resultierenden Import beibehalten und die organization vollzeit in Azure DevOps Services verwenden möchten, nachdem der Import abgeschlossen ist.

Tipp

Es wird immer empfohlen, zuerst einen Trockenlaufimport durchzuführen.

Completed import specification file with import type

Organisationen mit trockener Ausführung

Mithilfe von Trockenausführungsimporten können Teams die Migration ihrer Sammlungen testen. Es wird erwartet, dass Organisationen nicht ewig in der Nähe bleiben, sondern für eine kurze Zeit existieren. Tatsächlich müssen alle abgeschlossenen Trockenlauforganisationen gelöscht werden, bevor eine Produktionsmigration ausgeführt werden kann. Alle Trockenlauforganisationen haben eine begrenzte Existenz und werden nach einem bestimmten Zeitraum automatisch gelöscht. Informationen dazu, wann die Organisation gelöscht wird, ist in die Erfolgs-E-Mail eingeschlossen, die Sie nach Abschluss des Imports erhalten sollten. Achten Sie darauf, dieses Datum zur Kenntnis zu nehmen und entsprechend zu planen.

Die meisten Organisationen mit trockener Ausführung haben 15 Tage Zeit, bevor sie gelöscht werden. Organisationen mit trockener Ausführung können auch einen Ablauf von 21 Tagen haben, wenn mehr als 100 Benutzer zur Importzeit über eine Einfache oder eine höhere Lizenz verfügen. Nach dem angegebenen Zeitraum wird die Trockenlauf-organization gelöscht. Sie können Importe mit trockener Ausführung so oft wiederholen, wie Sie benötigen, bevor Sie eine Produktionsmigration durchführen. Sie müssen alle vorherigen Trockenläufe löschen, bevor Sie eine neue versuchen. Wenn Ihr Team bereit ist, eine Produktionsmigration durchzuführen, müssen Sie die Trockenlauforganisation manuell löschen.

Weitere Informationen zu Aktivitäten nach dem Import finden Sie im Artikel nach dem Import .

Wenn Beim Importieren Probleme auftreten, finden Sie weitere Informationen unter Behandeln von Import- und Migrationsfehlern.

Ausführen eines Imports

Ihr Team ist nun bereit, mit dem Ausführen eines Imports zu beginnen. Es wird empfohlen, mit einem erfolgreichen Trockenlaufimport zu beginnen, bevor Sie einen Import mit Produktionsausführung versuchen. Mit Trockenlaufimporten können Sie im Voraus sehen, wie ein Import aussieht, potenzielle Probleme erkennen und Erfahrungen sammeln, bevor Sie in den Produktionsbetrieb gehen.

Hinweis

  • Wenn Sie einen abgeschlossenen Import mit Produktionsausführung für eine Sammlung wiederholen müssen, wie im Fall eines Rollbacks, wenden Sie sich an Azure DevOps Services Kundensupport, bevor Sie einen weiteren Import in die Warteschlange stellen.
  • Azure-Administratoren können verhindern, dass Benutzer neue Azure DevOps-Organisationen erstellen. Wenn die Microsoft Entra-Mandantenrichtlinie aktiviert ist, kann der Import nicht abgeschlossen werden. Bevor Sie beginnen, stellen Sie sicher, dass die Richtlinie nicht festgelegt ist oder dass für den Benutzer, der die Migration ausführt, eine Ausnahme vorhanden ist. Weitere Informationen finden Sie unter Einschränken der Organisationserstellung über die Microsoft Entra-Mandantenrichtlinie.
  • Azure DevOps Services unterstützt keine Aufbewahrungsrichtlinien pro Pipeline, und sie werden nicht an die gehostete Version übertragen.

Überlegungen für Rollbackpläne

Ein häufiges Problem für Teams, die eine endgültige Produktionsausführung durchführen, ist ihr Rollbackplan, wenn etwas mit dem Import schief geht. Es wird dringend empfohlen, eine trockene Ausführung durchzuführen, um sicherzustellen, dass Sie die Importeinstellungen testen können, die Sie für das Datenmigrationstool für Azure DevOps bereitstellen.

Das Rollback für die endgültige Produktionsausführung ist relativ einfach. Bevor Sie den Import in die Warteschlange stellen, trennen Sie die Teamprojektsammlung von Azure DevOps Server, wodurch sie ihren Teammitgliedern nicht zur Verfügung steht. Wenn Sie aus irgendeinem Grund einen Rollback für die Produktionsausführung durchführen und den lokalen Server für Ihre Teammitglieder wieder online schalten müssen, können Sie dies tun. Fügen Sie die Teamprojektsammlung erneut lokal an, und informieren Sie Ihr Team darüber, dass sie weiterhin normal arbeiten, während Ihr Team gruppiert, um mögliche Fehler zu verstehen.

Warteschlange für einen Import

Wichtig

Bevor Sie fortfahren, stellen Sie sicher, dass Ihre Sammlung getrennt wurde, bevor Sie eine DACPAC-Datei generieren oder die Sammlungsdatenbank auf einen SQL Azure virtuellen Computer hochladen. Wenn Sie diesen Schritt nicht abschließen, tritt beim Import ein Fehler auf. Für den Fall, dass beim Import ein Fehler auftritt, finden Sie weitere Informationen unter Problembehandlung bei Import- und Migrationsfehlern.

Starten Sie einen Import mithilfe des Importbefehls des Datenmigrationstools. Der Importbefehl verwendet eine Importspezifikationsdatei als Eingabe. Es analysiert die Datei, um sicherzustellen, dass die angegebenen Werte gültig sind, und bei erfolgreicher Ausführung wird ein Import in Azure DevOps Services in die Warteschlange gestellt. Der Importbefehl erfordert eine Internetverbindung, erfordert jedoch keine Verbindung mit Ihrer Azure DevOps Server-Instanz.

Öffnen Sie zunächst ein Eingabeaufforderungsfenster, und ändern Sie die Verzeichnisse in den Pfad zum Datenmigrationstool. Es wird empfohlen, den Hilfetext zu überprüfen, der mit dem Tool bereitgestellt wird. Führen Sie den folgenden Befehl aus, um die Anleitung und Hilfe für den Importbefehl anzuzeigen:

Migrator import /help

Der Befehl zum Warteschleifen eines Imports weist die folgende Struktur auf:

Migrator import /importFile:{location of import specification file}

Das folgende Beispiel zeigt einen abgeschlossenen Importbefehl:

Migrator import /importFile:C:\DataMigrationToolFiles\import.json

Nachdem die Überprüfung bestanden wurde, werden Sie aufgefordert, sich bei der Microsoft Entra-ID anzumelden. Es ist wichtig, sich mit einer Identität anzumelden, die mitglied desselben Microsoft Entra-Mandanten ist wie die Identitätszuordnungsprotokolldatei erstellt wurde. Der angemeldete Benutzer ist der Besitzer der importierten Organisation.

Hinweis

Jeder Microsoft Entra-Mandant ist auf fünf Importe pro 24-Stunden-Zeitraum beschränkt. Nur Importe, die sich in der Warteschlange befinden, zählen für diese Obergrenze.

Wenn Ihr Team einen Import initiiert, wird eine E-Mail-Benachrichtigung an den Benutzer gesendet, der den Import in die Warteschlange gestellt hat. Etwa 5 bis 10 Minuten nach der Warteschlange des Imports kann Ihr Team zum organization wechseln, um die status zu überprüfen. Nachdem der Import abgeschlossen ist, wird Ihr Team zur Anmeldung weitergeleitet, und eine E-Mail-Benachrichtigung wird an die Organisationsbesitzer gesendet.