Use TFSConfig to manage Azure DevOps on-premises (Zarządzanie zasobami lokalnymi przy użyciu programu TFSConfig)

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

Uwaga

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

Za pomocą narzędzia wiersza polecenia TFSConfig można wykonywać różne akcje administracyjne Azure DevOps wdrożenia lokalnego.

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

Ważne

Selektor wersji zawartości

Aby wyświetlić zawartość dostępną dla Twojej platformy, upewnij się, że wybierasz poprawną wersję tego artykułu z selektora wersji znajdującego się powyżej spisu treści. Obsługa funkcji różni się w zależności od tego, czy pracujesz z wersją Azure DevOps Services czy lokalną wersją programu Azure DevOps Server zmienioną na Team Foundation Server (TFS).

Aby dowiedzieć się, której wersji lokalnej używasz, zobacz Jakiej platformy/wersji używasz?

Uwaga

W przypadku serwera TFS 2010 i jego starszych wersji kilka z tych poleceń jest dostępnych w narzędziu wiersza polecenia TFSAdminUtils.

Lokalizacja narzędzia wiersza polecenia

Azure DevOps wiersza polecenia są zainstalowane w katalogu /Tools Azure DevOps serwera warstwy aplikacji.

  • 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 musi 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, który uruchamia program TFSConfig, musi mieć uprawnienia administracyjne dla tych samych serwerów i usług. Wymagania dotyczące określonych poleceń zostaną określone poniżej.

Wiele poleceń TFSConfig należy uruchomić 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 wiersza polecenia, a następnie kliknij przycisk Uruchom jako administrator. Aby uzyskać więcej informacji, zobacz: Kontrola konta użytkownika.

Akcje administracyjne można również wykonywać interaktywnie przy użyciu konsoli administracyjnej programu Azure DevOps Server. Zobacz krótki przewodnik po zadaniu administracyjnym.

Lista poleceń i uzyskiwanie pomocy

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

TFSConfig help

Aby uzyskać pomoc dla poszczególnych poleceń, użyj polecenia help i określ nazwę polecenia, za pomocą którego chcesz uzyskać pomoc. Aby na przykład uzyskać pomoc dla polecenia accounts:

TFSConfig help accounts

Konta

Użyj konta polecenia do zarządzania tymi kontami Azure DevOps Server usług.

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

To polecenie umożliwia również zmianę własności baz danych Azure DevOps Server 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 accountType, które są uruchamiane jako dane konto.
Zmiana Zmienia konto, które jest 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 korzystania z niego. Nie spowoduje 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 continue, jeśli niektóre kolekcje są nieosiągalne. 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ę do używania konta już dodanego do zasobów. Przydatne w scenariuszach równoważenia obciążenia sieciowego.
Usuń Usuwa konto ze wszystkich zasobów. Podczas usuwania konta należy stosować środki ostrożności, ponieważ może to spowodować, że inne serwery uzyskają odmowę usługi.
ResetOwner Jeśli bazy danych są przywracane w ramach przenoszenia, klonowania lub odzyskiwania po awarii, właściciel bazy danych może przełączyć się do administratora przywracając serwer. Ta opcja iteruje po wszystkich bazach danych i ustawia identyfikator logowania dbo na bieżącego właściciela.
Accounttype Opis
AdminConsole Użytkownicy konsoli administracyjnej to użytkownicy, którzy mają przyznane minimalne uprawnienia do korzystania z konsoli w różnych zasobach.
ApplicationTier Zmienia konto usługi w puli appPool dla podstawowych usług internetowych. (TFSService)
Serwer proxy Zmienia konto usługi w puli appPool dla usług sieci Web serwera proxy. (TFSProxy)
ReportingDataSource Zmienia konto, za pomocą których raporty mają dostęp do danych raportowania. (TFSReports)

Wartość domyślna to ApplicationTier.

Wartości sqlInstance i databaseName są odpowiednie tylko do użycia podczas dodawania konta do baz danych przed skonfigurowaniem warstwy aplikacji. Jest to przydatne głównie w scenariuszach odzyskiwania po awarii, w których wymagane jest inne konto przed uruchomieniem kreatora konfiguracji AT Only.

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 podany ciąg continue, będzie on kontynuowany, jeśli kolekcja jest nieosiągalna. Można go uruchomić ponownie, gdy są osiągalne.

Uwaga

Konta muszą być w formacie 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 typu konta, do którego się odwołujesz, 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żywany tylko z /ResetOwner.

Określa nazwę serwera, na którym działa program SQL Server, oraz 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żywany tylko z /ResetOwner.

Określa nazwę bazy danych, której własność chcesz zmienić. Za pomocą tego polecenia można zresetować własność bazy danych, który określisz do konta, na którym jest uruchomione polecenie.
continue Aktualizuje wszystkie grupy, które nie są dostępne po uruchomieniu polecenia. Ta opcja jest zwykle używana w scenariuszach równoważenia obciążenia sieciowego.

Wymagania wstępne

Aby użyć konta polecenia, musi być członkiem:

  • grupa zabezpieczeń Azure DevOps Administratorzy
  • rola sysadmin dla wszystkich SQL Server, których używa Azure DevOps Server wystąpienia.

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

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Za pomocą polecenia accounts zautomatyzuj zmiany kont usług, baz danych i grup kont usług Azure DevOps Server. Możesz skonfigurować konta, które zostały już utworzone, ale nie możesz ich tworzyć.

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 internetowej firmy Microsoft: Włączanie uwierzytelniania delegowanego.

Polecenie accounts obsługuje lokalne wdrożenia Azure DevOps Server wdrożenia. 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, , a Contoso\NewAccount hasło na Password .

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

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

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

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

Uwaga

Korzystając z tego polecenia, nie można określić konta, które ma zostać ustawione jako właściciel baz danych. Właściciel zostanie ustawiony na konto, na którym jest uruchomione polecenie .

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

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

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

To polecenie umożliwia również zmianę własności baz danych Azure DevOps Server 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, które jest używane jako konto usługi.

Ta opcja powoduje dodanie konta, które określisz do wszystkich niezbędnych grup, jeśli to możliwe, przyznanie do niego wymagań wstępnych i ustawienie usługi do korzystania z konta.

Jeśli nie użyjemy 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 powoduje dodanie konta, które określisz do niezbędnych grup, i przyznanie do niego uprawnień, które są wymagane do działania jako konto usługi (jeśli to możliwe).

Jednak ta opcja nie spowoduje zmiany konta, które jest używane jako konto usługi.

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

Możesz użyć tej opcji z /continue, jeśli niektóre usługi lub bazy danych mogą nie być dostępne w Twoim środowisku.

/set

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

W związku z tym należy użyć tej opcji tylko w przypadku kont, 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 typu konta, który określisz.

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

Jednak ta opcja nie spowoduje zmiany konta, które jest używane jako konto usługi.

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

/ResetOwner

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

Ta opcja iteruje mimo wszystkich baz danych i ustawia identyfikator logowania dbo na konto, za pomocą których uruchamiasz to polecenie.

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 powoduje aktualizację hasła dla konta, które zostało określone 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 otwierania i używania konsoli administracyjnej programu Azure DevOps (AdminConsole)
  • ApplicationTier: konto usługi używane na Azure DevOps Server (TFSService)
  • ReportingDataSource: konto źródeł danych dla usług Reporting Services (TFSReports)
  • Serwer proxy: konto usługi dla Azure DevOps Server proxy (TFSProxy)

Wartość domyślna to ApplicationTier.

/Account: Accountname

Określa nazwę konta, które chcesz dodać, zmienić lub usunąć z typu konta, do którego się odwołujesz, 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.

/Password: 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żywany tylko z /ResetOwner.

Określa nazwę serwera, na którym działa program SQL Server, oraz 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żywany tylko z /ResetOwner.

Określa nazwę bazy danych, której własność chcesz zmienić.

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

/continue

Aktualizuje wszystkie grupy, które nie są dostępne po uruchomieniu 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ą grupy dostępności AlwaysOn w SQL Server.

Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w parametrów połączenia.

