Zarządzanie Azure DevOps lokalnie przy użyciu narzędzia TFSConfig

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

Możesz użyć narzędzia wiersza polecenia TFSConfig, aby wykonać różne czynności administracyjne dla Azure DevOps wdrożenia lokalnego.

Program TFSConfig można uruchomić z dowolnego komputera, na którym zainstalowano Azure DevOps Server.

Lokalizacja narzędzia wiersza polecenia

Azure DevOps narzędzia wiersza polecenia są instalowane w katalogu /Tools serwera warstwy aplikacji Azure DevOps.

  • Azure DevOps Server 2020 r.:%programfiles%\Azure DevOps Server 2020\Tools
  • Azure DevOps Server 2019 r.:%programfiles%\Azure DevOps Server 2019\Tools
  • TFS 2018: %programfiles%\Microsoft Team Foundation Server 2018\Tools
  • TFS 2017: %programfiles%\Microsoft Team Foundation Server 15.0\Tools
  • TFS 2015: %programfiles%\Microsoft Team Foundation Server 14.0\Tools
  • TFS 2013: %programfiles%\Microsoft Team Foundation Server 12.0\Tools
  • TFS 2012: %programfiles%\Microsoft Team Foundation Server 11.0\Tools
  • TFS 2010: %programfiles%\Microsoft Team Foundation Server 2010\Tools

Wymagania wstępne

Aby wiele poleceń działało poprawnie, program TFSConfig będzie musiał mieć możliwość nawiązania połączenia z różnymi serwerami i usługami, które są częścią wdrożenia serwera TFS, a użytkownik z programem TFSConfig będzie musiał mieć uprawnienia administracyjne dla tych samych serwerów i usług. Poniżej zostaną określone wymagania dotyczące określonych poleceń.

Wiele poleceń TFSConfig musi zostać uruchomionych z wiersza polecenia z podwyższonym poziomem uprawnień, nawet jeśli uruchomiony użytkownik ma poświadczenia administracyjne. Aby otworzyć wiersz polecenia z podwyższonym poziomem uprawnień, kliknij przycisk Start, kliknij prawym przyciskiem myszy wiersz polecenia, a następnie kliknij polecenie Uruchom jako administrator. Aby uzyskać więcej informacji, zobacz: Kontrola konta użytkownika.

Możesz również wykonać akcje administracyjne interaktywnie przy użyciu konsoli administracyjnej dla Azure DevOps Server. Zobacz Krótki przewodnik po zadaniach administracyjnych.

Wyświetlanie listy poleceń i uzyskiwanie pomocy

Aby wyświetlić pełną listę poleceń TFSConfig , użyj polecenia pomocy :

TFSConfig help

Aby uzyskać pomoc dla pojedynczego polecenia, użyj polecenia pomocy i określ nazwę polecenia, za pomocą którego chcesz uzyskać pomoc. Aby na przykład uzyskać pomoc dotyczącą polecenia accounts :

TFSConfig help accounts

Konta

Użyj polecenia accounts, aby zarządzać tymi kontami usługi Azure DevOps Server.

  • konto usługi Azure DevOps Server
  • konto źródeł danych dla SQL Server Reporting Services
  • konto usługi serwera proxy Azure DevOps

Możesz również użyć tego polecenia, aby zmienić własność Azure DevOps Server baz danych.

TfsConfig accounts /change|add|set|delete|updatepassword|resetowner
	[/accountType:<adminConsole|applicationTier|proxy|reportingDataSource>]
	[/account:<accountName>] [/password:<password>]
	[/sqlInstance:<serverName>] [/databaseName:<databaseName>] [/continue]
Operacja Opis
UpdatePassword Zmienia hasło konta, które jest używane jako konto usługi. Zmienia istniejące konto i wszystkie typy kont, które są uruchamiane jako podane konto.
Zmiana Zmienia konto używane jako konto usługi. Dodaje nowe konto do niezbędnych zasobów i grup, przyznaje wymagane uprawnienia, a następnie ustawia usługę do jej używania. Nie powoduje to usunięcia starego konta z zasobów.

Jeśli nie używasz opcji accountType , konto usługi dla warstwy aplikacji zostanie zmienione.
Dodaj Dodaje tylko nowe konto do niezbędnych zasobów. Przydatne w scenariuszach równoważenia obciążenia sieciowego. Użyj flagi kontynuuj, jeśli niektóre kolekcje są niedostępne. Dodaj można uruchomić ponownie później, aby zaktualizować wszystkie pominięte kolekcje. Dodaje konto do grup, które są wymagane do korzystania z konta jako konta usługi.
Set Ustawia tylko usługę tak, aby korzystała z konta już dodanego do zasobów. Przydatne w scenariuszach równoważenia obciążenia sieciowego.
Usuń Usuwa konto ze wszystkich zasobów. Należy użyć środków ostrożności podczas usuwania konta, ponieważ może to spowodować, że inne serwery zostaną odrzucone usługi.
ResetOwner Jeśli bazy danych zostaną przywrócone w ramach przenoszenia, klonowania lub odzyskiwania po awarii, właściciel bazy danych może przełączyć się do administratora przywracającego serwer. Ta opcja iteruje wszystkie bazy danych i ustawia identyfikator logowania dbo do bieżącego właściciela.
Accounttype Opis
AdminConsole Użytkownicy konsoli administracyjnej to użytkownicy, którym przyznano minimalne uprawnienia w różnych zasobach do korzystania z konsoli programu .
ApplicationTier Zmienia konto usługi w puli aplikacji dla podstawowych usług internetowych. (TFSService)
Serwer proxy Zmienia konto usługi w puli aplikacji dla usług internetowych serwera proxy. (TFSProxy)
ReportingDataSource Zmienia konto używane przez raporty w celu uzyskania dostępu do danych raportowania. (TFSReports)

Wartość domyślna to ApplicationTier.

Klasa sqlInstance i databaseName są odpowiednie tylko do użycia podczas dodawania konta do baz danych przed skonfigurowaniem warstwy aplikacji. Jest to przede wszystkim przydatne w scenariuszach odzyskiwania po awarii, w których jest potrzebne inne konto przed uruchomieniem kreatora konfiguracji tylko usługi AT.

Opcja kontynuuj jest używana podczas dodawania lub zmieniania konta. W przypadku tych operacji konto jest zmieniane w każdej bazie danych kolekcji. Jeśli zostanie podana kontynuacja, będzie ona kontynuowana, jeśli kolekcja jest niemożliwa do osiągnięcia. Można go uruchomić ponownie, gdy są osiągalne.

Uwaga

Konta muszą mieć format domainName\userName. W przypadku kont systemowych należy użyć cudzysłowów wokół pełnej nazwy konta (na przykład "NT Authority\Network Service"). Konta systemowe nie wymagają hasła.

Parametr Opis
Konto Określa nazwę konta, które chcesz dodać, zmienić lub usunąć z przywoływałego typu konta, na przykład /AccountType:ApplicationTier.
Hasło Określa hasło konta usługi. Ten parametr jest opcjonalny, jeśli używasz konta systemowego lub konta, które nie ma hasła, takiego jak usługa sieciowa.
sqlInstance Używane tylko z /ResetOwner.

Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Należy określić nazwę i wystąpienie w następującym formacie:

Servername\instancename.
Databasename Używane tylko z /ResetOwner.

Określa nazwę bazy danych, której własność ma zostać zmieniona. Za pomocą tego polecenia można zresetować własność bazy danych określonej do konta, na którym jest uruchamiane polecenie.
continue Aktualizuje wszystkie grupy, które nie są dostępne podczas uruchamiania polecenia. Ta opcja jest zwykle używana w scenariuszach równoważenia obciążenia sieciowego.

Wymagania wstępne

Aby użyć polecenia accounts , musisz być członkiem:

  • grupa zabezpieczeń administratorzy Azure DevOps
  • rola administratora systemu dla wszystkich wystąpień SQL Server używanych przez wystąpienie Azure DevOps Server.

Jeśli używasz opcji /proxy , musisz być administratorem na serwerze proxy.

Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Użyj polecenia accounts, aby zautomatyzować zmiany w kontach usług, bazach danych i grupach kont usług Azure DevOps Server. Możesz skonfigurować konta, które zostały już utworzone, ale nie można tworzyć kont.

Przed zmianą domeny lub grupy roboczej konta konto musi mieć poufne konto i nie może być delegowane uprawnienia na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz tę stronę w witrynie sieci Web firmy Microsoft: Włączanie uwierzytelniania delegowanego.

Polecenie accounts obsługuje lokalne wdrożenia Azure DevOps Server. Aby zmienić właściciela konta Azure DevOps Services, zobacz Zmienianie własności konta.

Przykłady

Zmień konto usługi źródeł danych dla usług Reporting Services na nowe konto w domenie Contoso i Contoso\NewAccounthasło na Password.

TfsConfig accounts /change /AccountType:ReportingDataSource /Account:Contoso\NewAccount /Password:Password

Dodaj konto systemowe usługi sieciowej do grup kont usług dla Azure DevOps Server (konta systemowe nie mają haseł).

TfsConfig accounts /add /AccountType:ApplicationTier /Account:"NT Authority\Network Service"

Zmień własność TFS_Warehouse bazy danych na ContosoMain SQL Server w TeamDatabases nazwanym wystąpieniu na konto użytkownika, na którym jest uruchamiane polecenie.

Uwaga

Nie można określić, które konto ma być ustawione jako właściciel baz danych podczas korzystania z tego polecenia. Właściciel zostanie ustawiony na konto, w ramach którego uruchamiasz polecenie.

TfsConfig accounts /ResetOwner /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_Warehouse

Użyj polecenia Konta , aby zarządzać tymi kontami usług TFS.

  • konto usługi TFS
  • konto źródeł danych dla SQL Server Reporting Services
  • konto usługi serwera proxy Azure DevOps

Możesz również użyć tego polecenia, aby zmienić własność Azure DevOps Server baz danych.

TFSConfig Accounts /change|add|set|delete|updatepassword|resetowner
[/AccountType:{AdminConsole|ApplicationTier|Proxy|ReportingDataSource}]
[/Account:AccountName] [/Password:Password]
[/SQLInstance:ServerName] [/DatabaseName:DatabaseName] [/Continue] [/usesqlalwayson]

Opcja

Opis

/change

Zmienia konto używane jako konto usługi.

Ta opcja powoduje dodanie konta określonego dla wszystkich niezbędnych grup, nadania mu w miarę możliwości wymagań wstępnych i ustawiania usługi na korzystanie z konta.

Jeśli nie używasz opcji /AccountType z tą opcją, konto usługi dla warstwy aplikacji zostanie zmienione.

/add

Dodaje konto do grup, które są wymagane do korzystania z konta jako konta usługi.

Ta opcja dodaje konto określone do niezbędnych grup i przyznaje mu uprawnienia wymagane do działania jako konto usługi (jeśli to możliwe).

Jednak ta opcja nie spowoduje zmiany konta używanego jako konto usługi.

Ta opcja jest zwykle używana w scenariuszach równoważenia obciążenia sieciowego (NLB).

Tej opcji można użyć z /continue, jeśli niektóre usługi lub bazy danych mogą być niedostępne w twoim środowisku.

/set

Ustawia konto jako konto usługi. Ta opcja nie dodaje konta do żadnych grup.

W związku z tym należy użyć tej opcji tylko z kontami, które zostały już dodane do wymaganych grup i mają niezbędne uprawnienia.

Ta opcja jest zwykle używana w scenariuszach równoważenia obciążenia sieciowego.

/delete

Usuwa konto z określonego typu konta.

Ta opcja usuwa konto określone z niezbędnych grup i usuwa uprawnienia wymagane do działania jako konto usługi (jeśli to możliwe).

Jednak ta opcja nie spowoduje zmiany konta używanego jako konto usługi.

Upewnij się, że nie używasz tej opcji dla konta, które serwery we wdrożeniu są obecnie używane jako konto usługi.

/ResetOwner

Zmienia własność baz danych, których Azure DevOps Server używać do konta używanego do uruchamiania tego polecenia.

Ta opcja iteruje mimo że wszystkie bazy danych i ustawia identyfikator logowania dbo do konta, którego używasz do uruchomienia tego polecenia.

Może być konieczne użycie tej opcji podczas przenoszenia lub przywracania wdrożenia.

/UpdatePassword

Zmienia hasło konta, które jest używane jako konto usługi.

Ta opcja aktualizuje hasło dla konta określonego dla wszystkich usług w Azure DevOps Server, które używają tego konta.

/AccountType: { AdminConsole | | ApplicationTier ReportingDataSource | Serwer proxy }

  • AdminConsole: grupa użytkowników, którzy mają minimalne uprawnienia wymagane do otwarcia konsoli administracyjnej i korzystania z konsoli administracyjnej dla Azure DevOps (AdminConsole)
  • ApplicationTier: konto usługi używane do Azure DevOps Server (TFSService)
  • ReportingDataSource: konto źródeł danych dla usług Reporting Services (TFSReports)
  • Serwer proxy: konto usługi dla serwera proxy Azure DevOps Server (TFSProxy)

Wartość domyślna to ApplicationTier.

/Konto: Accountname

Określa nazwę konta, które chcesz dodać, zmienić lub usunąć z przywoływałego typu konta, na przykład /AccountType:ApplicationTier.

Określ konto w jednej z następujących form: Domain\AccountName lub Computer\AccountName.

Jeśli chcesz użyć konta systemowego, takiego jak usługa sieciowa lub system lokalny, użyj formatu Computer\AccountName.

Aby uzyskać więcej informacji na temat sposobu określania konta systemowego, zobacz przykłady użycia w dalszej części tego tematu.

/Hasło: Hasło

Określa hasło konta usługi.

Uwaga: Ten parametr jest opcjonalny, jeśli używasz konta systemowego lub konta, które nie ma hasła, takiego jak usługa sieciowa.

/SQLInstance: Nazwa_serwera

Używane tylko z /ResetOwner.

Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne.

Należy określić nazwę i wystąpienie w następującym formacie:

Servername\instancename.

/DatabaseName: Databasename

Używane tylko z /ResetOwner.

Określa nazwę bazy danych, której własność ma zostać zmieniona.

Za pomocą tego polecenia można zresetować własność bazy danych określonej do konta, na którym jest uruchamiane polecenie.

/continue

Aktualizuje wszystkie grupy, które nie są dostępne podczas uruchamiania polecenia. Ta opcja jest zwykle używana w scenariuszach równoważenia obciążenia sieciowego.

/usesqlalwayson

Używane tylko z /ResetOwner w połączeniu z /SQLInstance i /DatabaseName.

Określa, że bazy danych są częścią zawsze włączonej grupy dostępności w SQL Server.

W przypadku skonfigurowania ta opcja ustawia wartość MultiSubnetFailover w parametrach połączenia.

