Przechodzenie z jednego środowiska do innego Azure DevOps w środowisku lokalnym

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 — TFS 2013

Uwaga

Azure DevOps Server wcześniej nosiła nazwę Visual Studio Team Foundation Server.

Najbardziej powszechnym scenariuszem przenoszenia opartego na środowisku jest zmiana domeny wdrożenia usługi Azure DevOps Server, bez względu na to, czy jest to zmiana nazwy domeny, czy przejście z grupy roboczej do domeny.

Ważne

W niektórych sytuacjach możesz chcieć zmienić domenę wdrożenia Azure DevOps Server, a także jego sprzęt. Zmiana sprzętu jest przeniesieniem opartym na przywracaniu i nigdy nie należy łączyć tych dwóch typów przenoszenia. Najpierw wykonaj przeniesienie sprzętu,a następnie zmień środowisko.

Ponadto zmiana tożsamości w Azure DevOps Server w ramach przenoszenia środowiska 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ślne przeniesienie, upewnij się, że rozumiesz następujące wymagania:

  • Gdy konto użytkownika znajduje się w Azure DevOps Server, nie można go usunąć ani zamapować na nie innego konta. Jeśli na przykład przenosisz domenę A/użytkownika do domeny B/użytkownikaB, polecenie Tożsamości będzie działać tylko w przypadku migrowania użytkownika, jeśli domenaB/użytkownikB nie jest jeszcze obecny w Azure DevOps Server.
  • Ponieważ członkowie lokalnej grupy Administratorzy są automatycznie dodawana do usługi Azure DevOps Server, pamiętaj o usunięciu wszystkich kont, które mają zostać zmigrowane z tej grupy przed zmianą domeny lub środowiska.

Aby uzyskać więcej informacji, przejdź tutaj, aby uzyskać szczegółowy opis sposobu działania Azure DevOps Server, w tym ograniczenia narzędzia.

W poniższych sekcjach przedstawiono kroki zmiany środowiska wdrożenia Azure DevOps Server wdrożenia:

  1. Sprawdzanie uprawnień i kont
  2. Zatrzymywanie Azure DevOps Server usługi
  3. Back Up Data
  4. Przyłącz Azure DevOps Server do nowej domeny
  5. Konfigurowanie SharePoint products dla nowego środowiska
  6. Przenoszenie Azure DevOps Server kont użytkowników i usług
  7. Konfigurowanie raportowania i Analysis Services
  8. Ponowne Azure DevOps Server usług

Sprawdzanie uprawnień i kont

Aby pomyślnie zmienić środowisko dla programu Azure DevOps Server, musisz być administratorem na komputerze lokalnym, a także w programie Azure DevOps Server i całym oprogramowaniu, od którego zależy wdrożenie: SQL Server, raportowanie, produkty SharePoint (jeśli wdrożenie korzysta z raportowania lub SharePoint) oraz wszelkie inne oprogramowanie, z którym współdziała wdrożenie, takie jak Project Server. Jednak wszyscy członkowie lokalnej grupy Administratorzy są automatycznie uwzględniani w 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 ma być migrowane 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 konto, z których korzystasz, należy do następujących grup:
    • Serwery: Administratorzy (lokalni administratorzy grupy lub równoważnej)
    • Azure DevOps Server: Administratorzy programu Team Foundation i użytkownicy konsoli administracyjnej
    • SQL Server: sysadmin
    • SharePoint Produkty: Administratorzy farmy (jeśli wdrożenie Azure DevOps Server integruje się z SharePoint Products)

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

Teraz, gdy masz pewność, że używasz konta, które ma wszystkie wymagane uprawnienia, możesz rozpocząć sprawdzanie kont, aby sprawdzić, czy w środowisku, do którego będziesz się przenosić, mogą wystąpić konflikty z nazwami lub grupami. Wiemy już, że nie można migrować kont, które są członkami lokalnej grupy administratorów, więc najpierw je usuńmy.

Usuwanie kont do zmigrowania z lokalnej grupy administratorów

  • Otwórz lokalną grupę Administratorzy i usuń wszystkie konta, które mają być migrowane do nowego środowiska. Powtórz ten krok dla innych grup, których to dotyczy.

Teraz sprawdź listę tożsamości w bieżącym środowisku Azure DevOps Server i poszukaj potencjalnych problemów z grupami lub indywidualnymi 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, wraz ze szczegółami, których kont nie można migrować automatycznie.