Aby uzyskać więcej informacji, zobacz [Zawsze włączone grupy dostępności (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć konta polecenia, musi być członkiem

  • grupa zabezpieczeń Administratorzy Team Foundation
  • rola sysadmin dla wszystkich SQL Server, których używa Azure DevOps Server wystąpienie.

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

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server> (Odwołanie do uprawnień dla Azure DevOps Server>).

Uwagi

Użyj konta polecenie, aby zautomatyzować zmiany kont usług, baz danych i grup kont usług Azure DevOps Server. Możesz skonfigurować konta, które zostały już utworzone, ale nie możesz ich tworzyć.

Przed zmianą domeny lub grupy roboczej konta konto musi mieć poufne konto i nie może mieć delegowanego 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 wdrożenia. Aby zmienić właściciela konta w 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" w bazie danych "ContosoMain" SQL Server nazwanego wystąpienia "TeamDatabases" na konto użytkownika, na którym jest uruchomione _ polecenie .

Uwaga

Korzystając z tego polecenia, nie można określić konta, które ma zostać ustawione jako właściciel baz danych. Właściciel zostanie ustawiony na konto, na którym uruchamiasz polecenie.

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

AddProjectReports

Uwaga

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

Użyj polecenia addProjectReports, aby dodać lub zastąpić raporty dla istniejącego projektu zespołowego.

TfsConfig addProjectReports /collection:<teamProjectCollectionUrl> /teamProject:<projectName> /template:<templateName>
[/force]
Opcja Opis
— kolekcja Wymagane. Adres URL kolekcji Project Team.
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

Jeśli projekt nie zawiera raportów lub chcesz zaktualizować raporty zdefiniowane dla procesu, użyj polecenia addProjectReports.

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

  • Projekt został utworzony w portalu Azure DevOps, a nie z witryny 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, a stare raporty w projekcie nie są już zgodne, użyj opcji /force. Jeśli masz dostosowane raporty, przed wykonaniem tej pracy należy utworzyć kopię zapasową.

Aby dowiedzieć się więcej na temat dodawania raportów do aplikacji 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 umożliwia dodawanie lub zastępowanie raportów dotyczących istniejącego projektu.

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

Opcja

Opis

/collection

Wymagane. Adres URL Project Kolekcji.

/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

Użyj polecenia AddProjectReports, 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 witryny 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, a stare raporty w projekcie nie są już zgodne, użyj opcji /force. Jeśli masz dostosowane raporty, przed wykonaniem tej pracy należy utworzyć kopię zapasową.

Aby dowiedzieć się więcej na temat dodawania raportów do aplikacji 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 Uwierzytelnianie zmienia protokół uwierzytelniania sieciowego używany Azure DevOps Server aplikacji lub witryny sieci Web 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
  • Negotiate: Użyj protokołu uwierzytelniania Negotiate (Kerberos)

/siteType

Określa witrynę sieci Web (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, musi być członkiem grupy zabezpieczeń administratorzy programu Azure DevOps i administratora lokalnego na serwerze warstwy aplikacji lub serwera proxy, w zależności od wartości siteType opcji.

Uwagi

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

Przed użyciem uwierzytelniania polecenie, aby zmienić protokół uwierzytelniania, można uruchomić polecenie z /viewAll opcji, aby zobaczyć, jakie są istniejące ustawienia.

Przykład

W poniższym przykładzie wyświetlana jest bieżąca wartość przypisana dla protokołu uwierzytelniania sieciowego.

TFSConfig Authentication /viewAll

Polecenie Uwierzytelnianie zmienia protokół uwierzytelniania sieciowego używany przez warstwę aplikacji SERWERA 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
  • Negotiate: Użyj protokołu uwierzytelniania Negotiate (Kerberos)

/siteType

Określa witrynę sieci Web (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, musi być członkiem grupy zabezpieczeń Administratorzy team Foundation i administratora lokalnego na serwerze warstwy aplikacji lub serwera proxy, w zależności od wartości siteType opcji.

Uwagi

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

Przed użyciem uwierzytelniania polecenie, aby zmienić protokół uwierzytelniania, można uruchomić polecenie z /viewAll opcji, aby zobaczyć, jakie są istniejące ustawienia.

Przykład

W poniższym przykładzie wyświetlana jest bieżąca wartość przypisana dla protokołu uwierzytelniania sieciowego.

TFSConfig Authentication /viewAll

Certyfikaty

Użyj polecenia certificates, aby zmienić sposób konfigurowania certyfikatów na użytek uwierzytelniania klienta we wdrożeniu programu Azure DevOps Server, które korzysta z protokołu HTTPS, protokołu 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, a nie bieżącego kontekstu użytkownika.
Wyłącz Określa, że ustawienie certyfikatu uwierzytelniania klienta zostanie wyłączone.
autoWybór 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, który pasuje do określonego odcisku palca. Można określić więcej niż jeden certyfikat, oddzielając poszczególne odciski palca przecinkiem.

Wymagania wstępne

Aby użyć certyfikaty polecenia, musi być członkiem grupy zabezpieczeń Azure DevOps Administratorzy i lokalnej grupy Administratorzy na komputerze, z którego jest uruchamiane polecenie. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

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

Przed użyciem certyfikaty polecenia, należy najpierw skonfigurować serwery we wdrożeniu programu 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 certificates służy do konfigurowania certyfikatów klienta używanych przez wdrożenie programu Azure DevOps Server, które zostało skonfigurowane do używania protokołów HTTPS/SSL i certyfikatów. Jeśli używasz certyfikaty polecenia bez opcji, certyfikat klienta zostanie automatycznie wybrany z bieżącego kontekstu użytkownika, z którego uruchamiasz polecenie.

Przykłady

Poniższy przykład pokazuje, jak określić certyfikat komputera lokalnego, który ma odcisk 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

Za pomocą polecenia Certyfikaty możesz zmienić sposób konfigurowania certyfikatów na użytek uwierzytelniania klienta we wdrożeniu programu Azure DevOps Server, które korzysta z protokołu HTTPS, protokołu 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, a nie bieżącego kontekstu użytkownika.

/Disable

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

/autoSelect

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, który pasuje do określonego odcisku palca. Można określić więcej niż jeden certyfikat, oddzielając poszczególne odciski palca przecinkiem.

Wymagania wstępne

Aby użyć certyfikaty polecenia, musi być członkiem grupy zabezpieczeń Administratorzy team Foundation i lokalnej grupy Administratorzy na komputerze, na którym jest uruchamiane polecenie. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

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

Przed użyciem certyfikaty polecenia, należy najpierw skonfigurować serwery we wdrożeniu usługi 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 programu Azure DevOps Server, które zostało skonfigurowane do używania protokołu HTTPS/SSL i certyfikatów. Jeśli używasz certyfikaty polecenia 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 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

ChangeServerID polecenie zmienia identyfikatory GUID, które są skojarzone z bazami danych dla Azure DevOps Server. Identyfikatory GUID muszą być unikatowe w ramach wdrożenia 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żytelne. Można zmienić identyfikator GUID bazy danych konfiguracji, identyfikatory GUID dla wszystkich baz danych kolekcji projektów we wdrożeniu lub oba te identyfikatory.

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

  • Po przywróceniu wdrożenia na nowy sprzęt stare wdrożenie nadal działa i chcesz korzystać z obu wdrożeń. Ten scenariusz jest czasami nazywany klonowaniem serwera.

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

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

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

Uwaga

ChangeServerID polecenie jest nieodwracalne. 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, na którym działa program SQL Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName .
Databasename Wymagane. Określa nazwę bazy danych konfiguracji dla Azure DevOps Server. Domyślnie nazwa tej bazy danych to TFS_ConfigurationDB.
projectCollectionsOnly Określa, że tylko identyfikatory GUID dla kolekcji zostaną zmienione.
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 Azure DevOps i innych kolekcji.

Wymagania wstępne

Aby użyć changeServerID polecenia, musi być członkiem grupy zabezpieczeń administratorzy programu Azure DevOps i członkiem roli zabezpieczeń sysadmin dla wszystkich wystąpień SQL Server, które Azure DevOps Server używane. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps (Odwołanie do uprawnień dla Azure DevOps).

Uwagi

Za pomocą polecenia changeServerID można utworzyć dyskretny duplikat wdrożenia usługi Azure DevOps Server do celów testowania lub klonowania. Po użyciu polecenia changeServerID należy skierować klientów do utworzenia połączenia 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 contoso1 usługi Azure DevOps Server, gdzie baza danych konfiguracji jest hostowana na serwerze o nazwie w nazwanych wystąpieniach w ContosoMain TeamDatabases SQL Server.

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

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

  • Po przywróceniu wdrożenia na nowy sprzęt stare wdrożenie nadal działa i chcesz korzystać z obu wdrożeń. Ten scenariusz jest czasami nazywany klonowaniem serwera.

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

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

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

    Uwaga

    ChangeServerID polecenie jest nieodwracalne. 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, na którym działa program SQL Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName

/DatabaseName: DatabaseName

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

/ProjectCollectionsOnly

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

/ConfigDBOnly

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

/usesqlalwayson

Określa, że bazy danych są częścią grupy dostępności AlwaysOn w SQL Server. Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w parametrów połączenia.

Aby uzyskać więcej informacji, zobacz Zawsze włączone grupy dostępności (SQL Server).

Wymagania wstępne

Aby użyć polecenia ChangeServerID, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i członkiem roli zabezpieczeń sysadmin dla wszystkich wystąpień SQL Server, których Azure DevOps Server. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps (Odwołanie do uprawnień dla Azure DevOps).

Uwagi

Polecenie ChangeServerID umożliwia utworzenie dyskretnego duplikatu wdrożenia usługi Azure DevOps Server do celów testowania lub klonowania. Po użyciu polecenia ChangeServerID należy skierować klientów do utworzenia połączenia 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 contoso1 usługi Azure DevOps Server, gdzie baza danych konfiguracji jest hostowana na serwerze o nazwie "ContosoMain" w nazwanych wystąpieniach "TeamDatabases" w programie SQL Server.

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

Indeks kodu

Użyj polecenia codeIndex, aby zarządzać indeksowaniem kodu na Azure DevOps Server. Na przykład możesz zresetować indeks, aby naprawić informacje codeLens, lub wyłączyć indeksowanie, aby zbadać problemy 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 na: Rozpocznij indeksowanie wszystkich zmian.
off: zatrzymaj indeksowanie wszystkich zmian.
keepupOnly: zatrzymaj indeksowanie utworzonych wcześniej zmian i rozpocznij indeksowanie tylko nowych.
ignoreList Określa listę plików kodu i ich ścieżek, które nie mają być indeksowane.

dodaj: Dodaj plik, który nie ma być indeksowany do listy ignorowanych plików.
usuń: usuń plik, który ma być indeksowany, z listy ignorowanych plików.
removeAll: wyczyść listę ignorowanych 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.

Można użyć symbolu wieloznacznego (*) na początku, na końcu lub na obu końcach ścieżki serwera.
listLargeFiles Przedstawia określoną liczbę plików, która przekracza określony rozmiar w KB. Następnie można użyć /ignoreList opcji, aby wykluczyć te pliki z indeksowania.

W tym celu musisz mieć Team Foundation Server 2013 z aktualizacją Update 3.
reindexAll Wyczyść wcześniej indeksowane dane i uruchom ponownie indeksowanie.
destroyCodeIndex Usuń indeks kodu i usuń wszystkie indeksowane dane. Nie wymaga potwierdzenia, jeśli używasz /noPrompt opcji.
temporaryDataSizeLimit Kontroluj, ile danych tymczasowych tworzy codelens podczas przetwarzania grupy zmian. Domyślny limit wynosi 6 GB (2 GB w aktualizacji Update 5).

view: Pokaż bieżący limit rozmiaru.
SizeInGBs: zmień limit rozmiaru.
disable : Usuń limit rozmiaru.

Ten limit jest sprawdzany przed rozpoczęciem przetwarzania nowego grupy zmian przez codeLens. Jeśli dane tymczasowe przekroczy ten limit, funkcje CodeLens wstrzymają przetwarzanie wcześniejszych zmian, a nie nowych. CodeLens ponownie uruchomi przetwarzanie po wyczyszczeniu danych i spadku poniżej tego limitu. Oczyszczanie jest uruchamiane automatycznie raz dziennie. Oznacza to, że dane tymczasowe mogą przekroczyć ten limit do momentu uruchomienia czyszczenia.

W tym celu musisz mieć Team Foundation Server 2013 z aktualizacją Update 4.
indexHistoryPeriod Kontrolowanie czasu indeksowania historii zmian. Ma to wpływ na to, ile historii pokazuje ci codelens. Domyślny limit wynosi 12 miesięcy. Oznacza to, że narzędzie CodeLens pokazuje historię zmian tylko z ostatnich 12 miesięcy.

view: pokazuje bieżącą liczbę miesięcy.
all: indeksowanie całej historii zmian.
NumberOfMonths: zmień liczbę miesięcy używanych do indeksowania historii zmian.

W tym celu musisz mieć Team Foundation Server 2013 z aktualizacją Update 4.
Collectionname Określa nazwę kolekcji projektu, na którym ma być uruchamiane polecenie CodeIndex. Wymagane, jeśli nie używasz /CollectionId.
Collectionid Określa numer identyfikacyjny kolekcji projektu, na którym ma być uruchamiane polecenie CodeIndex. Wymagane, jeśli nie używasz /CollectionName

Wymagania wstępne

Aby użyć codeIndex polecenia, musi być członkiem grupy zabezpieczeń Azure DevOps Administratorzy. Zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Przykłady

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

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

Aby rozpocząć indeksowanie wszystkich zmian:

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

Aby zatrzymać indeksowanie utworzonych wcześniej zmian i rozpocząć indeksowanie tylko nowych:

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

Aby znaleźć maksymalnie 50 plików większych 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ę zmianami:

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 na Azure DevOps Server. Na przykład możesz zresetować indeks, aby naprawić informacje codeLens, lub wyłączyć indeksowanie, aby zbadać problemy 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 ]

  • na: Rozpocznij indeksowanie wszystkich zmian.
  • off: zatrzymaj indeksowanie wszystkich zmian.
  • keepupOnly: zatrzymaj indeksowanie utworzonych wcześniej zmian i rozpocznij indeksowanie tylko nowych.

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

Określa listę plików kodu i ich ścieżek, które nie mają być indeksowane.

  • dodaj: Dodaj plik, który nie ma być indeksowany do listy ignorowanych plików.
  • usuń: usuń plik, który ma być indeksowany, z listy ignorowanych plików.
  • removeAll: wyczyść listę ignorowanych 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.

Można użyć symbolu wieloznacznego (*) na początku, na końcu lub na obu końcach ścieżki serwera.

/listLargeFiles
/fileCount: FileCount /minSize:MinSize

Przedstawia określoną liczbę plików, która przekracza określony rozmiar w KB. Następnie można użyć /ignoreList opcji, aby wykluczyć te pliki z indeksowania.
W przypadku tej opcji musisz mieć wersję Team Foundation Server 2013 z aktualizacją Update 3 lub nowszą.

/reindexAll

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

/destroyCodeIndex [/noPrompt]

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

/temporaryDataSizeLimit:[view | SizeInGBs | disable]

Kontroluj, ile danych tymczasowych tworzy codelens podczas przetwarzania grupy zmian. Domyślny limit wynosi 6 GB (2 GB w aktualizacji Update 5).

  • view: Pokaż bieżący limit rozmiaru.
  • SizeInGBs: zmień limit rozmiaru.
  • disable: Usuń limit rozmiaru.

Ten limit jest sprawdzany przed rozpoczęciem przetwarzania nowego grupy zmian przez codeLens. Jeśli dane tymczasowe przekroczy ten limit, funkcje CodeLens wstrzymają przetwarzanie wcześniejszych zmian, a nie nowych. CodeLens ponownie uruchomi przetwarzanie po wyczyszczeniu danych i spadku poniżej tego limitu. Oczyszczanie jest uruchamiane automatycznie raz dziennie. Oznacza to, że dane tymczasowe mogą przekroczyć ten limit do momentu uruchomienia czyszczenia.

W przypadku tej opcji musisz mieć wersję Team Foundation Server 2013 z aktualizacją Update 4 lub nowszą.

/indexHistoryPeriod:[view | all | NumberOfMonths]

Kontrolowanie czasu indeksowania historii zmian. Ma to wpływ na to, ile historii pokazuje ci codelens. Domyślny limit wynosi 12 miesięcy. Oznacza to, że narzędzie CodeLens pokazuje historię zmian tylko z ostatnich 12 miesięcy.

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

W przypadku tej opcji musisz mieć wersję Team Foundation Server 2013 z aktualizacją Update 4 lub nowszą.

/collectionName:CollectionName

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

/collectionId:CollectionId

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

Wymagania wstępne

Aby użyć polecenia , musisz być członkiem grupy zabezpieczeń CodeIndex Administratorzy programu Team Foundation. Zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Przykłady

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

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

Aby rozpocząć indeksowanie wszystkich zmian:

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

Aby zatrzymać indeksowanie utworzonych wcześniej zmian i rozpocząć indeksowanie tylko nowych:

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

Aby znaleźć maksymalnie 50 plików większych 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ę zmianami:

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 collection, aby dołączyć, odłączyć lub usunąć kolekcję projektu z wdrożenia Azure DevOps Server. Możesz również użyć polecenia collection, 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 /detach ani /delete jest używany. Jeśli określisz tę opcję, należy również użyć /collectionDB opcji. Jako opcji można również użyć /collectionName i /clone z tą opcją. Jeśli używasz /attach opcji, określona baza danych kolekcji zostanie dodana do wdrożenia Azure DevOps Server.
create Tworzy kolekcję.
Odłączyć Wymagane, jeśli nie /attach ani /delete jest używany. Jeśli określisz tę opcję, należy również użyć /collectionName opcji. W przypadku użycia opcji /detach baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie odłączeniu od wdrożenia usługi Azure DevOps Server.
delete Wymagane, jeśli nie /detach ani /attach jest używany. Jeśli określisz tę opcję, należy również użyć /collectionName opcji. Jeśli używasz /delete opcji, 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 żadnego 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 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 program SQL Server, oraz nazwę bazy danych kolekcji hostowanej na tym serwerze.
ServerName Określa nazwę serwera, który hostuje bazę danych konfiguracji dla usługi Azure DevOps Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName .
DatabaseName Określa nazwę bazy danych konfiguracji. Domyślnie nazwa tej bazy danych to 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 jako część dzielenia kolekcji projektów.

Porada

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

Wymagania wstępne

Aby użyć polecenia collections, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation oraz lokalnej grupy Administratorów na maszynie z programem TfsConfig. Musisz być również członkiem roli zabezpieczeń sysadmin dla wszystkich wystąpień SQL Server używanych przez Azure DevOps Server danych. Jeśli wdrożenie jest zintegrowane z programem SharePoint i używasz opcji /delete, musisz być również członkiem grupy Administratorzy farmy dla farmy SharePoint, z której usuwasz kolekcję lokacji.

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Aby interaktywnie zarządzać kolekcjami lub tworzyć kolekcje, można użyć węzła Kolekcje Project w konsoli administracyjnej programu Azure DevOps. Zobacz Zarządzanie kolekcjami projektów.

Przykłady

W poniższym przykładzie pokazano, jak trwale usunąć kolekcję Contoso Summer Intern Projects 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ć kolekcję projektu, nazwać ją i dołączyć zduplikowaną kolekcję do wdrożenia Contoso Summer Interns Projects Contoso Winter Interns Projects 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 /detach ani /delete jest używany.

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

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

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

/Detach

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

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

W przypadku użycia opcji /detach baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie odłączeniu od wdrożenia usługi Azure DevOps Server.

/Delete

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

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

Jeśli używasz /delete opcji, 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 żadnego innego wdrożenia.

Porada: Opcja /delete nie spowoduje usunięcia bazy danych kolekcji z SQL Server.

Po usunięciu bazy danych kolekcji z Azure DevOps Server można usunąć ją ręcznie 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 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 program SQL Server, oraz nazwę bazy danych kolekcji hostowanej na tym serwerze.

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

W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName .

  • DatabaseName: określa nazwę bazy danych konfiguracji. Domyślnie nazwa tej bazy danych to 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 jako część dzielenia kolekcji projektów.

Wymagania wstępne

Aby użyć polecenia Kolekcje, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation oraz lokalnej grupy Administratorów na maszynie z programem TFSConfig. Musisz być również członkiem roli zabezpieczeń sysadmin dla wszystkich wystąpień SQL Server używanych przez Azure DevOps Server danych. Jeśli wdrożenie jest zintegrowane z programem SharePoint i używasz opcji /delete, musisz być również członkiem grupy Administratorzy farmy dla farmy SharePoint, z której usuwasz kolekcję lokacji.

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Aby interaktywnie zarządzać kolekcjami lub tworzyć kolekcje, można użyć węzła Kolekcje Project w konsoli administracyjnej programu Azure DevOps. Zobacz Zarządzanie kolekcjami projektów.

Przykłady

W poniższym przykładzie pokazano, jak trwale usunąć kolekcję projektów "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ę projektów "Contoso Summer Interns Projects", nazwać ją "Contoso 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 programu TFS 2015.2 i nowszych wersji.

Polecenie columnStoreIndex służy do włączania lub wyłączania indeksów magazynu kolumn dla baz danych używanych przez Azure DevOps Server wdrożenia.

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

Wymagania wstępne

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

Uwagi

Zazwyczaj używasz polecenia columnStoreIndex, jeśli przenosisz bazę danych z wystąpienia usługi SQL które obsługuje indeks magazynu kolumn do tego, który tego nie zrobił. W takim przypadku należy wyłączyć wszystkie indeksy magazynu kolumn przed pomyślnym przeniesieniem baz danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia usługi SQL, które obsługuje indeks magazynu kolumn, możesz ponownie włączyć indeks magazynu kolumn w celu zaoszczędnia miejsca i uzyskania wydajności.

Przykład

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

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

Polecenie ColumnStoreIndex służy do włączania lub wyłączania indeksów 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 jest włączanie lub wyłączanie indeksu magazynu kolumn dla danego SQL i bazy danych.

/sqlInstance

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

W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName

/databaseName

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

Wymagania wstępne

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

Uwagi

Zazwyczaj używa się polecenia ColumnStoreIndex, jeśli baza danych jest przenosłana z SQL, które obsługuje indeks magazynu kolumn do tego, który nie został. W takim przypadku należy wyłączyć wszystkie indeksy magazynu kolumn przed pomyślnym przeniesieniem baz danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia usługi SQL, które obsługuje indeks magazynu kolumn, możesz ponownie włączyć indeks magazynu kolumn w celu zaoszczędnia miejsca i uzyskania wydajności.

Przykład

W poniższym przykładzie pokazano, jak włączyć indeks magazynu kolumn dla bazy danych o nazwie TFS DefaultCollection w wystąpieniu usługi SQL uruchomionym na serwerze o nazwie "ContosoMain" w nazwanych wystąpieniach _ "TeamDatabases".

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

ConfigureMail (Konfiguracja Poczty) Skonfiguruj serwer z uruchomionym programem Azure DevOps Server do używania istniejącego serwera SMTP na użytek alertów e-mail.TfsConfig configureMail /Enabled:<true|false> /FromEmailAddress:<emailAddress> /SmtpHost:<SMTPHostName>### Wymagania wstępneAby użyć polecenia configureMail, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation na Azure DevOps w warstwie aplikacji. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Informacje o uprawnieniach dla Azure DevOps Server### UwagiZa pomocą konsoli administracyjnej można również skonfigurować Azure DevOps Server do korzystania z serwera SMTP.### PrzykładW poniższym przykładzie przedstawiono składnię używaną do konfigurowania adresu e-mail na i TFS@contoso.com serwera poczty SMTP jako ContosoMailServer :TfsConfig configureMail /FromEmailAddress:TFS@contoso.com /SmtpHost:ContosoMailServer


DBCompression

Polecenie dbCompression służy do włączania lub wyłączania kompresji strony bazy danych dla baz danych używanych Azure DevOps Server wdrożenia.

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

Wymagania wstępne

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

Uwagi

Zazwyczaj polecenia dbCompression używa się w przypadku przenoszenia bazy danych z wystąpienia usługi SQL które obsługuje kompresję do tej, która nie jest 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 usługi SQL, które obsługuje kompresję, możesz ponownie włączyć kompresję, aby zaoszczędzić miejsce.

To polecenie zmienia tylko to, czy Azure DevOps Server preferuje kompresję strony bazy danych, czy nie — bazy danych muszą być nadal hostowane w wystąpieniu usługi 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 przebudowanym w trybie online dla bazy danych o nazwie w wystąpieniu usługi SQL uruchomionym na serwerze o nazwie w TFS_DefaultCollection ContosoMain nazwanym wystąpieniu TeamDatabases .

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

Aby uzyskać informacje o programie TFS 2012 i jego starszych wersjach, zobacz https://support.microsoft.com/kb/2712111 .

Polecenie DBCompression służy do włączania lub wyłączania kompresji strony bazy danych dla baz danych używanych przez Azure DevOps Server wdrożenia.

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

Opcja

Opis

/pageCompression

Określa, czy jest w przypadku włączania lub wyłączania kompresji strony dla danego SQL i bazy danych.

/sqlInstance

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

W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName

/databaseName

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

/rebuildNow

Opcjonalny. Określa, czy indeksy bazy danych powinny zostać natychmiast ponownie skompresowane (skompresowane lub zdekompresowane w razie potrzeby). Jeśli nie zostanie użyty, indeksy zostaną ponownie skonsolidowane przez zadanie w tle, które jest uruchamiane co tydzień.

/offline

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

Wymagania wstępne

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

Uwagi

Zazwyczaj polecenia DBCompression używa się w przypadku przenoszenia bazy danych z wystąpienia usługi SQL które obsługuje kompresję do tej, która nie jest 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 usługi SQL, które obsługuje kompresję, możesz ponownie włączyć kompresję, aby zaoszczędzić miejsce.

To polecenie zmienia tylko to, czy Azure DevOps Server preferuje kompresję strony bazy danych, czy nie — bazy danych muszą być nadal hostowane w wystąpieniu usługi 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 przebudowanym w trybie online dla bazy danych o nazwie TFS DefaultCollection w wystąpieniu programu SQL uruchomionym na serwerze o nazwie "ContosoMain" w nazwanym wystąpieniu _ "TeamDatabases".

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

DeleteTestResults

Polecenie deleteTestResults umożliwia usunięcie starych przechowywanych wyników testów z magazynu kolekcji. Zwykle ma to na celu zmniejszenie rozmiaru magazynu lub skrócenie czasu 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 będą w wersji zapoznawczej.
sqlInstance Nazwa serwera, który hostuje bazę danych, dla której są usuwane lub przeglądane wyniki testów, oraz nazwa wystąpienia, jeśli używane jest wystąpienie inne niż domyślne. W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName .
Databasename Nazwa bazy danych, dla której są usuwane lub przeglądane wyniki testów.
typ Opcjonalny. Typ wyników testów do usunięcia. Prawidłowe wartości są automatyczne, ręczne i wszystkie.
preview Opcjonalny. Wyświetl liczbę wyników testów, które zostałyby 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 SQL Server wystąpienia.

Uwagi

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

Przykład

W poniższym przykładzie pokazano, jak usunąć wyniki testu ręcznego starsze niż 60 dni dla bazy danych o nazwie w wystąpieniu SQL uruchomionym na serwerze o nazwie w TFS_DefaultCollection ContosoMain nazwanych wystąpieniach TeamDatabases .

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

Dostępność poleceń: TFS 2017 i nowsze

Polecenie DeleteTestResults umożliwia usunięcie starych przechowywanych wyników testów z magazynu kolekcji. Zwykle ma to na celu zmniejszenie rozmiaru magazynu lub skrócenie czasu 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 będą w wersji zapoznawczej.

/sqlInstance

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

W przypadku określenia wystąpienia należy użyć formatu: ServerName\InstanceName

/databaseName

Nazwa bazy danych, dla której są usuwane lub przeglądane wyniki testów.

/type

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

/preview

Opcjonalny. Wyświetl liczbę wyników testów, które zostałyby 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 SQL Server wystąpienia.

Uwagi

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

Przykład

W poniższym przykładzie pokazano, jak usunąć wyniki testu ręcznego starsze niż 60 dni dla bazy danych o nazwie TFS DefaultCollection w wystąpieniu programu SQL uruchomionym na serwerze o nazwie "ContosoMain" w nazwanych wystąpieniach _ "TeamDatabases".

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

DeploymentPool

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 lub zmienia identyfikator zabezpieczeń (SID) użytkowników i grup we wdrożeniu usługi 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 musisz uruchamiać tego polecenia, jeśli zmieniasz domeny w tym samym lesie usługi Active Directory. Azure DevOps Server automatycznie obsłuży zmiany identyfikatora SID dla przenosi 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 listy.
fromdomain Wymagane w przypadku używania /change. Określa oryginalną domenę tożsamości, które chcesz zmienić. W przypadku zmiany ze środowiska grupy roboczej program określa nazwę komputera.
todomain Wymagane w przypadku używania /change. Określa domenę, do której chcesz zmienić tożsamości. W przypadku zmiany na środowisko grupy roboczej program określa nazwę komputera.
account Określa nazwę konta, dla którego chcesz wyświetlić lub zmienić tożsamości.
toaccount Określa nazwę konta, na które chcesz zmienić tożsamości.
SQLInstance Określa nazwę serwera, na którym działa SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. W przypadku określenia wystąpienia należy 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 programu Team Foundation i członkiem roli sysadmin dla wszystkich wystąpień usługi SQL Server, które Team Foundation Server używane. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

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

Po zmianie tożsamości docelowe konto lub konta muszą już istnieć w Windows.

Należy poczekać na następną synchronizację tożsamości z Windows, zanim właściwości kont zmienianych za pomocą tego polecenia zostaną zaktualizowane. To wymaganie obejmuje zmiany z grupy na użytkownika, użytkownika na grupę 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 usług Windows przechowywanych w programie Azure DevOps Server oraz czy identyfikator SID dla każdego użytkownika lub grupy jest taki Windows. Administratorzy domeny Contoso1 tworzyli grupy domen, takie jak i , aby ułatwić zarządzanie uprawnieniami między Contoso1\\Developers Contoso1\\Testers 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 domenie Azure DevOps Server z domeny Contoso1 na identyfikatory SID dla kont, które mają pasujące nazwy w ContosoPrime domenie. Tylko nazwy kont, które są zgodne, będą mieć zaktualizowane identyfikatory SID. Jeśli na przykład konto istnieje jako i , identyfikator SID konta hholt zostanie zmieniony na identyfikator SID dla Contoso1\hholt ContosoPrime\hholt . ContosoPrime\hholt Jeśli konto ContosoPrime\hholt nie istnieje, identyfikator SID nie zostanie zaktualizowany dla . Contoso1\hholt

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

W poniższym przykładzie pokazano, jak zmienić konto dla pojedynczego konta użytkownika na konto Contoso1\hholt 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 konta usługi używanego we wdrożeniu usługi Azure DevOps Server podczas zmiany domeny wdrożenia NT AUTHORITY\NETWORK SERVICE 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 na konto domeny w nowej domenie , a następnie zmienić konto z powrotem na USŁUGA SIECIOWA na serwerze NT AUTHORITY\NETWORK SERVICE TempSVC w nowej domenie. Baza danych konfiguracji jest hostowana na serwerze o nazwie ContosoMain w nazwanych wystąpieniach 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 lub zmienia identyfikator zabezpieczeń (SID) użytkowników i grup we wdrożeniu programu TFS. 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 musisz uruchamiać tego polecenia, jeśli zmieniasz domeny w tym samym lesie usługi Active Directory. Azure DevOps Server automatycznie obsłuży zmiany identyfikatora SID dla przenosi 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 listy.

/fromdomain: Nazwa_domeny

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

/todomain: Nazwa_domeny

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

/account: Accountname

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

/toaccount: Accountname

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

/SQLInstance: Nazwa_serwera

Określa nazwę serwera, na którym działa SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. W przypadku określenia wystąpienia należy 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ą grupy dostępności AlwaysOn w SQL Server. Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w parametrów połączenia.

Aby uzyskać więcej informacji, zobacz [Zawsze włączone grupy dostępności (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 programu Team Foundation i członkiem roli sysadmin dla wszystkich wystąpień usługi SQL Server, które Azure DevOps Server używane. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

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

Po zmianie tożsamości docelowe konto lub konta muszą już istnieć w Windows.

Należy poczekać na następną synchronizację tożsamości z Windows, zanim właściwości kont zmienianych za pomocą tego polecenia zostaną zaktualizowane. To wymaganie obejmuje zmiany z grupy na użytkownika, użytkownika na grupę 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 usług Windows przechowywanych w programie Azure DevOps Server oraz czy identyfikator SID dla każdego użytkownika lub grupy jest taki Windows. Administratorzy domeny Contoso1 tworzyli grupy domen, takie jak "Deweloperzy Contoso1" i "Testerzy Contoso1", aby ułatwić zarządzanie uprawnieniami w usługach \ \ Azure DevOps Server, SQL Server Reporting Services i SharePoint Products.

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 domenie 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ą mieć zaktualizowane identyfikatory SID. Na przykład, jeśli konto "h nie" istnieje jako Contoso1 h dostęp i ContosoPrime h nie, identyfikator SID konta zostanie zmieniony na identyfikator SID dla \ \ ContosoPrime \ htolt. Jeśli konto "ContosoPrime h nie istnieje", identyfikator SID nie zostanie zaktualizowany dla klienta \ \ Contoso1.

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

W poniższym przykładzie pokazano, jak zmienić konto dla pojedynczego konta użytkownika Contoso1 h nie na konto 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 konta usługi "NT AUTHORITY NETWORK SERVICE" używanego we wdrożeniu programu 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 zmień konto usługi z USŁUGI SIECIOWEJ NT AUTHORITY na konto domeny w nowej domenie (TempSVC), a następnie zmień konto z powrotem na USŁUGA SIECIOWA na serwerze w nowej \ domenie. Baza danych konfiguracji jest hostowana na serwerze o nazwie "ContosoMain" w nazwanych wystąpieniach "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 jobs można utworzyć plik dziennika, który zawiera szczegółowe informacje o najnowszym 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 dla określonej kolekcji projektów zostanie ponownie podane zadanie. Jeśli używasz tej opcji, należy również użyć /CollectionName lub /CollectionID opcji.
dumplog Wymagane, jeśli /retry nie jest używany. Określa, że najnowsze działanie zadania dla kolekcji zostanie wysłane do pliku dziennika. Jeśli używasz tej opcji, należy również użyć opcji /CollectionName lub /CollectionID.
CollectionName Wymagane, jeśli /CollectionID nie jest używany. Określa nazwę kolekcji, dla której zostanie ponowiona ponowna próba ostatniego zadania (/retry) 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 zostanie ponowiona ponowna próba ostatniego zadania (/retry) lub rejestrowana (/dumplog).

Wymagania wstępne

Aby użyć zadania polecenia, musi być członkiem grupy zabezpieczeń Azure DevOps Administratorzy. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Aby interaktywnie ponowić próbę wykonania zadania, możesz otworzyć konsolę administracyjną usługi Azure DevOps, wybrać kartę Stan dla kolekcji, a następnie wybrać pozycję Ponów próbę wykonania zadania. Aby uzyskać więcej informacji, zobacz Open the Azure DevOps Administration Console.

Przykład

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

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

Za pomocą polecenia Zadania można utworzyć plik dziennika, który zawiera szczegółowe informacje o najnowszym 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

/ponów próbę

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

/dumplog

Wymagane, jeśli /retry nie jest używany. Określa, że najnowsze działanie zadania dla kolekcji zostanie wysłane do pliku dziennika. Jeśli używasz tej opcji, należy 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 zostanie ponowiona ponowna próba ostatniego zadania (/retry) 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 zostanie ponowiona ponowna próba ostatniego zadania (/retry) lub rejestrowana (/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 Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Aby interakcyjnie ponowić próbę wykonania zadania, możesz otworzyć konsolę administracyjną usługi Azure DevOps, kliknąć kartę Stan kolekcji, a następnie kliknąć pozycję Ponów zadanie. Aby uzyskać więcej informacji, zobacz Open the Azure DevOps Administration Console.

Przykład

W poniższym przykładzie pokazano, jak utworzyć plik dziennika, który zawiera listę najnowszych działań zadania dla kolekcji projektów "Contoso Summer Intern Projects" w Azure DevOps Server.

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

Laboratorium /delete

Użyj opcji TfsConfig Lab /Delete, aby usunąć wszystkie hosty grup, udziały biblioteki i środowiska z określonej kolekcji projektów. Domyślnie skojarzone obiekty w programie System Center Virtual Machine Manager (SCVMM) nie są usuwane. Możesz dodać opcję /External do wiersza polecenia, aby usunąć obiekty z kolekcji projektu i z programu SCVMM.

TfsConfig Lab /Delete /CollectionName:collectionName [/External] [/NoPrompt]
Opcja Opis
CollectionName:collectionName Wymagane. Określa nazwę kolekcji projektów w warstwie aplikacji Azure DevOps Server.
Zewnętrznych Opcjonalny. Jeśli jest określony, usuwa biblioteki udziałów i grup hostów w programie SCVMM oprócz obiektów w kolekcji projektu. Gdy /External nie zostanie określony, TfsConfig Lab /Delete polecenie usuwa tylko obiekty w kolekcji projektu.
NoPrompt Opcjonalny. Jeśli jest określony, nie wyświetla informacji o postępie i sukcesie.

Uwagi

Użyj polecenia /Delete, aby usunąć zasoby laboratorium z kolekcji projektów, gdy chcesz odłączyć konfigurację laboratorium kolekcji projektów. Jest to przydatne podczas przenoszenia kolekcji projektów z jednego Azure DevOps Server do innego, gdzie nowe wystąpienie Azure DevOps Server używa innego serwera SCVMM niż oryginalny. W takim przypadku musisz usunąć wszystkie zasoby laboratorium i ponownie skonfigurować laboratorium dla kolekcji projektów.

Uwaga

Opcja /Delete działa na wszystkich zasobami laboratorium w kolekcji projektów tylko wtedy, gdy opcje /LibraryShare i /GroupHost nie są określone w wierszu polecenia. Aby uzyskać więcej informacji, zobacz TfSConfig Lab /LibraryShare Commands (Laboratorium TFSConfig /LibraryShare) i TFSConfig Lab /HostGroup Commands (Polecenia /HostGroup).

Przykład

W poniższym przykładzie wszystkie obiekty laboratorium w kolekcji projektów DefaultCollection zostaną usunięte. Ponieważ /External opcja nie jest określona, obiekty są zachowywane w SCVMM.

tfsconfig lab /delete /collectionName:DefaultCollection

Użyj opcji TfsConfig Lab /Delete, aby usunąć wszystkie hosty grup, udziały biblioteki i środowiska z określonej kolekcji projektów. Domyślnie skojarzone obiekty w programie System Center Virtual Machine Manager (SCVMM) nie są usuwane. Możesz dodać opcję /External do wiersza polecenia, aby usunąć obiekty z kolekcji projektu i z programu SCVMM.

TfsConfig Lab /Delete /CollectionName:collectionName [/External] [/NoPrompt]
Opcja Opis
CollectionName:collectionName Wymagane. Określa nazwę kolekcji projektów w warstwie aplikacji Azure DevOps Server.
Zewnętrznych Opcjonalny. Jeśli jest określony, usuwa biblioteki udziałów i grup hostów w programie SCVMM oprócz obiektów w kolekcji projektu. Gdy /External nie zostanie określony, TfsConfig Lab /Delete polecenie usuwa tylko obiekty w kolekcji projektu.
NoPrompt Opcjonalny. Jeśli jest określony, nie wyświetla informacji o postępie i sukcesie.

Uwagi

Użyj polecenia /Delete, aby usunąć zasoby laboratorium z kolekcji projektów, gdy chcesz odłączyć konfigurację laboratorium kolekcji projektów. Jest to przydatne podczas przenoszenia kolekcji projektów z jednego Azure DevOps Server do innego, gdzie nowe wystąpienie Azure DevOps Server używa innego serwera SCVMM niż oryginalny. W takim przypadku musisz usunąć wszystkie zasoby laboratorium i ponownie skonfigurować laboratorium dla kolekcji projektów.

Uwaga

Opcja /Delete działa na wszystkich zasobami laboratorium w kolekcji projektów tylko wtedy, gdy opcje /LibraryShare i /GroupHost nie są określone w wierszu polecenia. Aby uzyskać więcej informacji, zobacz TFSConfig Lab /LibraryShare Commands(.. /tfsconfig-cmd.md#lab-libraryshare) i polecenia laboratorium TFSConfig Lab /HostGroup.

Przykład

W poniższym przykładzie wszystkie obiekty laboratorium w kolekcji projektów DefaultCollection zostaną usunięte. Ponieważ /External opcja nie jest określona, obiekty są zachowywane w SCVMM.

tfsconfig lab /delete /collectionName:DefaultCollection

Laboratorium /dns

TfsConfig Lab /DNS polecenie dodaje, usuwa lub wyświetla rekordy DNS, które zostały utworzone przez Visual Studio Lab Management dla środowisk izolowanych sieci.

    TfsConfig Lab /DNS 
    {/Add | /Delete | /List}
        [/CollectionName:collectionName |
        / CollectionName:collectionName /TeamProject:projectName |
        / CollectionName:collectionName /TeamProject:projectName /LabEnvironment:environmentUri |
        /Name:FQDN /IP:IpAddress]
        [/NoPrompt]
Opcja Opis
Dodaj Dodaje określone rekordy DNS. Aby użyć opcji /Add, środowiska docelowe muszą być uruchomione.
Usuwanie Usuwa określone rekordy DNS.
Lista Wyświetla określone rekordy DNS.
LabEnvironment: environmentUri Dotyczy opcji /Add, /Delete lub /List dla pojedynczego środowiska izolowanego od sieci, które jest określone przez environmentUri.

Aby użyć opcji LabEnvironment, należy również określić opcje /Collection i /TeamProject.
TeamProject: projectName W przypadku użycia bez opcji /LabEnvironment program określa opcje /Add, /Delete lub /List we wszystkich środowiskach izolowanych od sieci w projekcie określonym przez parametr projectName. W przeciwnym razie /TeamProject określa projekt, który zawiera środowisko.

Aby użyć /TeamProject opcji, należy również określić /Collection opcji
CollectionName: collectionName W przypadku użycia bez opcji /TeamProject program określa opcje /Add, /Delete lub /List we wszystkich środowiskach izolowanych od sieci w kolekcji projektu określonej przez parametr collectionName. W przeciwnym razie /Collection określa kolekcję projektu, która zawiera projekt.
Nazwa: FQDN Określa w pełni kwalifikowaną nazwę domeny lokalizacji sieciowej zawierającej środowisko docelowe.

Należy określić /Name i /IP opcje razem.
Adres IP: Ipaddress Określa adres IP środowiska docelowego.

Należy określić /Name i /IP opcje razem.

Uwagi

Azure DevOps Server używa sufiksu, który jest wprowadzany podczas rejestrowania unikatowej nazwy zewnętrznej w systemie DNS dla każdej maszyny wirtualnej w środowisku izolowanym od sieci. Rekord aliasu DNS umożliwia maszynom i innym obiektom spoza sieci izolowanej komunikowanie się z maszynami w sieci izolowanej. Ponieważ Azure DevOps Server do strefy DNS w celu zarejestrowania rekordu aliasu, konto usługi, w ramach którego działa program Azure DevOps, musi mieć uprawnienia do dodawania lub usuwania rekordów aliasów w określonej strefie DNS.

Jeśli wdrożenie usługi Team Foundation Server ma więcej niż jedną warstwę aplikacji, a każda warstwa aplikacji działa na innym koncie usługi, każde konto usługi w warstwie aplikacji musi mieć uprawnienia do edytowania rekordów aliasów DNS utworzonych przez inne warstwy aplikacji.

Uwaga

Zarządzanie rekordami DNS jest wykonywane automatycznie przez Lab Management. /DNS polecenia należy używać tylko w następujących sytuacjach:

  • Zmieniasz konto, na którym Azure DevOps Server uruchamiane.
  • Kolekcję projektu można przenieść z jednego wystąpienia Azure DevOps Server do innego.

W obu tych przypadkach należy usunąć rekordy DNS utworzone przy użyciu starego konta usługi Azure DevOps Server, a następnie ponownie utworzyć te same rekordy DNS przy użyciu nowego konta usługi Azure DevOps Server. Jeśli te kroki nie są wykonywane w poprzednich scenariuszach, nowe konto usługi Azure DevOps Server nie będzie w stanie wykonać automatycznego zarządzania tymi rekordami DNS. W związku z tym użytkownicy nie będą mogli łączyć się ze środowiskami wirtualnymi.

Określ tylko jedną z opcji /Add, /Delete lub /List w wierszu polecenia TfsConfig Lab /DNS. Jeśli nie określisz żadnych opcji docelowych, operacja działa na wszystkich maszynach wirtualnych we wszystkich środowiskach izolowanych sieci, które należą do wszystkich kolekcji projektów w Team Foundation Server danych.

Aby kierować wpisy DNS w środowiskach izolowanych sieci obiektu w hierarchii obiektów usługi Lab Management, użyj odpowiedniej kombinacji opcji /Collection, /TeamProject i /LabEnvironment

  • Opcja /LabEnvironment służy do polecenia w określonym środowisku izolowanym od sieci. Należy użyć opcji /CollectionName i /TeamProject z opcją /LabEnvironment, aby określić kolekcję projektu i projekt, który zawiera środowisko.

    Użyj formatu vstfs:///LabManagement/LabEnvironment/ environmentID, aby określić adres URI środowiska. Identyfikator środowiska (environmnetID) można wyświetlić w podglądzie środowiska programu Lab Management lub w opisie maszyny wirtualnej w programie SCVMM konsola administratora.

  • Opcja /TeamProject dotyczy operacji w izolowanych środowiskach sieciowych w określonym projekcie. Opcja /TeamProject musi być używana z opcją /CollectionName, a opcja /CollectionName musi określać kolekcję projektu, która zawiera projekt.

  • Opcja /CollectionName określa operację na izolowanych środowiskach sieciowych w określonej kolekcji projektów.

Drugim sposobem określania środowiska izolowanego sieci jest użycie opcji /Name i /IP w celu określenia w pełni kwalifikowanej nazwy zewnętrznej i zewnętrznego adresu IP poszczególnych maszyn wirtualnych. Należy określić zarówno /Name i /IP opcje w wierszu polecenia. Nazwę zewnętrzną i zewnętrzny adres IP maszyny wirtualnej można wyświetlić w Podglądzie środowiska programu Lab Management lub w opisie maszyny wirtualnej w programie SCVMM konsola administratora.

Przykłady

W pierwszym przykładzie rekordy dla wszystkich środowisk izolowanych od sieci w projekcie są dodawane do systemu DNS. W drugim przykładzie pojedynczy rekord DNS jest usuwany.

tfsconfig lab /dns /add /collectionname:Collection0 /teamproject:Project1
tfsconfig lab /dns /delete /name:0b668996-2736-46d2-88ac-0733acbd0d9c.contoso.com /ip:111.00.000.000

TfsConfig Lab /DNS polecenie dodaje, usuwa lub wyświetla rekordy DNS, które zostały utworzone przez Visual Studio Lab Management dla środowisk izolowanych sieci.

TfsConfig Lab /DNS 
{/Add | /Delete | /List}
    [/CollectionName:collectionName |
    / CollectionName:collectionName /TeamProject:projectName |
    / CollectionName:collectionName /TeamProject:projectName /LabEnvironment:environmentUri |
    /Name:FQDN /IP:IpAddress]
    [/NoPrompt]
Opcja Opis
Dodaj Dodaje określone rekordy DNS. Aby użyć opcji /Add, środowiska docelowe muszą być uruchomione.
Usuwanie Usuwa określone rekordy DNS.
Lista Wyświetla określone rekordy DNS.
LabEnvironment: environmentUri Dotyczy opcji /Add, /Delete lub /List dla pojedynczego środowiska izolowanego od sieci, które jest określone przez environmentUri.

Aby użyć opcji LabEnvironment, należy również określić opcje /Collection i /TeamProject.
TeamProject: projectName W przypadku użycia bez opcji /LabEnvironment program określa opcje /Add, /Delete lub /List we wszystkich środowiskach izolowanych od sieci w projekcie określonym przez parametr projectName. W przeciwnym razie /TeamProject określa projekt, który zawiera środowisko.

Aby użyć /TeamProject opcji, należy również określić /Collection opcji
CollectionName: collectionName W przypadku użycia bez opcji /TeamProject program określa opcje /Add, /Delete lub /List we wszystkich środowiskach izolowanych od sieci w kolekcji projektu określonej przez parametr collectionName. W przeciwnym razie /Collection określa kolekcję projektu, która zawiera projekt.
Nazwa: FQDN Określa w pełni kwalifikowaną nazwę domeny lokalizacji sieciowej zawierającej środowisko docelowe.

Należy określić /Name i /IP opcje razem.
Adres IP: Ipaddress Określa adres IP środowiska docelowego.

Należy określić /Name i /IP opcje razem.

Uwagi

Azure DevOps Server używa sufiksu, który jest wprowadzany podczas rejestrowania unikatowej nazwy zewnętrznej w systemie DNS dla każdej maszyny wirtualnej w środowisku izolowanym od sieci. Rekord aliasu DNS umożliwia maszynom i innym obiektom spoza sieci izolowanej komunikowanie się z maszynami w sieci izolowanej. Ponieważ Azure DevOps Server do strefy DNS w celu zarejestrowania rekordu aliasu, konto usługi, w ramach którego działa program Azure DevOps, musi mieć uprawnienia do dodawania lub usuwania rekordów aliasów w określonej strefie DNS.

Jeśli wdrożenie usługi Azure DevOps Server ma więcej niż jedną warstwę aplikacji, a każda warstwa aplikacji działa na innym koncie usługi, każde konto usługi w warstwie aplikacji musi mieć uprawnienia do edytowania rekordów aliasów DNS utworzonych przez inne warstwy aplikacji.

Uwaga

Zarządzanie rekordami DNS jest wykonywane automatycznie przez Lab Management. /DNS polecenia należy używać tylko w następujących sytuacjach:

  • Zmieniasz konto, na którym Azure DevOps Server uruchamiane.
  • Kolekcję projektu można przenieść z jednego wystąpienia Azure DevOps Server do innego.

W obu tych przypadkach należy usunąć rekordy DNS utworzone przy użyciu starego konta usługi Azure DevOps Server, a następnie ponownie utworzyć te same rekordy DNS przy użyciu nowego konta usługi Azure DevOps Server. Jeśli te kroki nie są wykonywane w poprzednich scenariuszach, nowe konto usługi Azure DevOps Server nie będzie w stanie wykonać automatycznego zarządzania tymi rekordami DNS. W związku z tym użytkownicy nie będą mogli łączyć się ze środowiskami wirtualnymi.

Określ tylko jedną z opcji /Add, /Delete lub /List w wierszu polecenia TfsConfig Lab /DNS. Jeśli nie określisz żadnych opcji docelowych, operacja działa na wszystkich maszynach wirtualnych we wszystkich środowiskach izolowanych sieci, które należą do wszystkich kolekcji projektów w Azure DevOps Server danych.

Aby kierować wpisy DNS w środowiskach izolowanych sieci obiektu w hierarchii obiektów usługi Lab Management, użyj odpowiedniej kombinacji opcji /Collection, /TeamProject i /LabEnvironment

  • Opcja /LabEnvironment służy do polecenia w określonym środowisku izolowanym od sieci. Należy użyć opcji /CollectionName i /TeamProject z opcją /LabEnvironment, aby określić kolekcję projektu i projekt, który zawiera środowisko.

    Użyj formatu vstfs:///LabManagement/LabEnvironment/ environmentID, aby określić adres URI środowiska. Identyfikator środowiska (environmnetID) można wyświetlić w podglądzie środowiska programu Lab Management lub w opisie maszyny wirtualnej w programie SCVMM konsola administratora.

  • Opcja /TeamProject dotyczy operacji w izolowanych środowiskach sieciowych w określonym projekcie. Opcja /TeamProject musi być używana z opcją /CollectionName, a opcja /CollectionName musi określać kolekcję projektu, która zawiera projekt.

  • Opcja /CollectionName określa cel operacji w środowiskach izolowanych sieci w określonej kolekcji projektów.

Drugim sposobem ukierunkowania środowiska izolowanego sieci jest użycie opcji /Name i /IP w celu określenia w pełni kwalifikowanej nazwy zewnętrznej i zewnętrznego adresu IP poszczególnych maszyn wirtualnych. Należy określić zarówno /Name i /IP opcje w wierszu polecenia. Nazwę zewnętrzną i zewnętrzny adres IP maszyny wirtualnej można wyświetlić w Podglądzie środowiska programu Lab Management lub w opisie maszyny wirtualnej w programie SCVMM konsola administratora.

Przykłady

W pierwszym przykładzie rekordy dla wszystkich środowisk izolowanych od sieci w projekcie są dodawane do systemu DNS. W drugim przykładzie pojedynczy rekord DNS jest usuwany.

REM First example
tfsconfig lab /dns /add /collectionname:Collection0 /teamproject:Project1

REM Second example
tfsconfig lab /dns /delete /name:0b668996-2736-46d2-88ac-0733acbd0d9c.contoso.com /ip:111.00.000.000

Laboratorium /hostgroup

Użyj poleceń TfsConfig Lab /HostGroup, aby dodać, edytować lub usunąć przypisanie grupy hostów System Center Virtual Machine Manager (SCVMM) do kolekcji projektów.

Grupy hostów przypisane w ten sposób są zarządzane przez Visual Studio Lab Management.

TfsConfig Lab /hostgroup /CollectionName:collectionName
  { /Add 
/SCVMMHostGroup:vmmHostPath 
/Name:name 
[LabEnvironmentPlacementPolicy:{Conservative|Aggressive}]
[/AutoProvision:{True|False}]
[/DNSSuffix:dnsSuffix]
| /Delete 
/Name:name
[/NoPrompt]
| /Edit 
/Name:name
{[/AutoProvision:{True|False}] 
[/LabEnvironmentPlacementPolicy:{Conservative|Aggressive}] 
[/DNSSuffix:dnsSuffix]}
[/NoPrompt]]
| /List
| /ListSCVmmHostGroups }

Opcja

Opis

CollectionName: collectionName

Wymagane. Nazwa kolekcji projektów w warstwie aplikacji Azure DevOps Server.

Dodaj

Dodaje określoną grupę hostów SCVMM do grup hostów kolekcji projektów. Opcje /SCVmmHostGroup i /Name należy określić za pomocą opcji Dodaj.

Usuwanie

Usuwa określoną grupę hostów z kolekcji projektów. Należy określić /Name opcji Usuń .

Edytuj

Ustawia jedną lub obie właściwości Lab Management AutoProvision i LabEnvironmentPlacementPolicy dla grupy hostów.

Należy określić opcję /Name i co najmniej jedną z opcji /AutoProvision lub /LabEnvironmentPlacementPolicy za pomocą opcji Edytuj.

SCVMMHostGroup:vmmH ostGroupPath

Wymagane z opcją /Add. Określa ścieżka hosta grupy hostów SCVMM.

Nazwa: nazwa

Wymagane z opcjami /Add, /Delete lub /Edit. Określ nazwę grupy hostów kolekcji projektów, która ma być dodawania, usuwania lub edytowania.

Autoprovision:{True | False}

Opcjonalnie z /Add lub /Edit opcje. Ustawia (True) lub czyszczy (Fałsz) właściwość AutoProvision grupy hostów. AutoProvision określa, czy grupa hostów jest automatycznie przypisywana do każdego projektu w kolekcji. Domyślnie grupy hostów są przypisywane do projektów w kolekcji, gdy używasz polecenia TfsConfig Lab/HostGroup.

LabEnvironmentPlacementPolicy:{Przejrzany | agresywny}

Opcjonalnie z /Add lub /Edit opcje. Określa, Lab Management traktuje maszyny fizyczne w grupie hostów, w której wdraża nowe środowiska laboratorium wirtualnego.

  • Zachowawczy (wartość domyślna). W decyzjach dotyczących wdrażania należy wziąć pod uwagę nie działające środowiska wirtualne. Obejmuje to wszystkie maszyny wirtualne, które są częścią środowisk, które są również w " stanie " Zatrzymane.
  • Agresywne Podczas podejmowania decyzji dotyczących wdrażania nie należy uwzględniać nie uruchomionych środowisk wirtualnych.

DNSSuffix:[dnsSuffix]

Opcjonalny. Zestawy lub sufiks DNS komputerów wirtualnych w grupie hostów.

  • Jeśli /DNSSuffix: opcja jest określona bez wartości dnsSuffix, ustawia lub resetuje sufiks DNS sufiks komputerów wirtualnych do sufiksu komputera hosta w grupie hostów.
  • Jeśli /DNSSuffix opcja nie zostanie określona z /Add opcji, sufiks komputerów wirtualnych są ustawione na sufiksy ich komputerów hostów w grupie hostów.
  • Jeśli /DNSSuffix opcja nie zostanie określona z /Edit opcji, sufiks komputerów wirtualnych nie zostanie zmieniony.

NoPrompt

Opcjonalnie z /Delete lub /Edit opcje. Nie monituj użytkownika o potwierdzenie.

Lista

Przedstawia grupy hostów przypisane do kolekcji projektów.

ListSCVmmHostGroups

Przedstawia grupy hostów dostępne w programie SCVMM.

Uwagi

Grupy hostów to kontenery, które administrator tworzy w programie SCVMM w celu grupowania zestawu hostów maszyn wirtualnych w celu łatwego zarządzania.

Grupy hostów są hierarchiczne; Grupa hostów może zawierać inne grupy hostów.

Każda grupa hostów jest identyfikowana przez ścieżka hosta, sekwencję nazw grup hostów, która określa lokalizację hosta lub grupy hostów w hierarchii grup hostów w programie SCVMM.

Wszystkie ścieżki hostów rozpoczynają się od głównej grupy hostów.

Na przykład ścieżka hosta, że host VMHost05 należy do grupy hostów Site21, która jest podrzędną grupą hostów grupy hostów All Hosts\\New York\\Site21\\VMHost05 Nowy Jork.

W wierszu polecenia użyj tylko jednej z opcji /Add, /Delete lub /Edit. Użyj oddzielnych wierszy poleceń TfsConfig Lab /HostGroup, aby przypisać wiele grup hostów do kolekcji projektów.

Możesz również użyć poleceń TfsConfig Lab /HostGroup, aby ustawić właściwości specyficzne dla Lab Management:

  • AutoProvision określa, czy grupa hostów jest przypisana do każdego projektu w kolekcji projektu.

Domyślnie automatyczna aprowizcja jest włączona.

Aby przypisać grupę hostów w kolekcji projektów do pojedynczego projektu, użyj polecenia TFSLabConfig CreateTeamProjectHostGroup.

  • True (wartość domyślna). Grupa hostów jest przypisywana do każdego projektu w kolekcji projektów.

  • Fałsz. Grupa hostów nie jest przypisana do każdego projektu w kolekcji projektu.

  • LabEnvironmentPlacementPolicy określa, Lab Management uwzględnia istniejące maszyny wirtualne podczas wdrażania nowych środowisk na maszynie fizycznej w grupie hostów.

  • Zachowawczy (wartość domyślna). W decyzjach dotyczących wdrażania należy wziąć pod uwagę nie działające środowiska wirtualne. Obejmuje to wszystkie maszyny wirtualne, które są częścią środowisk i są również w stanie "Zatrzymano".

  • Agresywne Podczas podejmowania decyzji dotyczących wdrażania nie należy uwzględniać nie uruchomionych środowisk wirtualnych.

  • DnsSuffix określa sufiks DNS do użycia dla komputerów wirtualnych utworzonych w grupie hostów. W poniższej tabeli opisano, jak sufiksy DNS komputerów wirtualnych są objęte ustawieniem /DNSSuffix.

DNSSuffix /Dodaj /Edit
DNSSuffix: dnsValue Sufiks DNS jest ustawiony na wartość dnsValue. Sufiks DNS jest ustawiony na wartość dnsValue.
DNSSuffix: Sufiks DNS jest dziedziczony z komputera hosta. Istniejąca wartość sufiksu jest usuwana, a sufiks DNS jest dziedziczony z komputera hosta.
<Nie określono> Sufiks DNS jest dziedziczony z komputera hosta. Sufiks DNS nie został zmieniony.

Przykład

W poniższym przykładzie grupa hostów SCVMM jest przypisana do kolekcji projektu.

Ponieważ /AutoProvision opcje nie są określone, grupa hostów jest automatycznie przypisywana do wszystkich projektów w kolekcji.

tfsconfig lab /hostgroup /add /scvmmhostgroup:"All Hosts\Lab1\HostGroup1" /collection:Collection0
        /name:Lab1Collection0_Lab1_HostGroup1

Użyj poleceń TfsConfig Lab /HostGroup, aby dodać, edytować lub usunąć przypisanie grupy hostów System Center Virtual Machine Manager (SCVMM) do kolekcji projektów.

Grupy hostów przypisane w ten sposób są zarządzane przez Visual Studio Lab Management.

TfsConfig Lab /hostgroup /CollectionName:collectionName
  { /Add 
/SCVMMHostGroup:vmmHostPath 
/Name:name 
[LabEnvironmentPlacementPolicy:{Conservative|Aggressive}]
[/AutoProvision:{True|False}]
[/DNSSuffix:dnsSuffix]
| /Delete 
/Name:name
[/NoPrompt]
| /Edit 
/Name:name
{[/AutoProvision:{True|False}] 
[/LabEnvironmentPlacementPolicy:{Conservative|Aggressive}] 
[/DNSSuffix:dnsSuffix]}
[/NoPrompt]]
| /List
| /ListSCVmmHostGroups }

Opcja

Opis

CollectionName: collectionName

Wymagane. Nazwa kolekcji projektów w warstwie aplikacji Azure DevOps Server.

Dodaj

Dodaje określoną grupę hostów SCVMM do grup hostów kolekcji projektów. Opcje /SCVmmHostGroup i /Name należy określić za pomocą opcji Dodaj.

Usuwanie

Usuwa określoną grupę hostów z kolekcji projektów. Należy określić /Name opcji Usuń .

Edytuj

Ustawia jedną lub obie właściwości Lab Management AutoProvision i LabEnvironmentPlacementPolicy dla grupy hostów.

Musisz określić opcję /Name i co najmniej jedną z opcji /AutoProvision lub /LabEnvironmentPlacementPolicy za pomocą opcji Edytuj.

SCVMMHostGroup:vmmH ostGroupPath

Wymagane z /Add opcji. Określa ścieżka hosta grupy hostów SCVMM.

Nazwa: name

Wymagany z opcjami /Add, /Delete lub /Edit. Określ nazwę grupy hostów kolekcji projektów, która ma być dodawania, usuwania lub edytowania.

AutoProvision:{True | False}

Opcjonalnie z /Add lub /Edit opcje. Sets (True) lub clears (False) (Fałsz) właściwości AutoProvision grupy hostów. AutoProvision określa, czy grupa hostów jest automatycznie przypisywana do każdego projektu w kolekcji. Domyślnie grupy hostów są przypisywane do projektów w kolekcji, gdy używasz polecenia TfsConfig Lab/HostGroup.

LabEnvironmentPlacementPolicy:{Przejrzany | agresywny}

Opcjonalnie z /Add lub /Edit opcje. Określa, Lab Management traktuje maszyny fizyczne w grupie hostów, w której wdraża nowe środowiska laboratoriów wirtualnych.

  • Zachowawczy (wartość domyślna). Podczas podejmowania decyzji dotyczących wdrażania należy wziąć pod uwagę nie działające środowiska wirtualne. Dotyczy to również wszystkich maszyn wirtualnych, które są częścią środowisk w " stanie " Zatrzymano.
  • Agresywne Podczas podejmowania decyzji dotyczących wdrażania nie należy uwzględniać nie uruchomionych środowisk wirtualnych.

DNSSuffix:[dnsSuffix]

Opcjonalny. Zestawy lub sufiks DNS komputerów wirtualnych w grupie hostów.

  • Jeśli /DNSSuffix: opcja jest określona bez wartości dnsSuffix, ustawia lub resetuje sufiks DNS sufiks komputerów wirtualnych do sufiksu komputera hosta w grupie hostów.
  • Jeśli /DNSSuffix nie określono opcji /Add, sufiks komputerów wirtualnych są ustawione na sufiksy ich komputerów-hostów w grupie hostów.
  • Jeśli /DNSSuffix nie określono opcji /Edit, sufiks komputerów wirtualnych nie zostanie zmieniony.

NoPrompt

Opcjonalne z /Delete lub /Edit opcje. Nie monituj użytkownika o potwierdzenie.

Lista

Przedstawia grupy hostów przypisane do kolekcji projektów.

ListSCVmmHostGroups

Przedstawia grupy hostów dostępne w programie SCVMM.

Uwagi

Grupy hostów to kontenery, które administrator tworzy w programie SCVMM w celu grupowania zestawu hostów maszyn wirtualnych w celu łatwego zarządzania.

Grupy hostów są hierarchiczne; grupa hostów może zawierać inne grupy hostów.

Każda grupa hostów jest identyfikowana przez ścieżka hosta, czyli sekwencję nazw grup hostów określającą lokalizację hosta lub grupy hostów w hierarchii grup hostów w programie SCVMM.

Wszystkie ścieżki hostów rozpoczynają się od głównej grupy hostów.

Na przykład identyfikator ścieżka hosta, że host VMHost05 należy do grupy hostów Site21, która jest podrzędną grupą hostów grupy hostów All Hosts\\New York\\Site21\\VMHost05 Nowy Jork.

W wierszu polecenia użyj tylko jednej z opcji /Add, /Delete lub /Edit. Użyj oddzielnych wierszy polecenia TfsConfig Lab /HostGroup, aby przypisać wiele grup hostów do kolekcji projektów.

Można również użyć poleceń TfsConfig Lab /HostGroup, aby ustawić właściwości specyficzne dla Lab Management:

  • Opcja AutoProvision określa, czy grupa hostów jest przypisana do każdego projektu w kolekcji projektów.

Domyślnie opcja AutoProvision jest włączona.

Aby przypisać grupę hostów w kolekcji projektów do pojedynczego projektu, użyj polecenia TFSLabConfig CreateTeamProjectHostGroup.

  • True (wartość domyślna). Grupa hostów jest przypisywana do każdego projektu w kolekcji projektów.

  • Fałsz. Grupa hostów nie jest przypisana do każdego projektu w kolekcji projektów.

  • LabEnvironmentPlacementPolicy określa, Lab Management uwzględnia istniejące maszyny wirtualne podczas wdrażania nowych środowisk na maszynie fizycznej w grupie hostów.

  • Zachowawczy (wartość domyślna). Podczas podejmowania decyzji dotyczących wdrażania należy wziąć pod uwagę nie działające środowiska wirtualne. Dotyczy to również wszystkich maszyn wirtualnych, które są częścią środowisk i są w stanie "Zatrzymano".

  • Agresywne Podczas podejmowania decyzji dotyczących wdrażania nie należy uwzględniać nie uruchomionych środowisk wirtualnych.

  • DnsSuffix określa sufiks DNS do użycia dla komputerów wirtualnych utworzonych w grupie hostów. W poniższej tabeli opisano, jak sufiksy DNS komputerów wirtualnych są objęte ustawieniem /DNSSuffix.

DNSSuffix /Dodaj /Edit
DNSSuffix: dnsValue Sufiks DNS jest ustawiony na wartość dnsValue. Sufiks DNS jest ustawiony na wartość dnsValue.
DNSSuffix: Sufiks DNS jest dziedziczony z komputera hosta. Istniejąca wartość sufiksu jest usuwana, a sufiks DNS jest dziedziczony z komputera-hosta.
<Nie określono> Sufiks DNS jest dziedziczony z komputera hosta. Sufiks DNS nie został zmieniony.

Przykład

W poniższym przykładzie grupa hostów SCVMM jest przypisywana do kolekcji projektów.

Ponieważ /AutoProvision opcje nie są określone, grupa hostów jest automatycznie przypisywana do wszystkich projektów w kolekcji.

tfsconfig lab /hostgroup /add /scvmmhostgroup:"All Hosts\Lab1\HostGroup1" /collection:Collection0
/name:Lab1Collection0_Lab1_HostGroup1

Laboratorium /libraryshare

Możesz użyć polecenia TfsConfig Lab /LibraryShare, aby dodać, usunąć lub edytować przypisanie udziału biblioteki z programu System Center Virtual Machine Manager (SCVMM) do kolekcji projektów. Można również użyć tego zestawu poleceń właściwości, które są specyficzne dla programu Visual Studio Lab Management i do wyświetlania biblioteki udziałów, które są aktualnie przypisane do kolekcji w programie Lab Management lub do wyświetlania wszystkich udziałów biblioteki w programie SCVMM.

TfsConfig Lab /LibraryShare
    /CollectionName:collectionName
     { /Add 
       /SCVMMLibraryShare:librarySharePath 
       /Name:name 
        [/AutoProvision:{True|False}]
    | /Delete 
       /Name:name 
        [/NoPrompt]
    | /Edit 
       /Name:name 
       /AutoProvision:{True|False} 
        [/NoPrompt]
    | /List
    | /ListSCVMMLibraryShares }
Opcja Opis
Dodaj Dodaje określony udział biblioteki do kolekcji projektów. Opcje /SCVMMLibraryShare i /Name należy określić za pomocą opcji Dodaj.
Usuwanie Usuwa określony udział biblioteki z kolekcji projektów. Należy określić /Name opcji Usuń .
Edytuj Ustawia lub czyszczy właściwość AutoProvision udziału biblioteki. Opcje /Name i /AutoProvision należy określić za pomocą opcji Edytuj.

Domyślnie udziały biblioteki są przypisywane do projektów w kolekcji.

Zmiana automatycznego aprowizowania ma wpływ na istniejące projekty.
CollectionName: collectionName Wymagane. Określ nazwę kolekcji projektów w warstwie aplikacji Azure DevOps Server.
SCVMMLibraryShare: librarysharePath Wymagane w przypadku dodawania . Określa ścieżkę do biblioteki ​Virtual Machine Manager biblioteki.
Nazwa: libraryShareName Wymagane w przypadku dodawania, usuwania i edytowania. Określa nazwę udziału biblioteki w kolekcji projektów.
Automatyczna aprowizcja Opcjonalnie z dodawaniem ; wymagana w przypadku edytowania. Określa, czy udziały biblioteki są automatycznie przypisywane do każdego projektu w kolekcji. Domyślnie udziały biblioteki są przypisane do projektów.
NoPrompt Opcjonalnie z opcjami Dodaj i Edytuj. Nie monituj użytkownika o potwierdzenie.
Lista Wyświetla listę wszystkich udziałów biblioteki przypisanych do określonej kolekcji projektów.
ListSCVMMLibraryShares Wyświetla listę wszystkich udziałów biblioteki dostępnych w ​Virtual Machine Manager.

Uwagi

Udział biblioteczny to wyznaczony udział na serwerze ​Virtual Machine Manager biblioteki. Udział biblioteczny zapewnia dostęp do zasobów opartych na plikach dla środowisk wirtualnych Lab Management, które są przechowywane na serwerach biblioteki, takich jak obrazy ISO i wirtualne dyski twarde. Udziały biblioteki są tworzone w ​Virtual Machine Manager. Visual Studio Lab Management korzysta z udziałów biblioteki do aprowizowania maszyn wirtualnych w laboratorium.

W wierszu polecenia /LibraryShare użyj tylko jednej z opcji /Add, /Edit lub /Delete w laboratorium TfsConfig Lab. Użyj oddzielnych wierszy polecenia TfsConfig Lab /LibraryShare, aby przypisać wiele udziałów biblioteki do kolekcji.

Domyślnie udziały biblioteki w kolekcji projektów są automatycznie przypisywane do każdego z projektów w kolekcji. Możesz użyć opcji /AutoProvision z poleceniami /Add i /Edit, aby zmienić udziały biblioteki.

  • Ustaw opcję /AutoProvision na wartość False, aby wyłączyć automatyczne przypisywanie udziału biblioteki do projektów. Aby przypisać lub usunąć udział biblioteczny w indywidualnym projekcie, użyj polecenia TfsLabConfig TFSLabConfig CreateTeamProjectLibraryShare.

  • Ustaw opcję /AutoProvision na wartość True, aby włączyć automatyczne przypisania.

Możesz użyć polecenia TfsConfig Lab /LibraryShare, aby dodać, usunąć lub edytować przypisanie udziału biblioteki z programu System Center Virtual Machine Manager (SCVMM) do kolekcji projektów. Można również użyć tego zestawu poleceń właściwości, które są specyficzne dla programu Visual Studio Lab Management i do wyświetlania biblioteki udziałów, które są aktualnie przypisane do kolekcji w programie Lab Management lub do wyświetlania wszystkich udziałów biblioteki w programie SCVMM.

TfsConfig Lab /LibraryShare
        /CollectionName:collectionName
        { /Add
            /SCVMMLibraryShare:librarySharePath
            /Name:name
            [/AutoProvision:{True|False}]
        | /Delete
            /Name:name
            [/NoPrompt]
        | /Edit
            /Name:name
            /AutoProvision:{True|False}
            [/NoPrompt]
        | /List
        | /ListSCVMMLibraryShares }
Opcja Opis
Dodaj Dodaje określony udział biblioteki do kolekcji projektów. Opcje /SCVMMLibraryShare i /Name należy określić za pomocą opcji Dodaj.
Usuwanie Usuwa określony udział biblioteki z kolekcji projektów. Należy określić /Name opcji Usuń .
Edytuj Ustawia lub czyszczy właściwość AutoProvision udziału biblioteki. Opcje /Name i /AutoProvision należy określić za pomocą opcji Edytuj.

Domyślnie udziały biblioteki są przypisywane do projektów w kolekcji.

[!NOTE] Zmiana automatycznego aprowizowania ma wpływ na istniejące projekty.
CollectionName: collectionName Wymagane. Określ nazwę kolekcji projektów w warstwie aplikacji Azure DevOps Server.
SCVMMLibraryShare: librarysharePath Wymagane w przypadku dodawania . Określa ścieżkę do biblioteki ​Virtual Machine Manager biblioteki.
Nazwa: libraryShareName Wymagane w przypadku dodawania, usuwania i edytowania. Określa nazwę udziału biblioteki w kolekcji projektów.
Automatyczna aprowizcja Opcjonalnie z dodawaniem ; wymagana w przypadku edytowania. Określa, czy udziały biblioteki są automatycznie przypisywane do każdego projektu w kolekcji. Domyślnie udziały biblioteki są przypisane do projektów.
NoPrompt Opcjonalnie z opcjami Dodaj i Edytuj. Nie monituj użytkownika o potwierdzenie.
Lista Wyświetla listę wszystkich udziałów biblioteki przypisanych do określonej kolekcji projektów.
ListSCVMMLibraryShares Wyświetla listę wszystkich udziałów biblioteki dostępnych w ​Virtual Machine Manager.

Uwagi

Udział biblioteczny to wyznaczony udział na serwerze ​Virtual Machine Manager biblioteki. Udział biblioteczny zapewnia dostęp do zasobów opartych na plikach dla środowisk wirtualnych Lab Management, które są przechowywane na serwerach biblioteki, takich jak obrazy ISO i wirtualne dyski twarde. Udziały biblioteki są tworzone w ​Virtual Machine Manager. Visual Studio Lab Management korzysta z udziałów biblioteki do aprowizowania maszyn wirtualnych w laboratorium.

W wierszu polecenia /LibraryShare użyj tylko jednej z opcji /Add, /Edit lub /Delete w laboratorium TfsConfig Lab. Użyj oddzielnych wierszy polecenia TfsConfig Lab /LibraryShare, aby przypisać wiele udziałów biblioteki do kolekcji.

Domyślnie udziały biblioteki w kolekcji projektów są automatycznie przypisywane do każdego z projektów w kolekcji. Możesz użyć opcji /AutoProvision z poleceniami /Add i /Edit, aby zmienić udziały biblioteki.

  • Ustaw opcję /AutoProvision na wartość False, aby wyłączyć automatyczne przypisywanie udziału biblioteki do projektów. Aby przypisać lub usunąć udział biblioteczny w indywidualnym projekcie, użyj polecenia TfsLabConfig TFSLabConfig CreateTeamProjectLibraryShare.

  • Ustaw opcję /AutoProvision na wartość True, aby włączyć automatyczne przypisania.


Laboratorium /settings

Konfigurację Visual Studio Lab Management przy użyciu opcji /Ustawienia TFSConfig Lab. Opcja Ustawienia opcji

  • Ustawia nazwę serwera programu System Center Virtual Machine Manager (SCVMM), który kontroluje administrowanie maszynami wirtualnymi w laboratorium.

  • Ustawia lokalizację sieciową, taką jak domena sieciowa lub grupa robocza, z którym mogą łączyć się komputery fizyczne we wszystkich grupach hostów.

  • Ustawia adresy IP i sufiks wirtualnego serwera DNS dla sieci izolowanych od sieci w laboratorium.

TfsConfig Lab
    /Settings
        [/ScVmmServerName:VMMServerName]
        [/NetworkLocation:networkLocation]
        [/IpBlock:networkIsolationIpRange]
        [/DnsSuffix:networkIsolationDnsSuffix] 
        [/NoPrompt]
        [/List]
Opcja Opis
ScvmmServerName: VMMServerName Opcjonalny. Ustawia w pełni kwalifikowaną nazwę serwera System Center Virtual Machine Manager 2008 (SCVMM), który będzie używany przez Azure DevOps Server. Jest to nazwa serwera SCVMM, który będzie używany do zarządzania maszynami wirtualnymi. Aby Azure DevOps Server się z programem SCVMM, należy dodać konto, na którym jest Azure DevOps Server do roli Administratora w programie SCVMM.
NetworkLocation: networkLocation Opcjonalny. Ustawia w pełni kwalifikowaną nazwę sieci, taką jak domena sieciowa lub grupa robocza, która jest dostępna na wszystkich hostach w sieci laboratorium. Podczas a incytowania maszyny wirtualnej program Lab Management automatycznie łączy maszynę wirtualną z określoną siecią. Lokalizacje sieciowe dostępne na hoście można znaleźć przy użyciu programu SCVMM konsola administratora.
IpBlock: networkIsolationIpRange Opcjonalny. Ustawia zakres adresów IP, które mają być przypisane do maszyn wirtualnych w środowisku podczas tworzenia izolowanej sieci. Ponieważ adresy IP są używane tylko do wewnętrznego routingu między maszynami wirtualnymi i nie są widoczne poza granicami środowiska, można określić dowolny zakres adresów IP, który nie jest używany w sieci określonej przez /NetworkLocation opcji. W większości przypadków powinien działać domyślny zakres 192.168.23.0/24. Jeśli wystąpią problemy z nawiązywaniem połączenia z izolowanym środowiskiem sieciowym, może być konieczne wybranie innego zakresu.
DnsSuffix: networkIsolationDnsSuffix Opcjonalny. Ustawia sufiks DNS, który będzie używany do rejestrowania nazw maszyn wirtualnych w sieci izolowanej dla środowiska wirtualnego. Aby sprawdzić, czy sufiks jest poprawnie skonfigurowany w hierarchii DNS, skontaktuj się z administratorem sieci.
NoPrompt Opcjonalny. Nie monituj o potwierdzenie. Nie należy używać z /List opcji.
Lista Wyświetla listę bieżących wartości konfiguracji dla Lab Management.

Uwagi

Jedna z opcji /ScvmmServerName, /NetworkLocation, /IpBlock, /DnsSuffix lub /List musi być określona w każdym wierszu polecenia /Ustawienia TfsConfig Lab.

Aby skonfigurować Lab Management, należy określić zarówno /ScVmmServerName i /NetworkLocation opcje. Można jednak określić te opcje w osobnych wierszach polecenia.

Aby skonfigurować izolację sieci, należy określić zarówno /IpBlock i /DnsSuffix opcje. Można jednak określić te opcje w osobnych wierszach polecenia.

Izolacja sieci umożliwia używanie wielu kopii maszyny wirtualnej bez konfliktów nazw maszyn i adresów IP. Należy przypisać zarówno sufiks DNS, jak i zakres adresów IP dla sieci izolowanej. Ponieważ adresy IP są używane tylko do routingu wewnętrznego między maszynami wirtualnymi i nie są widoczne poza granicami środowiska, można określić dowolny zakres adresów IP, który nie jest używany w sieci publicznej. W większości przypadków domyślny zakres 192.168.1.0/24 powinien działać. Jeśli wystąpią problemy z nawiązywaniem połączenia ze środowiskami izolowanym od sieci, może być konieczne wybranie innego zakresu.

Przykłady

W tym przykładzie Lab Management przy użyciu opcji /ScvmmServerName i /NetworkLocation w jednym wierszu polecenia.

tfsconfig lab /settings /scvmmservername:vmmserver /networklocation:lab1.contoso.com

W tym przykładzie izolacja sieci jest konfigurowana przy użyciu opcji /IpBlock i /DNSSuffix w osobnych wierszach polecenia.

tfsconfig lab /settings /ipblock: 192.168.23.0/24
tfsconfig lab /settings /dnssuffix:virtual1.lab1.contoso.com

Konfigurację Visual Studio Lab Management przy użyciu opcji /Ustawienia TFSConfig Lab. Opcja Ustawienia opcji

  • Ustawia nazwę serwera programu System Center Virtual Machine Manager (SCVMM), który kontroluje administrowanie maszynami wirtualnymi w laboratorium.

  • Ustawia lokalizację sieciową, taką jak domena sieciowa lub grupa robocza, z którym mogą łączyć się komputery fizyczne we wszystkich grupach hostów.

  • Ustawia adresy IP i sufiks wirtualnego serwera DNS dla sieci izolowanych od sieci w laboratorium.

    TfsConfig Lab /Ustawienia [/ScVmmServerName:VMMServerName] [/NetworkLocation:networkLocation] [/IpBlock:networkIsolationIpRange] [/DnsSuffix:networkIsolationDnsSuffix] [/NoPrompt] [/List]

Opcja Opis
ScvmmServerName: VMMServerName Opcjonalny. Ustawia w pełni kwalifikowaną nazwę serwera System Center Virtual Machine Manager 2008 (SCVMM), który będzie używany przez Azure DevOps Server. Jest to nazwa serwera SCVMM, który będzie używany do zarządzania maszynami wirtualnymi. Aby Azure DevOps Server się z programem SCVMM, należy dodać konto, na którym jest Azure DevOps Server do roli Administratora w programie SCVMM.
NetworkLocation: networkLocation Opcjonalny. Ustawia w pełni kwalifikowaną nazwę sieci, taką jak domena sieciowa lub grupa robocza, która jest dostępna na wszystkich hostach w sieci laboratorium. Podczas a incytowania maszyny wirtualnej program Lab Management automatycznie łączy maszynę wirtualną z określoną siecią. Lokalizacje sieciowe dostępne na hoście można znaleźć przy użyciu programu SCVMM konsola administratora.
IpBlock: networkIsolationIpRange Opcjonalny. Ustawia zakres adresów IP, które mają być przypisane do maszyn wirtualnych w środowisku podczas tworzenia izolowanej sieci. Ponieważ adresy IP są używane tylko do wewnętrznego routingu między maszynami wirtualnymi i nie są widoczne poza granicami środowiska, można określić dowolny zakres adresów IP, który nie jest używany w sieci określonej przez /NetworkLocation opcji. W większości przypadków powinien działać domyślny zakres 192.168.23.0/24. Jeśli wystąpią problemy z nawiązywaniem połączenia z izolowanym środowiskiem sieciowym, może być konieczne wybranie innego zakresu.
DnsSuffix: networkIsolationDnsSuffix Opcjonalny. Ustawia sufiks DNS, który będzie używany do rejestrowania nazw maszyn wirtualnych w sieci izolowanej dla środowiska wirtualnego. Aby sprawdzić, czy sufiks jest poprawnie skonfigurowany w hierarchii DNS, skontaktuj się z administratorem sieci.
NoPrompt Opcjonalny. Nie monituj o potwierdzenie. Nie należy używać z /List opcji.
Lista Wyświetla listę bieżących wartości konfiguracji dla Lab Management.

Uwagi

Jedna z opcji /ScvmmServerName, /NetworkLocation, /IpBlock, /DnsSuffix lub /List musi być określona w każdym wierszu polecenia /Ustawienia TfsConfig Lab.

Aby skonfigurować Lab Management, należy określić zarówno /ScVmmServerName i /NetworkLocation opcje. Można jednak określić te opcje w osobnych wierszach polecenia.

Aby skonfigurować izolację sieci, należy określić zarówno /IpBlock i /DnsSuffix opcje. Można jednak określić te opcje w osobnych wierszach polecenia.

Izolacja sieci umożliwia używanie wielu kopii maszyny wirtualnej bez konfliktów nazw maszyn i adresów IP. Należy przypisać zarówno sufiks DNS, jak i zakres adresów IP dla sieci izolowanej. Ponieważ adresy IP są używane tylko do routingu wewnętrznego między maszynami wirtualnymi i nie są widoczne poza granicami środowiska, można określić dowolny zakres adresów IP, który nie jest używany w sieci publicznej. W większości przypadków domyślny zakres 192.168.1.0/24 powinien działać. Jeśli wystąpią problemy z nawiązywaniem połączenia ze środowiskami izolowanym od sieci, może być konieczne wybranie innego zakresu.

Przykłady

W tym przykładzie Lab Management przy użyciu opcji /ScvmmServerName i /NetworkLocation w jednym wierszu polecenia.

tfsconfig lab /settings /scvmmservername:vmmserver /networklocation:lab1.contoso.com

W tym przykładzie izolacja sieci jest konfigurowana przy użyciu opcji /IpBlock i /DNSSuffix w osobnych wierszach polecenia.

tfsconfig lab /settings /ipblock: 192.168.23.0/24
tfsconfig lab /settings /dnssuffix:virtual1.lab1.contoso.com

Tryb offlineDetach

Polecenie offlineDetach umożliwia użycie bazy danych kolekcji w trybie offline do odłączanej bazy danych kolekcji w trybie 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ć offlineDetach polecenia, musi być członkiem roli sysadmin dla określonego SQL Server wystąpienia.

Uwagi

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

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 Azure DevOps Server wdrożenia. Wcześniej wymagało to przywrócenia kompletnego i spójnego zestawu baz danych (konfiguracji i wszystkich kolekcji) do środowiska przejściowego, skonfigurowania wdrożenia usługi Azure DevOps Server przy użyciu tych baz danych i odłączenia jednej interesującej kolekcji.

Zamiast tego można teraz przywrócić spójne kopie bazy danych konfiguracji i interesującej bazy danych kolekcji oraz uruchomić polecenie offlineDetach. Odłączoną bazę danych kolekcji można następnie dołączyć do dowolnego Azure DevOps Server wdrożenia w odpowiedniej wersji.

Przykład

Poniższy przykład ilustruje odłączenie bazy danych kolekcji o nazwie przy użyciu bazy danych konfiguracji o nazwie , z obiema w wystąpieniu SQL uruchomionym na serwerze o nazwie w TFS_PrimaryCollection TFS_Configuration ContosoTemp 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

Polecenie OfflineDetach umożliwia użycie bazy danych kolekcji w trybie offline do odłączanej bazy danych kolekcji w trybie 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ć offlineDetach polecenia, musi być członkiem roli sysadmin dla określonego SQL Server wystąpienia.

Uwagi

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

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 Azure DevOps Server wdrożenia. Wcześniej wymagało to przywrócenia kompletnego i spójnego zestawu baz danych (konfiguracji i wszystkich kolekcji) do środowiska przejściowego, skonfigurowania wdrożenia usługi Azure DevOps Server przy użyciu tych baz danych i odłączenia jednej interesującej kolekcji.

Zamiast tego można teraz przywrócić spójne kopie bazy danych konfiguracji i interesującej bazy danych kolekcji oraz uruchomić polecenie OfflineDetach. Odłączoną bazę danych kolekcji można następnie dołączyć do dowolnego Azure DevOps Server wdrożenia w odpowiedniej wersji.

Przykład

Poniższy przykład ilustruje odłączenie bazy danych kolekcji o nazwie TFS_PrimaryCollection przy użyciu bazy danych konfiguracji o nazwie TFS_Configuration, z obiema bazami danych w wystąpieniu usługi 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

Za pomocą polecenia serwera proxy można zaktualizować lub zmienić ustawienia używane przez Azure DevOps proxy. Azure DevOps Serwer proxy 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 zespołu rozproszonego. Konfigurując serwer Azure DevOps proxy, można znacznie zmniejszyć przepustowość potrzebną dla połączeń w szerokim 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 przekazywanie plików będą nadal wyświetlane w Azure DevOps Server. Jeśli używasz serwera Azure DevOps Services do hostowania projektu projektowego w chmurze, możesz użyć polecenia Serwera proxy, aby nie tylko zarządzać pamięcią podręczną dla projektów w hostowanej kolekcji, ale także do zarządzania niektórymi ustawieniami używanymi przez usługę.

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

Zobacz How to: Install Azure DevOps Proxy Server and set up a remote site. Aby uzyskać więcej informacji na temat konfigurowania serwera proxy na komputerach klienckich, zobacz Azure DevOps kontroli wersji programu.

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 Proxy.config plików. 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 poświadczenia na 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 należy go używać w przypadku lokalnych wdrożeń Azure DevOps Server.
delete Usuwa określony serwer lub kolekcję z listy serwerów proxy w Proxy.config plików.
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ślnym kontem usługi używanym w Azure DevOps Services jest " Usługa konta."
continue Kontynuuje wykonywanie polecenia, nawet jeśli proces weryfikacji generuje ostrzeżenia.
Kolekcja Określa adres URL kolekcji projektu hostowanej Azure DevOps Services 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, 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, który zawiera osobisty token dostępu. Ten token będzie używany do uwierzytelniania w kolekcji lub na koncie podczas rejestrowania serwera proxy. (Dodano do serwera 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 mogą służyć do konfigurowania repozytorium Git do użycia z wirtualnym systemem plików GvfsProjectName GvfsRepositoryName Git (GVFS) (dodanym w programie TFS 2018 Update 1)

Wymagania wstępne

Aby użyć serwera proxy polecenia, musi być członkiem grupy zabezpieczeń Azure DevOps Administratorzy i administratorem na serwerze proxy. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Informacje o uprawnieniach dla Azure DevOps Server).

Uwagi

Polecenie serwera proxy umożliwia zaktualizowanie istniejącej konfiguracji serwera Azure DevOps Server proxy. 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ę projektu hostowaną na platformie Azure DevOps Services do listy serwerów proxy przy użyciu osobistego tokenu dostępu w celu uwierzytelnienia. 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 w programie Azure DevOps Services bez monitu o zalogowanie.

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 względem kolekcji określonej za pomocą /Collection parametru . Osobisty token dostępu, który ma być używany, jest zapisywany w pliku c:\PersonalAccessToken.txt pod .

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 ma nazwę , nazwa konta używana na Azure DevOps Services to , a konto usługi używane przez serwer PhoneSaver HelenaPetersen.fabrikam.com proxy jest zmieniane na My Proxy Service Account . Ponieważ nazwa konta zawiera spacje, znaki cudzysłowu są używane do ująć nazwę.

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 plików GVFS.

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

Możesz użyć polecenia serwera proxy TFSConfig, aby zaktualizować lub zmienić ustawienia używane przez serwer Team Foundation Server proxy. Team Foundation Server Serwer proxy umożliwia rozproszonym zespołom korzystanie z kontroli wersji przez zarządzanie pamięcią podręczną pobranych plików kontroli wersji w lokalizacji rozproszonego zespołu. Konfigurując serwer Team Foundation Server proxy, można znacznie zmniejszyć przepustowość potrzebną dla połączeń w szerokim 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 przekazywanie plików będą nadal wyświetlane w Azure DevOps Server. Jeśli używasz serwera Azure DevOps Services do hostowania projektu projektowego w chmurze, możesz użyć polecenia Serwera proxy, aby nie tylko zarządzać pamięcią podręczną dla projektów w hostowanej kolekcji, ale także do zarządzania niektórymi ustawieniami używanymi przez usługę.

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

Zobacz How to: Install Azure DevOps Proxy Server and set up a remote site. Aby uzyskać więcej informacji na temat konfigurowania serwera proxy na komputerach klienckich, zobacz Kontrola wersji serwera Team Foundation Command Reference.

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 Proxy.config plików.

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 poświadczenia na 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 go używać w przypadku lokalnych wdrożeń Azure DevOps Server.

/Delete

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

/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ślnym kontem usługi używanym w Azure DevOps Services jest " Usługa konta."

/continue

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

/Collection:TeamProjectCollectionURL

Określa adres URL kolekcji projektu hostowanej Azure DevOps Services 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, musi być ujęta w cudzysłów ( " " ).

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, który zawiera osobisty token dostępu. Ten token będzie używany do uwierzytelniania w kolekcji lub na koncie podczas rejestrowania serwera proxy. (Dodano do serwera TFS 2018 Update 1)

/inputs:Key1=Value1; Key2=Wartość2;...

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) (dodanego w programie " " " " TFS 2018 Update 1)

Wymagania wstępne

Aby użyć serwera proxy polecenia, musi być członkiem grupy zabezpieczeń Administratorzy team Foundation i administrator na serwerze proxy. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Polecenie Serwer proxy umożliwia zaktualizowanie istniejącej konfiguracji serwera Azure DevOps proxy. 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ę projektu hostowaną na platformie Azure DevOps Services do listy serwerów proxy przy użyciu osobistego tokenu dostępu w celu uwierzytelnienia. 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 w programie Azure DevOps Services bez monitu o zalogowanie.

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 względem kolekcji określonej za pomocą parametru "/Collection". Osobisty token dostępu, który ma być używany, jest zapisywany w pliku w 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 plików 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ć SQL Server Reporting Services i SQL Server Analysis Services baz danych, które Azure DevOps Server używane.

TfsConfig rebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]
Opcja Opis
analysisServices Wymagane, jeśli /all nie jest używany. Określa, że tylko bazy danych dla Analysis Services zostanie ponownie skondygowana. Jeśli baza danych nie istnieje Analysis Services, 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, Azure DevOps Server będą ponownie budować.
reportingDataSourcePassword Wymagane, jeśli TFS_Analysis bazy danych 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ć rebuildWarehouse polecenia, musi być członkiem następujących grup:

  • Grupy Azure DevOps zabezpieczeń Administratorzy i Grupy zabezpieczeń Administratorzy na serwerze lub serwerach z konsolą administracyjną programu Azure DevOps

  • Grupa sysadmin na serwerze lub serwerach z uruchomionym wystąpieniem programu SQL Server hostem baz danych dla Azure DevOps Server

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Tego polecenia można użyć podczas przenoszenia lub dzielenia kolekcji projektu, przywracania danych lub zmiany konfiguracji wdrożenia w inny sposób.

Aby interaktywnie rozpocząć ponowne kompilowanie tych baz danych, można użyć węzła Raportowanie w konsoli administracyjnej programu Azure DevOps. Aby uzyskać więcej informacji, zobacz Open the Azure DevOps Administration Console.

Przykład

W poniższym przykładzie pokazano, jak ponownie skompilować Analysis Services bazy danych dla 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 SQL Server Reporting Services i SQL Server Analysis Services używane 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 bazy danych dla Analysis Services zostanie ponownie skondygowana.

Jeśli baza danych nie istnieje Analysis Services, 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, Azure DevOps Server będą ponownie budować.

/reportingDataSourcePassword: Hasło

Wymagane, jeśli TFS_Analysis bazy danych 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ć rebuildWarehouse polecenia, musi być członkiem następujących grup:

  • Grupy zabezpieczeń Administratorzy programu Team Foundation i grupy zabezpieczeń Administratorzy na serwerze lub serwerach z konsolą administracyjną programu Azure DevOps

  • grupę sysadmin na serwerze lub serwerach z uruchomionym wystąpieniem programu SQL Server hostem baz danych programu Azure DevOps Server

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Tego polecenia można użyć podczas przenoszenia lub dzielenia kolekcji projektu, przywracania danych lub zmiany konfiguracji wdrożenia w inny sposób.

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

Przykład

W poniższym przykładzie pokazano, jak ponownie skompilować Analysis Services bazy danych dla 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.

RegisterDB

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

TfsConfig registerDB /sqlInstance:<serverName> /databaseName:<databaseName>
Opcja Opis
SQLInstance Wymagane. Określa nazwę serwera, na którym działa program SQL Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. W przypadku określenia wystąpienia należy 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 administratorzy programu Azure DevOps na serwerze warstwy aplikacji dla programu Azure DevOps i członkiem grupy sysadmin w programie SQL Server na serwerze warstwy danych dla Azure DevOps. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Przed użyciem tego polecenia Azure DevOps Server kopii zapasowej baz danych programu .

Aby polecenie registerDB powiodło się, muszą być uruchomione następujące pule aplikacji i programy:

  • Azure DevOps Server 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, upewnij się, że Azure DevOps Server wskazuje nową lokalizację.

Przykład

Poniższy przykład przekierowuje Azure DevOps Server do bazy danych konfiguracji, która znajduje się na serwerze w ContosoMain SQL Server TeamDatabases wystąpienia programu .

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

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

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

Argument

Opis

/SQLInstance: Nazwa_serwera

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

W przypadku określenia wystąpienia należy 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ą grupy dostępności AlwaysOn w SQL Server.

Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w ciągu połączenia.

Aby uzyskać więcej informacji, zobacz [Zawsze włączone grupy dostępności (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 programu Team Foundation na serwerze warstwy aplikacji dla programu Azure DevOps i członkiem grupy sysadmin w programie SQL Server na serwerze warstwy danych dla Azure DevOps. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Przed użyciem tego polecenia Azure DevOps Server kopii zapasowej baz danych programu .

Aby polecenie RegisterDB powiodło się, muszą być uruchomione następujące pule aplikacji i programy:

  • Azure DevOps Server 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, upewnij 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 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 zmieniasz w inny sposób 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, dla której ma Azure DevOps Server, oprócz nazwy samej bazy danych.
SQLInstances Określa nazwę serwera, na którym działa program SQL Server, oprócz nazwy wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne.

W przypadku określenia więcej niż jednego serwera należy 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, które hostuje Analysis Services bazy danych.
AnalysisDatabaseName Opcjonalny. Określa nazwę bazy danych usługi Analysis Services, która ma być Azure DevOps Server, jeśli na serwerze określonym za pomocą opcji /AnalysisInstance jest więcej niż jedna taka baza danych.
preview Opcjonalny. Przedstawia 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. W przypadku użycia opcji /continue wszystkie kolekcje, których bazy danych nie znajdują się na serwerze lub serwerach, które określisz, zostaną ponownie skonfigurowane do używania serwera i wystąpienia, które hostują bazę danych konfiguracji.

Wymagania wstępne

Aby użyć polecenia remapDBs, musisz być członkiem grupy zabezpieczeń Administratorzy programu Azure DevOps i członkiem grupy zabezpieczeń sysadmin dla wszystkich baz danych programu SQL Server, które Azure DevOps Server używane. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Polecenie remapDBs umożliwia ponowne skonfigurowanie Azure DevOps Server do używania różnych serwerów i wystąpień SQL Server z serwerów i wystąpień w pierwotnej instalacji.

Przykład

W poniższym przykładzie pokazano, jak przekierować Azure DevOps Server do jej bazy danych konfiguracji TFS_Configuration . Ta baza danych jest hostowana ContosoMain w nazwanych wystąpieniach TeamDatabases . Bazy danych kolekcji projektów są przechowywane zarówno w wystąpieniu ContosoMain\TeamDatabases domyślnym, jak i w . 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 zmieniasz w inny sposób konfigurację wdrożenia. Na przykład należy przekierować program TFS do dowolnych baz danych kolekcji projektów, jeśli są one hostowane na innym serwerze lub serwerach niż baza danych konfiguracji. Należy również przekierować program 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 innym serwerze lub wystąpieniu niż baza 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, dla której ma Azure DevOps Server, oprócz nazwy samej bazy danych.

/SQLInstances: ServerName1, ServerName2

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

W przypadku określenia więcej niż jednego serwera należy 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, które hostuje Analysis Services bazy danych.

/AnalysisDatabaseName: Databasename

Opcjonalny. Określa nazwę bazy danych usługi Analysis Services, która ma być Azure DevOps Server, jeśli na serwerze określonym za pomocą opcji /AnalysisInstance jest więcej niż jedna taka baza danych.

/preview

Opcjonalny. Przedstawia 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.

W przypadku użycia opcji /continue wszystkie kolekcje, których bazy danych nie znajdują się na serwerze lub serwerach, które określisz, zostaną ponownie skonfigurowane do używania serwera i wystąpienia, które hostują bazę danych konfiguracji.

/usesqlalwayson

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

Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w ciągu połączenia.

Aby uzyskać więcej informacji, zobacz [Zawsze włączone grupy dostępności (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ń Administratorzy programu Team Foundation i członkiem grupy zabezpieczeń sysadmin dla wszystkich baz danych programu SQL Server, które Azure DevOps Server używane. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Polecenie RemapDBs umożliwia ponowne skonfigurowanie Azure DevOps Server do używania różnych serwerów i wystąpień SQL Server z serwerów i wystąpień w pierwotnej instalacji.

Przykład

W poniższym przykładzie pokazano, jak przekierować Azure DevOps Server do konfiguracji bazy danych TFS _ Configuration. Ta baza danych jest hostowana w firmie ContosoMain w nazwanych bazach danych TeamDatabase wystąpienia. Bazy danych kolekcji projektów są przechowywane zarówno w bazach danych ContosoMain TeamDatabase, jak i \ domyślnym wystąpieniu w firmie Contoso2.

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

RepairJobQueue

Polecenie repairJobQueue umożliwia naprawienie zaplanowanych zadań, które zostały zatrzymane na hostach wdrożenia i kolekcji.

TfsConfig repairJobQueue

Wymagania wstępne

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

Uwagi

Zwykle używa się polecenia repairJobQueue, jeśli zauważysz, że zaplanowane zadania nie są uruchomione.
Polecenie nie ma żadnych argumentów i wymaga skonfigurowania Azure DevOps Server wdrożenia.

Przykład

TfsConfig repairJobQueue

Dostępność poleceń: TFS 2015

Polecenie RepairJobQueue umożliwia naprawienie zaplanowanych zadań, które zostały zatrzymane na hostach wdrożenia i kolekcji.

TfsConfig repairJobQueue

Wymagania wstępne

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

Uwagi

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

Przykład

TFSConfig repairJobQueue

Ustawienia

Za pomocą polecenia settings można zautomatyzować zmiany w ujednoliconym lokalizatorze zasobów (adresIE URL) używanym przez interfejs powiadomień oraz adres serwera dla Azure DevOps Server. Domyślnie adres URL interfejsu powiadomień i adres URL serwera 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 generowanych Azure DevOps Server e-mail. To narzędzie należy uruchomić z poziomu warstwy aplikacji, aby zaktualizować wszystkie serwery tak, aby używać nowych adresów URL.

Aby zmienić te adresy URL interaktywnie lub tylko wyświetlić bieżące ustawienia, można użyć konsoli administracyjnej programu Azure DevOps. Zobacz krótki przewodnik po zadaniu administracyjnym.

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 grupy Administratorzy na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

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

Przykład

W poniższym przykładzie wartość właściwości NotificationURL jest zmieniana na , a wartość http://contoso.example.com/tfs właściwości 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 (adresIE URL) używanym przez interfejs powiadomień i adresie serwera dla Azure DevOps Server. Domyślnie adres URL interfejsu powiadomień i adres URL serwera 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 generowanych Azure DevOps Server e-mail. To narzędzie należy uruchomić z poziomu warstwy aplikacji, aby zaktualizować wszystkie serwery tak, aby używać nowych adresów URL.

Aby zmienić te adresy URL interaktywnie lub tylko wyświetlić bieżące ustawienia, można użyć konsoli administracyjnej programu Azure DevOps. Zobacz krótki przewodnik po zadaniu administracyjnym.

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 programu Team Foundation 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 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 w ramach wdrożenia.

Przykład

W poniższym przykładzie wartość właściwości NotificationURL jest zmieniana na , a wartość http://contoso.example.com/tfs właściwości 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 setup umożliwia odinstalowanie funkcji, które są obecnie skonfigurowane na maszynie, na której jest uruchamiane polecenie.

TfsConfig setup /uninstall:<feature[,feature,...]>
Opcja Opis
Odinstalować Określa co najmniej jedną cechę do odinstalowania z komputera, na którym uruchamiasz polecenie. Dostępne opcje to: All, ApplicationTier, Search i VersionControlProxy.

Opcja

Opis

/uninstall

Określaoneormorefeaturestobeuninstalledfromthemachinewhereyourunthecommand. Optionsinclude:All,ApplicationTier,SharePointExtensions,Search,TeamBuild,andVersionControlProxy.

Opcja

Opis

/uninstall

Określaoneormorefeaturestobeuninstalledfromthemachinewhereyourunthecommand. Optionsinclude:All,ApplicationTier,SharePointExtensions,TeamBuild,VersionControlProxy.

Wymagania wstępne

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

Przykłady

Poniższy przykład odinstalowuje wszystkie Azure DevOps Server funkcji 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,TeamBuild

TCM

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

Jeśli automatyczna migracja nie powiedzie się, użyj polecenia TCM, aby ręcznie uaktualnić plany testów i zestawy testów do odpowiednich typów elementów pracy (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 pakiety testów, aby wskazać plany testów i pakiety testów oparte na elementach pracy. Aktualizuje również istniejące dane zarządzania testami i połączenia między innymi istniejącymi artefaktami testów, takimi jak punkty testowe, 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 jakieś plany testów.

/CollectionName:CollectionName

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

Jeśli w nazwie kolekcji projektu znajdują się spacje, ujmij nazwę w cudzysłów, na przykład " Fabrikam Fiber Collection " .

/TeamProjectName:TeamProjectName

Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdzić stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej za pomocą /collectionName parametru.

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

Wymagania wstępne

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

Zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Aby można było użyć tego polecenia, należy uaktualnić serwer warstwy aplikacji do najnowszej Azure DevOps Server 2019 r.

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 czasie używania 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ć je 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 .

Polecenia TCM należy używać tylko w przypadku, gdy automatyczna migracja istniejących danych testowych zakończy się niepowodzeniem.

Aby dowiedzieć się więcej na temat migracji i kiedy używać tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami. Jeśli nie możesz uzyskać dostępu do planów testów lub pakietó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 dla każdego projektu po kolei.

Przykłady

Poniższy przykład pokazuje, jak sprawdzić stan uaktualnienia planu testu w projekcie Fabrikam Fiber hostowany w domyślnej kolekcji projektów (DefaultCollection):

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

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

Jeśli automatyczna migracja nie powiedzie się, użyj polecenia TCM, aby ręcznie uaktualnić plany testów i zestawy testów do odpowiednich typów elementów pracy (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 pakiety testów, aby wskazać plany testów i pakiety testów oparte na elementach pracy. Aktualizuje również istniejące dane zarządzania testami i połączenia między innymi istniejącymi artefaktami testów, takimi jak punkty testowe, 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 jakieś plany testów.

/CollectionName:CollectionName

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

Jeśli w nazwie kolekcji projektu znajdują się spacje, ujmij nazwę w cudzysłów, na przykład " Fabrikam Fiber Collection " .

/TeamProjectName:TeamProjectName

Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdzić stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej za pomocą /collectionName parametru.

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

Wymagania wstępne

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

Zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Aby można było użyć tego polecenia, należy uaktualnić serwer warstwy Azure DevOps Server do najnowszej wersji programu .

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 czasie używania 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ć je 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 .

Polecenia TCM należy używać tylko w przypadku, gdy automatyczna migracja istniejących danych testowych zakończy się niepowodzeniem.

Aby dowiedzieć się więcej na temat migracji i kiedy używać tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami.

Jeśli nie możesz uzyskać dostępu do planów testów lub pakietó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 dla każdego projektu po kolei.

Przykłady

Poniższy przykład pokazuje, jak sprawdzić stan uaktualnienia planu testu w projekcie Fabrikam Fiber hostowany w domyślnej kolekcji projektów (DefaultCollection):

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

Instalacji nienadzorowanej

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

Polecenie instalacji nienadzorowej jest przeznaczone dla użytkowników, którzy znają Azure DevOps Server i proces konfiguracji oraz muszą instalować Azure DevOps Server na różnych maszynach.

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

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

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

TfsConfig unattend /create|configure /type:InstallType /unattendfile:ConfigurationFileName 
    [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]
Opcja Opis
create Tworzy plik nienadzorowany o imieniu i parametrach, które określisz.
konfigurowanie Konfiguruje Azure DevOps Server przy użyciu pliku nienadzorowania i parametrów, które określisz. Należy 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 unattendfile Określa plik nienadzorowany do utworzenia lub użycia, w zależności od tego, czy początkowy parametr jest /create lub /configure. Jeśli używasz /configure, wymagane jest /unattendfile lub /type.
Wejścia Opcjonalny. Jeśli używasz /create, określa ustawienia i wartości do użycia podczas tworzenia pliku nienadzorowania. Jeśli używasz /configurespecifies dodatkowe ustawienia i wartości do użycia w połączeniu z pliku nienadzorowane.

Zamiast używać /inputs, można ręcznie edytować plik nienadzorowany 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 tajnych przy użyciu parametru /inputs.
verify Opcjonalny. Określa przebieg konfiguracji, który kończy sprawdzanie weryfikacji tylko na podstawie pliku instalacji nienadzorowej, danych wejściowych i typu konfiguracji. Jest to alternatywa dla wykonania pełnej konfiguracji.
continue Opcjonalny. Określa, że /create lub /configure należy kontynuować niezależnie od ostrzeżeń weryfikacji kontroli.
Typ instalacji Opis
NewServerBasic Konfiguruje podstawowe usługi programowe dla Azure DevOps Server. Obejmuje to kontrolę źródła, elementy robocze, kompilację i opcjonalnie wyszukiwanie.
NewServerAdvanced Konfiguruje podstawowe usługi programacyjne i umożliwia opcjonalną konfigurację integracji z usługami Reporting Services.
Uaktualnienie Uaktualnienia Azure DevOps Server do bieżącej wersji z obsługiwanej poprzedniej wersji.
PreProductionUpgrade Przetestuj uaktualnienie istniejącego Azure DevOps Server wdrożenia w środowisku przedprodukcyjnym. Zwykle odbywa się to przy użyciu baz danych przywróconych z produkcyjnych kopii zapasowych. Ten scenariusz obejmuje dodatkowe kroki w celu zapewnienia, że nowe wdrożenie nie będzie zakłócać wdrożenia produkcyjnego.
ApplicationTierOnlyBasic Skonfiguruj nową warstwę aplikacji przy użyciu istniejących ustawień z podanej bazy danych konfiguracji. Ta opcja umożliwia szybkie uruchomienie nowej warstwy aplikacji przy użyciu istniejących ustawień. Jeśli chcesz mieć możliwość zmiany istniejących ustawień, zamiast tego użyj typu Advanced ApplicationTierOnlyAdvanced.
ApplicationTierOnlyAdvanced Skonfiguruj nową warstwę aplikacji z pełną kontrolą wszystkich ustawień. Ustawienia wartość domyślna to istniejące wartości z podanej bazy danych konfiguracji. Jeśli chcesz zachować wszystkie istniejące ustawienia, zamiast tego użyj typu ApplicationTierOnlyBasic.
Klonowanie Skonfiguruj nowe Azure DevOps Server wdrożenia, które jest klonem istniejącego wdrożenia. Zwykle odbywa się to przy użyciu baz danych przywróconych z produkcyjnych kopii zapasowych w celu utworzenia środowiska, w którym można przetestować zmiany konfiguracji, rozszerzenia i inne modyfikacje. Ten scenariusz obejmuje dodatkowe kroki w celu zapewnienia, że nowe wdrożenie nie będzie zakłócać wdrożenia produkcyjnego.
Serwer proxy Konfiguruje usługę serwera proxy kontroli wersji.

Wymagania wstępne

  • Użytkownik musi być członkiem grupy Administratorzy na komputerze, na którym instalujesz oprogramowanie.

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

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

Uwagi

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

Polecenie instalacji nienadzorowej konfiguruje Azure DevOps Server składniki. Nie wykonuje początkowej instalacji oprogramowania. Oprogramowanie jest konfigurowane zgodnie ze specyfikacjami użytkownika po tym, jak bity znajdują się na komputerze.

Przykłady

W poniższym przykładzie pokazano, jak utworzyć plik instalacji nienadzorowej 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 jako część 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 plików 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 Azure DevOps proxy.

Ważne

Jeśli w tym przykładzie administratorzy chcą używać 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 nienadzorowany, taki 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 usługi Azure DevOps Server Build na serwerze przy użyciu konta usługi kompilacji, a następnie skonfigurować kompilację przy użyciu tego pliku FabrikamFiber\BuildSVC Azure DevOps Server.

Ważne

W tym przykładzie po utworzeniu pliku nienadzorowania administrator ręcznie edytuje plik, aby określić hasło do konta usługi kompilacji. Dodanie hasła jako danych wejściowych przy użyciu metody nie spowoduje ServiceAccountPassword=Password; dodania informacji o hasłach 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 informacje:

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ę Azure DevOps, oraz kolekcję FabrikamFiberTFS projektów skojarzoną 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 instalacji nienadzorowej jest przeznaczone dla użytkowników, którzy Azure DevOps Server i proces konfiguracji oraz muszą instalować Azure DevOps Server na różnych maszynach.

Jeśli na przykład używasz programu Team Foundation Build, możesz użyć polecenia Instalacji nienadzorowej, 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 dla Azure DevOps Server instalacji. Następnie użyj opcji Unattend /configure, aby faktycznie przeprowadzić konfigurację.

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

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

Opcja

Opis

/Create

Tworzy plik nienadzorowany o imieniu i parametrach, które określisz.

/Configure

Konfiguruje Azure DevOps Server przy użyciu pliku nienadzorowania i parametrów, które określisz.

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

/type:InstallType

Określa typ konfiguracji do użycia.

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

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

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

  • Kompilacja: konfiguruje usługę Team Foundation Build Service.

  • Serwer proxy: konfiguruje Azure DevOps proxy.

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

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

Ta wersja musi zostać pobrana i zainstalowana lokalnie przed uruchomieniem tego polecenia z /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 jest /create lub /configure. Jeśli używasz /configure, wymagane jest /unattendfile lub /type.

/inputs:Key1=Value1; Klucz2 = wartość2; ...

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

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

Zamiast używać /inputs, można ręcznie edytować plik nienadzorowany 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 tajnych przy użyciu parametru /inputs.

/verify

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

Jest to alternatywa dla wykonania pełnej konfiguracji.

/continue

Opcjonalny. Określa, że /create lub /configure należy kontynuować niezależnie od ostrzeżeń weryfikacji kontroli.

/?

Opcjonalny. Zapewnia pomoc wiersza polecenia dla polecenia nienadzorowane.

Wymagania wstępne

  • Użytkownik musi być członkiem grupy Administratorzy na komputerze, na którym instalujesz oprogramowanie.

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

Uwagi

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

Polecenie Instalacji nienadzorowej konfiguruje Azure DevOps Server składniki. Nie wykonuje początkowej instalacji oprogramowania. Oprogramowanie jest konfigurowane zgodnie ze specyfikacjami użytkownika po tym, jak bity znajdują się na komputerze.

Przykłady

W poniższym przykładzie pokazano, jak utworzyć plik instalacji nienadzorowej 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 jako część 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 plików 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 Azure DevOps proxy.

Ważne: Jeśli w tym przykładzie administratorzy chcą używać 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 nienadzorowania, taki 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 kompilacji Team Foundation Build na serwerze przy użyciu "FabrikamFiber BuildSVC" jako konta usługi kompilacji, a następnie skonfigurować kompilację Team Foundation Build przy użyciu tego pliku \ nienadzorowania.

Ważne:
W tym przykładzie po utworzeniu pliku nienadzorowania administrator ręcznie edytuje plik, aby określić hasło do konta usługi kompilacji. Dodanie hasła jako danych wejściowych przy użyciu " wartości ServiceAccountPassword=Password nie spowoduje dodania informacji o " hasłach 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 informacje:

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 program Team Foundation Build (FabrikamFiberTFS) i kolekcję projektu skojarzoną 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

ZipLogs (Pliki zip)

Polecenie ziplogs jest przeznaczone do zbierania dzienników i porzucania pliku zip w pliku ProgramData\Microsoft\Azure DevOps\Server Configuration .

Pliki zipLogs programu TfsConfig

TfsConfig zipLogs

Przestarzałe polecenia

Licencja

Możesz użyć polecenia Licencja, aby wyświetlić, zmodyfikować lub rozszerzyć klucz licencjonowania dla wdrożenia Azure DevOps Server.

TFSConfig License [/ProductKey:Key] [/extend [NewTrialID]]

Opcja

Opis

/ProductKey: Klucz

Określa, że klucz licencji dla wdrożenia zostanie zaktualizowany o wartość Klucza.

/extend

Określa, że okres licencjonowania wersji próbnej Azure DevOps Server zostanie wydłużony o 30 dni. Tej opcji można użyć tylko raz bez uzyskiwania nowego identyfikatora wersji próbnej. Jeśli jest wymagane drugie rozszerzenie, musisz uzyskać drugą licencję próbną od firmy Microsoft.

Wymagania wstępne

Aby użyć licencji polecenia, musi być członkiem grupy zabezpieczeń Azure DevOps Administratorzy. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Aby interaktywnie wyświetlać, modyfikować lub zmieniać licencjonowanie wdrożenia, można użyć konsoli administracyjnej programu Azure DevOps. Aby uzyskać więcej informacji, zobacz Otwórz konsolę administracyjną Azure DevOps i Znajdź lub zmień klucz produktudla Azure DevOps Server .

Przykłady

W poniższym przykładzie pokazano, jak wyświetlić informacje o licencjonowaniu dla wdrożenia Azure DevOps Server. W tym przykładzie wdrożenie korzysta z licencji próbnej.

TFSConfig License

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

Team Foundation Server Standard license
The following features are installed:
Team Foundation Server
Build Services
Build: 21106.00
Product ID: 01234-567-8910
Trial license with 74 days remaining, expiring on 6/30/2010
Trial ID: ABCD-EFGH-IJKL

TCM

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

Jeśli automatyczna migracja nie powiedzie się, użyj polecenia TCM, aby ręcznie uaktualnić plany testów i zestawy testów do odpowiednich typów elementów pracy (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 pakiety testów, aby wskazać plany testów i pakiety testów oparte na elementach pracy. Aktualizuje również istniejące dane zarządzania testami i połączenia między innymi istniejącymi artefaktami testów, takimi jak punkty testowe, 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 jakieś plany testów.

/CollectionName:CollectionName

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

Jeśli w nazwie kolekcji projektu znajdują się spacje, ujmij nazwę w cudzysłów, na przykład " Fabrikam Fiber Collection " .

/TeamProjectName:TeamProjectName

Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdzić stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej za pomocą /collectionName parametru.

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

Wymagania wstępne

Musisz być członkiem grupy zabezpieczeń Azure DevOps Administratorzy oraz administratorem na serwerze warstwy aplikacji.

Zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.

Uwagi

Aby można było użyć tego polecenia, należy uaktualnić serwer warstwy Azure DevOps Server do najnowszej wersji programu .

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 czasie używania 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ć je 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 .

Polecenia TCM należy używać tylko w przypadku, gdy automatyczna migracja istniejących danych testowych zakończy się niepowodzeniem.

Aby dowiedzieć się więcej na temat migracji i kiedy używać tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami.

Jeśli nie możesz uzyskać dostępu do planów testów lub pakietó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 dla każdego projektu po kolei.

Przykłady

Poniższy przykład pokazuje, jak sprawdzić stan uaktualnienia planu testu w projekcie Fabrikam Fiber hostowany w domyślnej kolekcji projektów (DefaultCollection):

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

Importuj

Polecenie importu zostało wycofane na serwerach TFS 2013. Wcześniejsze wersje są dostępne tutaj:

Jeśli potrzebujesz pomocy przy uaktualnianiu danych i projektów z wcześniejszej wersji programu Azure DevOps Server, zobacz Uaktualnianieprogramu Azure DevOps Server lub skontaktuj się z Pomoc techniczna Microsoft.

PrepareSQL

W programie TFS 2012 nie można było wypracowyć polecenia prepareSQL. Wcześniejsze wersje są dostępne tutaj:

Napraw

Polecenie naprawy zostało naprawione w programie TFS 2012. Wcześniejsze wersje są dostępne tutaj:

Jeśli musisz naprawić procedury składowane po awarii poprawki bazy danych, skontaktuj się z Pomoc techniczna Microsoft .

Zdiagnozować

Polecenie diagnose było przestarzałe w programie TFS 2013. Wcześniejsze wersje są dostępne tutaj:

Jeśli potrzebujesz pomocy w diagnozowaniu potencjalnych niezgodności między aktualizacjami oprogramowania na serwerach warstwy aplikacji i warstwy danych dla usługi Azure DevOps Server, skontaktuj się z pomocą techniczną Community deweloperów.

Aktualizacje

Polecenie updates zostało wycofane w programie TFS 2013. Wcześniejsze wersje są dostępne tutaj:

Jeśli potrzebujesz pomocy przy instalowaniu aktualizacji oprogramowania, których brakuje w bazach danych programu Azure DevOps Server, skontaktuj się z Pomoc techniczna Microsoft.

PrepareClone

Polecenie PrepareClone zostało wycofane na serwerach TFS 2017.

PrepareClone polecenie usuwa informacje o zaplanowanych kopii zapasowych, SharePoint i raportowania zasobów z Azure DevOps Server wdrożenia.

To polecenie jest używane w dwóch okolicznościach:

  • podczas przenoszenia wdrożenia na nowy sprzęt, ale chcesz nadal korzystać ze starego wdrożenia
  • podczas klonowania wdrożenia Azure DevOps Server wdrożenia

W każdym z tych przypadków uruchomienie tego polecenia ma kluczowe znaczenie.

Jeśli tego nie zimkniesz, oryginalne zasoby będą używane zarówno przez oryginalne, jak i nowe serwery.

Jeśli zarówno oryginalne, jak i nowe serwery są na żywo i wskazują te same SharePoint lub zasoby raportowania przez dowolny czas, może to spowodować uszkodzenie baz danych.

Ważne

To polecenie należy uruchomić przed konfiguracją, niezależnie od tego, czy przenosisz, czy klonujesz Azure DevOps Server. Uruchomienie go po zakończeniu konfiguracji może prowadzić do niespójności między zawartością w bazach danych i zawartością w web.config danych. Te niespójności mogą spowodować, że serwer będzie w trybie offline. Jeśli już skonfigurowano wdrożenie przeniesione lub sklonowane Azure DevOps Server i musisz uruchomić polecenie , wykonaj następujące kroki. Najpierw przejmij serwer w tryb pracy. Następnie uruchom polecenie PrepareClone, polecenie ChangeServerID, a następnie polecenie RemapDBs. Na koniec odszukaj serwer.

TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:TFSConfigurationDatabaseName
        [/notificationURL: TFSURL] [/usesqlalwayson]

Opcja

Wyniki działania

/DatabaseName

Określa nazwę serwera, który hostuje bazę danych, dla której ma Azure DevOps Server, oprócz nazwy samej bazy danych konfiguracji.

/SQLInstance: Nazwa_serwera

Określa nazwę serwera, który ma być mapowanie jako serwer, który hostuje co najmniej jednej bazy danych dla Azure DevOps Server. Jeśli wystąpienie inne niż domyślne hostuje bazę danych, należy również określić nazwę wystąpienia.

Użyj tego formatu: Nazwa_wystąpienia_serwera.

/NotificationURL: TFSURL

Opcjonalny. Określa adres URL powiadomienia dla serwera warstwy aplikacji.

/usesqlalwayson

Opcjonalny. Określa, że bazy danych są częścią grupy dostępności AlwaysOn w SQL Server. Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w parametrów połączenia.

Aby uzyskać więcej informacji, zobacz [Zawsze włączone grupy dostępności (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć PrepareClone polecenia, musi być członkiem grupy zabezpieczeń administratorzy programu Azure DevOps i członkiem grupy zabezpieczeń sysadmin dla wszystkich baz danych programu SQL Server, które Azure DevOps Server używane.

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Polecenie PrepareClone umożliwia ponowne skonfigurowanie programu Azure DevOps Server w przypadku przeniesienia oryginalnej instalacji na nowy sprzęt i kontynuowania korzystania z oryginalnego wdrożenia Azure DevOps Server i sprzętu lub sklonowania wdrożenia usługi Azure DevOps Server do celów testowych. Aby obsługiwać konfigurację klonowania, należy użyć narzędzia TFSConfig PrepareClone w połączeniu z plikami TFSConfig RemapDBs i TFSConfig ChangeServerID.

Przykład

W poniższym przykładzie pokazano, jak za pomocą polecenia w przeniesionym Azure DevOps Server o nazwie NewFabrikamTFS usunąć stare informacje o kopii zapasowej, raportowaniu i SharePoint kopii zapasowej. Jeśli te informacje nie zostaną usunięte, oryginalne wdrożenie usługi Azure DevOps Server nadal używa tych samych zasobów, a bazy danych zostaną uszkodzone. W tym przykładzie adres SQL Server obsługujący przeniesiony serwer Azure DevOps Server nosi również nazwę NewFabrikamTFS, a wystąpienie jest wystąpieniem domyślnym, więc nie są wymagane żadne konkretne informacje o wystąpieniu, tylko nazwa serwera.

TFSConfig PrepareClone /SQLInstance:NewFabrikamTFS /DatabaseName:TFS_Configuration

Licencja

Możesz użyć polecenia Licencja, aby wyświetlić, zmodyfikować lub rozszerzyć klucz licencjonowania dla wdrożenia Azure DevOps Server.

TFSConfig License [/ProductKey:Key] [/extend [NewTrialID]]

Opcja

Opis

/ProductKey: Klucz

Określa, że klucz licencji dla wdrożenia zostanie zaktualizowany o wartość Klucza.

/extend

Określa, że okres licencjonowania wersji próbnej Azure DevOps Server zostanie wydłużony o 30 dni. Tej opcji można użyć tylko raz bez uzyskiwania nowego identyfikatora wersji próbnej. Jeśli jest wymagane drugie rozszerzenie, musisz uzyskać drugą licencję próbną od firmy Microsoft.

Wymagania wstępne

Aby użyć polecenia Licencja, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation. Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Aby interaktywnie wyświetlać, modyfikować lub zmieniać licencjonowanie wdrożenia, można użyć konsoli administracyjnej programu Azure DevOps.

Aby uzyskać więcej informacji, zobacz Otwórz konsolę administracyjną Azure DevOps i Znajdź lub zmień klucz produktudla Azure DevOps Server .

Przykłady

W poniższym przykładzie pokazano, jak wyświetlić informacje o licencjonowaniu dla wdrożenia Azure DevOps Server. W tym przykładzie wdrożenie korzysta z licencji próbnej.

TFSConfig License

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

Team Foundation Server Standard license
The following features are installed:
Team Foundation Server
Build Services
Build: 21106.00
Product ID: 01234-567-8910
Trial license with 74 days remaining, expiring on 6/30/2010
Trial ID: ABCD-EFGH-IJKL
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 pakiety testów, aby wskazać plany testów i pakiety testów oparte na elementach pracy. Aktualizuje również istniejące dane zarządzania testami i połączenia między innymi istniejącymi artefaktami testów, takimi jak punkty testowe, 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 jakieś plany testów.

/CollectionName:CollectionName

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

Jeśli w nazwie kolekcji projektu znajdują się spacje, ujmij nazwę w cudzysłów, na przykład " Fabrikam Fiber Collection " .

/TeamProjectName:TeamProjectName

Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdzić stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej za pomocą /collectionName parametru.

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

Wymagania wstępne

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

Zobacz Ustawianie uprawnień administratora dla Team Foundation Server.

Uwagi

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

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 czasie używania 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ć je osobno dla każdego projektu.

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

Polecenia TCM należy używać tylko w przypadku, gdy automatyczna migracja istniejących danych testowych zakończy się niepowodzeniem.

Aby dowiedzieć się więcej na temat migracji i kiedy używać tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami.

Jeśli nie możesz uzyskać dostępu do planów testów lub pakietó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 dla każdego projektu po kolei.

Przykłady

Poniższy przykład pokazuje, jak sprawdzić stan uaktualnienia planu testu w projekcie Fabrikam Fiber hostowany w domyślnej kolekcji projektów (DefaultCollection):

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

Importuj

Polecenie importu zostało wycofane na serwerach TFS 2013. Wcześniejsze wersje są dostępne tutaj:

Jeśli potrzebujesz pomocy przy uaktualnianiu danych i projektów z wcześniejszej wersji programu Azure DevOps Server, zobacz Uaktualnianieprogramu Azure DevOps Server lub skontaktuj się z Pomoc techniczna Microsoft.

PrepareSQL

W programie TFS 2012 nie można było wypracowyć polecenia prepareSQL. Wcześniejsze wersje są dostępne tutaj:

Napraw

Polecenie naprawy zostało naprawione w programie TFS 2012. Wcześniejsze wersje są dostępne tutaj:

Jeśli musisz naprawić procedury składowane po awarii poprawki bazy danych, skontaktuj się z Pomoc techniczna Microsoft .

Zdiagnozować

Polecenie diagnose było przestarzałe w programie TFS 2013. Wcześniejsze wersje są dostępne tutaj:

Jeśli potrzebujesz pomocy w diagnozowaniu potencjalnych niezgodności między aktualizacjami oprogramowania na serwerach warstwy aplikacji i warstwy danych dla usługi Azure DevOps Server, skontaktuj się z pomocą techniczną Community deweloperów.

Aktualizacje

Polecenie updates zostało wycofane na serwerach TFS 2013. Wcześniejsze wersje są dostępne tutaj:

Jeśli potrzebujesz pomocy przy instalowaniu aktualizacji oprogramowania, których brakuje w bazach danych programu Azure DevOps Server, skontaktuj się z Pomoc techniczna Microsoft.

PrepareClone

Polecenie PrepareClone zostało wycofane na serwerach TFS 2017.

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

PrepareClone polecenie usuwa informacje o zaplanowanych kopii zapasowych, SharePoint i raportowania zasobów z Azure DevOps Server wdrożenia.

To polecenie jest używane w dwóch okolicznościach:

  • podczas przenoszenia wdrożenia na nowy sprzęt, ale chcesz nadal korzystać ze starego wdrożenia
  • podczas klonowania wdrożenia Azure DevOps Server wdrożenia

W każdym z tych przypadków uruchomienie tego polecenia ma kluczowe znaczenie.

Jeśli tego nie zimkniesz, oryginalne zasoby będą używane zarówno przez oryginalne, jak i nowe serwery.

Jeśli zarówno oryginalne, jak i nowe serwery są na żywo i wskazują te same SharePoint lub zasoby raportowania przez dowolny czas, może to spowodować uszkodzenie baz danych.

Ważne:
To polecenie należy uruchomić przed konfiguracją, niezależnie od tego, czy przenosisz, czy klonujesz Azure DevOps Server. Uruchomienie go po zakończeniu konfiguracji może prowadzić do niespójności między zawartością w bazach danych i zawartością w web.config danych. Te niespójności mogą spowodować, że serwer będzie w trybie offline. Jeśli już skonfigurowano wdrożenie przeniesione lub sklonowane Azure DevOps Server i musisz uruchomić polecenie , wykonaj następujące kroki. Najpierw przejmij serwer w tryb pracy. Następnie uruchom polecenie PrepareClone, polecenie ChangeServerID, a następnie polecenie RemapDBs. Na koniec odszukaj serwer.

TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:TFSConfigurationDatabaseName
[/notificationURL: TFSURL] [/usesqlalwayson]

Opcja

Wyniki działania

/DatabaseName

Określa nazwę serwera, który hostuje bazę danych, dla której ma Azure DevOps Server, oprócz nazwy samej bazy danych konfiguracji.

/SQLInstance: Nazwa_serwera

Określa nazwę serwera, który ma być mapowanie jako serwer, który hostuje co najmniej jednej bazy danych dla Azure DevOps Server. Jeśli wystąpienie inne niż domyślne hostuje bazę danych, należy również określić nazwę wystąpienia.

Użyj tego formatu: Nazwa_wystąpienia_serwera.

/NotificationURL: TFSURL

Opcjonalny. Określa adres URL powiadomienia dla serwera warstwy aplikacji.

/usesqlalwayson

Opcjonalny. Określa, że bazy danych są częścią grupy dostępności AlwaysOn w SQL Server. Jeśli ta opcja jest skonfigurowana, ustawia wartość MultiSubnetFailover w parametrów połączenia.

Aby uzyskać więcej informacji, zobacz [Zawsze włączone grupy dostępności (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Wymagania wstępne

Aby użyć polecenia PrepareClone, musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i członkiem grupy zabezpieczeń sysadmin dla wszystkich baz danych programu SQL Server, które Azure DevOps Server używane.

Aby uzyskać więcej informacji, zobacz Permission reference for Azure DevOps Server (Odwołanie do uprawnień dla Azure DevOps Server).

Uwagi

Polecenie PrepareClone umożliwia ponowne skonfigurowanie programu Azure DevOps Server w przypadku przeniesienia oryginalnej instalacji na nowy sprzęt i kontynuowania korzystania z oryginalnego wdrożenia Azure DevOps Server i sprzętu lub sklonowania wdrożenia usługi Azure DevOps Server do celów testowych. Aby obsługiwać konfigurację klonowania, należy użyć narzędzia TFSConfig PrepareClone w połączeniu z plikami TFSConfig RemapDBs i TFSConfig ChangeServerID.

Przykład

W poniższym przykładzie pokazano, jak za pomocą polecenia na przeniesionym Azure DevOps Server o nazwie NewFabrikamTFS usunąć stare informacje o zasobach kopii zapasowej, raportowania i SharePoint kopii zapasowej. Jeśli te informacje nie zostaną usunięte, oryginalne wdrożenie usługi Azure DevOps Server nadal używa tych samych zasobów, a bazy danych zostaną uszkodzone. W tym przykładzie nazwa serwera SQL Server przeniesionego serwera Azure DevOps Server również nosi nazwę NewFabrikamTFS, a wystąpienie jest wystąpieniem domyślnym, więc nie są wymagane żadne konkretne informacje o wystąpieniu, a tylko nazwa serwera.

TFSConfig PrepareClone /SQLInstance:NewFabrikamTFS /DatabaseName:TFS_Configuration