Aby uzyskać więcej informacji, zobacz [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć polecenia Accounts , musisz być członkiem

  • grupa zabezpieczeń Administratorzy team foundation
  • rola administratora systemu dla wszystkich wystąpień SQL Server używanych przez wystąpienie Azure DevOps Server.

Jeśli używasz opcji /proxy , musisz być administratorem na serwerze proxy.

Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server>.

Uwagi

Użyj polecenia Accounts, aby zautomatyzować zmiany w kontach usług, bazach danych i grupach kont usług Azure DevOps Server. Możesz skonfigurować konta, które zostały już utworzone, ale nie można tworzyć kont.

Przed zmianą domeny lub grupy roboczej konta konto musi mieć poufne konto i nie może być delegowane uprawnienia na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz tę stronę w witrynie sieci Web firmy Microsoft: Włączanie uwierzytelniania delegowanego.

Polecenie Accounts obsługuje lokalne wdrożenia Azure DevOps Server. Aby zmienić właściciela konta Azure DevOps Services, zobacz Zmienianie własności konta.

Przykłady

Zmień konto usługi źródeł danych dla usług Reporting Services na nowe konto w domenie Contoso, Contoso\NewAccount i hasło na Hasło.

TFSConfig Accounts /change /AccountType:ReportingDataSource /Account:Contoso\NewAccount /Password:Password

Dodaj konto systemu usługi sieciowej do grup kont usług dla Azure DevOps Server. (Konta systemowe nie mają haseł).

TFSConfig Accounts /add /AccountType:ApplicationTier /Account:"NT Authority\Network Service"

Zmień własność bazy danych "TFS_Warehouse" na SQL Server "ContosoMain" w nazwanym wystąpieniu "TeamDatabases" na konto użytkownika, w ramach którego uruchamiasz polecenie.

Uwaga

Nie można określić, które konto ma być ustawione jako właściciel baz danych podczas korzystania z tego polecenia. Właściciel zostanie ustawiony na konto, w ramach którego uruchamiasz polecenie.

TFSConfig Accounts /ResetOwner /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_Warehouse

AddProjectReports

Uwaga

Polecenie addProjectReports jest dostępne w programie TFS 2017.1 i nowszych wersjach.

Polecenie addProjectReports służy do dodawania lub zastępowania raportów dla istniejącego projektu zespołowego.

TfsConfig addProjectReports /collection:<teamProjectCollectionUrl> /teamProject:<projectName> /template:<templateName>
[/force]
Opcja Opis
— kolekcja Wymagane. Adres URL kolekcji Project zespołu.
teamproject Wymagane. Określa nazwę projektu zespołowego.
szablon Wymagane. Określa nazwę szablonu procesu. Dostępne opcje to Agile, CMMI i Scrum.
Życie Opcjonalny. Określa, że raporty powinny zostać zastąpione, jeśli już istnieją.

Wymagania wstępne

Aby użyć polecenia addProjectReports , musisz mieć uprawnienia do uruchamiania programu TFSConfig i przekazywania raportów do usługi Reporting Service.

Uwagi

Polecenie addProjectReports jest używane, gdy projekt nie ma raportów lub chcesz zaktualizować raporty zdefiniowane dla procesu.

Może być konieczne użycie tego polecenia, gdy:

  • Projekt został utworzony w portalu Azure DevOps, a nie z Visual Studio
  • Projekt został utworzony na podstawie Visual Studio, jednak raportowanie nie zostało skonfigurowane w Azure DevOps Server.

Jeśli chcesz zastąpić raporty w projekcie domyślnymi raportami, ponieważ uaktualniono Azure DevOps Server i stare raporty w projekcie nie są już zgodne, użyj opcji /force. Jeśli masz dostosowane raporty, przed wykonaniem tej czynności utwórz kopię zapasową.

Aby dowiedzieć się więcej na temat dodawania raportów do lokalnego Azure DevOps Server, zobacz Dodawanie raportów do projektu.

Przykład

W poniższym przykładzie pokazano, jak dodać raporty Agile do MyProject projektu w http://myTfsServer:8080/tfs/DefaultCollection kolekcji projektów.

TFSConfig addProjectReports /collection:http://myTfsServer:8080/tfs/DefaultCollection /teamproject:MyProject /template:Agile

Polecenie AddProjectReports służy do dodawania lub zastępowania raportów dla istniejącego projektu.

TfsConfig addProjectReports
/collection:teamProjectCollectionUrl
/teamProject:projectName
/template:templateName
[/force]

Opcja

Opis

/collection

Wymagane. Adres URL kolekcji Project.

/teamProject

Wymagane. Określa nazwę projektu.

/template

Wymagane. Określa nazwę szablonu procesu. Dostępne opcje to Agile, CMMI i Scrum

/force

Opcjonalny. Określa, że raporty powinny zostać zastąpione, jeśli już istnieją.

Wymagania wstępne

Aby użyć polecenia AddProjectReports , musisz mieć uprawnienia do uruchamiania programu TFSConfig i przekazywania raportów do usługi Reporting Service.

Uwagi

Polecenie AddProjectReports jest używane, gdy projekt nie ma raportów lub chcesz zaktualizować raporty zdefiniowane dla procesu.

Może być konieczne użycie tego polecenia, gdy:

  • projekt został utworzony w portalu internetowym, a nie z Visual Studio
  • projekt został utworzony na podstawie Visual Studio, jednak raportowanie nie zostało skonfigurowane w Azure DevOps Server.

Jeśli chcesz zastąpić raporty w projekcie domyślnymi raportami, ponieważ uaktualniono Azure DevOps Server i stare raporty w projekcie nie są już zgodne, użyj opcji /force. Jeśli masz dostosowane raporty, przed wykonaniem tej czynności utwórz kopię zapasową.

Aby dowiedzieć się więcej na temat dodawania raportów do lokalnego Azure DevOps Server, zobacz Dodawanie raportów do projektu.

Przykład

W poniższym przykładzie pokazano, jak dodać raporty Agile do projektu MyProject w http://myTfsServer:8080/tfs/DefaultCollection kolekcji projektów.

TFSConfig addprojectreports /collection:http://myTfsServer:8080/tfs/DefaultCollection /teamproject:MyProject /template:Agile

Authentication

Polecenie uwierzytelniania zmienia protokół uwierzytelniania sieciowego używany przez Azure DevOps Server warstwę aplikacji lub witrynę internetową serwera proxy.

TFSConfig Authentication [/provider:NTLM|Negotiate] [/viewAll] [/siteType:ApplicationTier|Proxy]

Opcja

Opis

/viewAll

Wyświetla bieżące ustawienia uwierzytelniania dla Azure DevOps Server.

/provider: { | NTLM Negocjuj }

Określa dostawcę uwierzytelniania, który chcesz skonfigurować dla witryny sieci Web.

  • NTLM: użyj protokołu uwierzytelniania NTML
  • Negocjuj: użyj protokołu uwierzytelniania Negotiate (Kerberos)

/siteType

Określa witrynę internetową (warstwę aplikacji lub serwer proxy), której protokół uwierzytelniania sieciowego chcesz zmienić. Warstwa aplikacji jest domyślna.

Wymagania wstępne

Aby użyć uwierzytelniania polecenia, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps i administratorem lokalnym na serwerze warstwy aplikacji lub serwerze proxy, w zależności od wartości opcji siteType.

Uwagi

Polecenie Uwierzytelnianie jest używane przez administratora, który chce zmienić protokół uwierzytelniania sieciowego dla co najmniej jednej witryny sieci Web, na której opiera się Azure DevOps Server. Administrator uruchamia to polecenie z warstwy aplikacji, aby zaktualizować te witryny internetowe, które wymagają zmiany w protokole uwierzytelniania sieciowego. Polecenie zmienia właściwość NTAuthenticationProviders w metabazie usług IIS.

Przed użyciem polecenia Authentication w celu zmiany protokołu uwierzytelniania można uruchomić polecenie z opcją /viewAll , aby zobaczyć, jakie są istniejące ustawienia.

Przykład

Poniższy przykład przedstawia bieżącą wartość przypisaną do protokołu uwierzytelniania sieciowego.

TFSConfig Authentication /viewAll

Polecenie Uwierzytelnianie zmienia protokół uwierzytelniania sieciowego używany przez warstwę aplikacji TFS lub witrynę internetową serwera proxy.

TFSConfig Authentication [/provider:NTLM|Negotiate] [/viewAll] [/siteType:ApplicationTier|Proxy]

Opcja

Opis

/viewAll

Wyświetla bieżące ustawienia uwierzytelniania dla Azure DevOps Server.

/provider: { | NTLM Negocjuj }

Określa dostawcę uwierzytelniania, który chcesz skonfigurować dla witryny sieci Web.

  • NTLM: użyj protokołu uwierzytelniania NTML
  • Negocjuj: użyj protokołu uwierzytelniania Negotiate (Kerberos)

/siteType

Określa witrynę internetową (warstwę aplikacji lub serwer proxy), której protokół uwierzytelniania sieciowego chcesz zmienić. Warstwa aplikacji jest domyślna.

Wymagania wstępne

Aby użyć polecenia Uwierzytelnianie , musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i administratorem lokalnym na serwerze warstwy aplikacji lub serwerze proxy, w zależności od wartości opcji siteType .

Uwagi

Polecenie Uwierzytelnianie jest używane przez administratora, który chce zmienić protokół uwierzytelniania sieciowego dla co najmniej jednej witryny sieci Web, na której opiera się Azure DevOps Server. Administrator uruchamia to polecenie z warstwy aplikacji, aby zaktualizować te witryny internetowe, które wymagają zmiany w protokole uwierzytelniania sieciowego. Polecenie zmienia właściwość NTAuthenticationProviders w metabazie usług IIS.

Przed użyciem polecenia Authentication w celu zmiany protokołu uwierzytelniania można uruchomić polecenie z opcją /viewAll , aby zobaczyć, jakie są istniejące ustawienia.

Przykład

Poniższy przykład przedstawia bieżącą wartość przypisaną do protokołu uwierzytelniania sieciowego.

TFSConfig Authentication /viewAll

Certyfikaty

Użyj polecenia certyfikatów, aby zmienić sposób konfigurowania certyfikatów na potrzeby uwierzytelniania klienta we wdrożeniu Azure DevOps Server, który korzysta z protokołu HTTPS, secure sockets layer (SSL) i certyfikatów.

TfsConfig certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]
Opcja Opis
Maszyny Określa, że lista certyfikatów będzie pochodzić z kontekstu komputera lokalnego zamiast bieżącego kontekstu użytkownika.
Wyłącz Określa, że ustawienie certyfikatu uwierzytelniania klienta zostanie wyłączone.
autowybierz Określa, że certyfikat zostanie automatycznie wybrany z listy certyfikatów. Okno Zarządzanie certyfikatami klienta nie zostanie otwarte.
noprompt Określa, że okno Zarządzanie certyfikatami klienta nie zostanie otwarte po uruchomieniu polecenia Certyfikaty.
odciski palca Określa, że będzie używany certyfikat zgodny z określonym odciskiem palca. Można określić więcej niż jeden certyfikat, oddzielając poszczególne odciski palca przecinkami.

Wymagania wstępne

Aby użyć certyfikatów polecenia, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps i lokalnej grupy administratorzy na komputerze, z którego uruchamiasz polecenie. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Domyślnie polecenie certyfikatów automatycznie wybiera certyfikat klienta z listy certyfikatów dla bieżącego użytkownika. Można jednak użyć opcji polecenia, aby określić określony certyfikat lub certyfikaty z bieżącego kontekstu użytkownika lub z kontekstu komputera lokalnego.

Przed użyciem polecenia certyfikatów należy najpierw skonfigurować serwery we wdrożeniu Azure DevOps Server do korzystania z certyfikatów. Aby uzyskać więcej informacji, zobacz Konfigurowanie protokołu HTTPS przy użyciu protokołu Secure Sockets Layer (SSL) dla Azure DevOps Server.

Polecenie certyfikatów służy do konfigurowania certyfikatów klienta używanych przez wdrożenie Azure DevOps Server, które zostały skonfigurowane do używania protokołu HTTPS/SSL i certyfikatów. Jeśli używasz polecenia Certyfikaty bez opcji, certyfikat klienta zostanie automatycznie wybrany z bieżącego kontekstu użytkownika, z którego uruchamiasz polecenie.

Przykłady

W poniższym przykładzie pokazano, jak określić certyfikat komputera lokalnego, który ma odcisk aa bb cc dd ee palca bez monitowania.

TfsConfig certificates /machine /thumbprint:aa bb cc dd ee /noprompt

W poniższym przykładzie pokazano, jak określić przy użyciu automatycznego wyboru certyfikatu klienta z bieżącego magazynu użytkowników.

TfsConfig certificates /autoselect

Użyj polecenia Certyfikaty, aby zmienić sposób konfigurowania certyfikatów na potrzeby uwierzytelniania klienta we wdrożeniu Azure DevOps Server, który korzysta z protokołu HTTPS, secure sockets layer (SSL) i certyfikatów.

TFSConfig Certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]

Opcja

Opis

/machine

Określa, że lista certyfikatów będzie pochodzić z kontekstu komputera lokalnego zamiast bieżącego kontekstu użytkownika.

/disable

Określa, że ustawienie certyfikatu uwierzytelniania klienta zostanie wyłączone.

/autoWybierz

Określa, że certyfikat zostanie automatycznie wybrany z listy certyfikatów. Okno Zarządzanie certyfikatami klienta nie zostanie otwarte.

/noprompt

Określa, że okno Zarządzanie certyfikatami klienta nie zostanie otwarte po uruchomieniu polecenia Certyfikaty.

/thumbprints: odcisk palca

Określa, że będzie używany certyfikat zgodny z określonym odciskiem palca. Można określić więcej niż jeden certyfikat, oddzielając poszczególne odciski palca przecinkami.

Wymagania wstępne

Aby użyć polecenia Certyfikaty , musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i lokalnej grupy Administratorzy na komputerze, z którego uruchamiasz polecenie. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Domyślnie polecenie Certyfikaty automatycznie wybierze certyfikat klienta z listy certyfikatów bieżącego użytkownika. Można jednak użyć opcji polecenia, aby określić określony certyfikat lub certyfikaty z bieżącego kontekstu użytkownika lub z kontekstu komputera lokalnego.

Przed użyciem polecenia Certyfikaty należy najpierw skonfigurować serwery we wdrożeniu Azure DevOps Server do korzystania z certyfikatów. Aby uzyskać więcej informacji, zobacz Konfigurowanie protokołu HTTPS przy użyciu protokołu Secure Sockets Layer (SSL) dla Azure DevOps Server.

Polecenie Certyfikaty służy do konfigurowania certyfikatów klienta używanych przez wdrożenie Azure DevOps Server, które zostały skonfigurowane do używania protokołu HTTPS/SSL i certyfikatów. Jeśli używasz polecenia Certyfikaty bez opcji, certyfikat klienta zostanie automatycznie wybrany z bieżącego kontekstu użytkownika, z którego uruchamiasz polecenie.

Przykłady

W poniższym przykładzie pokazano, jak określić certyfikat komputera lokalnego z odciskiem palca "aa bb cc dd ee" bez monitowania.

TFSConfig Certificates /machine /thumbprint:aa bb cc dd ee /noprompt

W poniższym przykładzie pokazano, jak określić przy użyciu automatycznego wyboru certyfikatu klienta z bieżącego magazynu użytkowników.

TFSConfig Certificates /autoselect

Changeserverid

Polecenie changeServerID zmienia identyfikatory GUID skojarzone z bazami danych dla Azure DevOps Server. Identyfikatory GUID muszą być unikatowe we wdrożeniu Azure DevOps Server. Jeśli więcej niż jedna baza danych ma ten sam identyfikator GUID, wdrożenie może stać się niestabilne lub bezużyteczne. Można zmienić identyfikator GUID bazy danych konfiguracji, identyfikatory GUID dla wszystkich baz danych kolekcji projektów we wdrożeniu lub oba te elementy.

Chociaż zwykle nie używa się tego polecenia w codziennych operacjach, można użyć tego polecenia w następujących okolicznościach:

  • Wdrożenie zostało przywrócone do nowego sprzętu, stare wdrożenie nadal działa i chcesz korzystać z obu wdrożeń. Ten scenariusz jest czasami określany jako klonowanie serwera.

  • Chcesz przetestować aktualizację oprogramowania lub konfigurację sprzętu na zduplikowane wdrożenie, aby nie ryzykować zakłócenia środowiska produkcyjnego.

  • Chcesz w pełni przetestować przywracanie baz danych do nowego sprzętu w laboratorium testowym lub oddzielnym środowisku, aby upewnić się, że wdrożenie można przywrócić.

  • Identyfikator GUID dla bazy danych kolekcji należy zresetować po przeniesieniu go do innego wdrożenia, dla którego ten identyfikator GUID jest już zarezerwowany.

Uwaga

Polecenie changeServerID nie jest odwracalne. Po zmianie identyfikatora GUID nie można cofnąć tej zmiany, z wyjątkiem przywracania poprzedniej wersji tej bazy danych.

TfsConfig changeServerID /sqlInstance:<serverName> /databaseName:<configurationDatabaseName>
	[/projectCollectionsOnly] [/configDBOnly] [/collectionName]
Opcja Opis
sqlInstance Wymagane. Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.
Databasename Wymagane. Określa nazwę bazy danych konfiguracji dla Azure DevOps Server. Domyślnie nazwa tej bazy danych jest TFS_ConfigurationDB.
projectCollectionsOnly Określa, że zostaną zmienione tylko identyfikatory GUID dla kolekcji.
configDBOnly Określa, że zostanie zmieniony tylko identyfikator GUID bazy danych konfiguracji.
Collectionname Określa, aby utworzyć nowy identyfikator wystąpienia dla określonej kolekcji, ale nie dla wystąpienia Azure DevOps i innych kolekcji.

Wymagania wstępne

Aby użyć polecenia changeServerID, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps i członkiem roli zabezpieczeń sysadmin dla wszystkich wystąpień SQL Server, które Azure DevOps Server używa. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps.

Uwagi

Użyj polecenia changeServerID, aby utworzyć dyskretny duplikat wdrożenia Azure DevOps Server na potrzeby testowania lub klonowania. Po użyciu polecenia changeServerID należy skierować klientów, aby utworzyć połączenie ze zmienionym serwerem, zanim będzie można go użyć.

Przykład

W poniższym przykładzie pokazano, jak zmienić identyfikatory GUID wszystkich baz danych we wdrożeniu Azure DevOps Server firmy Contoso1, gdzie baza danych konfiguracji jest hostowana na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases w SQL Server.

TfsConfig changeServerID /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB

Polecenie ChangeServerID zmienia identyfikatory GUID skojarzone z bazami danych dla serwera TFS. Identyfikatory GUID muszą być unikatowe we wdrożeniu serwera TFS. Jeśli więcej niż jedna baza danych ma ten sam identyfikator GUID, wdrożenie może stać się niestabilne lub bezużyteczne. Można zmienić identyfikator GUID bazy danych konfiguracji, identyfikatory GUID dla wszystkich baz danych kolekcji projektów we wdrożeniu lub oba te elementy. Chociaż zwykle nie używa się tego polecenia w codziennych operacjach, można użyć tego polecenia w następujących okolicznościach:

  • Wdrożenie zostało przywrócone do nowego sprzętu, stare wdrożenie nadal działa i chcesz korzystać z obu wdrożeń. Ten scenariusz jest czasami określany jako klonowanie serwera.

  • Chcesz przetestować aktualizację oprogramowania lub konfigurację sprzętu na zduplikowane wdrożenie, aby nie ryzykować zakłócenia środowiska produkcyjnego.

  • Chcesz w pełni przetestować przywracanie baz danych do nowego sprzętu w laboratorium testowym lub oddzielnym środowisku, aby upewnić się, że wdrożenie można przywrócić.

  • Identyfikator GUID dla bazy danych kolekcji należy zresetować po przeniesieniu go do innego wdrożenia, dla którego ten identyfikator GUID jest już zarezerwowany.

    Uwaga

    Polecenie ChangeServerID nie jest odwracalne. Po zmianie identyfikatora GUID nie można cofnąć tej zmiany, z wyjątkiem przywracania poprzedniej wersji tej bazy danych.

    TFSConfig ChangeServerID /SQLInstance:ServerName /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]

Opcja

Opis

/SQLInstance: ServerName

Wymagane. Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName

/DatabaseName: DatabaseName

Wymagane. Określa nazwę bazy danych konfiguracji dla Azure DevOps Server. Domyślnie nazwa tej bazy danych jest TFS_ConfigurationDB.

/ProjectCollectionsOnly

Określa, że zostaną zmienione tylko identyfikatory GUID dla kolekcji.

/ConfigDBOnly

Określa, że zostanie zmieniony tylko identyfikator GUID bazy danych konfiguracji.

/usesqlalwayson

Określa, że bazy danych są częścią zawsze włączonej grupy dostępności w SQL Server. W przypadku skonfigurowania ta opcja ustawia wartość MultiSubnetFailover w parametrach połączenia.

Aby uzyskać więcej informacji, zobacz AlwaysOn Availability Groups (SQL Server).

Wymagania wstępne

Aby użyć polecenia ChangeServerID, musisz być członkiem grupy zabezpieczeń Administratorzy team Foundation i członkiem roli zabezpieczeń sysadmin dla wszystkich wystąpień SQL Server, które Azure DevOps Server używa. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps.

Uwagi

Polecenie ChangeServerID służy do tworzenia dyskretnego duplikatu wdrożenia Azure DevOps Server na potrzeby testowania lub klonowania. Po użyciu polecenia ChangeServerID należy skierować klientów, aby utworzyć połączenie ze zmienionym serwerem, zanim będzie można go użyć.

Przykład

W poniższym przykładzie pokazano, jak zmienić identyfikatory GUID wszystkich baz danych we wdrożeniu Azure DevOps Server firmy Contoso1, gdzie baza danych konfiguracji jest hostowana na serwerze o nazwie "ContosoMain" w nazwanym wystąpieniu "TeamDatabases" w SQL Server.

TFSConfig ChangeServerID /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB

Indeks kodu

Użyj polecenia codeIndex, aby zarządzać indeksowaniem kodu w Azure DevOps Server. Na przykład możesz zresetować indeks, aby naprawić informacje o funkcji CodeLens, lub wyłączyć indeksowanie w celu zbadania problemów z wydajnością serwera.

TfsConfig codeIndex /indexingStatus | /setIndexing:[on|off|keepupOnly] |
	/ignoreList:[ add | remove | removeAll | view ] <serverPath> |
	/listLargeFiles [/fileCount:FileCount] [/minSize:MinSize] |
	/reindexAll | 
    /destroyCodeIndex [/noPrompt] |
	/temporaryDataSizeLimit:[ view | <SizeInGBs> | disable ] |
	/indexHistoryPeriod:[ view | all | <NumberOfMonths> ] [/collectionName:<collectionName> | /collectionId:<collectionId>]
Opcja Opis
indexingStatus Pokaż stan i konfigurację usługi indeksowania kodu.
setIndexing on: Rozpocznij indeksowanie wszystkich zestawów zmian.
wyłączone: zatrzymaj indeksowanie wszystkich zestawów zmian.
keepupOnly: zatrzymaj indeksowanie wcześniej utworzonych zestawów zmian i zacznij indeksować tylko nowe zestawy zmian.
ignoreList Określa listę plików kodu i ich ścieżki, których nie chcesz indeksować.

add: Dodaj plik, który nie ma być indeksowany do listy ignorowanych plików.
remove: usuń plik, który ma zostać zaindeksowany z listy ignorowanych plików.
removeAll: wyczyść zignorowaną listę plików i rozpocznij indeksowanie wszystkich plików.
view: Zobacz wszystkie pliki, które nie są indeksowane.
ServerPath: określa ścieżkę do pliku kodu.

Symbol wieloznaczny (*) można użyć na początku, na końcu lub na obu końcach ścieżki serwera.
listLargeFiles Pokazuje określoną liczbę plików, które przekraczają określony rozmiar w KB. Następnie możesz użyć opcji /ignoreList , aby wykluczyć te pliki z indeksowania.

