Przetestuj migrację przebiegów
Twój zespół jest teraz gotowy do rozpoczęcia procesu rozpoczynania przebiegu testu migracji, a następnie pełnej migracji produkcyjnej. W tej fazie omówimy końcowe kroki kolejkowania migracji oprócz innych zadań, które zwykle pojawiają się na końcu projektu migracji.
Wymagania wstępne
Przed rozpoczęciem migracji przebiegu testu ukończ fazę Przygotowywanie przebiegu testu.
Weryfikowanie kolekcji
Zweryfikuj każdą kolekcję, która ma zostać zmigrowana do usług Azure DevOps Services. Krok weryfikacji sprawdza różne aspekty kolekcji, w tym między innymi rozmiar, sortowanie, tożsamość i procesy.
Uruchom walidację przy użyciu narzędzia do migracji danych.
Pobierz narzędzie do migracji danych.
Skopiuj plik zip do jednej z warstw aplikacji usługi Azure DevOps Server.
Rozpakuj plik. Narzędzie można również uruchomić z innej maszyny bez zainstalowanego serwera Azure DevOps Server, o ile komputer może nawiązać połączenie z bazą danych konfiguracji wystąpienia usługi Azure DevOps Server.
Otwórz okno wiersza polecenia na serwerze i wprowadź polecenie cd, aby zmienić katalog, w którym jest przechowywane narzędzie do migracji danych. Pośmiń chwilę, aby przejrzeć zawartość pomocy dla narzędzia.
a. Aby wyświetlić pomoc i wskazówki najwyższego poziomu, uruchom następujące polecenie.
Migrator /helpb. Wyświetl tekst pomocy dla polecenia .
Migrator validate /helpPodczas pierwszego sprawdzania poprawności kolekcji polecenie powinno mieć następującą prostą strukturę.
Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}Gdzie
{name}podaje nazwę dzierżawy firmy Microsoft Entra, na przykład do uruchamiania względem kolekcji DefaultCollection i dzierżawy firmy fabrikam , polecenie będzie wyglądać podobnie do poniższego przykładu.Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}Aby uruchomić narzędzie z maszyny innej niż usługa Azure DevOps Server, potrzebny jest parametr /connectionString . Parametr parametry połączenia wskazuje bazę danych konfiguracji usługi Azure DevOps Server. Na przykład jeśli zweryfikowane polecenie jest uruchamiane przez firmę Fabrikam, polecenie będzie wyglądać następująco.
Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"Ważne
Narzędzie do migracji danych nie edytuje żadnych danych ani struktur w kolekcji. Odczytuje kolekcję tylko w celu zidentyfikowania problemów.
Po zakończeniu walidacji można wyświetlić pliki dziennika i wyniki.
Podczas walidacji zostanie wyświetlone ostrzeżenie, jeśli niektóre potoki zawierają reguły przechowywania dla potoku. Usługa Azure DevOps Services używa modelu przechowywania opartego na projekcie i nie obsługuje zasad przechowywania potoku. Jeśli przejdziesz do migracji, zasady nie są przenoszone do hostowanej wersji. Zamiast tego mają zastosowanie domyślne zasady przechowywania na poziomie projektu. Zachowaj ważne kompilacje, aby uniknąć ich utraty.
Po zakończeniu wszystkich weryfikacji można przejść do następnego kroku procesu migracji. Jeśli narzędzie do migracji danych flaguje błędy, popraw je przed kontynuowaniem. Aby uzyskać wskazówki dotyczące poprawiania błędów walidacji, zobacz Rozwiązywanie problemów z błędami migracji i migracji.
Importowanie plików dziennika
Po otwarciu katalogu dziennika może zostać wyświetlonych kilka plików rejestrowania.
Główny plik dziennika nosi nazwę DataMigrationTool.log. Zawiera szczegółowe informacje o wszystkim, co zostało uruchomione. Aby ułatwić skoncentrowanie się na określonych obszarach, dziennik jest generowany dla każdej głównej operacji weryfikacji.
Jeśli na przykład tfsMigrator zgłasza błąd w kroku "Weryfikowanie procesów projektu", możesz otworzyć plik ProjectProcessMap.log , aby wyświetlić wszystko, co zostało uruchomione dla tego kroku, zamiast przewijać cały dziennik.
Przejrzyj plik TryMatchOobProcesses.log tylko wtedy, gdy próbujesz przeprowadzić migrację procesów projektu w celu użycia odziedziczonego modelu. Jeśli nie chcesz używać dziedziczonego modelu, możesz zignorować te błędy, ponieważ nie uniemożliwiają importowania do usług Azure DevOps Services. Aby uzyskać więcej informacji, zobacz faza walidacji migracji.
Generowanie plików migracji
Narzędzie do migracji danych zweryfikowało kolekcję i zwraca wynik "Wszystkie weryfikacje kolekcji zostały pomyślnie przekazane". Przed przełączenie kolekcji do trybu offline w celu jej migracji wygeneruj pliki migracji. Po uruchomieniu prepare polecenia wygenerujesz dwa pliki migracji:
- IdentityMapLog.csv: przedstawia mapę tożsamości między usługą Active Directory i identyfikatorem Entra firmy Microsoft.
- migration.json: wymaga wypełnienia specyfikacji migracji, której chcesz użyć do rozpoczęcia migracji.
Polecenie Prepare
Polecenie prepare pomaga w generowaniu wymaganych plików migracji. Zasadniczo to polecenie skanuje kolekcję, aby znaleźć listę wszystkich użytkowników w celu wypełnienia dziennika mapy tożsamości, IdentityMapLog.csv, a następnie próbuje nawiązać połączenie z identyfikatorem Entra firmy Microsoft w celu znalezienia dopasowania każdej tożsamości. W tym celu firma musi użyć narzędzia Microsoft Entra Connect (wcześniej znanego jako narzędzie synchronizacji katalogów, narzędzie synchronizacji katalogów lub narzędzie DirSync.exe).
Jeśli synchronizacja katalogów jest skonfigurowana, narzędzie do migracji danych powinno znaleźć pasujące tożsamości i oznaczyć je jako Aktywne. Jeśli nie ma dopasowań, tożsamość jest oznaczona jako Historyczna w dzienniku mapy tożsamości, dlatego należy zbadać, dlaczego użytkownik nie jest uwzględniony w synchronizacji katalogu. Plik specyfikacji migracji, migration.json, należy wypełnić przed migracją.
validate W przeciwieństwie do polecenia wymaga połączenia internetowego, prepare ponieważ musi nawiązać połączenie z identyfikatorem Entra firmy Microsoft, aby wypełnić plik dziennika mapy tożsamości. Jeśli wystąpienie usługi Azure DevOps Server nie ma dostępu do Internetu, uruchom narzędzie z maszyny, która to robi. Jeśli możesz znaleźć maszynę z intranetowym połączeniem z wystąpieniem usługi Azure DevOps Server i połączeniem internetowym, możesz uruchomić to polecenie. Aby uzyskać pomoc dotyczącą prepare polecenia, uruchom następujące polecenie:
Migrator prepare /help
W dokumentacji pomocy znajdują się instrukcje i przykłady uruchamiania Migrator polecenia z poziomu samego wystąpienia usługi Azure DevOps Server i maszyny zdalnej. Jeśli uruchamiasz polecenie z jednej z warstw aplikacji wystąpienia usługi Azure DevOps Server, polecenie powinno mieć następującą strukturę:
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"
Parametr connectionString jest wskaźnikiem do bazy danych konfiguracji wystąpienia usługi Azure DevOps Server. Jeśli na przykład firma Fabrikam uruchamia prepare polecenie, polecenie wygląda jak w poniższym przykładzie:
Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
Gdy narzędzie do migracji danych uruchamia prepare polecenie, uruchamia pełną walidację, aby upewnić się, że nic się nie zmieniło w kolekcji od czasu ostatniej pełnej weryfikacji. W przypadku wykrycia nowych problemów nie są generowane żadne pliki migracji.
Wkrótce po uruchomieniu polecenia zostanie wyświetlone okno logowania microsoft Entra. Zaloguj się przy użyciu tożsamości należącej do domeny dzierżawy określonej w poleceniu . Upewnij się, że określona dzierżawa firmy Microsoft Entra jest dzierżawą, z którą chcesz wspierać przyszłą organizację. W naszym przykładzie firmy Fabrikam użytkownik wprowadza poświadczenia podobne do poniższego przykładowego zrzutu ekranu.
Ważne
Nie używaj testowej dzierżawy firmy Microsoft Entra na potrzeby migracji testowej i produkcyjnej dzierżawy firmy Microsoft Entra na potrzeby przebiegu produkcyjnego. Użycie testowej dzierżawy firmy Microsoft Entra może spowodować problemy z migracją tożsamości po rozpoczęciu pracy produkcyjnej z produkcyjną dzierżawą firmy Microsoft Entra w organizacji.
Po pomyślnym uruchomieniu prepare polecenia w narzędziu do migracji danych w oknie wyników zostanie wyświetlony zestaw dzienników i dwa pliki migracji. W katalogu dziennika znajdź folder logs i dwa pliki:
- migration.json to plik specyfikacji migracji. Zalecamy, aby pośminąć trochę czasu, aby go wypełnić.
- IdentityMapLog.csv zawiera wygenerowane mapowanie usługi Active Directory na tożsamości firmy Microsoft Entra. Przed rozpoczęciem migracji przejrzyj ją pod kątem kompletności.
Dwa pliki zostały szczegółowo opisane w następnych sekcjach.
Plik specyfikacji migracji
Specyfikacja migracji, migration.json, jest plikiem JSON, który zapewnia ustawienia migracji. Zawiera ona odpowiednią nazwę organizacji, informacje o koncie magazynu i inne informacje. Większość pól jest wypełniana automatycznie, a niektóre pola wymagają danych wejściowych przed podjęciem próby migracji.
Wyświetlane pola i wymagane akcje pliku migration.json zostały opisane w poniższej tabeli:
| Pole | opis | Wymagana akcja |
|---|---|---|
| Źródło | Informacje o lokalizacji i nazwach plików danych źródłowych używanych do migracji. | Nie musisz wykonywać żadnej akcji. Przejrzyj informacje dotyczące akcji podrzędnych, które należy wykonać. |
| Lokalizacja | Klucz sygnatury dostępu współdzielonego do konta usługi Azure Storage hostujący pakiet aplikacji warstwy danych (DACPAC). | Nie musisz wykonywać żadnej akcji. To pole zostało omówione w późniejszym kroku. |
| Pliki | Nazwy plików zawierających dane migracji. | Nie musisz wykonywać żadnej akcji. Przejrzyj informacje dotyczące akcji podrzędnych, które należy wykonać. |
| Pakiet DACPAC | Plik DACPAC, który pakuje bazę danych kolekcji do użycia w celu wprowadzenia danych podczas migracji. | Nie musisz wykonywać żadnej akcji. W późniejszym kroku utworzysz ten plik przy użyciu kolekcji, a następnie przekażesz go do konta usługi Azure Storage. Zaktualizuj plik na podstawie nazwy używanej podczas generowania go w dalszej części tego procesu. |
| Obiekt docelowy | Właściwości nowej organizacji do migracji. | Nie musisz wykonywać żadnej akcji. Przejrzyj informacje dotyczące akcji podrzędnych, które należy wykonać. |
| Nazwisko | Nazwa organizacji, która ma zostać utworzona podczas migracji. | Podaj nazwę. Nazwę można szybko zmienić później po zakończeniu migracji. UWAGA: nie twórz organizacji o tej nazwie przed uruchomieniem migracji. Organizacja jest tworzona w ramach procesu migracji. |
| Typ importu | Typ migracji, którą chcesz uruchomić. | Nie musisz wykonywać żadnej akcji. W późniejszym kroku wybierz typ migracji do uruchomienia. |
| Dane weryfikacji | Informacje potrzebne do ułatwienia obsługi migracji. | Narzędzie do migracji danych generuje sekcję "ValidationData". Zawiera informacje ułatwiające wspieranie środowiska migracji. Nie* edytuj wartości w tej sekcji lub migracja może zakończyć się niepowodzeniem. |
Po zakończeniu poprzedniego procesu powinien istnieć plik, który wygląda jak w poniższym przykładzie.
Na poprzedniej ilustracji planista migracji firmy Fabrikam dodał nazwę organizacji fabrikam-import i wybraną pozycję CUS (Central Stany Zjednoczone) jako lokalizację geograficzną migracji. Pozostały inne wartości, ponieważ mają zostać zmodyfikowane tuż przed przełączenie kolekcji do trybu offline przez planistę na potrzeby migracji.
Uwaga
Importy przebiegów testowych mają automatycznie dołączany ciąg "-dryrun" na końcu nazwy organizacji, którą można zmienić po migracji.
Obsługiwane regiony platformy Azure na potrzeby migracji
Usługa Azure DevOps Services jest dostępna w kilku lokalizacjach geograficznych platformy Azure. Jednak nie wszystkie lokalizacje, w których usługa Azure DevOps Services jest dostępna, są obsługiwane na potrzeby migracji. W poniższej tabeli wymieniono lokalizacje geograficzne platformy Azure, które można wybrać do migracji. Uwzględniona jest również wartość, którą należy umieścić w pliku specyfikacji migracji w celu określenia lokalizacji geograficznej migracji.
| Lokalizacja geograficzna | Lokalizacja geograficzna platformy Azure | Wartość specyfikacji importu |
|---|---|---|
| Stany Zjednoczone | Środkowe Stany Zjednoczone | CUS |
| Europa | Europa Zachodnia | UZE |
| Zjednoczone Królestwo | Zjednoczone Królestwo, część południowa | UKS |
| Australia | Australia Wschodnia | EAU |
| SAmeryka Południowa | Brazylia Południowa | SBR |
| Azja i Pacyfik | Indie Południowe | MA |
| Azja i Pacyfik | Azja Południowo-wschodnia (Singapur) | SEA |
| Kanada | Kanada Środkowa | Napisy |
Dziennik mapy tożsamości
Dziennik mapy tożsamości ma równe znaczenie dla rzeczywistych danych migrowanych do usług Azure DevOps Services. Podczas przeglądania pliku ważne jest, aby zrozumieć, jak działa migracja tożsamości i jakie mogą być potencjalne wyniki. Migracja tożsamości może stać się aktywna lub historyczna. Aktywne tożsamości mogą logować się do usług Azure DevOps Services, ale tożsamości historyczne nie mogą.
Aktywne tożsamości
Aktywne tożsamości odnoszą się do tożsamości użytkowników w usłudze Azure DevOps Services po migracji. W usłudze Azure DevOps Services te tożsamości są licencjonowane i wyświetlane jako użytkownicy w organizacji. Tożsamości są oznaczone jako aktywne w kolumnie Oczekiwany stan importu w pliku dziennika mapy tożsamości.
Tożsamości historyczne
Tożsamości historyczne są mapowane jako takie w kolumnie Oczekiwany stan importu w pliku dziennika mapy tożsamości. Tożsamości bez wpisu wiersza w pliku również stają się historyczne. Przykładem tożsamości bez wpisu wiersza może być pracownik, który nie pracuje już w firmie.
W przeciwieństwie do aktywnych tożsamości, tożsamości historyczne:
- Nie masz dostępu do organizacji po migracji.
- Nie masz licencji.
- Nie wyświetlaj się jako użytkownicy w organizacji. Wszystko, co się utrzymuje, to pojęcie nazwy tej tożsamości w organizacji, dzięki czemu jej historia może być przeszukiwana później. Zalecamy używanie tożsamości historycznych dla użytkowników, którzy nie pracują już w firmie lub którzy nie potrzebują dalszego dostępu do organizacji.
Uwaga
Po zaimportowaniu tożsamości jako historycznej nie można jej uaktywnić.
Omówienie pliku dziennika mapy tożsamości
Plik dziennika mapy tożsamości jest podobny do przedstawionego tutaj przykładu:
Kolumny w pliku dziennika mapy tożsamości zostały opisane w poniższej tabeli:
Ty i Twój administrator firmy Microsoft Entra muszą badać użytkowników oznaczonych jako Nie znaleziono dopasowań (sprawdź microsoft Entra ID Sync), aby zrozumieć, dlaczego nie są one częścią usługi Microsoft Entra Connect Sync.
| Kolumna | opis |
|---|---|
| Active Directory: użytkownik (Azure DevOps Server) | Przyjazna nazwa wyświetlana używana przez tożsamość w usłudze Azure DevOps Server. Ta nazwa ułatwia zidentyfikowanie użytkownika, do którego wiersza na mapie odwołuje się. |
| Active Directory: identyfikator zabezpieczeń | Unikatowy identyfikator tożsamości lokalna usługa Active Directory w usłudze Azure DevOps Server. Ta kolumna służy do identyfikowania użytkowników w kolekcji. |
| Microsoft Entra ID: Oczekiwany użytkownik importu (Azure DevOps Services) | Oczekiwany adres logowania dopasowanego wkrótce do aktywnego użytkownika lub Nie znaleziono dopasowania (Sprawdź synchronizację identyfikatorów entra firmy Microsoft) wskazujący, że tożsamość została utracona podczas synchronizacji identyfikatorów entra firmy Microsoft i jest importowana jako historyczna. |
| Oczekiwany stan importu | Oczekiwany stan migracji użytkownika: Aktywny, jeśli istnieje dopasowanie między usługą Active Directory i identyfikatorem Entra firmy Microsoft, lub wartość historyczna, jeśli nie ma dopasowania. |
| Data weryfikacji | Ostatni raz dziennik mapy tożsamości został zweryfikowany. |
Podczas odczytywania pliku zwróć uwagę, czy wartość w kolumnie Oczekiwany stan importu jest aktywna , czy historyczna. Aktywne wskazuje, że tożsamość w tym wierszu mapuje się poprawnie na migrację, staje się aktywna. Historyczne oznacza, że tożsamości stają się historyczne w przypadku migracji. Ważne jest, aby przejrzeć wygenerowany plik mapowania pod kątem kompletności i poprawności.
Ważne
Migracja nie powiedzie się, jeśli wystąpią poważne zmiany w synchronizacji identyfikatora zabezpieczeń programu Microsoft Entra Connect między próbami migracji. Możesz dodać nowych użytkowników między przebiegami testów i wprowadzić poprawki, aby upewnić się, że wcześniej zaimportowane tożsamości historyczne staną się aktywne. Nie można jednak zmienić istniejącego użytkownika, który został wcześniej zaimportowany jako aktywny. Spowoduje to niepowodzenie migracji. Przykładem zmiany może być ukończenie migracji przebiegu testowego, usunięcie tożsamości z identyfikatora Entra firmy Microsoft zaimportowanego aktywnie, ponowne utworzenie nowego użytkownika w identyfikatorze Entra firmy Microsoft dla tej samej tożsamości, a następnie próba przeprowadzenia innej migracji. W takim przypadku aktywna migracja tożsamości jest podejmowana między usługą Active Directory a nowo utworzoną tożsamością firmy Microsoft Entra, ale powoduje niepowodzenie migracji.
Przejrzyj prawidłowo dopasowane tożsamości. Czy są obecne wszystkie oczekiwane tożsamości? Czy użytkownicy są mapowane na poprawną tożsamość firmy Microsoft Entra?
Jeśli należy zmienić jakiekolwiek wartości, skontaktuj się z administratorem firmy Microsoft Entra, aby sprawdzić, czy tożsamość lokalna usługa Active Directory jest częścią synchronizacji z identyfikatorem Entra firmy Microsoft i prawidłowo skonfigurować. Aby uzyskać więcej informacji, zobacz Integrowanie tożsamości lokalnych z identyfikatorem Entra firmy Microsoft.
Następnie przejrzyj tożsamości, które są oznaczone jako historyczne. To etykietowanie oznacza, że nie można odnaleźć zgodnej tożsamości firmy Microsoft Entra z dowolnego z następujących powodów:
- Tożsamość nie jest skonfigurowana do synchronizacji między lokalna usługa Active Directory i identyfikatorem Entra firmy Microsoft.
- Tożsamość nie jest jeszcze wypełniana w identyfikatorze Entra firmy Microsoft (na przykład jest to nowy pracownik).
- Tożsamość nie istnieje w wystąpieniu firmy Microsoft Entra.
- Użytkownik, który jest właścicielem tej tożsamości, nie pracuje już w firmie.
Aby rozwiązać pierwsze trzy powody, skonfiguruj docelową tożsamość lokalna usługa Active Directory do synchronizacji z identyfikatorem Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Integrowanie tożsamości lokalnych z identyfikatorem Entra firmy Microsoft. Musisz skonfigurować i uruchomić program Microsoft Entra Connect, aby tożsamości zostały zaimportowane jako aktywne w usłudze Azure DevOps Services.
Czwarty powód można zignorować, ponieważ pracownicy, którzy nie znajdują się już w firmie, powinni zostać zaimportowani jako historyczni.
Tożsamości historyczne (małe zespoły)
Uwaga
Strategia migracji tożsamości proponowana w tej sekcji powinna być uwzględniana tylko przez małe zespoły.
Jeśli program Microsoft Entra Connect nie jest skonfigurowany, wszyscy użytkownicy w pliku dziennika mapy tożsamości są oznaczani jako historyczne. Uruchomienie migracji w ten sposób powoduje zaimportowanie wszystkich użytkowników jako historycznych. Zdecydowanie zalecamy skonfigurowanie programu Microsoft Entra Connect , aby upewnić się, że użytkownicy są zaimportowani jako aktywni.
Uruchomienie migracji ze wszystkimi tożsamościami historycznymi ma konsekwencje, które należy dokładnie rozważyć. Należy wziąć pod uwagę tylko zespoły z kilkoma użytkownikami, dla których koszt konfigurowania programu Microsoft Entra Connect jest zbyt wysoki.
Aby przeprowadzić migrację wszystkich tożsamości jako historycznych, wykonaj kroki opisane w kolejnych sekcjach. Podczas kolejki migracji tożsamość używana do kolejkowania migracji jest uruchamiana w organizacji jako właściciel organizacji. Wszyscy inni użytkownicy są importowane jako historyczne. Właściciele organizacji mogą następnie dodawać użytkowników z powrotem przy użyciu tożsamości firmy Microsoft Entra. Dodani użytkownicy są traktowani jako nowi użytkownicy. Nie są właścicielami żadnej z ich historii i nie ma możliwości ponownego ponownego użycia tej historii w tożsamości Firmy Microsoft Entra. Jednak użytkownicy nadal mogą wyszukiwać historię premii, wyszukując ich \<domain>\<Active Directory username>.
Narzędzie do migracji danych wyświetla ostrzeżenie, jeśli wykryje kompletny scenariusz tożsamości historycznych. Jeśli zdecydujesz się przejść w dół tej ścieżki migracji, musisz wyrazić zgodę w narzędziu na ograniczenia.
Subskrypcje programu Visual Studio
Narzędzie do migracji danych nie może wykryć subskrypcji programu Visual Studio (wcześniej znanych jako korzyści MSDN) podczas generowania pliku dziennika mapy tożsamości. Zamiast tego zalecamy zastosowanie funkcji automatycznego uaktualniania licencji po migracji. Jeśli konta służbowe użytkowników są poprawnie połączone , usługi Azure DevOps Services automatycznie stosują swoje korzyści z subskrypcji programu Visual Studio podczas pierwszego logowania po migracji. Nigdy nie są naliczane opłaty za licencje przypisane podczas migracji, dzięki czemu możesz bezpiecznie obsługiwać subskrypcje później.
Nie musisz powtarzać migracji przebiegu testowego, jeśli subskrypcje programu Visual Studio użytkowników nie są automatycznie uaktualniane w usłudze Azure DevOps Services. Łączenie subskrypcji programu Visual Studio odbywa się poza zakresem migracji. Jeśli konto służbowe jest poprawnie połączone przed migracją lub po migracji, licencje użytkowników zostaną automatycznie uaktualnione podczas następnego logowania. Po pomyślnym uaktualnieniu licencji przy następnym uruchomieniu migracji użytkownicy zostaną automatycznie uaktualnieni podczas pierwszego logowania do organizacji.
Przygotowanie do migracji
Teraz wszystko jest gotowe do wykonania podczas migracji przebiegu testu. Zaplanuj przestój z zespołem, aby przejąć kolekcję w tryb offline na potrzeby migracji. Po zaakceptowaniu czasu uruchomienia migracji przekaż wygenerowane wymagane zasoby i kopię bazy danych na platformę Azure. Przygotowanie do migracji składa się z następujących pięciu kroków.
Krok 1. Przełącz kolekcję w tryb offline i odłącz ją.
Krok 2. Generowanie pliku DACPAC z kolekcji, którą zamierzasz zmigrować.
Krok 3. Przekazywanie plików DACPAC i plików migracji do konta usługi Azure Storage.
Krok 4. Generowanie tokenu SAS w celu uzyskania dostępu do konta magazynu.
Krok 5. Ukończenie specyfikacji migracji.
Uwaga
Przed przeprowadzeniem migracji produkcyjnej zdecydowanie zalecamy ukończenie migracji przebiegu testowego. Po uruchomieniu testu można sprawdzić, czy proces migracji działa dla kolekcji i czy nie ma żadnych unikatowych kształtów danych, które mogą spowodować niepowodzenie migracji produkcyjnej.
Krok 1. Odłączanie kolekcji
Odłączanie kolekcji jest kluczowym krokiem w procesie migracji. Dane tożsamości dla kolekcji znajdują się w bazie danych konfiguracji wystąpienia usługi Azure DevOps Server, gdy kolekcja jest dołączona i w trybie online. Gdy kolekcja jest odłączona od wystąpienia usługi Azure DevOps Server, pobiera kopię tych danych tożsamości i pakuje ją z kolekcją na potrzeby transportu. Bez tych danych nie można wykonać części tożsamości migracji.
Napiwek
Zalecamy, aby kolekcja była odłączona do momentu zakończenia migracji, ponieważ nie ma możliwości migracji zmian, które wystąpiły podczas migracji. Ponownie dołącz kolekcję po utworzeniu jej kopii zapasowej na potrzeby migracji, więc nie masz obaw o posiadanie najnowszych danych dla tego typu migracji. Aby całkowicie uniknąć czasu offline, możesz również użyć odłączenia w trybie offline dla przebiegów testów.
Ważne jest, aby rozważyć koszt wyboru, aby spowodować zerowy przestój dla przebiegu testu. Wymaga to utworzenia kopii zapasowych kolekcji i bazy danych konfiguracji, przywrócenia ich w wystąpieniu SQL, a następnie utworzenia odłączonej kopii zapasowej. Analiza kosztów może udowodnić, że wykonanie bezpośrednio odłączonej kopii zapasowej zajmuje zaledwie kilka godzin.
Krok 2. Generowanie pliku DACPAC
DACPACs oferują szybką i stosunkowo łatwą metodę przenoszenia kolekcji do usług Azure DevOps Services. Jednak po przekroczeniu określonego progu rozmiar bazy danych kolekcji korzyści wynikające z używania pakietu DACPAC zaczynają się zmniejszać.
Uwaga
Jeśli narzędzie do migracji danych wyświetli ostrzeżenie, że nie można użyć metody DACPAC, musisz przeprowadzić migrację przy użyciu metody Usługi SQL Azure maszyny wirtualnej. Pomiń kroki od 2 do 5 w tym przypadku i postępuj zgodnie z instrukcjami w sekcji Przygotowywanie przebiegu testu, Migrowanie dużych kolekcji, a następnie kontynuuj określanie typu migracji. Jeśli narzędzie do migracji danych nie wyświetli ostrzeżenia, użyj metody DACPAC opisanej w tym kroku.
Pakiet DACPAC to funkcja programu SQL Server, która umożliwia pakowanie baz danych w jednym pliku i wdrażanie ich w innych wystąpieniach programu SQL Server. Plik DACPAC można również przywrócić bezpośrednio do usług Azure DevOps Services, dzięki czemu można go użyć jako metody pakowania do pobierania danych kolekcji w chmurze.
Ważne
- W przypadku korzystania z SqlPackage.exe należy użyć wersji programu .NET Framework SqlPackage.exe, aby przygotować pakiet DACPAC. Instalator MSI musi służyć do instalowania wersji programu .NET Framework SqlPackage.exe. Nie używaj interfejsu wiersza polecenia dotnet ani .zip (Windows .NET 6) wersji SqlPackage.exe, ponieważ te wersje mogą generować DACPACs niezgodne z usługą Azure DevOps Services.
- Wersja 161 pakietu SqlPackage domyślnie szyfruje połączenia bazy danych i może nie łączyć się. Jeśli wystąpi błąd procesu logowania, dodaj
;Encrypt=False;TrustServerCertificate=Truedo parametry połączenia instrukcji SqlPackage.
Pobierz i zainstaluj SqlPackage.exe przy użyciu najnowszego instalatora MSI z informacji o wersji pakietu SqlPackage.
Po użyciu Instalatora MSI SqlPackage.exe instaluje się w ścieżce podobnej do %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.
Podczas generowania pakietu DACPAC należy pamiętać o dwóch kwestiach: dysku, na którym jest zapisywany pakiet DACPAC, oraz miejsce na dysku na maszynie generującej pakiet DACPAC. Chcesz mieć pewność, że masz wystarczającą ilość miejsca na dysku, aby ukończyć operację.
Podczas tworzenia pakietu SqlPackage.exe tymczasowo przechowuje dane z kolekcji w katalogu tymczasowym na dysku C maszyny, z której inicjujesz żądanie pakowania.
Może się okazać, że dysk C jest zbyt mały, aby obsługiwać tworzenie pakietu DACPAC. Ilość potrzebnego miejsca można oszacować, wyszukując największą tabelę w bazie danych kolekcji. DACPACs są tworzone pojedynczo jedną tabelę. Maksymalna wymagana ilość miejsca do uruchomienia generacji jest w przybliżeniu równoważna rozmiarowi największej tabeli w bazie danych kolekcji. Jeśli zapiszesz wygenerowany pakiet DACPAC na dysku C, rozważ rozmiar bazy danych kolekcji zgodnie z raportem w pliku DataMigrationTool.log z przebiegu weryfikacji.
Plik DataMigrationTool.log zawiera listę największych tabel w kolekcji przy każdym uruchomieniu polecenia. Aby zapoznać się z przykładem rozmiarów tabel dla kolekcji, zobacz następujące dane wyjściowe. Porównaj rozmiar największej tabeli z wolnym miejscem na dysku, który hostuje katalog tymczasowy.
Ważne
Przed kontynuowaniem generowania pliku DACPAC upewnij się, że kolekcja jest odłączona.
[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
Upewnij się, że dysk hostujący katalog tymczasowy ma co najmniej tyle wolnego miejsca. Jeśli tak nie jest, musisz przekierować katalog tymczasowy, ustawiając zmienną środowiskową.
SET TEMP={location on disk}
Innym zagadnieniem jest miejsce zapisania danych DACPAC. Wskazywanie zapisanej lokalizacji na odległym dysku zdalnym może spowodować wydłużenie czasu generowania. Jeśli dysk szybki, taki jak dysk półprzewodnikowy (SSD) jest dostępny lokalnie, zalecamy, aby dysk docelowy był lokalizacją zapisywania DACPAC. W przeciwnym razie zawsze szybsze jest użycie dysku znajdującego się na maszynie, na której znajduje się baza danych kolekcji, a nie dysk zdalny.
Po zidentyfikowaniu lokalizacji docelowej pakietu DACPAC i upewnieniu się, że masz wystarczającą ilość miejsca, nadszedł czas na wygenerowanie pliku DACPAC.
Otwórz okno wiersza polecenia i przejdź do lokalizacji SqlPackage.exe. Aby wygenerować pakiet DACPAC, zastąp wartości symbolu zastępczego wymaganymi wartościami, a następnie uruchom następujące polecenie:
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
- Źródło danych: wystąpienie programu SQL Server, które hostuje bazę danych kolekcji usługi Azure DevOps Server.
- Katalog początkowy: nazwa bazy danych kolekcji.
- targetFile: lokalizacja na dysku i nazwa pliku DACPAC.
W poniższym przykładzie pokazano polecenie generacji DACPAC uruchomione w samej warstwie danych usługi Azure DevOps Server:
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
Dane wyjściowe polecenia to plik DACPAC wygenerowany z bazy danych kolekcji Foo o nazwie Foo.dacpac.
Konfigurowanie kolekcji na potrzeby migracji
Po przywróceniu bazy danych kolekcji na maszynie wirtualnej platformy Azure skonfiguruj logowanie SQL, aby umożliwić usłudze Azure DevOps Services łączenie się z bazą danych w celu migracji danych. To logowanie umożliwia dostęp tylko do odczytu do pojedynczej bazy danych.
Aby rozpocząć, otwórz program SQL Server Management Studio na maszynie wirtualnej, a następnie otwórz nowe okno zapytania względem bazy danych do zaimportowania.
Ustaw odzyskiwanie bazy danych na proste:
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
Utwórz logowanie SQL dla bazy danych i przypisz to logowanie "TFSEXECROLE":
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>'
Zgodnie z naszym przykładem Fabrikam dwa polecenia SQL wyglądają jak w poniższym przykładzie:
ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;
USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'
Uwaga
Włącz tryb uwierzytelniania programu SQL Server i systemu Windows w programie SQL Server Management Studio na maszynie wirtualnej. Jeśli nie włączysz trybu uwierzytelniania, migracja zakończy się niepowodzeniem.
Konfigurowanie pliku specyfikacji migracji w celu kierowania maszyny wirtualnej
Zaktualizuj plik specyfikacji migracji, aby uwzględnić informacje o sposobie nawiązywania połączenia z wystąpieniem programu SQL Server. Otwórz plik specyfikacji migracji i wprowadź następujące aktualizacje.
Usuń parametr DACPAC z obiektu plików źródłowych.
Specyfikacja migracji przed zmianą jest wyświetlana w poniższym kodzie.
Specyfikacja migracji po zmianie jest wyświetlana w poniższym kodzie.
Wypełnij wymagane parametry i dodaj następujący obiekt właściwości w obiekcie źródłowym w pliku specyfikacji.
"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" }
Po zastosowaniu zmian specyfikacja migracji wygląda jak w poniższym przykładzie.
Specyfikacja migracji jest teraz skonfigurowana do używania Usługi SQL Azure maszyny wirtualnej do migracji. Wykonaj pozostałe kroki przygotowania do migracji do usług Azure DevOps Services. Po zakończeniu migracji pamiętaj, aby usunąć logowanie SQL lub obrócić hasło. Firma Microsoft nie zachowuje informacji logowania po zakończeniu migracji.
Krok 3. Przekazywanie pliku DACPAC
Uwaga
Jeśli używasz metody maszyny wirtualnej Usługi SQL Azure, musisz podać tylko parametry połączenia. Nie musisz przekazywać żadnych plików i możesz pominąć ten krok.
Pakiet DACPAC musi zostać umieszczony w kontenerze usługi Azure Storage, który może być istniejącym kontenerem lub utworzonym specjalnie na potrzeby migracji. Ważne jest, aby upewnić się, że kontener jest tworzony w odpowiednich lokalizacjach geograficznych.
Usługi Azure DevOps Services są dostępne w wielu lokalizacjach geograficznych. Podczas importowania do tych lokalizacji ważne jest prawidłowe umieszczenie danych, aby upewnić się, że migracja może rozpocząć się pomyślnie. Dane muszą być umieszczane w tej samej lokalizacji geograficznej, do której importujesz. Umieszczenie danych w dowolnym innym miejscu powoduje, że nie można uruchomić migracji. W poniższej tabeli wymieniono dopuszczalne lokalizacje geograficzne służące do tworzenia konta magazynu i przekazywania danych.
| Żądana lokalizacja geograficzna migracji | Lokalizacja geograficzna konta magazynu |
|---|---|
| Środkowe Stany Zjednoczone | Środkowe Stany Zjednoczone |
| Europa Zachodnia | Europa Zachodnia |
| Zjednoczone Królestwo | Zjednoczone Królestwo, część południowa |
| Australia Wschodnia | Australia Wschodnia |
| Brazylia Południowa | Brazylia Południowa |
| Indie południowe | Indie południowe |
| Kanada Środkowa | Kanada Środkowa |
| Azja i Pacyfik (Singapur) | Azja i Pacyfik (Singapur) |
Mimo że usługi Azure DevOps Services są dostępne w wielu lokalizacjach geograficznych w Stanach Zjednoczonych, tylko lokalizacja Central Stany Zjednoczone akceptuje nowe usługi Azure DevOps Services. W tej chwili nie można migrować danych do innych lokalizacji platformy Azure w Stanach Zjednoczonych.
Utwórz kontener obiektów blob w witrynie Azure Portal. Po utworzeniu kontenera przekaż plik DACPAC kolekcji.
Po zakończeniu migracji usuń kontener obiektów blob i towarzyszące mu konto magazynu przy użyciu narzędzi takich jak AzCopy lub inne narzędzie Eksploratora usługi Azure Storage, takie jak Eksplorator usługi Azure Storage.
Uwaga
Jeśli plik DACPAC jest większy niż 10 GB, zalecamy użycie narzędzia AzCopy. Narzędzie AzCopy ma obsługę przekazywania wielowątkowego w celu szybszego przekazywania.
Krok 4. Generowanie tokenu SAS
Token sygnatury dostępu współdzielonego (SAS) zapewnia delegowany dostęp do zasobów na koncie magazynu. Token umożliwia firmie Microsoft uzyskanie najniższego poziomu uprawnień wymaganych do uzyskania dostępu do danych w celu przeprowadzenia migracji.
Tokeny SAS można wygenerować przy użyciu witryny Azure Portal. Z punktu widzenia zabezpieczeń zalecamy wykonanie następujących zadań:
- Wybierz pozycję Tylko odczyt i lista jako uprawnienia dla tokenu SAS. Żadne inne uprawnienia nie są wymagane.
- Ustaw czas wygaśnięcia nie dalej niż siedem dni w przyszłości.
- Ogranicz dostęp tylko do adresów IP usług Azure DevOps Services.
- Traktuj klucz sygnatury dostępu współdzielonego jako klucz tajny. Nie pozostawiaj klucza w niezabezpieczonej lokalizacji, ponieważ przyznaje dostęp do odczytu i listy do wszystkich danych przechowywanych w kontenerze.
Krok 5. Ukończenie specyfikacji migracji
Wcześniej w procesie wypełniono częściowo plik specyfikacji migracji, znany jako migration.json. W tym momencie masz wystarczającą ilość informacji, aby ukończyć wszystkie pozostałe pola z wyjątkiem typu migracji. Typ migracji zostanie omówiony w dalszej części sekcji migracji.
W pliku specyfikacji migration.json w obszarze Źródło wypełnij następujące pola.
- Lokalizacja: wklej klucz SYGNATURy dostępu współdzielonego wygenerowany na podstawie skryptu, a następnie skopiowany w poprzednim kroku.
- Dacpac: upewnij się, że plik, w tym rozszerzenie pliku dacpac , ma taką samą nazwę jak plik DACPAC przekazany do konta magazynu.
Ostateczny plik specyfikacji migracji powinien wyglądać podobnie do poniższego przykładu.
Określanie typu migracji
Importy mogą być kolejkowane jako przebieg testowy lub przebieg produkcyjny. Parametr ImportType określa typ migracji:
- TestRun: użyj przebiegu testu do celów testowych. System usuwa przebieg testu po upływie 45 dni.
- ProductionRun: użyj przebiegu produkcyjnego, jeśli chcesz zachować wynikową migrację i korzystać z organizacji w pełnym wymiarze czasu pracy w usługach Azure DevOps Services po zakończeniu migracji.
Napiwek
Zawsze zalecamy ukończenie najpierw migracji przebiegu testu.
Organizacje uruchamiania testowego
Organizacje testowe uruchamiane pomagają zespołom testować migrację swoich kolekcji. Przed uruchomieniem migracji produkcyjnej należy usunąć wszystkie ukończone organizacje przebiegu testowego. Wszystkie organizacje uruchamiane testowo mają ograniczone istnienie i są automatycznie usuwane po upływie określonego czasu. Informacje o tym, kiedy organizacja zostanie usunięta, zostaną uwzględnione w wiadomości e-mail z informacją o powodzeniu, którą należy otrzymać po zakończeniu migracji. Pamiętaj, aby zanotować tę datę i odpowiednio zaplanować.
Organizacje uruchamiane testowe mają 45 dni, zanim zostaną usunięte. Po upływie określonego czasu organizacja przebiegu testowego zostanie usunięta. Przed rozpoczęciem migracji produkcyjnej można powtarzać importowanie przebiegów testowych tyle razy, ile potrzebujesz.
Usuwanie przebiegów testów
Usuń wszystkie poprzednie przebiegi testu przed podjęciem próby utworzenia nowego. Gdy zespół jest gotowy do przeprowadzenia migracji produkcyjnej, należy ręcznie usunąć organizację uruchamiania testowego. Zanim będzie można uruchomić drugą migrację przebiegu testu lub ostateczną migrację produkcyjną, upewnij się, że usunięto wszystkie poprzednie organizacje usługi Azure DevOps Services utworzone w poprzednim przebiegu testowym. Aby uzyskać więcej informacji, zobacz Usuwanie organizacji.
Napiwek
Opcjonalne informacje ułatwiające użytkownikowi pomyślną migrację przebiegów testowych firmyAny, która następuje po pierwszym, powinna zająć więcej czasu, biorąc pod uwagę dodatkowy czas wymagany do wyczyszczenia zasobów z poprzednich przebiegów testów.
Udostępnienie nazwy organizacji po usunięciu lub zmianie nazwy organizacji może potrwać do jednej godziny. Aby uzyskać więcej informacji, zobacz artykuł Zadania po migracji .
Jeśli wystąpią problemy z migracją, zobacz Rozwiązywanie problemów z migracją i migracją.
Uruchamianie migracji
Twój zespół jest teraz gotowy do rozpoczęcia procesu uruchamiania migracji. Zalecamy rozpoczęcie od pomyślnej migracji przebiegu testu przed podjęciem próby migracji produkcyjnej. W przypadku importowania przebiegów testowych możesz zobaczyć z wyprzedzeniem, jak wygląda migracja, zidentyfikować potencjalne problemy i uzyskać doświadczenie przed rozpoczęciem pracy produkcyjnej.
Uwaga
- Jeśli musisz powtórzyć ukończoną migrację do środowiska produkcyjnego dla kolekcji, tak jak w przypadku wycofania, skontaktuj się z działem obsługi klienta usługi Azure DevOps Services przed kolejką innej migracji.
- Administratorzy platformy Azure mogą uniemożliwić użytkownikom tworzenie nowych organizacji usługi Azure DevOps. Jeśli zasady dzierżawy firmy Microsoft Entra są włączone, migracja nie powiedzie się. Przed rozpoczęciem sprawdź, czy zasady nie są ustawione lub czy występuje wyjątek dla użytkownika wykonującego migrację. Aby uzyskać więcej informacji, zobacz Ograniczanie tworzenia organizacji za pośrednictwem zasad dzierżawy firmy Microsoft Entra.
- Usługi Azure DevOps Services nie obsługują zasad przechowywania potoku i nie są przenoszone do hostowanej wersji.
Zagadnienia dotyczące planów wycofywania
Typowym problemem dla zespołów wykonujących końcowe uruchomienie produkcyjne jest ich plan wycofywania, jeśli coś pójdzie nie tak z migracją. Zdecydowanie zalecamy przeprowadzenie testu, aby upewnić się, że możesz przetestować ustawienia migracji podane w narzędziu do migracji danych dla usługi Azure DevOps.
Wycofanie końcowego przebiegu produkcyjnego jest dość proste. Przed kolejką migracji odłącz kolekcję projektów zespołowych od usługi Azure DevOps Server, co sprawia, że jest niedostępna dla członków zespołu. Jeśli z jakiegokolwiek powodu musisz wycofać przebieg produkcyjny i przywrócić serwer lokalny do trybu online dla członków zespołu, możesz to zrobić. Dołącz ponownie kolekcję projektów zespołowych lokalnie i poinformuj zespół, że nadal działają normalnie, podczas gdy zespół przegrupuje się, aby zrozumieć potencjalne błędy.
Następnie możesz skontaktować się z pomocą techniczną usługi Azure DevOps Services, aby uzyskać pomoc w zrozumieniu przyczyny błędu, jeśli nie możesz określić przyczyny. Aby uzyskać więcej informacji, zobacz artykuł Rozwiązywanie problemów. Bilety pomocy technicznej klienta można otworzyć na poniższej stronie https://aka.ms/AzureDevOpsImportSupport. Należy pamiętać, że jeśli problem wymaga, aby inżynierowie grupy produktów mogli zaangażować te przypadki, będą obsługiwane w regularnych godzinach pracy.
Odłącz kolekcję projektów zespołowych od usługi Azure DevOps Server, aby przygotować ją do migracji.
Przed wygenerowaniem kopii zapasowej bazy danych SQL narzędzie do migracji danych wymaga całkowitego odłączenia kolekcji od serwera Azure DevOps Server (a nie sql). Proces odłączania w usłudze Azure DevOps Server przenosi informacje o tożsamości użytkownika przechowywane poza bazą danych kolekcji i umożliwia przenoszenie ich do nowego serwera lub w tym przypadku do usług Azure DevOps Services.
Odłączanie kolekcji można łatwo wykonać z poziomu konsoli administracyjnej serwera Usługi Azure DevOps w wystąpieniu serwera Usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Przenoszenie kolekcji projektów, Odłącz kolekcję.
Kolejkowanie migracji
Ważne
Przed kontynuowaniem upewnij się, że kolekcja została odłączona przed wygenerowaniem pliku DACPAC lub przekazaniem bazy danych kolekcji do maszyny wirtualnej Usługi SQL Azure. Jeśli ten krok nie zostanie ukończony, migracja zakończy się niepowodzeniem. W przypadku niepowodzenia migracji zobacz Rozwiązywanie problemów z migracją.
Rozpocznij migrację przy użyciu polecenia importowania narzędzia do migracji danych. Polecenie migracji przyjmuje plik specyfikacji migracji jako dane wejściowe. Analizuje on plik, aby upewnić się, że podane wartości są prawidłowe i, jeśli się powiedzie, kolejkuje migrację do usług Azure DevOps Services. Polecenie migracji wymaga połączenia internetowego, ale nie wymaga połączenia z wystąpieniem usługi Azure DevOps Server.
Aby rozpocząć, otwórz okno wiersza polecenia i zmień katalogi na ścieżkę do narzędzia do migracji danych. Zalecamy przejrzenie tekstu pomocy dostarczonego z narzędziem. Uruchom następujące polecenie, aby wyświetlić wskazówki i pomoc dotyczącą polecenia migracji:
Migrator import /help
Polecenie kolejkowania migracji ma następującą strukturę:
Migrator import /importFile:{location of migration specification file}
W poniższym przykładzie pokazano ukończone polecenie migracji:
Migrator import /importFile:C:\DataMigrationToolFiles\migration.json
Po pomyślnym zakończeniu walidacji zaloguj się do identyfikatora Entra firmy Microsoft przy użyciu tożsamości, która jest członkiem tej samej dzierżawy firmy Microsoft Entra co plik dziennika mapy tożsamości został skompilowany. Zalogowany użytkownik jest właścicielem zaimportowanej organizacji.
Uwaga
Każda dzierżawa firmy Microsoft Entra jest ograniczona do pięciu importów na okres 24-godzinny. Tylko importy, które są liczone w kolejce względem tego limitu.
Gdy twój zespół inicjuje migrację, do użytkownika, który w kolejce migracji, zostanie wysłane powiadomienie e-mail. Około 5 do 10 minut po zakończeniu kolejki migracji zespół może przejść do organizacji, aby sprawdzić stan. Po zakończeniu migracji twój zespół jest kierowany do logowania, a powiadomienie e-mail jest wysyłane do właściciela organizacji.
Narzędzie do migracji danych flaguje błędy, które należy poprawić przed migracją. W tym artykule opisano najbardziej typowe ostrzeżenia i błędy, które mogą wystąpić podczas przygotowywania do migracji. Po skorygowaniu każdego błędu ponownie uruchom polecenie weryfikujące migrację, aby zweryfikować rozwiązanie.