Sprawdzanie tożsamości

  1. Na serwerze warstwy aplikacji dla programu 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 aktualnie 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 żadnych potencjalnych duplikatów lub problemów z tożsamościami w środowisku, do którego zostaną Azure DevOps Server, i podjąć kroki w celu ograniczenia potencjalnych konfliktów.

Zatrzymywanie usług

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

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

  2. Wpisz następujące polecenie TFSServiceControl:

    TFSServiceControl quiesce

Back up the databases and the SQL Server Reporting Services encryption key (Kopię zapasową baz danych i klucza szyfrowania SQL Server Reporting Services danych)

  1. Otwórz konsolę administracyjną programu Azure DevOps Server a następnie na stronie Zaplanowane kopie zapasowe należy utworzyć pełną kopię zapasową. Kopia zapasowa będzie tworzyć kopię zapasową wszystkiego, co skonfigurowano dla kopii zapasowej w planie tworzenia kopii zapasowej, ale zrobi to natychmiast, nie zgodnie z czasem zaplanowanym w planie. Jeśli wdrożenie korzysta z raportowania, można utworzyć kopię zapasową klucza szyfrowania w ramach tego zestawu kopii zapasowych.

    Okno można zamknąć po zakończeniu zadania

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

  2. Po zakończeniu tworzenia kopii zapasowej sprawdź, czy kopia zapasowa jest dostępna na urządzeniu magazynującego lub w udziałach sieciowych i czy możesz uzyskać dostęp do tej kopii zapasowej z nowego sprzętu.

Przyłącz serwer 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ć do serwera.

    Jeśli zostanie wyświetlony monit o podanie nazwy użytkownika i hasła konta z uprawnieniami do przyłączenia tego komputera do domeny, podaj odpowiednie poświadczenia.

  3. Uruchom ponownie komputer, aby zmiana domeny zaczęła obowiązywać.

    Uwaga

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

Konfigurowanie SharePoint produktów dla nowego środowiska

Jeśli zmieniasz środowisko na środowisko, w którym nie ma zaufania do poprzedniego środowiska, może być konieczne skonfigurowanie usługi SharePoint Products, zanim będzie działać prawidłowo. Informacje o użytkownikach importowanych z usług katalogowych są dostępne SharePoint lokacjach z selektor osób web control. Administratorzy lokacji i inni użytkownicy używają selektor osób do wybierania osób i grup podczas przypisywania uprawnień. Jeśli informacje o użytkownikach znajdują się w wielu lasach lub w lesie bez relacji zaufania dla wszystkich użytkowników, mogą być konieczne dodatkowe kroki w celu zapewnienia, że wszystkie osoby i grupy są dostępne z tej kontrolki sieci Web.

Pomiń tę procedurę, jeśli nie używasz produktów usługi SharePoint w swoim wdrożeniu, jeśli nowe środowisko ma relację zaufania dwukierunkowego do starego środowiska lub jeśli w konsoli administracyjnej usługi SharePoint Azure DevOps nie są wyświetlane żadne błędy aplikacji internetowej SharePoint.

  1. Na każdym serwerze, który jest częścią farmy programu SharePoint obsługującej wdrożenie programu Azure DevOps Server, otwórz okno wiersza polecenia z uprawnieniami administracyjnymi i zmień katalogi na %programfiles% \ Common Files Microsoft Shared Web Server \ \ Extensions \ 15 \ BIN.

  2. Wpisz następujące polecenie, gdzie klucz jest kluczem szyfrowania, którego chcesz użyć we wdrożeniu usługi SharePoint Products:

    stsadm.exe -o setapppassword -password Key

    Uwaga

    Ten klucz jest ciągiem szyfrowania używanym do szyfrowania hasła konta używanego do uzyskiwania dostępu do lasu lub domeny. Ciąg szyfrowania musi być taki sam dla każdego serwera w farmie, ale dla każdej farmy powinien być używany unikatowy ciąg.

  3. Wpisz następujące polecenie, gdzie domena:DNSName jest lasem docelowym lub domeną i jej nazwą DNS, użytkownikiem, hasłem jest nazwa użytkownika i hasło dla konta, które ma dostęp do docelowego lasu lub domeny, a WebApp to nazwa aplikacji internetowej obsługującej wdrożenie usługi Azure DevOps Server:

    stsadm.exe -o setproperty -pn peoplepicker-searchadforests -pv domain:DnsName,user,password -url http://WebApp

  4. Wpisz następujące polecenie, gdzie adres URL jest adresem URL kolekcji witryn obsługującej kolekcję projektów, port to numer portu przypisany do tej kolekcji witryn, a UserName jest nazwą użytkownika konta, które będzie pełnić funkcję właściciela dla tej kolekcji witryn:

    stsadm.exe -o siteowner -url http:// URL: Port -ownerlogin UserName

  5. Powtórz poprzedni krok dla każdej kolekcji witryn używanej przez Azure DevOps Server lokacji.

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