W tym celu będziesz potrzebować Team Foundation Server 2013 r. z aktualizacją Update 3.
reindexAll Wyczyść wcześniej indeksowane dane i ponownie uruchom indeksowanie.
destroyCodeIndex Usuń indeks kodu i usuń wszystkie indeksowane dane. Nie wymaga potwierdzenia, jeśli używasz /noPrompt opcji.
temporaryDataSizeLimit Kontrolowanie ilości danych tymczasowych tworzonych przez funkcję CodeLens podczas przetwarzania zestawów zmian. Domyślny limit to 6 GB (2 GB w aktualizacji Update 5).

view: Pokaż bieżący limit rozmiaru.
SizeInGBs: zmień limit rozmiaru.
wyłącz: usuń limit rozmiaru.

Ten limit jest sprawdzany, zanim funkcja CodeLens przetworzy nowy zestaw zmian. Jeśli dane tymczasowe przekraczają ten limit, funkcja CodeLens wstrzyma przetwarzanie przeszłych zmian, a nie nowych. Funkcja CodeLens ponownie uruchomi przetwarzanie po wyczyszczeniu danych i spadnie poniżej tego limitu. Oczyszczanie jest uruchamiane automatycznie raz dziennie. Oznacza to, że dane tymczasowe mogą przekroczyć ten limit do momentu uruchomienia oczyszczania.

W tym celu będziesz potrzebować Team Foundation Server 2013 r. z aktualizacją Update 4.
indexHistoryPeriod Określ, jak długo indeksować historię zmian. Ma to wpływ na to, ile historii pokazuje CodeLens. Domyślny limit to 12 miesięcy. Oznacza to, że funkcja CodeLens pokazuje historię zmian tylko z ostatnich 12 miesięcy.

view: Pokaż bieżącą liczbę miesięcy.
all: Indeksuj całą historię zmian.
NumberOfMonths: zmień liczbę miesięcy używanych do indeksowania historii zmian.

W tym celu będziesz potrzebować Team Foundation Server 2013 r. z aktualizacją Update 4.
Collectionname Określa nazwę kolekcji projektu, na której ma zostać uruchomione polecenie CodeIndex . Wymagane, jeśli nie używasz /CollectionId.
Collectionid Określa numer identyfikacyjny kolekcji projektu, na której ma zostać uruchomione polecenie CodeIndex . Wymagane, jeśli nie używasz /CollectionName

Wymagania wstępne

Aby użyć polecenia codeIndex, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps. Zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Przykłady

Aby wyświetlić stan indeksowania kodu i konfigurację:

TfsConfig codeIndex /indexingStatus /collectionName:"Fabrikam Web Site"

Aby rozpocząć indeksowanie wszystkich zestawów zmian:

TfsConfig codeIndex /setIndexing:on /collectionName:"Fabrikam Web Site"

Aby zatrzymać indeksowanie wcześniej utworzonych zestawów zmian i zacząć indeksować tylko nowe zestawy zmian:

TfsConfig codeIndex /setIndexing:keepupOnly /collectionName:"Fabrikam Web Site"

Aby znaleźć maksymalnie 50 plików, które są większe niż 10 KB:

TfsConfig codeIndex /listLargeFiles /fileCount:50 /minSize:10 /collectionName:"Fabrikam Web Site"

Aby wykluczyć określony plik z indeksowania i dodać go do listy ignorowanych plików:

TfsConfig codeIndex /ignoreList:add "$/Fabrikam Web Site/Catalog.cs" /collectionName:"Fabrikam Web Site"

Aby wyświetlić wszystkie pliki, które nie są indeksowane:

TfsConfig codeIndex /ignoreList:view

Aby wyczyścić wcześniej indeksowane dane i ponownie uruchomić indeksowanie:

TfsConfig codeIndex /reindexAll /collectionName:"Fabrikam Web Site"

Aby zapisać całą historię zestawu zmian:

TfsConfig codeIndex /indexHistoryPeriod:all /collectionName:"Fabrikam Web Site"

Aby usunąć limit rozmiaru danych tymczasowych CodeLens i kontynuować indeksowanie niezależnie od tymczasowego rozmiaru danych:

TfsConfig codeIndex /temporaryDataSizeLimit:disable /collectionName:"Fabrikam Web Site"

Aby usunąć indeks kodu z potwierdzeniem:

TfsConfig codeIndex /destroyCodeIndex /collectionName:"Fabrikam Web Site"

Dostępność poleceń: TFS 2015 i TFS 2013

Użyj polecenia CodeIndex, aby zarządzać indeksowaniem kodu w Azure DevOps Server. Możesz na przykład zresetować indeks, aby naprawić informacje CodeLens lub wyłączyć indeksowanie w celu zbadania problemów z wydajnością serwera.

TFSConfig CodeIndex /indexingStatus | /setIndexing:[ on | off | keepupOnly ] |
        /ignoreList:[ add | remove | removeAll | view ] ServerPath |
        /listLargeFiles [/fileCount:FileCount] [/minSize:MinSize] |
        /reindexAll | /destroyCodeIndex [/noPrompt] |
        /temporaryDataSizeLimit:[ view | <SizeInGBs> | disable ] |
        /indexHistoryPeriod:[ view | all | <NumberOfMonths> ] [/collectionName:CollectionName | /collectionId:CollectionId]

Opcja

Opis

/indexingStatus

Pokaż stan i konfigurację usługi indeksowania kodu.

/setIndexing:[ on | off | keepupOnly ]

  • on: Rozpocznij indeksowanie wszystkich zestawów zmian.
  • off: Zatrzymaj indeksowanie wszystkich zestawów zmian.
  • keepupOnly: Zatrzymaj indeksowanie wcześniej utworzonych zestawów zmian i zacznij indeksować tylko nowe zestawy zmian.

/ignoreList:[ add | remove | removeAll | view ] ServerPath

Określa listę plików kodu i ich ścieżki, których nie chcesz indeksować.

  • add: Dodaj plik, którego nie chcesz indeksować do listy ignorowanych plików.
  • remove: Usuń plik, który ma zostać indeksowany z listy zignorowanych plików.
  • removeAll: wyczyść zignorowaną listę plików i rozpocznij indeksowanie wszystkich plików.
  • view: Zobacz wszystkie pliki, które nie są indeksowane.
  • ServerPath: określa ścieżkę do pliku kodu.

Symbol wieloznaczny (*) można użyć na początku, na końcu lub na obu końcach ścieżki serwera.

/listLargeFiles/fileCount:FileCount/minSize:MinSize

Pokazuje określoną liczbę plików, które przekraczają określony rozmiar w KB. Następnie możesz użyć opcji /ignoreList , aby wykluczyć te pliki z indeksowania.
W przypadku tej opcji będziesz potrzebować Team Foundation Server 2013 z aktualizacją Update 3 lub nowszą wersją.

/reindexAll

Wyczyść wcześniej indeksowane dane i ponownie uruchom indeksowanie.

/destroyCodeIndex [/noPrompt]

Usuń indeks kodu i usuń wszystkie indeksowane dane. Nie wymaga potwierdzenia, jeśli używasz / noPrompt opcji.

/temporaryDataSizeLimit:[view | SizeInGBs | disable]

Kontrolowanie ilości danych tymczasowych tworzonych przez funkcję CodeLens podczas przetwarzania zestawów zmian. Domyślny limit to 6 GB (2 GB w aktualizacji Update 5).

  • view: Pokaż bieżący limit rozmiaru.
  • SizeInGBs: zmień limit rozmiaru.
  • wyłącz: usuń limit rozmiaru.

Ten limit jest sprawdzany, zanim funkcja CodeLens przetwarza nowy zestaw zmian. Jeśli dane tymczasowe przekraczają ten limit, funkcja CodeLens wstrzyma przetwarzanie przeszłych zmian, a nie nowych. Funkcja CodeLens ponownie uruchomi przetwarzanie po wyczyszczeniu danych i spadnie poniżej tego limitu. Oczyszczanie jest uruchamiane automatycznie raz dziennie. Oznacza to, że dane tymczasowe mogą przekroczyć ten limit do momentu uruchomienia oczyszczania.

W przypadku tej opcji będziesz potrzebować Team Foundation Server 2013 r. z aktualizacją Update 4 lub nowszą wersją.

/indexHistoryPeriod:[view | all | NumberOfMonths]

Określ, jak długo indeksować historię zmian. Ma to wpływ na to, ile pokazuje historia CodeLens. Domyślny limit wynosi 12 miesięcy. Oznacza to, że funkcja CodeLens pokazuje historię zmian tylko z ostatnich 12 miesięcy.

  • view: Pokaż bieżącą liczbę miesięcy.
  • all: Indeksuj całą historię zmian.
  • NumberOfMonths: zmień liczbę miesięcy używanych do indeksowania historii zmian.

W przypadku tej opcji będziesz potrzebować Team Foundation Server 2013 r. z aktualizacją Update 4 lub nowszą wersją.

/collectionName:CollectionName

Określa nazwę kolekcji projektu, na której ma zostać uruchomione polecenie CodeIndex . Wymagane, jeśli nie używasz /CollectionId.

/collectionId:CollectionId

Określa numer identyfikacyjny kolekcji projektu, na którym ma zostać uruchomione polecenie CodeIndex . Wymagane, jeśli nie używasz /CollectionName.

Wymagania wstępne

Aby użyć CodeIndex polecenia, musisz być członkiem grupy zabezpieczeń Administratorzy team Foundation. Zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Przykłady

Aby wyświetlić stan indeksowania kodu i konfigurację:

TFSConfig CodeIndex /indexingStatus /collectionName:"Fabrikam Web Site"

Aby rozpocząć indeksowanie wszystkich zestawów zmian:

TFSConfig CodeIndex /setIndexing:on /collectionName:"Fabrikam Web Site"

Aby zatrzymać indeksowanie wcześniej utworzonych zestawów zmian i zacząć indeksować tylko nowe zestawy zmian:

TFSConfig CodeIndex /setIndexing:keepupOnly /collectionName:"Fabrikam Web Site"

Aby znaleźć maksymalnie 50 plików, które są większe niż 10 KB:

TFSConfig CodeIndex /listLargeFiles /fileCount:50 /minSize:10 /collectionName:"Fabrikam Web Site"

Aby wykluczyć określony plik z indeksowania i dodać go do listy ignorowanych plików:

TFSConfig CodeIndex /ignoreList:add "$/Fabrikam Web Site/Catalog.cs" /collectionName:"Fabrikam Web Site"

Aby wyświetlić wszystkie pliki, które nie są indeksowane:

TFSConfig CodeIndex /ignoreList:view

Aby wyczyścić wcześniej indeksowane dane i ponownie uruchomić indeksowanie:

TFSConfig CodeIndex /reindexAll /collectionName:"Fabrikam Web Site"

Aby zapisać całą historię zestawu zmian:

TFSConfig CodeIndex /indexHistoryPeriod:all /collectionName:"Fabrikam Web Site"

Aby usunąć limit rozmiaru danych tymczasowych CodeLens i kontynuować indeksowanie niezależnie od tymczasowego rozmiaru danych:

TFSConfig CodeIndex /temporaryDataSizeLimit:disable /collectionName:"Fabrikam Web Site"

Aby usunąć indeks kodu z potwierdzeniem:

TFSConfig CodeIndex /destroyCodeIndex /collectionName:"Fabrikam Web Site"

Kolekcja

Możesz użyć polecenia kolekcji, aby dołączyć, odłączyć lub usunąć kolekcję projektu z wdrożenia Azure DevOps Server. Możesz również użyć polecenia kolekcji , aby zduplikować bazę danych istniejącej kolekcji, zmienić jej nazwę i dołączyć ją do wdrożenia. Ten proces jest czasami określany jako klonowanie kolekcji.

TfsConfig collection {/attach | /create | /detach | /delete} [/collectionName:<collectionName>]
    [/description:<collectionDescription>]
    [/collectionDB:<serverName>;<databaseName>]
    [/processModel:Inheritance|Xml]
    [/reportingFolder:<reportingFolderPath>]
    [/clone] [/verify] [/continue]
Opcja Opis
dołączać Wymagane, jeśli nie jest używany /detach ani /delete . Jeśli określisz tę opcję, musisz również użyć opcji /collectionDB . Jako opcję można również użyć /collectionName i /clone z tą opcją. Jeśli używasz opcji /attach, określona baza danych kolekcji zostanie dodana do wdrożenia Azure DevOps Server.
create Tworzy kolekcję.
Odłączyć Wymagane, jeśli nie jest używany /attach ani /delete . Jeśli określisz tę opcję, musisz również użyć opcji /collectionName . Jeśli używasz opcji /detach, baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie odłączona od wdrożenia Azure DevOps Server.
delete Wymagane, jeśli nie jest używany /detach ani /attach . Jeśli określisz tę opcję, musisz również użyć opcji /collectionName . Jeśli używasz opcji /delete, baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie trwale odłączona od Azure DevOps Server. Nie będzie można ponownie dołączyć bazy danych kolekcji do tego lub innego wdrożenia.
CollectionName Określa nazwę kolekcji projektów. Jeśli nazwa kolekcji zawiera spacje, należy ująć nazwę w cudzysłów (na przykład "Moja kolekcja"). Wymagane, jeśli jest używany /detach lub /delete . Jeśli używasz tej opcji z /detach lub /delete, określa kolekcję, która zostanie odłączona lub usunięta. Jeśli używasz tej opcji z /attach, określa nową nazwę kolekcji. Jeśli używasz tej opcji zarówno z /attach , jak i /clone, określa nazwę zduplikowanej kolekcji.
CollectionDB Wymagane, jeśli / attach jest używany. Ta opcja określa nazwę serwera, na którym działa SQL Server, oraz nazwę bazy danych kolekcji hostowanej na tym serwerze.
ServerName Określa nazwę serwera, który hostuje bazę danych konfiguracji dla Azure DevOps Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.
DatabaseName Określa nazwę bazy danych konfiguracji. Domyślnie nazwa tej bazy danych jest TFS_ConfigurationDB.
clone Jeśli określisz tę opcję, oryginalna baza danych kolekcji zostanie dołączona jako klon w SQL Server, a ta baza danych zostanie dołączona do Azure DevOps Server. Ta opcja jest używana głównie w ramach dzielenia kolekcji projektów.

Porada

Opcja /delete nie usunie bazy danych kolekcji z SQL Server. Po usunięciu bazy danych kolekcji z Azure DevOps Server można ręcznie usunąć bazę danych z SQL Server.

Wymagania wstępne

Aby użyć polecenia kolekcji , musisz być członkiem grupy zabezpieczeń Administratorzy team Foundation, a także lokalnej grupy Administratorzy na maszynie z uruchomioną programem TfsConfig. Musisz również być członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez bazy danych Azure DevOps Server. Jeśli wdrożenie jest zintegrowane z SharePoint i używasz /delete opcji, musisz być również członkiem grupy Administratorzy farmy dla farmy SharePoint farmy, z której usuwasz zbiór witryn.

Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Aby zarządzać kolekcjami interaktywnie lub utworzyć kolekcję, możesz użyć węzła Project Collections w konsoli administracyjnej Azure DevOps. Zobacz Zarządzanie kolekcjami projektów.

Przykłady

W poniższym przykładzie pokazano, jak trwale usunąć Contoso Summer Intern Projects kolekcję projektu z wdrożenia Azure DevOps Server.

TfsConfig collection /delete /CollectionName:"Contoso Summer Intern Projects"
TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
Deleting a project collection is an irreversible operation. A deleted collection cannot be reattached to the same or another Team Foundation Server. Are you sure you want to delete 'Contoso Summer Intern Projects'? (Yes/No)
Yes
Found Collection 'Contoso Summer Intern Projects' Deleting...
The delete of collection 'Contoso Summer Intern Projects' succeeded.

W poniższym przykładzie pokazano, jak zduplikować Contoso Summer Interns Projects kolekcję projektu, nadać jej Contoso Winter Interns Projectsnazwę i dołączyć zduplikowaną kolekcję do wdrożenia Azure DevOps Server.

TfsConfig collection /attach /collectiondb:"ContosoMain;TFS_Contoso Summer Interns Projects"
    /CollectionName:"Contoso Winter Intern Projects" /clone

Możesz użyć polecenia Kolekcja , aby dołączyć, odłączyć lub usunąć kolekcję projektu z wdrożenia serwera TFS. Możesz również użyć polecenia Kolekcja , aby zduplikować bazę danych istniejącej kolekcji, zmienić jej nazwę i dołączyć ją do wdrożenia. Ten proces jest czasami określany jako klonowanie kolekcji. Nie można jednak użyć polecenia Kolekcja do utworzenia kolekcji projektów.

TFSConfig Collection {/attach | /detach | /delete} [/collectionName:CollectionName]
        [/collectionDB:ServerName;DatabaseName] [/clone]

Parametry

Opcja

Opis

/attach

Wymagane, jeśli nie jest używany /detach ani /delete .

Jeśli określisz tę opcję, musisz również użyć opcji /collectionDB .

Jako opcję można również użyć /collectionName i /clone z tą opcją.

Jeśli używasz opcji /attach, określona baza danych kolekcji zostanie dodana do wdrożenia Azure DevOps Server.

/detach

Wymagane, jeśli nie jest używany /attach ani /delete .

Jeśli określisz tę opcję, musisz również użyć opcji /collectionName .

Jeśli używasz opcji /detach, baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie odłączona od wdrożenia Azure DevOps Server.

/delete

Wymagane, jeśli nie jest używany /detach ani /attach .

Jeśli określisz tę opcję, musisz również użyć opcji /collectionName .

Jeśli używasz opcji /delete, baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie trwale odłączona od Azure DevOps Server.

Nie będzie można ponownie dołączyć bazy danych kolekcji do tego lub innego wdrożenia.

Wskazówka: Opcja /delete nie usunie bazy danych kolekcji z SQL Server.

Po usunięciu bazy danych kolekcji z Azure DevOps Server można ręcznie usunąć bazę danych z SQL Server.

/CollectionName: Collectionname

Określa nazwę kolekcji projektów. Jeśli nazwa kolekcji zawiera spacje, należy ująć nazwę w cudzysłów (na przykład "Moja kolekcja").

Wymagane, jeśli jest używany /detach lub /delete .

Jeśli używasz tej opcji z /detach lub /delete, określa kolekcję, która zostanie odłączona lub usunięta.

Jeśli używasz tej opcji z /attach, określa nową nazwę kolekcji.

Jeśli używasz tej opcji zarówno z /attach , jak i /clone, określa nazwę zduplikowanej kolekcji.

/CollectionDB: ServerName;DatabaseName

Wymagane, jeśli / attach jest używany.

Ta opcja określa nazwę serwera, na którym działa SQL Server, oraz nazwę bazy danych kolekcji hostowanej na tym serwerze.

  • ServerName: określa nazwę serwera, który hostuje bazę danych konfiguracji dla Azure DevOps Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne.

Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.

  • DatabaseName: określa nazwę bazy danych konfiguracji. Domyślnie nazwa tej bazy danych jest TFS_ConfigurationDB.

/clone

Jeśli określisz tę opcję, oryginalna baza danych kolekcji zostanie dołączona jako klon w SQL Server, a ta baza danych zostanie dołączona do Azure DevOps Server. Ta opcja jest używana głównie w ramach dzielenia kolekcji projektów.

