Przenoszenie z jednego środowiska do innego dla lokalnej usługi Azure DevOps

Azure DevOps Server 2022 r. | Azure DevOps Server 2020 r. | Azure DevOps Server 2019 r.

Najbardziej typowy scenariusz przenoszenia oparty na środowisku zmienia domenę wdrożenia Azure DevOps Server, niezależnie od tego, czy jest to zmiana nazwy domeny, czy przejście z grupy roboczej do domeny.

Ważne

W niektórych sytuacjach warto zmienić domenę wdrożenia Azure DevOps Server, a także jego sprzęt. Zmiana sprzętu jest przeniesieniem opartym na przywróceniu i nigdy nie należy łączyć dwóch typów przenoszenia. Najpierw ukończ przenoszenie sprzętu, a następnie zmień środowisko.

Ponadto zmiana tożsamości w Azure DevOps Server w ramach ruchu środowiskowego jest aspektem, który najczęściej powoduje konflikty lub problemy. Polecenie tożsamości to zaawansowane narzędzie, ale ma pewne ograniczenia. Przeczytaj o tym w ramach planowania przeniesienia. Aby zapewnić pomyślny ruch, upewnij się, że rozumiesz następujące wymagania:

• Po utworzeniu konta użytkownika w Azure DevOps Server nie można go usunąć ani zamapować na inne konto. Jeśli na przykład przenosisz domenę/użytkownikaA do domenyB/userB, polecenie Tożsamości będzie działać tylko w celu migracji użytkownika, jeśli domenaB/użytkownikB nie jest jeszcze obecny w Azure DevOps Server.
• Ponieważ członkowie lokalnej grupy Administratorzy są automatycznie dodawani do Azure DevOps Server, przed zmianą domeny lub środowiska należy usunąć wszystkie konta, które mają zostać zmigrowane z tej grupy.

Aby uzyskać więcej informacji w tle, przejdź tutaj, aby uzyskać szczegółowy opis sposobu działania zmian tożsamości w Azure DevOps Server, w tym ograniczeń narzędzia.

Omówimy kroki zmiany środowiska wdrożenia Azure DevOps Server w następujących sekcjach:

1. Sprawdzanie uprawnień i kont
2. Zatrzymywanie usług Azure DevOps Server
3. Tworzenie kopii zapasowej danych
4. Dołącz Azure DevOps Server do nowej domeny
5. Przenoszenie kont użytkowników i usług Azure DevOps Server
6. Konfigurowanie usług Reporting and Analysis Services
7. Ponowne uruchamianie usług Azure DevOps Server

Sprawdzanie uprawnień i kont

Aby pomyślnie zmienić środowisko dla Azure DevOps Server, musisz być administratorem na komputerze lokalnym, a także dla Azure DevOps Server i całego oprogramowania, na którym zależy wdrożenie: SQL Server, raportowanie i inne oprogramowanie, z którym międzyoperacyjnie wykonuje wdrożenie, takie jak Project Server. Jednak wszyscy członkowie lokalnej grupy Administratorzy są automatycznie dołączani do Azure DevOps Server, co może powodować problemy podczas próby migracji kont. W związku z tym należy użyć konta, które nie zamierzasz migrować w ramach przenoszenia środowiska. Możesz rozważyć dodanie specjalnego konta administracyjnego tylko do przeniesienia i użycie tego konta do przeprowadzenia migracji.

Aby zweryfikować uprawnienia na poziomie administratora

• Upewnij się, że używane konto jest członkiem następujących grup:
  • Serwery: Administratorzy (lokalna grupa administratorów lub równoważne)
  • Azure DevOps Server: Administratorzy programu Team Foundation i użytkownicy konsoli Administracja
  • SQL Server: sysadmin

Jeśli nie jesteś członkiem jednej lub kilku z tych grup, uzyskaj teraz uprawnienia.

Teraz, gdy masz pewność, że używasz konta, które ma wszystkie wymagane uprawnienia, nadszedł czas, aby rozpocząć sprawdzanie kont, aby sprawdzić, czy w środowisku, do którego będziesz przenosić jakiekolwiek konflikty z nazwami lub grupami. Wiemy już, że nie można migrować kont będących członkami lokalnej grupy Administratorzy, więc najpierw usuńmy te konta.

Usuwanie kont do migracji z lokalnej grupy administratorów

• Otwórz lokalną grupę Administratorzy i usuń wszystkie konta, które chcesz przeprowadzić migrację do nowego środowiska. Powtórz ten krok dla innych grup, których może dotyczyć problem.

Teraz sprawdź listę tożsamości w bieżącym środowisku Azure DevOps Server i poszukaj potencjalnych problemów z grupami lub poszczególnymi kontami użytkowników, które mogą istnieć w nowym środowisku.

Porada