Jak wspomniano na początku tego tematu, przenoszenie kont ma największe prawdopodobieństwo wystąpienia trudności, szczególnie w przypadku, gdy migracja użytkowników nie była starannie zaplanowana. Polecenie Tożsamości TFSConfig 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żna użyć trybu wsadowego tożsamości TFSConfig, aby zmienić wszystkie tożsamości jednocześnie. W przeciwnym razie musisz zmienić tożsamości indywidualnie i określić inną nazwę konta docelowego, jak o ile o tym podano poniżej.

  1. Na serwerze warstwy aplikacji dla programu 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 Twoje 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. Należy wykonać dwuetapową zmianę procesu. Zobacz przykład w poleceniu tożsamości.

  2. Aby przeprowadzić migrację wszystkich kont, które mają taką samą nazwę w nowym środowisku, wpisz następujące polecenie:

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

    Spowoduje to przetwarzanie wsadowe kont.

  3. Jeśli jesteś nową domeną zawierającą co najmniej jedną tożsamość, w której nazwa zmienia się między środowiskami, musisz ręcznie zaktualizować identyfikatory SID dla każdej z tych tożsamości. Jeśli na przykład w poprzednim środowisku konto użytkownika Christie Stan było kontem Fabrikam CChurch, ale w nowym środowisku jest kontem \ NewFabrikam ChristieC, należy ręcznie zaktualizować jej \ identyfikator 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 korzysta z 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 Azure DevOps proxy, uruchom następujące polecenie, aby zaktualizować konto usługi używane na serwerze proxy:

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

    Uwaga

    W przypadku przechodzenia do domeny niezau zaufanej może być również konieczne ręczne dodanie użytkowników i grup do zespołów, projektów, kolekcji i Azure DevOps Server samodzielnie. Aby uzyskać więcej informacji, zobacz Dodawanieużytkowników do projektów, Ustawianie uprawnień administratoradla 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 czynności w celu skonfigurowania kont usług z uprawnieniami wymaganymi do działania. Aby uzyskać więcej informacji, zobacz Assign permissions to support TFS-Project Server integration (Przypisywanie uprawnień do obsługi integracji z programem TFS-Project Server) i ConfigureTFS-Project Server integration (Integracja serwera ConfigureTFS-Project Server).

Konfigurowanie raportowania i Analysis Services

Możesz pominąć tę procedurę, jeśli nie używasz raportowania w ramach wdrożenia.

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

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

    Raporty nadal wskazują stary serwer

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

    Upewnij się, że informacje na wszystkich 3 kartach są poprawne

  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 magazynujące zostały zmienione wraz ze zmianą nazwy domeny, należy zaktualizować zaplanowany plan tworzenia kopii zapasowej, aby wskazać te zasoby, których nazwy zostały zmienione.

  • W konsoli administracyjnej przejdź do węzła Zaplanowane kopie zapasowe i ponownie skonfiguruj zaplanowane kopie zapasowe w celu tworzenia kopii zapasowych Azure DevOps Server baz danych na nowym serwerze. Aby uzyskać więcej informacji, zobacz Tworzenie harmonogramu i planu tworzenia kopii zapasowych.

Ponowne uruchamianie usług

Teraz, po zaktualizowania Azure DevOps Server wszystkich informacji dotyczących nowego środowiska, uruchom ponownie usługi.

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

  2. Wpisz następujące polecenie TFSServiceControl:

    TfSServiceControl unquiesce (Kontrola TFSServiceControl)

Pytania i odpowiedzi

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

Odpowiedź: tak. Jest to nazywane przenoszeniem sprzętowym, a kroki znajdują się w te tematze Move or clone from one hardware to another ( Przenoszenie lub klonowanie z jednego sprzętu na inny). Nie należy próbować łączyć przenoszenia opartego na środowisku z przeniesieniem sprzętowym. Najpierw wykonaj przeniesienie sprzętu, a następnie zmień środowisko.