Wymagania wstępne

Aby użyć polecenia Kolekcje , musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation, a także lokalnej grupy Administratorzy na komputerze z uruchomionym programem TFSConfig. Musisz również być członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez bazy danych Azure DevOps Server. Jeśli wdrożenie jest zintegrowane z SharePoint i używasz /delete opcji, musisz być również członkiem grupy Administratorzy farmy dla farmy SharePoint farmy, z której usuwasz zbiór witryn.

Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Aby zarządzać kolekcjami interaktywnie lub utworzyć kolekcję, możesz użyć węzła Project Collections w konsoli administracyjnej Azure DevOps. Zobacz Zarządzanie kolekcjami projektów.

Przykłady

W poniższym przykładzie pokazano, jak trwale usunąć kolekcję projektu "Contoso Summer Intern Projects" z wdrożenia Azure DevOps Server.

TFSConfig Collection /delete /CollectionName:"Contoso Summer Intern Projects"


TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
Deleting a project collection is an irreversible operation. A deleted collection cannot be reattached to the same or another Team Foundation Server. Are you sure you want to delete 'Contoso Summer Intern Projects'? (Yes/No)
Yes
Found Collection 'Contoso Summer Intern Projects' Deleting...
The delete of collection 'Contoso Summer Intern Projects' succeeded.

W poniższym przykładzie pokazano, jak zduplikować kolekcję projektu "Contoso Summer Interns Projects", nadać jej nazwę "Contoso Winter Interns Projects" i dołączyć zduplikowaną kolekcję do wdrożenia Azure DevOps Server.

TFSConfig Collection /attach /collectiondb:"ContosoMain;TFS_Contoso Summer Interns Projects"
            /CollectionName:"Contoso Winter Intern Projects" /clone

ColumnStoreIndex

Uwaga

Dostępność poleceń: wymaga wersji TFS 2015.2 i nowszych.

Użyj polecenia columnStoreIndex, aby włączyć lub wyłączyć indeksy magazynu kolumn dla baz danych używanych przez wdrożenie Azure DevOps Server.

TfsConfig columnStoreIndex /enabled:<true|false>
	/sqlInstance:<serverName>
	/databaseName:<databaseName>
Opcja Opis
enabled Określa, czy włączasz lub wyłączasz indeks magazynu kolumn dla danego wystąpienia i bazy danych SQL.
sqlInstance Określa nazwę serwera, który hostuje bazę danych, dla której indeks magazynu kolumn jest włączony lub wyłączony, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.
Databasename Określa nazwę bazy danych, dla której indeks magazynu kolumn jest włączony lub wyłączony.

Wymagania wstępne

Aby użyć polecenia columnStoreIndex, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

Zazwyczaj należy użyć polecenia columnStoreIndex, jeśli przenosisz bazę danych z wystąpienia SQL, które obsługuje indeks magazynu kolumn do tego, który nie. W takim przypadku należy wyłączyć wszystkie indeksy magazynu kolumn, zanim będzie można pomyślnie przenieść bazy danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia SQL, które obsługuje indeks magazynu kolumn, możesz ponownie włączyć indeks magazynu kolumn, aby zaoszczędzić miejsce i uzyskać wydajność.

Przykład

W poniższym przykładzie pokazano, jak włączyć indeks magazynu kolumn dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases.

TfsConfig columnStoreIndex /enabled:true /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection

Użyj polecenia ColumnStoreIndex , aby włączyć lub wyłączyć indeksy magazynu kolumn dla baz danych używanych przez wdrożenie serwera TFS.

TfsConfig columnStoreIndex /enabled:{true|false}
        /sqlInstance:ServerName
        /databaseName:DatabaseName

Opcja

Opis

/enabled

Określa, czy włączasz lub wyłączasz indeks magazynu kolumn dla danego wystąpienia i bazy danych SQL.

/sqlInstance

Określa nazwę serwera, który hostuje bazę danych, dla której indeks magazynu kolumn jest włączony lub wyłączony, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne.

Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName

/databaseName

Określa nazwę bazy danych, dla której indeks magazynu kolumn jest włączony lub wyłączony.

Wymagania wstępne

Aby użyć polecenia ColumnStoreIndex, musisz być członkiem roli administratora systemu dla określonego wystąpienia SQL Server.

Uwagi

Zazwyczaj należy użyć polecenia ColumnStoreIndex, jeśli przenosisz bazę danych z wystąpienia SQL, które obsługuje indeks magazynu kolumn do takiego, który nie. W takim przypadku należy wyłączyć wszystkie indeksy magazynu kolumn, zanim będzie można pomyślnie przenieść bazy danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia SQL, które obsługuje indeks magazynu kolumn, możesz ponownie włączyć indeks magazynu kolumn, aby zaoszczędzić miejsce i uzyskać wydajność.

Przykład

W poniższym przykładzie pokazano, jak włączyć indeks magazynu kolumn dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie "ContosoMain" w nazwanym wystąpieniu "TeamDatabases".

TFSConfig columnStoreIndex /enabled:true /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection

Konfigurowanie poczty e-mail

Skonfiguruj serwer z systemem Azure DevOps Server, aby używać istniejącego serwera SMTP na potrzeby alertów poczty e-mail.

TfsConfig configureMail /Enabled:<true|false> /FromEmailAddress:<emailAddress> /SmtpHost:<SMTPHostName>
Opcja Opis
FromEmailAddress Określa adres, z którego mają być wysyłane powiadomienia e-mail z Azure DevOps Server na potrzeby zaewidencjonowania, elementu roboczego przypisanego do Ciebie lub innych powiadomień. Ten adres jest również sprawdzany pod kątem ważności, a w zależności od konfiguracji serwera może być konieczne reprezentowanie prawidłowego konta e-mail na serwerze poczty. Jeśli adres nie istnieje lub jest nieprawidłowy, zostanie użyty domyślny adres e-mail.
SmtpHost Określa nazwę serwera, który hostuje serwer poczty.

Wymagania wstępne

Aby użyć polecenia configureMail, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation na serwerze Azure DevOps warstwie aplikacji. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server

Uwagi

Konsolę administracyjną można również skonfigurować Azure DevOps Server do korzystania z serwera SMTP.

Przykład

W poniższym przykładzie przedstawiono składnię używaną do konfigurowania adresu e-mail z adresu e-mail i TFS@contoso.com serwera poczty SMTP jako ContosoMailServer:

TfsConfig configureMail /FromEmailAddress:TFS@contoso.com /SmtpHost:ContosoMailServer

DbCompression

Użyj polecenia dbCompression, aby włączyć lub wyłączyć kompresję strony bazy danych dla baz danych używanych przez wdrożenie Azure DevOps Server.

TfsConfig dbCompression /pageCompression:[enable|disable]
	/sqlInstance:<serverName>
	/databaseName:<databaseName>
	[/rebuildNow [/offline]]
Opcja Opis
pageCompression Określa, czy włączasz lub wyłączasz kompresję strony dla danego wystąpienia i bazy danych SQL.
sqlInstance Określa nazwę serwera, który hostuje bazę danych, dla której kompresja strony jest włączona lub wyłączona, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName
Databasename Określa nazwę bazy danych, dla której kompresja strony jest włączona lub wyłączona.
rebuildNow Opcjonalny. Określa, czy indeksy baz danych powinny zostać od razu skompilowane (i skompresowane lub zdekompresowane). Jeśli nie jest używany, indeksy zostaną ponownie skompilowane przez zadanie w tle, które jest uruchamiane co tydzień.
tryb offline Opcjonalny. Używane tylko w połączeniu z /rebuildNow. Jeśli /offline nie zostanie określony, indeksy zostaną ponownie skompilowane w trybie online. Jeśli określono /offline , indeksy zostaną ponownie skompilowane w trybie offline. Spowoduje to zablokowanie innych operacji, ale może być szybsze niż ponowne kompilowanie indeksu online.

Wymagania wstępne

Aby użyć polecenia dbCompression, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

Zazwyczaj należy użyć polecenia dbCompression, jeśli przenosisz bazę danych z wystąpienia SQL, które obsługiwało kompresję do tego, który nie. W takim przypadku należy wyłączyć kompresję i dekompresować wszystkie indeksy przed pomyślnym przeniesieniem baz danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia SQL, które obsługuje kompresję, możesz ponownie włączyć kompresję w celu zaoszczędzenia miejsca.

To polecenie zmienia tylko to, czy Azure DevOps Server woli korzystać z kompresji strony bazy danych, czy nie — bazy danych muszą być nadal hostowane w wystąpieniu SQL, którego wersja obsługuje kompresję. Aby uzyskać więcej informacji, zobacz Funkcje obsługiwane przez wersje SQL Server.

Przykład

W poniższym przykładzie pokazano, jak natychmiast włączyć kompresję strony z indeksami utworzonymi w trybie online dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases.

TfsConfig dbCompression /pageCompression:enable /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection /rebuildNow

W przypadku serwera TFS 2012 i starszych wersji zobacz https://support.microsoft.com/kb/2712111.

Użyj polecenia DBCompression, aby włączyć lub wyłączyć kompresję strony bazy danych dla baz danych używanych przez wdrożenie Azure DevOps Server.

TFSConfig dbCompression /pageCompression:{enable|disable}
        /sqlInstance:ServerName
        /databaseName:DatabaseName
        [/rebuildNow [/offline]]

Opcja

Opis

/pageCompression

Określa, czy włączasz lub wyłączasz kompresję strony dla danego wystąpienia i bazy danych SQL.

/sqlInstance

Określa nazwę serwera, który hostuje bazę danych, dla której kompresja strony jest włączona lub wyłączona, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne.

Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName

/databaseName

Określa nazwę bazy danych, dla której kompresja strony jest włączona lub wyłączona.

/rebuildNow

Opcjonalny. Określa, czy indeksy baz danych powinny zostać od razu skompilowane (i skompresowane lub zdekompresowane). Jeśli nie jest używany, indeksy zostaną ponownie skompilowane przez zadanie w tle, które jest uruchamiane co tydzień.

/offline

Opcjonalny. Używane tylko w połączeniu z /rebuildNow. Jeśli /offline nie zostanie określony, indeksy zostaną ponownie skompilowane w trybie online. Jeśli określono /offline , indeksy zostaną ponownie skompilowane w trybie offline. Spowoduje to zablokowanie innych operacji, ale może być szybsze niż ponowne kompilowanie indeksu online.

Wymagania wstępne

Aby użyć polecenia DBCompression, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

Zwykle należy użyć polecenia DBCompression, jeśli przenosisz bazę danych z wystąpienia SQL, które obsługiwało kompresję do tej, która nie była obsługiwana. W takim przypadku należy wyłączyć kompresję i dekompresować wszystkie indeksy, zanim będzie można pomyślnie przenieść bazy danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia SQL, które obsługuje kompresję, możesz ponownie włączyć kompresję w celu zaoszczędzenia miejsca.

To polecenie zmienia tylko to, czy Azure DevOps Server woli używać kompresji strony bazy danych, czy nie — bazy danych muszą być nadal hostowane w wystąpieniu SQL, którego wersja obsługuje kompresję. Aby uzyskać więcej informacji, zobacz Funkcje obsługiwane przez wersje SQL Server.

Przykład

W poniższym przykładzie pokazano, jak natychmiast włączyć kompresję strony z indeksami przebudowanymi w trybie online dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie "ContosoMain" w nazwanym wystąpieniu "TeamDatabases".

TFSConfig dbCompression /pageCompression:enable /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection /rebuildNow

DeleteTestResults

Użyj polecenia deleteTestResults , aby usunąć stare przechowywane wyniki testu z magazynu kolekcji. Zwykle odbywa się to w celu zmniejszenia rozmiaru magazynu lub skrócenia czasu podejmowanych podczas migrowania wyników testów do nowego schematu.

TfsConfig deleteTestResults /ageInDays:<number> /sqlInstance:<serverName> /databaseName:<databaseName>
    [/type:[automated|manual|all]]
    [/preview]
Opcja Opis
ageInDays Wyniki testów starsze niż określona liczba dni zostaną usunięte lub w wersji zapoznawczej.
sqlInstance Nazwa serwera, który hostuje bazę danych, dla której są usuwane lub wyświetlane wyniki testów, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.
Databasename Nazwa bazy danych, dla której wyniki testów są usuwane lub wyświetlane w podglądzie.
typ Opcjonalny. Typ wyników testu do usunięcia. Prawidłowe wartości są zautomatyzowane, ręczne i wszystkie.
preview Opcjonalny. Wyświetl liczbę wyników testów, które zostaną usunięte na podstawie wieku w dniach, ale nie usuwaj tych wyników.

Wymagania wstępne

Aby użyć polecenia deleteTestResults, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

Użyj /preview parametru, aby wyświetlić wyniki testów posortowane według nazwy projektu i roku bez usuwania tych wyników.

Przykład

W poniższym przykładzie pokazano, jak usunąć wyniki testów ręcznych starszych niż 60 dni dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases.

TfsConfig deleteTestResults /ageInDays:60 /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection /type:manual

Dostępność poleceń: TFS 2017 lub nowszy

Użyj polecenia DeleteTestResults , aby usunąć stare przechowywane wyniki testu z magazynu kolekcji. Zwykle odbywa się to w celu zmniejszenia rozmiaru magazynu lub skrócenia czasu podejmowanych podczas migrowania wyników testów do nowego schematu.

TFSConfig DeleteTestResults /ageInDays:{number} 
    /sqlInstance:ServerName
    /databaseName:DatabaseName
    [/type:{automated|manual|all}]
    [/preview]

Opcja

Opis

/ageInDays

Wyniki testów starsze niż określona liczba dni zostaną usunięte lub w wersji zapoznawczej.

/sqlInstance

Nazwa serwera, który hostuje bazę danych, dla której są usuwane lub wyświetlane wyniki testów, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne.

Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName

/databaseName

Nazwa bazy danych, dla której wyniki testów są usuwane lub wyświetlane w podglądzie.

/type

Opcjonalny. Typ wyników testu do usunięcia. Prawidłowe wartości są zautomatyzowane, ręczne i wszystkie.

/preview

Opcjonalny. Wyświetl liczbę wyników testów, które zostaną usunięte na podstawie wieku w dniach, ale nie usuwaj tych wyników.

Wymagania wstępne

Aby użyć polecenia DeleteTestResults, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

Użyj /preview parametru, aby wyświetlić wyniki testów posortowane według nazwy projektu i roku bez usuwania tych wyników.

Przykład

W poniższym przykładzie pokazano, jak usunąć wyniki testów ręcznych starszych niż 60 dni dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie "ContosoMain" w nazwanym wystąpieniu "TeamDatabases".

TFSConfig deleteTestResults /ageInDays:60 /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection /type:manual

Pula wdrożenia

Polecenie deploymentPool jest przeznaczone do migrowania wszystkich grup wdrożeń z jednej puli wdrożeń do innej.

TfsConfig deploymentpool /migrateDeploymentGroups /fromPool:<source pool name> /toPool:<destination pool name>
Opcja Opis
fromPool Nazwa puli źródłowej.
toPool Nazwa puli docelowej.

Tożsamości

Polecenie tożsamości wyświetla listę lub zmienia identyfikator zabezpieczeń (SID) użytkowników i grup we wdrożeniu Azure DevOps Server. Może być konieczne zmianę lub zaktualizowanie identyfikatora SID dla użytkowników i grup w jednym z następujących scenariuszy:

  • Zmienianie domeny wdrożenia

  • Zmiana z grupy roboczej na domenę lub z domeny na grupę roboczą

  • Migrowanie kont między domenami w usłudze Active Directory

Uwaga

Nie trzeba uruchamiać tego polecenia, jeśli zmieniasz domeny w tym samym lesie usługi Active Directory. Azure DevOps Server automatycznie obsłuży zmiany sid dla ruchów w tym samym lesie.