Rozważ utworzenie tabeli lub mapy migracji tożsamości, które mają zostać przeniesione w ramach przenoszenia środowiska, w tym szczegółowe informacje o tym, które konta mogą nie być w stanie zostać zmigrowane automatycznie.

Sprawdzanie tożsamości

1. Na serwerze warstwy aplikacji dla usługi Azure DevOps otwórz okno wiersza polecenia z uprawnieniami administracyjnymi, przejdź do folderu %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools i uruchom następujące polecenie, aby wyświetlić tożsamości obecnie w systemie:

   TFSConfig Identities
   

2. Zostanie wyświetlona lista tożsamości. Sprawdź tych użytkowników i grupy, aby upewnić się, że nie ma potencjalnych duplikatów ani problemów z tożsamościami w środowisku, do którego przeniesiesz się Azure DevOps Server, i podejmij kroki w celu ograniczenia potencjalnych konfliktów.

Zatrzymywanie usług

Zatrzymanie usług pomaga zapewnić, że użytkownicy nie mogą wprowadzać zmian w elementach roboczych ani zaewidencjonować kodu źródłowego do oryginalnego wdrożenia podczas lub po zakończeniu procesu przenoszenia.

1. Na komputerze warstwy aplikacji otwórz okno wiersza polecenia i zmień katalogi na Drive:\%programfiles%\TFS 12.0\Tools.

2. Wpisz następujące polecenie TFSServiceControl :

   Stan spoczynku TFSServiceControl

Tworzenie kopii zapasowych baz danych i klucza szyfrowania SQL Server Reporting Services

1. Otwórz konsolę administracyjną Azure DevOps Server i na stronie Zaplanowane kopie zapasowe wykonaj pełną kopię zapasową. Kopia zapasowa utworzy kopię zapasową wszystkiego, co zostało skonfigurowane do tworzenia kopii zapasowej w planie kopii zapasowej, ale zrobi to natychmiast, a nie zgodnie z czasem zaplanowanym w planie. Jeśli wdrożenie korzysta z raportowania, możesz utworzyć kopię zapasową klucza szyfrowania w ramach tego zestawu kopii zapasowych.

   

   (Jeśli nie masz skonfigurowanych kopii zapasowych, musisz utworzyć plan przed wykonaniem pełnej kopii zapasowej).

2. Po zakończeniu tworzenia kopii zapasowej sprawdź, czy kopia zapasowa jest dostępna na urządzeniu magazynu lub udziale sieciowym, i czy możesz uzyskać dostęp do tej kopii zapasowej z nowego sprzętu.

Dołączanie serwera warstwy aplikacji do nowej domeny

1. Na każdym serwerze otwórz właściwości komputera.

2. Zmień ustawienia komputera na domenę lub grupę roboczą, do której chcesz dołączyć serwer.

   Jeśli zostanie wyświetlony monit o podanie nazwy użytkownika i hasła konta, które ma uprawnienia do dołączenia tego komputera do domeny, podaj odpowiednie poświadczenia.

3. Uruchom ponownie komputer, aby zmiana domeny weszła w życie.

   Uwaga

   Po ponownym uruchomieniu komputera może pojawić się ostrzeżenie, że nie można uruchomić usług lub sterowników. Kontynuuj pracę z następną procedurą.

Przenoszenie kont użytkowników i kont usług

Jak wspomniano na początku tego tematu, przenoszenie kont jest najbardziej prawdopodobne, aby napotkać trudności, szczególnie jeśli nie zaplanowano dokładnie migracji użytkowników. Polecenie TFSConfig Identities nie może migrować żadnego konta do konta, które już istnieje w Azure DevOps Server.

Jeśli nazwy kont są takie same w obu domenach, a jedyną różnicą jest nazwa domeny, możesz użyć trybu wsadowego tożsamości TFSConfig, aby zmienić wszystkie tożsamości jednocześnie. W przeciwnym razie należy zmienić tożsamości indywidualnie i określić inną nazwę konta docelowego, jak opisano poniżej.

1. Na serwerze warstwy aplikacji dla usługi Azure DevOps otwórz okno wiersza polecenia z uprawnieniami administracyjnymi, przejdź do folderu %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools i uruchom następujące polecenie, aby zmienić identyfikatory usług (SID) dla konta usługi na nową domenę:

   TFSConfig identities /change /fromdomain:OldComputerorDomainName /todomain:NewDomainName /account:OldTFSServiceAccount /toaccount:NewTFSServiceAccount
   

   Ostrzeżenie

   Jeśli konto usługi było kontem systemowym, takim jak usługa sieciowa, nie można bezpośrednio migrować konta usługi, ponieważ konto systemowe o tej samej nazwie istnieje w nowym środowisku. Musisz wykonać zmianę dwuetapowego procesu. Zobacz przykład w poleceniu Tożsamości.

2. Aby przeprowadzić migrację wszystkich kont o tej samej nazwie w nowym środowisku, wpisz następujące polecenie:

   TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName
   

   Spowoduje to przetworzenie kont wsadowych.

3. Jeśli nowa domena zawiera co najmniej jedną tożsamość, w której nazwa zmienia się między środowiskami, należy ręcznie zaktualizować identyfikatory SID dla każdej z tych tożsamości. Jeśli na przykład konto użytkownika Christie Church było kontem użytkownika Fabrikam\CChurch w poprzednim środowisku, ale jest to NewFabrikam\ChristieC w nowym środowisku, konieczne byłoby ręczne zaktualizowanie jej identyfikatora SID. Dla każdego konta, które ma to wymaganie, wpisz następujące polecenie:

   TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName /account:OldAccountName /toaccount:NewAccountName
   

4. Teraz uruchom następujące polecenie, aby zaktualizować konto usługi:

   TFSConfig Accounts /change /AccountType:ApplicationTier /account:AccountName /password:Password
   

5. Jeśli wdrożenie używa raportowania, uruchom następujące polecenie, aby zaktualizować konto źródła danych używane do raportowania:

   TFSConfig Accounts /change /AccountType:ReportingDataSource /account:AccountName /password:Password
   

6. Jeśli wdrożenie używa serwera proxy usługi Azure DevOps, uruchom następujące polecenie, aby zaktualizować konto usługi używane dla serwera proxy:

   TFSConfig Accounts /change /AccountType:Proxy /account:AccountName /password:Password
   

   Uwaga

   Jeśli przechodzisz do domeny nienależącej do zaufanej domeny, może być również konieczne ręczne dodawanie użytkowników i grup do zespołów, projektów, kolekcji i Azure DevOps Server siebie. Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników do projektów, Ustawianie uprawnień administratora dla kolekcji projektów i Ustawianie uprawnień administratora dla Azure DevOps Server.

7. Jeśli wdrożenie jest zintegrowane z programem Project Server, może być konieczne wykonanie dodatkowych kroków w celu skonfigurowania kont usług z uprawnieniami wymaganymi do operacji. Aby uzyskać więcej informacji, zobacz Przypisywanie uprawnień do obsługi integracji z serwerem TFS-Project i integracji z programem ConfigureTFS-Project Server.

Konfigurowanie usług Reporting and Analysis Services

Tę procedurę można pominąć, jeśli nie używasz raportowania w ramach wdrożenia.

Jeśli zmieniono nazwę serwera raportów w ramach tego typu przenoszenia, musisz przekierować Azure DevOps Server do serwera raportów w nowej lokalizacji. Należy również ponownie uruchomić magazyn i ręcznie ponownie skompilować bazę danych dla usług Analysis Services.

1. Otwórz konsolę administracyjną usługi Azure DevOps, przejdź do węzła Raportowanie i edytuj ustawienia.

   

2. Zmień wartości na wszystkich trzech kartach, tak aby zawierały nową nazwę serwera. Upewnij się, że podajesz poprawne informacje dla konta źródeł danych w nowym środowisku.

   

3. Wybierz pozycję Uruchom zadania , aby ponownie uruchomić raportowanie.

4. Wybierz pozycję Rozpocznij ponowne kompilowanie , aby ponownie skompilować magazyn.

Konfigurowanie kopii zapasowych

Jeśli nazwa udziału sieciowego lub urządzenie magazynu zmieni się wraz ze zmianą nazwy domeny, należy zaktualizować zaplanowany plan kopii zapasowej, aby wskazać te zmienione zasoby.

• W konsoli administracyjnej przejdź do węzła Zaplanowane kopie zapasowe i skonfiguruj ponownie zaplanowane kopie zapasowe, aby utworzyć kopię zapasową Azure DevOps Server baz danych na nowym serwerze. Aby uzyskać więcej informacji, zobacz Twórca harmonogram tworzenia kopii zapasowych i planowanie.

Ponowne uruchamianie usług

Po zaktualizowaniu Azure DevOps Server ze wszystkimi informacjami dotyczącymi nowego środowiska uruchom ponownie usługi.

1. Na komputerze Azure DevOps Server warstwie aplikacji otwórz okno wiersza polecenia z uprawnieniami administracyjnymi i zmień katalogi na Dysk:\%programfiles%\TFS 12.0\Tools.

2. Wpisz następujące polecenie TFSServiceControl :

   Funkcja TFSServiceControl wyczyszczanie

Pytania i odpowiedzi

Pyt.: Chcę zmienić serwer fizyczny lub serwery dla mojego wdrożenia, a nie domeny. Czy mogę to zrobić?

Odpowiedź: tak. Jest to nazywane przeniesieniem opartym na sprzęcie, a kroki są dostępne w sekcji Przenoszenie lub klonowanie z jednego sprzętu do innego. Nie należy próbować łączyć ruchu opartego na środowisku z przenoszeniem opartym na sprzęcie. Najpierw ukończ przenoszenie sprzętu, a następnie zmień środowisko.