TfsConfig identities [/change /fromdomain:<domainName1> /todomain:<domainName2>
    [/account:<accountName> [/toaccount:<accountName>]] [/sqlInstance:<serverName> /databaseName:<databaseName>]
Opcja Opis
zmienianie Określa, że chcesz zmienić tożsamości zamiast ich wyświetlania.
fromdomain Wymagane w przypadku używania /change. Określa oryginalną domenę tożsamości, które chcesz zmienić. Jeśli zmieniasz się ze środowiska grupy roboczej, określa nazwę komputera.
todomena Wymagane w przypadku używania /change. Określa domenę, do której chcesz zmienić tożsamości. Jeśli zmieniasz środowisko grupy roboczej, określa nazwę komputera.
account Określa nazwę konta, dla którego chcesz wyświetlić listę lub zmienić tożsamości.
toaccount Określa nazwę konta, do którego chcesz zmienić tożsamości.
SqlInstance Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć następującego formatu:

Servername\instancename
DatabaseName Określa nazwę bazy danych konfiguracji dla Azure DevOps Server.

Wymagania wstępne

Aby użyć polecenia tożsamości, musisz być członkiem grupy zabezpieczeń Administratorzy team Foundation i członkiem roli administratora systemu dla wszystkich wystąpień SQL Server, które Team Foundation Server używa. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Opcjonalnie możesz określić bazę danych, aby zmienić tożsamości przed skonfigurowaniem serwera warstwy aplikacji na potrzeby wdrożenia. Na przykład można określić bazę danych, aby zmienić konto usługi podczas klonowania wdrożenia Azure DevOps Server.

W przypadku zmiany tożsamości konto docelowe lub konta muszą już istnieć w Windows.

Przed zaktualizowaniem właściwości kont, które zostaną zmienione za pomocą tego polecenia, należy poczekać na następną synchronizację tożsamości z Windows. To wymaganie obejmuje zmiany z grupy na użytkownika, użytkownika do grupy i konta domeny na konto lokalne.

Przykłady

W poniższym przykładzie pokazano, jak wyświetlić listę nazw wszystkich użytkowników i grup Windows przechowywanych w Azure DevOps Server oraz wyświetlać, czy identyfikator SID dla każdego użytkownika lub grupy jest zgodny z identyfikatorem SID w Windows. Administratorzy domeny Contoso1 utworzyli grupy domen, takie jak Contoso1\\Developers i Contoso1\\Testers ułatwiające zarządzanie uprawnieniami w ramach Azure DevOps Server, SQL Server Reporting Services i SharePoint Products.

TfsConfig identities

    TFSConfig - Team Foundation Server Configuration Tool
    Copyright � Microsoft Corporation. All rights reserved.

    Account Name Exists (see note 1) Matches (see note 2)
    --------------------------------------------------------------------
    CREATOR OWNER True True
    Contoso1\hholt True True
    BUILTIN\Administrators True True
    Contoso1\Developers True True
    Contoso1\Testers True True
    Contoso1\PMs True True
    Contoso1\jpeoples True True
    Contoso1\Domain Admins True True
    Contoso1\SVCACCT1 True True

    9 security identifiers (SIDs) were found stored in Team Foundation Server. Of these, 9 were found in Windows. 0 had differing SIDs.

W poniższym przykładzie pokazano, jak zmienić identyfikatory SID dla wszystkich kont w Azure DevOps Server z domeny Contoso1 na identyfikatory SID dla kont, które mają zgodne nazwy w domenieContosoPrime. Tylko nazwy kont, które są zgodne, będą miały zaktualizowane identyfikatory SID. Jeśli na przykład hholt konto istnieje jako Contoso1\hholt i ContosoPrime\hholt, identyfikator SID konta zostanie zmieniony na identyfikator SID dla .ContosoPrime\hholt ContosoPrime\hholt Jeśli konto nie istnieje, identyfikator SID nie zostanie zaktualizowany dla elementu Contoso1\hholt.

TfsConfig identities /change /fromdomain:Contoso1 /todomain:ContosoPrime

W poniższym przykładzie pokazano, jak zmienić konto dla pojedynczego konta użytkownika na Contoso1\hholtkonto innego użytkownika, ContosoPrime\jpeoples.

TfsConfig identities /change /fromdomain:Contoso1 /todomain:ContosoPrime /account:hholt /toaccount:jpeoples

W poniższym przykładzie pokazano, jak zmienić identyfikator SID NT AUTHORITY\NETWORK SERVICE konta usługi używanego we wdrożeniu Azure DevOps Server podczas zmiany domeny wdrożenia z Contoso1 na ContosoPrime. Aby zmienić konto systemowe, takie jak usługa sieciowa, należy wykonać proces dwuetapowy. Najpierw należy zmienić konto usługi z NT AUTHORITY\NETWORK SERVICE na konto domeny w nowej domenie TempSVC, a następnie zmienić konto z powrotem na USŁUGĘ SIECIową na serwerze w nowej domenie. Baza danych konfiguracji jest hostowana na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases w SQL Server.

TfsConfig identities /change /fromdomain:"NT AUTHORITY" /todomain:ContosoPrime /account:"NETWORK SERVICE"
  /toaccount:TempSVC /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB

TfsConfig identities /change /fromdomain:ContosoPrime /todomain:"NT AUTHORITY" /account:TempSVC
	/toaccount:"NETWORK SERVICE"

Polecenie Tożsamości wyświetla listę lub zmienia identyfikator zabezpieczeń (SID) użytkowników i grup we wdrożeniu serwera TFS. Może być konieczne zmianę lub zaktualizowanie identyfikatora SID dla użytkowników i grup w jednym z następujących scenariuszy:

  • zmiana domeny wdrożenia

  • zmiana z grupy roboczej na domenę lub z domeny na grupę roboczą

  • migrowanie kont między domenami w usłudze Active Directory

    Uwaga

    Nie trzeba uruchamiać tego polecenia, jeśli zmieniasz domeny w tym samym lesie usługi Active Directory. Azure DevOps Server automatycznie obsłuży zmiany sid dla ruchów w tym samym lesie.

    Tożsamości TFSConfig [/change /fromdomain:DomainName1 /todomain:DomainName2 [/account:AccountName] [/toaccount:AccountName]] [/sqlInstance:ServerName /databaseName:DatabaseName] [/account:AccountName] [/usesqlalwayson]

Opcja

Opis

/change

Określa, że chcesz zmienić tożsamości zamiast ich wyświetlania.

/fromdomain: Nazwa_domeny

Wymagane w przypadku używania /change. Określa oryginalną domenę tożsamości, które chcesz zmienić. Jeśli zmieniasz się ze środowiska grupy roboczej, określa nazwę komputera.

/todomain: Nazwa_domeny

Wymagane w przypadku używania /change. Określa domenę, do której chcesz zmienić tożsamości. Jeśli zmieniasz środowisko grupy roboczej, określa nazwę komputera.

/account: Accountname

Określa nazwę konta, dla którego chcesz wyświetlić listę lub zmienić tożsamości.

/toaccount: Accountname

Określa nazwę konta, do którego chcesz zmienić tożsamości.

/SQLInstance: Nazwa_serwera

Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć następującego formatu:

Servername\instancename

/DatabaseName: Databasename

Określa nazwę bazy danych konfiguracji dla Azure DevOps Server.

/usesqlalwayson

Określa, że bazy danych są częścią zawsze włączonej grupy dostępności w SQL Server. W przypadku skonfigurowania ta opcja ustawia wartość MultiSubnetFailover w parametrach połączenia.

Aby uzyskać więcej informacji, zobacz [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć polecenia Tożsamości, musisz być członkiem grupy zabezpieczeń Administratorzy team foundation i członkiem roli administratora systemu dla wszystkich wystąpień SQL Server używanych przez Azure DevOps Server. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Opcjonalnie możesz określić bazę danych, aby zmienić tożsamości przed skonfigurowaniem serwera warstwy aplikacji na potrzeby wdrożenia. Na przykład można określić bazę danych, aby zmienić konto usługi podczas klonowania wdrożenia Azure DevOps Server.

W przypadku zmiany tożsamości konto docelowe lub konta muszą już istnieć w Windows.

Przed zaktualizowaniem właściwości kont, które zostaną zmienione za pomocą tego polecenia, należy poczekać na następną synchronizację tożsamości z Windows. To wymaganie obejmuje zmiany z grupy na użytkownika, użytkownika do grupy i konta domeny na konto lokalne.

Przykłady

W poniższym przykładzie pokazano, jak wyświetlić listę nazw wszystkich użytkowników i grup Windows przechowywanych w Azure DevOps Server oraz wyświetlać, czy identyfikator SID dla każdego użytkownika lub grupy jest zgodny z identyfikatorem SID w Windows. Administratorzy domeny Contoso1 utworzyli grupy domen, takie jak "Contoso1\Developers" i "Contoso1\Testers", aby ułatwić zarządzanie uprawnieniami między Azure DevOps Server, SQL Server Reporting Services i produktami SharePoint.

TFSConfig Identities

Przykładowe dane wyjściowe:

TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.

Account Name Exists (see note 1) Matches (see note 2)
--------------------------------------------------------------------
CREATOR OWNER True True
Contoso1\hholt True True
BUILTIN\Administrators True True
Contoso1\Developers True True
Contoso1\Testers True True
Contoso1\PMs True True
Contoso1\jpeoples True True
Contoso1\Domain Admins True True
Contoso1\SVCACCT1 True True

9 security identifiers (SIDs) were found stored in Team Foundation Server. Of these, 9 were found in Windows. 0 had differing SIDs.

W poniższym przykładzie pokazano, jak zmienić identyfikatory SID dla wszystkich kont w Azure DevOps Server z domeny Contoso1 na identyfikatory SID dla kont, które mają pasujące nazwy w domenie ContosoPrime. Tylko nazwy kont, które są zgodne, będą miały zaktualizowane identyfikatory SID. Jeśli na przykład konto "hholt" istnieje jako Contoso1\hholt i ContosoPrime\hholt, identyfikator SID konta zostanie zmieniony na identyfikator SID dla contosoPrime\hholt. Jeśli konto "ContosoPrime\hholt" nie istnieje, identyfikator SID nie zostanie zaktualizowany dla domeny Contoso1\hholt.

TFSConfig Identities /change /fromdomain:Contoso1 /todomain:ContosoPrime

W poniższym przykładzie pokazano, jak zmienić konto dla pojedynczego konta użytkownika Contoso1\hholt na konto innego konta użytkownika ContosoPrime\jpeoples.

TFSConfig Identities /change /fromdomain:Contoso1 /todomain:ContosoPrime /account:hholt /toaccount:jpeoples

W poniższym przykładzie pokazano, jak zmienić identyfikator SID konta usługi "NT AUTHORITY\NETWORK SERVICE", które jest używane we wdrożeniu Azure DevOps Server podczas zmiany domeny wdrożenia z Contoso1 na ContosoPrime. Aby zmienić konto systemowe, takie jak usługa sieciowa, należy wykonać proces dwuetapowy. Najpierw należy zmienić konto usługi z NT AUTHORITY\NETWORK na konto domeny w nowej domenie (TempSVC), a następnie zmienić konto z powrotem na USŁUGĘ SIECIową na serwerze w nowej domenie. Baza danych konfiguracji jest hostowana na serwerze o nazwie "ContosoMain" w nazwanym wystąpieniu "TeamDatabases" w SQL Server.

TFSConfig Identities /change /fromdomain:"NT AUTHORITY" /todomain:ContosoPrime /account:"NETWORK SERVICE"
    /toaccount:TempSVC /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB
TFSConfig Identities /change /fromdomain:ContosoPrime /todomain:"NT AUTHORITY" /account:TempSVC
    /toaccount:"NETWORK SERVICE"

Stanowiska

Za pomocą polecenia zadania można utworzyć plik dziennika zawierający szczegółowe informacje o ostatnim działaniu zadania dla określonej kolekcji projektów lub ponowić próbę wykonania zadania dla jednej lub wszystkich kolekcji projektów.

TfsConfig jobs /retry|dumplog [/CollectionName:<collectionName>] [/CollectionId:<id>]
Opcja Opis
retry Wymagane, jeśli /dumplog nie jest używany. Określa, że najnowsze zadanie zostanie ponownie odcięte dla określonej kolekcji projektu. Jeśli używasz tej opcji, musisz również użyć /CollectionName lub /CollectionID opcji.
dumplog Wymagane, jeśli /retry nie jest używany. Określa, że ostatnie działanie zadania dla kolekcji zostanie wysłane do pliku dziennika. Jeśli używasz tej opcji, musisz również użyć opcji /CollectionName lub /CollectionID .
CollectionName Wymagane, jeśli /CollectionID nie jest używany. Określa nazwę kolekcji, dla której najnowsze zadanie zostanie ponowione (/ponowione) lub zarejestrowane (/dumplog). Jeśli chcesz określić wszystkie kolekcje, możesz użyć gwiazdki (*).
CollectionID Wymagane, jeśli /CollectionName nie jest używany. Określa numer identyfikacyjny kolekcji, dla której najnowsze zadanie zostanie ponowione (/ponowione) lub zarejestrowane (/dumplog).

Wymagania wstępne

Aby użyć polecenia zadania, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Aby wykonać zadanie interaktywnie, możesz otworzyć konsolę administracyjną dla Azure DevOps, wybrać kartę Stan dla kolekcji, a następnie wybrać pozycję Ponów próbę zadania. Aby uzyskać więcej informacji, zobacz Otwieranie konsoli administracyjnej Azure DevOps.

Przykład

W poniższym przykładzie pokazano, jak utworzyć plik dziennika zawierający listę najnowszych działań zadań dla Contoso Summer Intern Projects kolekcji projektów w Azure DevOps Server.

TfsConfig jobs /dumplog /CollectionName:"Contoso Summer Intern Projects"

Możesz użyć polecenia Zadania , aby utworzyć plik dziennika, który zawiera szczegóły najnowszego działania zadania dla określonej kolekcji projektów lub ponowić próbę wykonania zadania dla jednej lub wszystkich kolekcji projektów.

TFSConfig Jobs /retry|dumplog [/CollectionName:CollectionName] [/CollectionID:ID]

Opcja

Opis

/ponów próbę

Wymagane, jeśli /dumplog nie jest używany. Określa, że najnowsze zadanie zostanie ponownie odpięte dla określonej kolekcji projektów. Jeśli używasz tej opcji, musisz również użyć /CollectionName lub /CollectionID opcji.

/dumplog

Wymagane, jeśli /retry nie jest używane. Określa, że najnowsze działanie zadania dla kolekcji zostanie wysłane do pliku dziennika. Jeśli używasz tej opcji, musisz również użyć opcji /CollectionName lub /CollectionID .

/CollectionName: Collectionname

Wymagane, jeśli /CollectionID nie jest używany. Określa nazwę kolekcji, dla której najnowsze zadanie zostanie ponowione (/ponowione) lub zarejestrowane (/dumplog). Jeśli chcesz określić wszystkie kolekcje, możesz użyć gwiazdki (*).

/CollectionID: IDENTYFIKATOR

Wymagane, jeśli /CollectionName nie jest używany. Określa numer identyfikacyjny kolekcji, dla której najnowsze zadanie zostanie ponowione (/ponowione) lub zarejestrowane (/dumplog).

Wymagania wstępne

Aby użyć polecenia Zadania , musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Aby ponowić próbę zadania interaktywnie, możesz otworzyć konsolę administracyjną dla Azure DevOps, kliknij kartę Stan kolekcji, a następnie kliknij pozycję Ponów próbę zadania. Aby uzyskać więcej informacji, zobacz Otwieranie konsoli administracyjnej Azure DevOps.

Przykład

W poniższym przykładzie pokazano, jak utworzyć plik dziennika zawierający listę najnowszych działań związanych z zadaniem dla kolekcji projektów "Contoso Summer Intern Projects" w Azure DevOps Server.

TFSConfig Jobs /dumplog /CollectionName:"Contoso Summer Intern Projects"

Tryb offlineDetach

Użyj polecenia offlineDetach , aby utworzyć bazę danych kolekcji offline w odłączonej bazie danych kolekcji offline.

TfsConfig offlineDetach /configurationDB:<databaseName>
    /collectionDB:<databaseName>
Opcja Opis
configurationDB Określa nazwę bazy danych konfiguracji, która ma być używana.
collectionDB Określa nazwę bazy danych kolekcji do odłączenia.

Wymagania wstępne

Aby użyć polecenia offlineDetach, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

To polecenie modyfikuje schemat określonej bazy danych kolekcji i nigdy nie powinno być uruchamiane względem baz danych, które są używane przez wdrożenie Team Foundation Server. Jeśli bazy danych są używane przez wdrożenie Team Foundation Server, użyj TfsConfig collection /detach zamiast tego.

To polecenie jest przydatne, gdy trzeba przywrócić pojedynczą bazę danych kolekcji z kopii zapasowej bez przywracania innych baz danych kolekcji, które są częścią tego samego wdrożenia Azure DevOps Server. Wcześniej wymagane było przywrócenie kompletnego i spójnego zestawu baz danych (konfiguracji i wszystkich kolekcji) do środowiska przejściowego, skonfigurowania wdrożenia Azure DevOps Server przy użyciu tych baz danych i odłączenia jednej kolekcji zainteresowań.

Zamiast tego można teraz przywrócić spójne kopie bazy danych konfiguracji i bazy danych kolekcji zainteresowań i uruchomić polecenie offlineDetach . Odłączona baza danych kolekcji może być następnie dołączona do dowolnego wdrożenia Azure DevOps Server w odpowiedniej wersji.

Przykład

Poniższy przykład ilustruje odłączanie bazy danych kolekcji o nazwie TFS_PrimaryCollection, przy użyciu bazy danych konfiguracji o nazwie TFS_Configuration, z obu w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoTemp w nazwanym wystąpieniu Backups.

TfsConfig offlineDetach /configurationDB:ContosoTemp\Backups;TFS_Configuration /collectionDB:ContosoTemp\Backups;TFS_PrimaryCollection

Dostępność poleceń: TFS 2015 Update 3 i nowsze

Użyj polecenia OfflineDetach , aby utworzyć bazę danych kolekcji offline w odłączonej bazie danych kolekcji offline.

TFSConfig offlineDetach /configurationDB:DatabaseName
        /collectionDB:DatabaseName

Opcja

Opis

/configurationDB

Określa nazwę bazy danych konfiguracji, która ma być używana.

/collectionDB

Określa nazwę bazy danych kolekcji do odłączenia.

Wymagania wstępne

Aby użyć polecenia OfflineDetach, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.

Uwagi

To polecenie modyfikuje schemat określonej bazy danych kolekcji i nigdy nie powinno być uruchamiane względem baz danych, które są używane przez wdrożenie Azure DevOps Server. Jeśli bazy danych są używane przez wdrożenie Azure DevOps Server, użyj kolekcji TfsConfig /detach zamiast tego.

To polecenie jest przydatne, gdy trzeba przywrócić pojedynczą bazę danych kolekcji z kopii zapasowej bez przywracania innych baz danych kolekcji, które są częścią tego samego wdrożenia Azure DevOps Server. Wcześniej wymagane było przywrócenie kompletnego i spójnego zestawu baz danych (konfiguracji i wszystkich kolekcji) do środowiska przejściowego, skonfigurowania wdrożenia Azure DevOps Server przy użyciu tych baz danych i odłączenia jednej kolekcji zainteresowań.

Zamiast tego można teraz przywrócić spójne kopie bazy danych konfiguracji i bazy danych kolekcji zainteresowań i uruchomić polecenie OfflineDetach. Odłączona baza danych kolekcji może być następnie dołączona do dowolnego wdrożenia Azure DevOps Server w odpowiedniej wersji.

Przykład

W poniższym przykładzie pokazano odłączanie bazy danych kolekcji o nazwie TFS_PrimaryCollection przy użyciu bazy danych konfiguracji o nazwie TFS_Configuration z obu w wystąpieniu SQL uruchomionym na serwerze o nazwie "ContosoTemp" w nazwanym wystąpieniu "Kopie zapasowe".

TFSConfig offlineDetach /configurationDB:ContosoTemp\Backups;TFS_Configuration /collectionDB:ContosoTemp\Backups;TFS_PrimaryCollection

Serwer proxy

Możesz użyć polecenia serwera proxy, aby zaktualizować lub zmienić ustawienia używane przez serwer proxy Azure DevOps. serwer proxy Azure DevOps zapewnia obsługę rozproszonych zespołów do korzystania z kontroli wersji przez zarządzanie pamięcią podręczną pobranych plików kontroli wersji w lokalizacji rozproszonego zespołu. Konfigurując serwer proxy Azure DevOps, można znacznie zmniejszyć przepustowość wymaganą przez połączenia rozległe. Ponadto nie trzeba zarządzać pobieraniem i buforowaniem plików wersji; zarządzanie plikami jest niewidoczne dla dewelopera, który korzysta z plików. W międzyczasie wszystkie wymiany metadanych i przekazywanie plików będą nadal wyświetlane w Azure DevOps Server. Jeśli używasz Azure DevOps Services do hostowania projektu programistycznego w chmurze, możesz użyć polecenia proxy, aby nie tylko zarządzać pamięcią podręczną projektów w hostowanej kolekcji, ale także zarządzać niektórymi ustawieniami używanymi przez usługę.

Aby uzyskać więcej informacji na temat instalowania serwera proxy Azure DevOps i początkowej konfiguracji serwera proxy,

Zobacz Instrukcje: instalowanie serwera proxy Azure DevOps i konfigurowanie lokacji zdalnej. Aby uzyskać więcej informacji na temat konfigurowania serwera proxy na komputerach klienckich, zobacz Azure DevOps Dokumentacja poleceń kontroli wersji.

TfsConfig proxy /add|delete|change [/Collection:<teamProjectCollectionURL> /account:<accountName>]
	/Server:<TeamFoundationServerURL> [/inputs:Key1=Value1; Key2=Value2;...] [/continue]
Opcja Opis
add Dodaje określony serwer lub kolekcję do listy serwerów proxy w pliku Proxy.config. Możesz uruchomić /add wiele razy, aby uwzględnić więcej kolekcji lub serwerów. W przypadku używania /add z kolekcją hostowaną na Azure DevOps Services zostanie wyświetlony monit o podanie poświadczeń w Azure DevOps Services.
zmienianie Zmienia poświadczenia przechowywane jako konto usługi dla Azure DevOps Services. /change opcja jest używana tylko dla Azure DevOps Services; nie powinna być używana do lokalnych wdrożeń Azure DevOps Server.
delete Usuwa określony serwer lub kolekcję z listy serwerów proxy w pliku Proxy.config.
account Określa konto używane jako konto usługi dla serwera proxy w Azure DevOps Services. Ta opcja jest używana tylko dla Azure DevOps Services w połączeniu z /change opcji.

Domyślne konto usługi używane dla Azure DevOps Services to "Usługa konta".
continue Kontynuuje wykonywanie polecenia, nawet jeśli proces weryfikacji generuje ostrzeżenia.
Kolekcja Określa adres URL kolekcji projektów hostowanej na Azure DevOps Services w AccountName.DomainName/CollectionName formacie.
account Określa nazwę konta, które jest używane jako konto usługi dla Azure DevOps Services. Jeśli nazwa konta ma spacje, nazwa musi być ujęta w cudzysłów (""). Wszystkie znaki specjalne w nazwach kont muszą być określone zgodnie ze składnią wiersza polecenia.
account Określa adres URL wdrożenia Azure DevOps Server w ServerURL:Port/tfs formacie.
PersonalAccessTokenFile Opcjonalnie określa ścieżkę do pliku zawierającego osobisty token dostępu. Ten token będzie używany do uwierzytelniania w kolekcji lub koncie podczas rejestrowania serwera proxy. (Dodano w programie TFS 2018 Update 1)
Wejścia Opcjonalny. Określa dodatkowe ustawienia i wartości do użycia podczas konfigurowania serwera proxy.!
Na przykład wartości i GvfsProjectNameGvfsRepositoryName mogą służyć do konfigurowania repozytorium Git do użycia z wirtualnym systemem plików Git (GVFS) (dodane w programie TFS 2018 Update 1)

Wymagania wstępne

Aby użyć serwera proxy polecenia, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps i administratorem na serwerze proxy. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Polecenie serwera proxy służy do aktualizowania istniejącej konfiguracji serwera proxy Azure DevOps Server. Nie można użyć polecenia serwera proxy do początkowej instalacji i konfiguracji serwera proxy.

Przykłady

W poniższym przykładzie pokazano, jak dodać wdrożenie Azure DevOps Server o nazwie FABRIKAM do listy serwerów proxy.

TfsConfig proxy /add /Server:http://www.fabrikam.com:8080/tfs 

W poniższym przykładzie pokazano, jak dodać kolekcję projektów hostowaną na Azure DevOps Services do listy serwerów proxy przy użyciu osobistego tokenu dostępu do uwierzytelniania. Ten token będzie używany tylko do rejestrowania serwera proxy przy użyciu konta Azure DevOps Services — domyślne konto usługi będzie nadal używane do uruchamiania serwera proxy. Ten parametr został dodany w programie TFS 2018 Update 1 w celu obsługi rejestrowania serwera proxy przy użyciu Azure DevOps Services bez konieczności monitu logowania.

TfsConfig proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver

W poniższym przykładzie pokazano, jak dodać kolekcję projektów do listy serwerów proxy. W tym przykładzie użyto osobistego tokenu dostępu do uwierzytelniania w kolekcji określonej za pomocą parametru /Collection . Osobisty token dostępu do użycia jest zapisywany w pliku pod adresem c:\PersonalAccessToken.txt.

TfsConfig proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
	/PersonalAccessTokenFile:c:\PersonalAccessToken.txt

W poniższym przykładzie pokazano, jak zmienić konto usługi używane przez serwer proxy dla kolekcji projektów hostowanej na Azure DevOps Services. Kolekcja nosi nazwę PhoneSaver, nazwa konta używana dla Azure DevOps Services to HelenaPetersen.fabrikam.com, a konto usługi używane przez serwer proxy jest zmieniane na My Proxy Service Account. Ponieważ nazwa konta zawiera spacje, znaki cudzysłowu są używane do uwzględnienia nazwy.

TfsConfig proxy /change /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
	/account:"My Proxy Service Account"

W poniższym przykładzie pokazano, jak dodać repozytorium Git do użycia z systemem GVFS.

TfsConfig proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver /inputs:GvfsProjectName=PhoneSaver;GvfsRepositoryName=AnotherRepository

Możesz użyć serwera proxy TFSConfig, aby zaktualizować lub zmienić ustawienia używane przez serwer proxy Team Foundation Server. serwer proxy Team Foundation Server zapewnia obsługę rozproszonych zespołów w celu korzystania z kontroli wersji przez zarządzanie pamięcią podręczną pobranych plików kontroli wersji w lokalizacji rozproszonego zespołu. Konfigurując serwer proxy Team Foundation Server, można znacznie zmniejszyć przepustowość wymaganą w przypadku połączeń na całym obszarze. Ponadto nie trzeba zarządzać pobieraniem i buforowaniem plików wersji; zarządzanie plikami jest niewidoczne dla dewelopera, który korzysta z plików. W międzyczasie wszelkie wymiany metadanych i przekazywania plików nadal pojawiają się w Azure DevOps Server. Jeśli używasz Azure DevOps Services do hostowania projektu programistycznego w chmurze, możesz użyć polecenia proxy, aby nie tylko zarządzać pamięcią podręczną dla projektów w kolekcji hostowanej, ale także zarządzać niektórymi ustawieniami używanymi przez usługę.

Aby uzyskać więcej informacji na temat instalowania serwera proxy Azure DevOps i początkowej konfiguracji serwera proxy,

Zobacz Instrukcje: instalowanie serwera proxy Azure DevOps i konfigurowanie lokacji zdalnej. Aby uzyskać więcej informacji na temat konfigurowania serwera proxy na komputerach klienckich, zobacz Kontrola wersji serwera Team Foundation Dokumentacja poleceń.

TFSConfig Proxy /add|delete|change [/Collection:TeamProjectCollectionURL /account:AccountName]
            /Server:TeamFoundationServerURL [/inputs:Key1=Value1; Key2=Value2;...] [/Continue]

Opcja

Opis

/add

Dodaje określony serwer lub kolekcję do listy serwerów proxy w pliku Proxy.config.

Można uruchomić /dodać wiele razy, aby uwzględnić więcej kolekcji lub serwerów.

W przypadku używania /add z kolekcją hostowaną na Azure DevOps Services zostanie wyświetlony monit o podanie poświadczeń w Azure DevOps Services.

/change

Zmienia poświadczenia przechowywane jako konto usługi dla Azure DevOps Services.

/change opcja jest używana tylko dla Azure DevOps Services; nie należy jej używać do lokalnych wdrożeń Azure DevOps Server.

/delete

Usuwa określony serwer lub kolekcję z listy serwerów proxy w pliku Proxy.config.

/account

Określa konto używane jako konto usługi dla serwera proxy w Azure DevOps Services.

Ta opcja jest używana tylko dla Azure DevOps Services w połączeniu z /change opcji.

Domyślne konto usługi używane na potrzeby Azure DevOps Services to "Usługa konta".

/continue

Kontynuuje wykonywanie polecenia, nawet jeśli proces weryfikacji generuje ostrzeżenia.

/Collection:TeamProjectCollectionURL

Określa adres URL kolekcji projektów hostowanej na Azure DevOps Services w AccountName.DomainName/CollectionName formacie .

/account:AccountName

Określa nazwę konta, które jest używane jako konto usługi dla Azure DevOps Services.

Jeśli nazwa konta ma spacje, nazwa musi być ujęta w znaki cudzysłowu ("").

Wszystkie znaki specjalne w nazwach kont muszą być określone zgodnie ze składnią wiersza polecenia.

/account:ServerURL

Określa adres URL wdrożenia Azure DevOps Server w ServerURL:Port/tfs formacie.

/PersonalAccessTokenFile:P athToFileWithPAT

Opcjonalnie określa ścieżkę do pliku zawierającego osobisty token dostępu. Ten token będzie używany do uwierzytelniania w kolekcji lub koncie podczas rejestrowania serwera proxy. (Dodano w programie TFS 2018 Update 1)

/inputs:Key1=Value1; Key2=Value2;...

Opcjonalny. Określa dodatkowe ustawienia i wartości do użycia podczas konfigurowania serwera proxy.

Na przykład wartości "GvfsProjectName" i "GvfsRepositoryName" mogą służyć do konfigurowania repozytorium Git do użycia z wirtualnym systemem plików Git (GVFS) (dodano w programie TFS 2018 Update 1)

Wymagania wstępne

Aby użyć serwera proxy polecenia, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i administratorem na serwerze proxy. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Użyj polecenia Proxy, aby zaktualizować istniejącą konfigurację serwera proxy Azure DevOps. Nie można użyć serwera proxy polecenia do początkowej instalacji i konfiguracji serwera proxy.

Przykłady

W poniższym przykładzie pokazano, jak dodać wdrożenie Azure DevOps Server o nazwie FABRIKAM do listy serwerów proxy.

TFSConfig Proxy /add /Server:http://www.fabrikam.com:8080/tfs 

W poniższym przykładzie pokazano, jak dodać kolekcję projektów hostowaną na Azure DevOps Services do listy serwerów proxy przy użyciu osobistego tokenu dostępu do uwierzytelniania. Ten token będzie używany tylko do rejestrowania serwera proxy przy użyciu konta Azure DevOps Services — domyślne konto usługi będzie nadal używane do uruchamiania serwera proxy. Ten parametr został dodany w programie TFS 2018 Update 1 w celu obsługi rejestrowania serwera proxy przy użyciu Azure DevOps Services bez konieczności monitu logowania.

TFSConfig Proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver 

W poniższym przykładzie pokazano, jak dodać kolekcję projektów do listy serwerów proxy. W tym przykładzie użyto osobistego tokenu dostępu do uwierzytelniania w kolekcji określonej za pomocą parametru "/Collection". Osobisty token dostępu do użycia jest zapisywany w pliku w lokalizacji "c:\PersonalAccessToken.txt"

TFSConfig Proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
            /PersonalAccessTokenFile:c:\PersonalAccessToken.txt

The following example shows how to change the service account used by the proxy for the project collection hosted on Azure DevOps Services. The collection is named PhoneSaver, the account name used for Azure DevOps Services is HelenaPetersen.fabrikam.com, and the service account used by the proxy is being changed to "My Proxy Service Account". Because the account name contains spaces, quotation marks are used to enclose the name.

```console
TFSConfig Proxy /change /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
            /account:"My Proxy Service Account"

W poniższym przykładzie pokazano, jak dodać repozytorium Git do użycia z systemem GVFS.

TFSConfig Proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver /inputs:GvfsProjectName=PhoneSaver;GvfsRepositoryName=AnotherRepository

RebuildWarehouse

Możesz użyć polecenia rebuildWarehouse, aby ponownie skompilować bazy danych SQL Server Reporting Services i SQL Server Analysis Services używane przez Azure DevOps Server.

TfsConfig rebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]
Opcja Opis
analysisServices Wymagane, jeśli /all nie jest używany. Określa, że tylko baza danych dla usług Analysis Services zostanie ponownie skompilowana. Jeśli dla usług Analysis Services nie istnieje żadna baza danych, należy również użyć opcji /reportingDataSourcePassword .
all Wymagane, jeśli /analysisServices nie jest używany. Określa, że wszystkie bazy danych raportowania i analizy, które Azure DevOps Server używane zostaną ponownie skompilowane.
reportingDataSourcePassword Wymagane, jeśli baza danych TFS_Analysis nie istnieje. Określa hasło konta, które jest używane jako konto źródeł danych dla SQL Server Reporting Services (TFSReports). Aby uzyskać więcej informacji, zobacz Konta usług i zależności w Azure DevOps Server.

Wymagania wstępne

Aby użyć polecenia rebuildWarehouse , musisz być członkiem następujących grup:

  • Grupa zabezpieczeń administratorzy Azure DevOps i grupa zabezpieczeń Administratorzy na serwerze lub serwerach z uruchomioną konsolą administracyjną dla Azure DevOps

  • Grupa sysadmin na serwerze lub serwerach z uruchomionym wystąpieniem SQL Server hostujących bazy danych dla Azure DevOps Server

Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

To polecenie może być używane podczas przenoszenia lub dzielenia kolekcji projektu, przywracania danych lub zmiany konfiguracji wdrożenia.

Aby uruchomić ponowne kompilowanie tych baz danych interaktywnie, możesz użyć węzła Raportowanie w konsoli administracyjnej dla Azure DevOps. Aby uzyskać więcej informacji, zobacz Otwieranie konsoli administracyjnej Azure DevOps.

Przykład

W poniższym przykładzie pokazano, jak ponownie skompilować bazę danych usług Analysis Services na potrzeby wdrożenia Azure DevOps Server.

TfsConfig rebuildWarehouse /analysisServices

    TFSConfig - Team Foundation Server Configuration Tool
    Copyright � Microsoft Corporation. All rights reserved.
    The Analysis Services database was successfully rebuilt.

Za pomocą polecenia RebuildWarehouse można ponownie skompilować bazy danych SQL Server Reporting Services i SQL Server Analysis Services używane przez Visual Studio Team Foundation Server (TFS).

TFSConfig RebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]

Opcja

Opis

/analysisServices

Wymagane, jeśli /all nie jest używany.

Określa, że tylko baza danych dla usług Analysis Services zostanie ponownie skompilowana.

Jeśli dla usług Analysis Services nie istnieje żadna baza danych, należy również użyć opcji /reportingDataSourcePassword .

/all

Wymagane, jeśli /analysisServices nie jest używany.

Określa, że wszystkie bazy danych raportowania i analizy używane przez Azure DevOps Server zostaną przebudowane.

/reportingDataSourcePassword: Hasło

Wymagane, jeśli baza danych TFS_Analysis nie istnieje.

Określa hasło konta używanego jako konto źródeł danych dla SQL Server Reporting Services (TFSReports).

Aby uzyskać więcej informacji, zobacz Konta usług i zależności w Azure DevOps Server.

Wymagania wstępne

Aby użyć polecenia RebuildWarehouse , musisz być członkiem następujących grup:

  • grupa zabezpieczeń Administratorzy programu Team Foundation i grupa zabezpieczeń Administratorzy na serwerze lub serwerach z uruchomioną konsolą administracyjną dla Azure DevOps

  • grupa sysadmin na serwerze lub serwerach z uruchomionym wystąpieniem SQL Server hostujących bazy danych dla Azure DevOps Server

Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

To polecenie może być używane podczas przenoszenia lub dzielenia kolekcji projektu, przywracania danych lub zmiany konfiguracji wdrożenia.

Aby uruchomić ponowne kompilowanie tych baz danych interaktywnie, możesz użyć węzła Raportowanie w konsoli administracyjnej dla Azure DevOps. Aby uzyskać więcej informacji, zobacz Otwieranie konsoli> administracyjnej Azure DevOps.

Przykład

W poniższym przykładzie pokazano, jak ponownie skompilować bazę danych usług Analysis Services na potrzeby wdrożenia Azure DevOps Server.

TFSConfig RebuildWarehouse /analysisServices

TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
The Analysis Services database was successfully rebuilt.

Rejestrowanie bazy danychDB

Użyj bazy danych registerDB, aby zaktualizować nazwę serwera, który hostuje bazę danych konfiguracji w Azure DevOps Server. To polecenie można użyć podczas przywracania bazy danych konfiguracji do nowego sprzętu lub zmiany domeny wdrożenia.

TfsConfig registerDB /sqlInstance:<serverName> /databaseName:<databaseName>
Opcja Opis
SQLInstance Wymagane. Określa nazwę serwera z uruchomionym SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.
Databasename Wymagane. Określa nazwę bazy danych konfiguracji. Domyślnie jest to Tfs_Configuration.

Wymagania wstępne

Aby użyć polecenia registerDB, musisz być członkiem grupy administratorów Azure DevOps na serwerze warstwy aplikacji dla Azure DevOps i członkiem grupy sysadmin w SQL Server na serwerze warstwy danych dla Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Przed użyciem tego polecenia należy utworzyć kopię zapasową baz danych dla Azure DevOps Server.

Aby polecenie registerDB powiodło się, należy uruchomić następujące pule aplikacji i programy:

  • Azure DevOps Server pula aplikacji (pula aplikacji)
  • ReportServer (pula aplikacji)
  • SQL Server Reporting Services (program)

Aby to polecenie działało poprawnie, należy podać dokładną nazwę lub adres bazy danych konfiguracji. Jeśli musisz zmienić serwer, na którym jest przechowywana ta baza danych, musisz upewnić się, że Azure DevOps Server wskazuje nową lokalizację.

Przykład

Poniższy przykład przekierowuje Azure DevOps Server do bazy danych konfiguracji znajdującej się na serwerze ContosoMain w wystąpieniu TeamDatabasesSQL Server .

TfsConfig registerDB /SQLInstance:ContosoMain\TeamDatabases /databaseName:Tfs_Configuration

Użyj usługi RegisterDB, aby zaktualizować nazwę serwera, który hostuje bazę danych konfiguracji w Visual Studio Team Foundation Server (TFS). To polecenie można użyć podczas przywracania bazy danych konfiguracji do nowego sprzętu lub zmiany domeny wdrożenia.

TFSConfig RegisterDB /SQLInstance:ServerName /databaseName: DatabaseName [/usesqlalwayson]

Argument

Opis

/SQLInstance: Nazwa_serwera

Wymagane. Określa nazwę serwera z uruchomionym SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne.

Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName.

/databaseName: Databasename

Wymagane. Określa nazwę bazy danych konfiguracji. Domyślnie jest to Tfs_Configuration.

/usesqlalwayson

Opcjonalny. Określa, że bazy danych są częścią zawsze włączonej grupy dostępności w SQL Server.

W przypadku skonfigurowania ta opcja ustawia wartość MultiSubnetFailover w parametrach połączenia.

Aby uzyskać więcej informacji, zobacz [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć polecenia RegisterDB, musisz być członkiem grupy Administratorzy team Foundation na serwerze warstwy aplikacji dla Azure DevOps i członkiem grupy sysadmin w SQL Server na serwerze warstwy danych dla Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Przed użyciem tego polecenia należy utworzyć kopię zapasową baz danych dla Azure DevOps Server.

Aby polecenie RegisterDB powiodło się, należy uruchomić następujące pule aplikacji i programy:

  • Azure DevOps Server pula aplikacji (pula aplikacji)
  • ReportServer (pula aplikacji)
  • SQL Server Reporting Services (program)

Aby to polecenie działało poprawnie, należy podać dokładną nazwę lub adres bazy danych konfiguracji. Jeśli musisz zmienić serwer, na którym jest przechowywana ta baza danych, musisz upewnić się, że Azure DevOps Server wskazuje nową lokalizację.

Przykład

Poniższy przykład przekierowuje Azure DevOps Server do bazy danych konfiguracji znajdującej się na serwerze ContosoMain w wystąpieniu SQL Server TeamDatabases.

TFSConfig RegisterDB /SQLInstance:ContosoMain\TeamDatabases /databaseName:Tfs_Configuration

Ponowne mapowanie baz danych

Polecenie remapDBs przekierowuje Azure DevOps Server do jego baz danych, gdy są one przechowywane na więcej niż jednym serwerze i przywracasz, przenosisz lub w inny sposób zmieniasz konfigurację wdrożenia. Na przykład należy przekierować Azure DevOps Server do dowolnych baz danych kolekcji projektów, jeśli są one hostowane na oddzielnym serwerze lub serwerach z bazy danych konfiguracji. Należy również przekierować Azure DevOps Server do serwera lub serwerów z systemem SQL Server Analysis Services lub SQL Server Reporting Services, jeśli te bazy danych są hostowane na oddzielnym serwerze lub wystąpieniu z bazy danych konfiguracji.

TfsConfig remapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,ServerName2
	[/AnalysisInstance:<serverName>] [/AnalysisDatabaseName:<databaseName>]
	[/preview] [/continue]
Opcja Opis
DatabaseName Określa nazwę serwera, który hostuje bazę danych, którą chcesz mapować dla Azure DevOps Server, oprócz nazwy samej bazy danych.
SqlInstances Określa nazwę serwera, na którym działa SQL Server, oprócz nazwy wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne.

Jeśli określasz więcej niż jeden serwer, musisz użyć przecinka, aby oddzielić wiele par nazw serwerów i wystąpień.
AnalysisInstance Opcjonalny. Określa nazwę serwera i wystąpienia, które hostuje SQL Server Analysis Services. Użyj tej opcji, aby określić serwer i wystąpienie hostujące bazę danych usług Analysis Services.
AnalysisDatabaseName Opcjonalny. Określa nazwę bazy danych usług Analysis Services, której chcesz użyć z Azure DevOps Server, jeśli masz więcej niż jedną taką bazę danych na serwerze określonym z opcją /AnalysisInstance.
preview Opcjonalny. Wyświetla akcje, które należy wykonać, aby zaktualizować konfigurację.
continue Opcjonalny. Określa, że polecenie RemapDB powinno być kontynuowane, nawet jeśli podczas próby zlokalizowania co najmniej jednej bazy danych wystąpi błąd. Jeśli używasz /continue opcji, wszystkie kolekcje, których bazy danych nie znajdują się na serwerze lub serwerach, które określisz, zostaną ponownie skonfigurowane do korzystania z serwera i wystąpienia, które hostuje bazę danych konfiguracji.

Wymagania wstępne

Aby użyć polecenia remapDBs, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps i członkiem grupy zabezpieczeń sysadmin dla wszystkich SQL Server baz danych, które Azure DevOps Server używać. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Użyj polecenia remapDBs, aby ponownie skonfigurować Azure DevOps Server do używania różnych serwerów i wystąpień SQL Server z serwerów i wystąpień w oryginalnej instalacji.

Przykład

W poniższym przykładzie pokazano, jak przekierować Azure DevOps Server do bazy danych TFS_Configurationkonfiguracji . Ta baza danych jest hostowana w ContosoMain nazwanym wystąpieniu TeamDatabases. Bazy danych kolekcji projektów są przechowywane zarówno ContosoMain\TeamDatabases w wystąpieniu domyślnym, jak i w systemie Contoso2.

TfsConfig remapDBs /DatabaseName:ContosoMain\TeamDatabases;TFS_Configuration
	/SQLInstances:ContosoMain\TeamDatabases,Contoso2

Polecenie RemapDBs przekierowuje Azure DevOps Server do jego baz danych, gdy są one przechowywane na więcej niż jednym serwerze i przywracasz, przenosisz lub w inny sposób zmieniasz konfigurację wdrożenia. Na przykład należy przekierować serwer TFS do dowolnych baz danych kolekcji projektów, jeśli są one hostowane na osobnym serwerze lub serwerach z bazy danych konfiguracji. Należy również przekierować serwer TFS do serwera lub serwerów z systemem SQL Server Analysis Services lub SQL Server Reporting Services, jeśli te bazy danych są hostowane na oddzielnym serwerze lub wystąpieniu z bazy danych konfiguracji.

TFSConfig RemapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,ServerName2
        [/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName]
        [/preview] [/continue] [/usesqlalwayson]

Opcja

Opis

/DatabaseName

Określa nazwę serwera, który hostuje bazę danych, którą chcesz mapować dla Azure DevOps Server, oprócz nazwy samej bazy danych.

/SQLInstances: ServerName1,ServerName2

Określa nazwę serwera, na którym działa SQL Server, oprócz nazwy wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne.

Jeśli określasz więcej niż jeden serwer, musisz użyć przecinka, aby oddzielić wiele par nazw serwerów i wystąpień.

/AnalysisInstance: Nazwa_serwera

Opcjonalny. Określa nazwę serwera i wystąpienia, które hostuje SQL Server Analysis Services.

Użyj tej opcji, aby określić serwer i wystąpienie hostujące bazę danych usług Analysis Services.

/AnalysisDatabaseName: Databasename

Opcjonalny. Określa nazwę bazy danych usług Analysis Services, której chcesz użyć z Azure DevOps Server, jeśli masz więcej niż jedną taką bazę danych na serwerze określonym z opcją /AnalysisInstance.

/preview

Opcjonalny. Wyświetla akcje, które należy wykonać, aby zaktualizować konfigurację.

/continue

Opcjonalny. Określa, że polecenie RemapDB powinno być kontynuowane, nawet jeśli podczas próby zlokalizowania co najmniej jednej bazy danych wystąpi błąd.

Jeśli używasz /continue opcji, wszystkie kolekcje, których bazy danych nie znajdują się na serwerze lub serwerach, które określisz, zostaną ponownie skonfigurowane do korzystania z serwera i wystąpienia, które hostuje bazę danych konfiguracji.

/usesqlalwayson

Opcjonalny. Określa, że bazy danych są częścią zawsze włączonej grupy dostępności w SQL Server.

W przypadku skonfigurowania ta opcja ustawia wartość MultiSubnetFailover w parametrach połączenia.

Aby uzyskać więcej informacji, zobacz [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć polecenia RemapDBs, musisz być członkiem grupy zabezpieczeń Team Foundation Administrators i członkiem grupy zabezpieczeń sysadmin dla wszystkich SQL Server baz danych, które Azure DevOps Server używać. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.

Uwagi

Użyj polecenia RemapDBs, aby ponownie skonfigurować Azure DevOps Server do używania różnych serwerów i wystąpień SQL Server z serwerów i wystąpień w oryginalnej instalacji.

Przykład

W poniższym przykładzie pokazano, jak przekierować Azure DevOps Server do TFS_Configuration bazy danych konfiguracji. Ta baza danych jest hostowana w usłudze ContosoMain w nazwanym wystąpieniu TeamDatabases. Bazy danych kolekcji projektów są przechowywane zarówno w bazie danych ContosoMain\TeamDatabases, jak i w domyślnym wystąpieniu w firmie Contoso2.

TFSConfig RemapDBs /DatabaseName:ContosoMain\TeamDatabases;TFS_Configuration
            /SQLInstances:ContosoMain\TeamDatabases,Contoso2

RepairJobQueue

Polecenie repairJobQueue służy do naprawiania zaplanowanych zadań, które przestały działać dla hostów wdrożenia i kolekcji.

TfsConfig repairJobQueue

Wymagania wstępne

Aby użyć polecenia repairJobQueue , musisz być członkiem lokalnej grupy administratorów na maszynie z uruchomionym programem TfsConfig. Musisz również być członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez wdrożenie Azure DevOps Server.

Uwagi

Zazwyczaj należy użyć polecenia repairJobQueue , jeśli zauważysz, że żadne zaplanowane zadania nie są uruchomione.
Polecenie nie bierze żadnych argumentów i wymaga skonfigurowania wdrożenia Azure DevOps Server.

Przykład

TfsConfig repairJobQueue

Dostępność poleceń: TFS 2015

Polecenie RepairJobQueue służy do naprawiania zaplanowanych zadań, które przestały działać dla hostów wdrożenia i kolekcji.

TfsConfig repairJobQueue

Wymagania wstępne

Aby użyć polecenia RepairJobQueue , musisz być członkiem lokalnej grupy administratorów na maszynie z uruchomionym programem TfsConfig. Musisz również być członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez wdrożenie Azure DevOps Server.

Uwagi

Zazwyczaj należy użyć polecenia RepairJobQueue , jeśli zauważysz, że żadne zaplanowane zadania nie są uruchomione.
Polecenie nie bierze żadnych argumentów i wymaga skonfigurowania wdrożenia Azure DevOps Server.

Przykład

TFSConfig repairJobQueue

Ustawienia

Za pomocą polecenia settings można zautomatyzować zmiany w ujednoliconym lokalizatorze zasobów (URL), który jest używany przez interfejs powiadomień i adres serwera dla Azure DevOps Server. Domyślnie adres URL interfejsu powiadomień i adres URL serwera są zgodne w Azure DevOps Server, ale można skonfigurować oddzielne adresy URL. Na przykład możesz użyć innego adresu URL dla automatycznych wiadomości e-mail, które Azure DevOps Server wygenerować. To narzędzie należy uruchomić z warstwy aplikacji, aby zaktualizować wszystkie serwery, aby korzystały z nowych adresów URL.

Aby interaktywnie zmienić te adresy URL lub po prostu wyświetlić bieżące ustawienia, możesz użyć konsoli administracyjnej dla Azure DevOps. Zobacz Szybki przewodnik dotyczący zadań administracyjnych.

TfsConfig settings [/publicURL:URL]
Opcja Opis
publicUrl Określa adres URL serwera warstwy aplikacji dla Azure DevOps. Ta wartość jest przechowywana w bazie danych konfiguracji dla Azure DevOps.

Wymagania wstępne

Musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps i grupy Administratorzy na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Polecenie ustawienia zmienia informacje o połączeniu komunikacji między serwerami we wdrożeniu Azure DevOps Server. Adres URL określony w /publicURL musi być dostępny dla wszystkich serwerów we wdrożeniu.

Przykład

Poniższy przykład zmienia wartość notificationURL na http://contoso.example.com/tfs i wartość ServerURL na http://contoso.example.com:8080/tfs.

TfsConfig settings /publicURL:http://contoso.example.com:8080/tfs

Za pomocą polecenia Ustawienia można zautomatyzować zmiany w ujednoliconym lokalizatorze zasobów (ADRES URL), który jest używany przez interfejs powiadomień i adres serwera dla Azure DevOps Server. Domyślnie adres URL interfejsu powiadomień i adres URL serwera są zgodne w Azure DevOps Server, ale można skonfigurować oddzielne adresy URL. Możesz na przykład użyć innego adresu URL dla automatycznych wiadomości e-mail generowanych Azure DevOps Server. To narzędzie należy uruchomić z poziomu warstwy aplikacji, aby zaktualizować wszystkie serwery, aby korzystały z nowych adresów URL.

Aby zmienić te adresy URL interaktywnie lub po prostu wyświetlić bieżące ustawienia, możesz użyć konsoli administracyjnej do Azure DevOps. Zobacz Krótki przewodnik po zadaniach administracyjnych.

TFSConfig Settings [/ServerURL:URL] [/NotificationURL:URL]

Opcja

Opis

/ServerURL: ADRES URL

Określa adres URL serwera warstwy aplikacji dla Azure DevOps. Ta wartość jest przechowywana w bazie danych konfiguracji dla Azure DevOps.

/NotificationURL: ADRES URL

Określa adres URL do użycia w tekście alertów e-mail, jeśli ten adres URL różni się od adresu URL serwera warstwy aplikacji dla Azure DevOps. Ta wartość jest przechowywana w bazie danych konfiguracji.

Wymagania wstępne

Musisz być członkiem grupy zabezpieczeń Administratorzy team foundation i administratorzy na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Polecenie Ustawienia zmienia informacje o połączeniu dla komunikacji między serwerami we wdrożeniu Azure DevOps Server. Adres URL określony w /ServerURL musi być dostępny dla wszystkich serwerów we wdrożeniu.

Przykład

Poniższy przykład zmienia wartość elementu NotificationURL na http://contoso.example.com/tfs i wartość ServerURL na http://contoso.example.com:8080/tfs.

TFSConfig Settings /NotificationURL:http://contoso.example.com/tfs /ServerURL:http://contoso.example.com:8080/tfs

Konfigurowanie

Polecenie instalatora służy do odinstalowywania funkcji, które są obecnie skonfigurowane na maszynie, na której jest uruchamiane polecenie.

TfsConfig setup /uninstall:<feature[,feature,...]>

Opcja

Opis

/uninstall

Określa co najmniej jedną funkcję do odinstalowania z maszyny, na której uruchamiasz polecenie. Dostępne opcje to: All, ApplicationTier, Search i VersionControlProxy.

Wymagania wstępne

Aby użyć polecenia konfiguracji, musisz być członkiem grupy zabezpieczeń administratorzy Azure DevOps.

Przykłady

Poniższy przykład odinstalowuje wszystkie funkcje Azure DevOps Server z bieżącej maszyny.

TfsConfig setup /uninstall:All

Poniższy przykład odinstalowuje warstwę aplikacji i funkcje kompilacji z bieżącej maszyny.

TfsConfig setup /uninstall:ApplicationTier 

TCM

Podczas uaktualniania do najnowszej wersji Azure DevOps Server system automatycznie próbuje uaktualnić składniki zarządzania testami, w tym plany testów i zestawy.

Jeśli automatyczna migracja nie powiedzie się, użyj polecenia TCM , aby uaktualnić plany testów i zestawy testów ręcznie do odpowiednich typów elementów roboczych (WIT).

TFSConfig TCM /upgradeTestPlans|upgradeStatus /CollectionName:CollectionName /TeamProject:TeamProjectName

Opcja

Opis

/upgradeTestPlans

Wymagane, chyba że / upgradeStatus jest używany.

Konwertuje istniejący plan testów i zestawy testów, aby wskazywały plany testów oparte na elementach roboczych i zestawy testów. Aktualizuje również istniejące dane zarządzania testami i linki między innymi istniejącymi artefaktami testowymi, takimi jak punkty testów, przebiegi testów i wyniki testów.

/upgradeStatus

Wymagane, chyba że / upgradeTestPlans jest używany.

Raportuje stan migracji danych testowych dla określonego projektu. Będzie również wskazywać, czy określony projekt ma jakiekolwiek plany testów.

/CollectionName:CollectionName

Wymagane. Określa kolekcję projektów zawierającą projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdź stan migracji.

Jeśli w nazwie kolekcji projektu znajdują się spacje, należy ująć nazwę w znaki cudzysłowu, na przykład "Fabrikam Fiber Collection".

/TeamProjectName:TeamProjectName

Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdź stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej przy użyciu /collectionName parametru.

Jeśli w nazwie projektu znajdują się spacje, należy ująć nazwę w cudzysłów, na przykład "Mój Project".

Wymagania wstępne

Musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i administratorem na serwerze warstwy aplikacji.

Zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Aby użyć tego polecenia, serwer warstwy aplikacji musi zostać uaktualniony do najnowszej wersji programu Azure DevOps Server 2019.

Przed użyciem polecenia TCM należy najpierw zaimportować definicję elementu roboczego planu testu i kategorię planu testów do projektu.

Aby dowiedzieć się więcej o migracji i korzystaniu z tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami.

Polecenie TCM jest stosowane do poszczególnych projektów. Jeśli musisz uaktualnić plany testów w więcej niż jednym projekcie, musisz uruchomić go osobno dla każdego projektu.

Musisz uruchomić polecenie TCM z katalogu narzędzi dla Azure DevOps Server. Domyślnie ta lokalizacja to: drive:\%programfiles%\TFS 12.0\Tools.

Polecenie TCM jest używane tylko w przypadku niepowodzenia automatycznej migracji istniejących danych testowych.

Aby dowiedzieć się więcej o migracji i korzystaniu z tego polecenia, ręczne aktualizacje do obsługi zarządzania testami. Jeśli nie możesz uzyskać dostępu do planów testów lub zestawów testów zdefiniowanych przed uaktualnieniem serwera, uruchom polecenie TFSConfig TCM upgradeStatus , aby określić stan migracji.

Uruchamiasz polecenie TCM dla pojedynczego projektu. Jeśli musisz uaktualnić więcej niż jeden projekt, musisz uruchomić go na każdym projekcie z kolei.

Przykłady

W poniższym przykładzie pokazano, jak sprawdzić stan uaktualnienia planu testów w projekcie Fabrikam Fiber hostowanym w domyślnej kolekcji projektów (DefaultCollection):

tfsconfig tcm /upgradeStatus /CollectionName:DefaultCollection /TeamProject:"Fabrikam Fiber"

Podczas uaktualniania do najnowszej wersji Azure DevOps Server system automatycznie próbuje uaktualnić składniki zarządzania testami, w tym plany testów i zestawy.

Jeśli automatyczna migracja nie powiedzie się, użyj polecenia TCM , aby uaktualnić plany testów i zestawy testów ręcznie do odpowiednich typów elementów roboczych (WIT).

TFSConfig TCM /upgradeTestPlans|upgradeStatus /CollectionName:CollectionName /TeamProject:TeamProjectName

Opcja

Opis

/upgradeTestPlans

Wymagane, chyba że / upgradeStatus jest używany.

Konwertuje istniejący plan testów i zestawy testów, aby wskazywały plany testów oparte na elementach roboczych i zestawy testów. Aktualizuje również istniejące dane zarządzania testami i linki między innymi istniejącymi artefaktami testowymi, takimi jak punkty testów, przebiegi testów i wyniki testów.

/upgradeStatus

Wymagane, chyba że / upgradeTestPlans jest używany.

Raportuje stan migracji danych testowych dla określonego projektu. Będzie również wskazywać, czy określony projekt ma jakiekolwiek plany testów.

/CollectionName:CollectionName

Wymagane. Określa kolekcję projektów zawierającą projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdź stan migracji.

Jeśli w nazwie kolekcji projektu znajdują się spacje, należy ująć nazwę w znaki cudzysłowu, na przykład "Fabrikam Fiber Collection".

/TeamProjectName:TeamProjectName

Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdź stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej przy użyciu /collectionName parametru.

Jeśli w nazwie projektu znajdują się spacje, należy ująć nazwę w cudzysłów, na przykład "Mój Project".

Wymagania wstępne

Musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i administratorem na serwerze warstwy aplikacji.

Zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Aby można było użyć tego polecenia, serwer warstwy aplikacji musi zostać uaktualniony do najnowszej wersji Azure DevOps Server.

Przed użyciem polecenia TCM należy najpierw zaimportować definicję elementu roboczego planu testu i kategorię planu testu do projektu.

Aby dowiedzieć się więcej o migracji i korzystaniu z tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami.

Polecenie TCM jest stosowane do poszczególnych projektów. Jeśli musisz uaktualnić plany testów w więcej niż jednym projekcie, musisz uruchomić go osobno dla każdego projektu.

Należy uruchomić polecenie TCM z katalogu narzędzi dla Azure DevOps Server. Domyślnie ta lokalizacja to: drive:\%programfiles%\TFS 12.0\Tools.

Polecenie TCM jest używane tylko w przypadku niepowodzenia automatycznej migracji istniejących danych testowych.

Aby dowiedzieć się więcej o migracji i korzystaniu z tego polecenia, aktualizacje ręczne do obsługi zarządzania testami.

Jeśli nie możesz uzyskać dostępu do planów testów ani zestawów testów zdefiniowanych przed uaktualnieniem serwera, uruchom polecenie TFSConfig TCM upgradeStatus , aby określić stan migracji.

Uruchamiasz polecenie TCM dla pojedynczego projektu. Jeśli musisz uaktualnić więcej niż jeden projekt, musisz go uruchomić dla każdego projektu z kolei.

Przykłady

W poniższym przykładzie pokazano, jak sprawdzić stan uaktualnienia planu testowego w projekcie Fabrikam Fiber hostowanym w domyślnej kolekcji projektów (DefaultCollection):

tfsconfig tcm /upgradeStatus /CollectionName:DefaultCollection /TeamProject:"Fabrikam Fiber"

Instalacji nienadzorowanej

Dostępność poleceń: Azure DevOps Server 2019

Polecenie nienadzorowane jest przeznaczone dla użytkowników, którzy znają Azure DevOps Server i proces konfiguracji oraz którzy muszą zainstalować Azure DevOps Server na różnych komputerach.

Jeśli na przykład używasz Azure DevOps Build, możesz użyć polecenia nienadzorowanego, aby zainstalować wiele serwerów kompilacji przy użyciu tego samego pliku konfiguracji.

Użyj opcji /create , aby utworzyć plik nienadzorowany. Ten plik definiuje wszystkie parametry konfiguracji instalacji Azure DevOps Server. Następnie użyj /configure opcji, aby rzeczywiście wykonać konfigurację.

Ten proces umożliwia skonfigurowanie Azure DevOps Server od początku do końca bez konieczności dostarczania danych wejściowych podczas procesu instalacji. W przypadku wielu instalacji pomaga to również zapewnić, że dokładnie te same parametry konfiguracji są używane na wielu serwerach.

TfsConfig unattend /create|configure /type:InstallType /unattendfile:ConfigurationFileName 
    [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]
Opcja Opis
create Tworzy plik nienadzorowany o określonej nazwie i parametrach.
konfigurowanie Konfiguruje Azure DevOps Server przy użyciu określonego pliku i parametrów nienadzorowanych. Musisz użyć /type lub /unattendfile z tą opcją.
typ Określa typ konfiguracji do użycia. Jeśli używasz /configure, /type lub /unattendfile są wymagane, ale nie można użyć obu.
plik nienadzorowany Określa plik nienadzorowany do utworzenia lub użycia, w zależności od tego, czy początkowy parametr to /create, czy /configure. W przypadku używania /configure wymagany jest plik /unattendfile lub /type.
Wejścia Opcjonalny. Jeśli używasz /create, określa ustawienia i wartości do użycia podczas tworzenia pliku nienadzorowanego. Jeśli używasz /configurespecifies dodatkowych ustawień i wartości do użycia w połączeniu z plikiem nienadzorowanym.

Alternatywą dla używania /inputs jest ręczne edytowanie pliku nienadzorowanego w dowolnym edytorze zwykłego tekstu. Jest to konieczne w przypadku niektórych typów wejściowych, takich jak ServiceAccountPassword lub PersonalAccessToken, ponieważ nie można ustawić tych wartości wpisów tajnych przy użyciu /inputs parametru.
verify Opcjonalny. Określa przebieg konfiguracji, który wykonuje tylko testy weryfikacyjne na podstawie pliku nienadzorowanego, danych wejściowych i typu konfiguracji. Jest to alternatywa dla wykonania pełnej konfiguracji.
continue Opcjonalny. Określa, że /create lub /configure powinny być kontynuowane niezależnie od ostrzeżeń z kontroli weryfikacji.
InstallType Opis
NewServerBasic Konfiguruje podstawowe usługi programistyczne dla Azure DevOps Server. Obejmuje to kontrolę źródła, elementy robocze, kompilację i opcjonalnie wyszukiwanie.
NewServerAdvanced Konfiguruje podstawowe usługi programistyczne i umożliwia opcjonalną konfigurację integracji z usługami Reporting Services.
Uaktualnienie Uaktualnia Azure DevOps Server do bieżącej wersji z obsługiwanej poprzedniej wersji.
PreProductionUpgrade Przetestuj uaktualnienie w istniejącym wdrożeniu Azure DevOps Server w środowisku przedprodukcyjnym. Zazwyczaj odbywa się to przy użyciu baz danych przywróconych z kopii zapasowych produkcyjnych. Ten scenariusz obejmuje dodatkowe kroki, aby upewnić się, że nowe wdrożenie nie będzie zakłócać wdrożenia produkcyjnego.
ApplicationTierOnlyBasic Skonfiguruj nową warstwę aplikacji przy użyciu istniejących ustawień z dostarczonej bazy danych konfiguracji. Ta opcja umożliwia szybkie uruchamianie nowej warstwy aplikacji przy użyciu istniejących ustawień. Jeśli chcesz zmienić istniejące ustawienia, zamiast tego użyj typu Advanced ApplicationTierOnlyAdvanced.
ApplicationTierOnlyAdvanced Skonfiguruj nową warstwę aplikacji z pełną kontrolą nad wszystkimi ustawieniami. Ustawienia domyślne wartości z podanej bazy danych konfiguracji. Jeśli chcesz zachować wszystkie istniejące ustawienia, zamiast tego użyj typu ApplicationTierOnlyBasic.
Klonowanie Skonfiguruj nowe wdrożenie Azure DevOps Server, które jest klonem istniejącego wdrożenia. Zazwyczaj odbywa się to przy użyciu baz danych przywróconych z kopii zapasowych produkcyjnych, aby utworzyć środowisko, w którym można przetestować zmiany konfiguracji, rozszerzenia i inne modyfikacje. Ten scenariusz obejmuje dodatkowe kroki, aby upewnić się, że nowe wdrożenie nie będzie zakłócać wdrożenia produkcyjnego.
Serwer proxy Konfiguruje usługę serwera proxy kontroli wersji.

Wymagania wstępne

  • Musisz być członkiem grupy Administratorzy na komputerze, na którym instalujesz oprogramowanie.

  • W zależności od typu instalacji może być również wymagane dodatkowe uprawnienia administratora.

Jeśli na przykład używasz polecenia nienadzorowanego do zainstalowania Azure DevOps Server, musisz być członkiem grupy sysadmin w wystąpieniu SQL Server, które będzie obsługiwać Azure DevOps Server. Aby uzyskać więcej informacji, zobacz sekcję Q & A dotyczącą dodawania administratorów na poziomie serwera do Azure DevOps Server.

Uwagi

Aby można było skonfigurować Azure DevOps Server za pomocą polecenia nienadzorowanego, należy utworzyć konta usług, które będą używane w ramach wdrożenia. Należy również zainstalować dowolne wstępnie wymagane oprogramowanie dla wybranego typu instalacji. Obejmuje to Azure DevOps Server siebie. Musisz zainstalować Azure DevOps Server, ale nie musisz go konfigurować, ponieważ polecenie nienadzorowane wykona to za Ciebie.

Polecenie nienadzorowane konfiguruje składniki Azure DevOps Server. Nie wykonuje początkowej instalacji oprogramowania. Konfiguruje oprogramowanie zgodnie ze specyfikacjami po wystąpieniu bitów na komputerze.

Przykłady

W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany dla podstawowej instalacji Azure DevOps Server.

TfsConfig unattend /create /type:basic /unattendfile:configTFSBasic.ini

W tym przykładzie plik nienadzorowany jest tworzony w tym samym katalogu co polecenie . Plik dziennika jest tworzony w ramach polecenia, a lokalizacja pliku jest zwracana w poleceniu w ramach wykonywania polecenia.

W poniższym przykładzie pokazano, jak określić repozytorium Git do użycia z systemem GVFS podczas konfiguracji.

TfsConfig unattend /configure /type:proxy /inputs:ProjectCollectionUrl=http://FabrikamFiberTFS:8080/tfs/defaultcollection;GvfsProjectName=Fabrikam-Fiber-Git;GvfsRepositoryName=TestGit

W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany dla konfiguracji serwera proxy Azure DevOps.

Ważne

W tym przykładzie, jeśli administratorzy chcą użyć osobistego tokenu dostępu do uwierzytelniania, będą musieli ręcznie edytować plik, aby określić wartość osobistego tokenu dostępu. Można to osiągnąć, dodając wiersz osobistego tokenu dostępu w utworzonym pliku nienadzorowanym, takim jak: PersonalAccessToken=PersonalAccessTokenValue.

TfsConfig unattend /create /type:proxy "/inputs:ProjectCollectionUrl=http://FabrikamFiberTFS:8080/tfs/defaultcollection" /unattendFile:c:\unattend.txt

W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany dla konfiguracji Azure DevOps Server Kompilacja na serwerze przy użyciu FabrikamFiber\BuildSVC konta usługi kompilacji, a następnie skonfigurować Azure DevOps Server Build przy użyciu tego pliku nienadzorowanego.

Ważne

W tym przykładzie po utworzeniu pliku nienadzorowanego administrator ręcznie edytuje plik, aby określić hasło dla konta usługi kompilacji. Dodanie hasła jako danych wejściowych przy użyciu polecenia ServiceAccountPassword=Password; nie powoduje dodania informacji o haśle do pliku.

TfsConfig unattend /create /type:build /unattendfile:configTFSBuild.ini
    /inputs:IsServiceAccountBuiltIn=false;ServiceAccountName=FabrikamFiber\\BuildSVCTFSConfig
TfsConfig unattend /configure /unattendfile:configTFSBuild.ini

Pierwsze polecenie zwraca następujące polecenie:

Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Command: unattend
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203133.log

Drugie polecenie zwraca następujące informacje, w tym nazwę serwera, na którym skonfigurowano Azure DevOps Build, oraz kolekcję projektów skojarzona FabrikamFiberTFS z kontrolerem DefaultCollection:

    Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
    Copyright (c) Microsoft Corporation. All rights reserved.

    Command: unattend

    ---------------------------------------------
            Inputs:
    ---------------------------------------------

    Feedback
            Send Feedback: True

    Build Resources
            Configuration Type: create
            Agent Count: 1
            New Controller Name: FabrikamFiberTFS - Controller
            Clean Up Resources: False

    Project Collection
            Collection URL: http://FabrikamFiberTFS:8080/tfs/defaultcollection

    Windows Service
            Service Account: FabrikamFiber\BuildSVC
            Service Password: ********

    Advanced Settings *
            Port: 9191

    ---------------------------------------------
            Running Readiness Checks
    ---------------------------------------------

    [1/2] System Verifications
    [2/2] Build Service Verifications

    ---------------------------------------------
            Configuring
    ---------------------------------------------

            root
    [1/4] Install Team Foundation Build Service
            Installing Windows services ...
            Adding service account to groups ...
            Setting ACL on a windows service
    [2/4] Enable Event Logging
            Adding event log sources ...
            Token replace a config file
            RegisterBuildEtwProvider
            Configuring ETW event sources ...
    [3/4] Register with Team Foundation Server
            Registering the build service
    [4/4] Start Team Foundation Build Service
            StartBuildHost
            Starting Windows services ...
            Marking feature configured status
    [Info] [Register with Team Foundation Server] Firewall exception added for port
    9191

    TeamBuild completed successfully.
    Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203322.log

Dostępność poleceń: TFS 2018, TFS 2017, TFS 2015, TFS 2013

Polecenie nienadzorowane jest przeznaczone dla użytkowników, którzy znają Azure DevOps Server i proces konfiguracji oraz którzy muszą zainstalować Azure DevOps Server na różnych komputerach.

Jeśli na przykład używasz programu Team Foundation Build, możesz użyć polecenia Nienadzorowane , aby zainstalować wiele serwerów kompilacji przy użyciu tego samego pliku konfiguracji.

Użyj opcji Unattend /create, aby utworzyć plik nienadzorowany. Ten plik definiuje wszystkie parametry konfiguracji instalacji Azure DevOps Server. Następnie użyj opcji Unattend /configure , aby rzeczywiście wykonać konfigurację.

Ten proces umożliwia skonfigurowanie Azure DevOps Server od początku do końca bez konieczności podawania danych wejściowych podczas procesu instalacji. W przypadku wielu instalacji pomaga to również zapewnić, że dokładnie te same parametry konfiguracji są używane na wielu serwerach.

TFSConfig unattend /create|unattend /type:InstallType /unattendfile:ConfigurationFileName [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]

Opcja

Opis

/create

Tworzy plik nienadzorowany o określonej nazwie i parametrach.

/configure

Konfiguruje Azure DevOps Server przy użyciu określonego pliku i parametrów nienadzorowanych.

Należy użyć /type lub /unattendfile z tą opcją.

/type:InstallType

Określa typ konfiguracji do użycia.

  • Podstawowe: konfiguruje Azure DevOps Server w podstawowej konfiguracji, w tym SQL Server Express.

  • Standardowa: konfiguruje Azure DevOps Server w standardowej konfiguracji pojedynczego serwera.

  • ATOnly: konfiguruje dodatkową warstwę aplikacji dla istniejącego wdrożenia Azure DevOps Server.

  • Kompilacja: konfiguruje usługę kompilacji Team Foundation.

  • Serwer proxy: konfiguruje serwer proxy Azure DevOps.

  • SPInstall: instaluje i konfiguruje program SharePoint Foundation 2013 do użycia z wdrożeniem Azure DevOps Server.

  • Uaktualnienie: uaktualnia poprzednią wersję Azure DevOps Server do najnowszej wersji oprogramowania.

Musisz pobrać i zainstalować tę wersję lokalnie przed uruchomieniem tego polecenia za pomocą polecenia /configure.

  • SpExtensions: konfiguruje rozszerzenia SharePoint dla Azure DevOps Server.

Jeśli używasz /configure, /type lub /unattendfile są wymagane, ale nie można użyć obu.

/unattendfile:ConfigurationFileName

Określa plik nienadzorowany do utworzenia lub użycia, w zależności od tego, czy początkowy parametr to /create, czy /configure. Jeśli używasz /configure, /unattendfile lub /type jest wymagany.

/inputs:Key1=Value1; Key2=Value2;...

Opcjonalny. Jeśli używasz /create, określa ustawienia i wartości do użycia podczas tworzenia pliku nienadzorowanego.

Jeśli używasz /configurespecifies dodatkowe ustawienia i wartości do użycia w połączeniu z plikiem nienadzorowanym.

Alternatywą dla używania /inputs jest ręczne edytowanie pliku nienadzorowanego w dowolnym edytorze zwykłego tekstu.

Jest to konieczne w przypadku niektórych typów danych wejściowych, takich jak ServiceAccountPassword lub PersonalAccessToken, ponieważ nie można ustawić tych wartości wpisów tajnych przy użyciu /inputs parametru.

/verify

Opcjonalny. Określa przebieg konfiguracji, który kończy sprawdzanie weryfikacji tylko na podstawie pliku nienadzorowanego, danych wejściowych i typu konfiguracji.

Jest to alternatywa dla wykonania pełnej konfiguracji.

/continue

Opcjonalny. Określa, że /create lub /configure powinny być kontynuowane niezależnie od ostrzeżeń z kontroli weryfikacji.

/?

Opcjonalny. Zapewnia pomoc wiersza polecenia dla polecenia nienadzorowanego.

Wymagania wstępne

  • Musisz być członkiem grupy Administratorzy na komputerze, na którym instalujesz oprogramowanie.

  • W zależności od typu instalacji może być również wymagane dodatkowe uprawnienia administratora. Jeśli na przykład do zainstalowania Azure DevOps Server używasz polecenia Unattend, musisz być członkiem grupy sysadmin w wystąpieniu SQL Server, które będzie obsługiwać Azure DevOps Server. Aby uzyskać więcej informacji, zobacz sekcję Q & A w sekcji Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Aby można było skonfigurować Azure DevOps Server za pomocą polecenia nienadzorowanego, należy utworzyć konta usług, które będą używane w ramach wdrożenia. Należy również zainstalować dowolne wstępnie wymagane oprogramowanie dla wybranego typu instalacji. Obejmuje to Azure DevOps Server się. Musisz zainstalować Azure DevOps Server, ale nie musisz go konfigurować, ponieważ polecenie Nienadzorowane zrobi to za Ciebie.

Polecenie Nienadzorowane konfiguruje składniki Azure DevOps Server. Nie wykonuje wstępnej instalacji oprogramowania. Konfiguruje oprogramowanie zgodnie ze specyfikacjami po wystąpieniu bitów na komputerze.

Przykłady

W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany na potrzeby podstawowej instalacji Azure DevOps Server.

TFSConfig Unattend /create /type:basic /unattendfile:configTFSBasic.ini

W tym przykładzie plik nienadzorowany jest tworzony w tym samym katalogu co polecenie . Plik dziennika jest tworzony w ramach polecenia, a lokalizacja pliku jest zwracana w poleceniu w ramach wykonywania polecenia.

W poniższym przykładzie pokazano, jak określić repozytorium Git do użycia z systemem GVFS podczas konfigurowania.

TFSConfig Unattend /configure /type:proxy /inputs:ProjectCollectionUrl=http://FabrikamFiberTFS:8080/tfs/defaultcollection;GvfsProjectName=Fabrikam-Fiber-Git;GvfsRepositoryName=TestGit

W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany na potrzeby konfiguracji serwera proxy Azure DevOps.

Ważne: W tym przykładzie, jeśli administratorzy chcą użyć osobistego tokenu dostępu do uwierzytelniania, będą musieli ręcznie edytować plik, aby określić wartość osobistego tokenu dostępu. Można to osiągnąć, dodając wiersz dla osobistego tokenu dostępu w utworzonym pliku nienadzorowanym, na przykład: "PersonalAccessToken=PersonalAccessTokenValue".

TfsConfig Unattend /create /type:proxy "/inputs:ProjectCollectionUrl=http://FabrikamFiberTFS:8080/tfs/defaultcollection" /unattendFile:c:\unattend.txt

W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany dla konfiguracji kompilacji Team Foundation na serwerze przy użyciu polecenia "FabrikamFiber\BuildSVC" jako konta usługi kompilacji, a następnie skonfigurować kompilację team foundation przy użyciu tego pliku nienadzorowanego.

Ważne:
W tym przykładzie po utworzeniu pliku nienadzorowanego administrator ręcznie edytuje plik, aby określić hasło dla konta usługi kompilacji. Dodanie hasła jako danych wejściowych przy użyciu polecenia "ServiceAccountPassword=Password" nie powoduje dodania informacji o haśle do pliku.

TFSConfig Unattend /create /type:build /unattendfile:configTFSBuild.ini
        /inputs:IsServiceAccountBuiltIn=false;ServiceAccountName=FabrikamFiber\\BuildSVCTFSConfig
        Unattend /configure /unattendfile:configTFSBuild.ini

Pierwsze polecenie zwraca następujące polecenie:

Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Command: unattend
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203133.log

Drugie polecenie zwraca następujące informacje, w tym nazwę serwera, na którym skonfigurowano kompilację Team Foundation (FabrikamFiberTFS) i kolekcję projektów skojarzona z kontrolerem (DefaultCollection):

Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Command: unattend

---------------------------------------------
        Inputs:
---------------------------------------------

Feedback
        Send Feedback: True

Build Resources
        Configuration Type: create
        Agent Count: 1
        New Controller Name: FabrikamFiberTFS - Controller
        Clean Up Resources: False

Project Collection
        Collection URL: http://FabrikamFiberTFS:8080/tfs/defaultcollection

Windows Service
        Service Account: FabrikamFiber\BuildSVC
        Service Password: ********

Advanced Settings *
        Port: 9191


---------------------------------------------
        Running Readiness Checks
---------------------------------------------

[1/2] System Verifications
[2/2] Build Service Verifications

---------------------------------------------
        Configuring
---------------------------------------------

        root
[1/4] Install Team Foundation Build Service
        Installing Windows services ...
        Adding service account to groups ...
        Setting ACL on a windows service
[2/4] Enable Event Logging
        Adding event log sources ...
        Token replace a config file
        RegisterBuildEtwProvider
        Configuring ETW event sources ...
[3/4] Register with Team Foundation Server
        Registering the build service
[4/4] Start Team Foundation Build Service
        StartBuildHost
        Starting Windows services ...
        Marking feature configured status
[Info] [Register with Team Foundation Server] Firewall exception added for port
9191


TeamBuild completed successfully.
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203322.log

Dzienniki pocztowe

Polecenie ziplogs jest przeznaczone do zbierania dzienników i upuścić zip pod adresem ProgramData\Microsoft\Azure DevOps\Server Configuration.

TfsConfig zipLogs

TfsConfig zipLogs