Use TFSConfig to manage Azure DevOps on-premises

Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Note: Azure DevOps Server was previously named Visual Studio Team Foundation Server.

For TFS 2010 and earlier versions, a few of these commands are available in the TFSAdminUtils command-line tool.

The TFSConfig command-line tool can be used to perform a variety of administrative actions for your Azure DevOps on-premises deployment.

TFSConfig can be run from any machine on which Azure DevOps Server has been installed.

Command-line tool location

Azure DevOps command line tools are installed in the /Tools directory of an Azure DevOps application-tier server.

  • Azure DevOps Server 2019: %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

Prerequisites

For many commands to operate correctly, TFSConfig will need to be able to connect to the various servers and services which are part of your TFS deployment, and the user running TFSConfig will need to have administrative permissions for these same servers and services. Requirements for specific commands will be called out below.

Many TFSConfig command must be run from an elevated Command Prompt, even if the running user has administrative credentials. To open an elevated Command Prompt, click Start, right-click Command Prompt, and then click Run as Administrator. For more information, see: User Account Control.

You can also perform administrative actions interactively using the administration console for Azure DevOps Server. See Administrative task quick reference.

List commands and get help

To display a full list of TFSConfig commands, use the help command:

TFSConfig help

To get help for an individual command, use the help command and specify the name of the command with which you want help. For example, to get help for the accounts command:

TFSConfig help accounts

Accounts

Use the accounts command to manage these Azure DevOps Server service accounts.

  • the Azure DevOps Server service account
  • the data sources account for SQL Server Reporting Services
  • the Azure DevOps Proxy Server service account

You can also use this command to change the ownership of the Azure DevOps Server databases.

TfsConfig accounts /change|add|set|delete|updatepassword|resetowner
	[/accountType:<adminConsole|applicationTier|proxy|reportingDataSource>]
	[/account:<accountName>] [/password:<password>]
	[/sqlInstance:<serverName>] [/databaseName:<databaseName>] [/continue]
Operation Description
UpdatePassword Changes the password of an account that is used as a service account. Changes the existing account and all accountTypes that run as the given account.
Change Changes the account that is used as the service account. Adds the new account to necessary resources and groups, grants the required permissions, then sets the service to use it. This does not remove the old account from the resources.

If you do not use the accountType option, the service account for the application tier will be changed.
Add Only adds the new account to the necessary resources. Useful for NLB scenarios. Use the continue flag if some collections are unreachable. Add can be run again later to update any missed collections. Adds an account to the groups that are required for using the account as a service account.
Set Only sets the service to use an account already added to the resources. Useful for NLB scenarios.
Delete Removes the account from all resources. Precautions should be used when deleting an account since it can cause other servers to get denied service.
ResetOwner If the databases are restored as part of a move, clone, or disaster recovery the database owner can switch to the admin restoring the server. This option iterates through all databases and sets the dbo login to the current owner.
AccountType Description
AdminConsole Administration Console Users are users that have been granted the minimum permissions across various resources to use the console.
ApplicationTier Changes the service account on the appPool for the core web services. (TFSService)
Proxy Changes the service account on the appPool for the proxy web services. (TFSProxy)
ReportingDataSource Changes the account the reports use to access the reporting data. (TFSReports)

The default value is ApplicationTier.

The sqlInstance and databaseName are only appropriate for use when adding an account to databases before the application tier is configured. This is primarily useful in disaster recovery scenarios where another account is needed before running the AT Only configuration wizard.

The continue option is used when adding or changing an account. For those operations, the account is changed in each collection database. If continue is supplied, it will continue if a collection is unreachable. It can be run again when they are reachable.

Note

The accounts must be in domainName\userName format. For system accounts, you must use quotes around the full account name (for example, "NT Authority\Network Service"). System accounts do not require a password.

Parameter Description
Account Specifies the name of the account that you want to add, change, or delete from a referenced account type, such as /AccountType:ApplicationTier.
Password Specifies the password of the service account. This parameter is optional if you are using a system account or an account that does not have a password, such as Network Service.
sqlInstance Used only with /ResetOwner.

Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. You must specify the name and instance in the following format:

ServerName\InstanceName.
databaseName Used only with /ResetOwner.

Specifies the name of the database whose ownership you want to change. By using this command, you reset the ownership of the database that you specify to the account under which you are running the command.
continue Updates any groups that are not available when you run the command. This option is usually used in NLB scenarios.

Prerequisites

To use the accounts command, you must be a member of:

  • the Azure DevOps Administrators security group
  • the sysadmin role for all SQL Server instances that your Azure DevOps Server instance uses.

If you use the /proxy option, you must be an administrator on the proxy server.

For more information, see Permission reference for Azure DevOps Server.

Remarks

Use the accounts command to automate changes to the service accounts, databases, and service account groups of Azure DevOps Server. You can configure accounts that you have already created, but you can't create accounts.

Before you change the domain or workgroup of an account, the account must have the Account is sensitive and cannot be delegated permission on the application-tier server. For more information, see this page on the Microsoft Web site: Enabling Delegated Authentication.

The accounts command supports on-premises Azure DevOps Server deployments. To change the account owner of a Azure DevOps Services account, see Change account ownership.

Examples

Change the service account of data sources for Reporting Services to a new account in the Contoso domain, Contoso\NewAccount, and the password, to Password.

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

Add the Network Service system account to the service account groups for Azure DevOps Server (system accounts don't have passwords).

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

Change the ownership of the TFS_Warehouse database on the ContosoMain SQL Server in the TeamDatabases named instance to the user account under which you are running the command.

Note

You can't specify what account to set as the owner of the databases when you use this command. The owner will be set to the account under which you are running the command.

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

Use the Accounts command to manage these TFS service accounts.

  • the TFS service account
  • the data sources account for SQL Server Reporting Services
  • the Azure DevOps Proxy Server service account

You can also use this command to change the ownership of the Azure DevOps Server databases.

TFSConfig Accounts /change|add|set|delete|updatepassword|resetowner
	[/AccountType:{AdminConsole|ApplicationTier|Proxy|ReportingDataSource}]
	[/Account:AccountName] [/Password:Password]
	[/SQLInstance:ServerName] [/DatabaseName:DatabaseName] [/Continue] [/usesqlalwayson]
Option Description
/change Changes the account that is used as the service account. This option adds the account that you specify to all the necessary groups, grants it the Prerequisites if possible, and sets the service to use the account. If you do not use the /AccountType option with this option, the service account for the application tier will be changed.
/add Adds an account to the groups that are required for using the account as a service account. This option adds the account that you specify to the necessary groups and grants it the permissions that are required to act as the service account (if possible). However, this option will not change the account that is used as the service account. This option is usually used in network load balancing (NLB) scenarios. You can use this option with /continue if some services or databases might not be available in your environment.
/set Sets an account as the service account. This option does not add the account to any groups. Therefore, you must use this option only with accounts that have already been added to the required groups and have the necessary permissions. This option is usually used in NLB scenarios.
/delete Removes an account from the account type that you specify. This option removes the account that you specify from the necessary groups and removes the permissions that are required to act as the service account (if possible). However, this option will not change the account that is used as the service account. Make sure that you do not use this option for an account that the servers in your deployment currently use as a service account.
/ResetOwner Changes the ownership of the databases that Azure DevOps Server uses to the account that you are using to run this command. This option iterates though all the databases and sets the dbo login to the account that you are using to run this command. You might need to use this option when you move or restore a deployment.
/UpdatePassword Changes the password of an account that is used as a service account. This option updates the password for the account that you specify for all services in Azure DevOps Server that use that account.
/AccountType: { AdminConsole | ApplicationTier | ReportingDataSource | Proxy }
  • AdminConsole: the group of users who have the minimum permissions that are required to open and use the administration console for Azure DevOps (AdminConsole)
  • ApplicationTier: the service account that is used for Azure DevOps Server (TFSService)
  • ReportingDataSource: the data sources account for Reporting Services (TFSReports)
  • Proxy: the service account for Azure DevOps Server Proxy (TFSProxy)

The default value is ApplicationTier.

/Account: AccountName Specifies the name of the account that you want to add, change, or delete from a referenced account type, such as /AccountType:ApplicationTier. Specify Account in one of the following forms: Domain\AccountName or Computer\AccountName. If you want to use a system account, such as Network Service or Local System, use the Computer\AccountName format. For more information about how to specify a system account, see the usage examples later in this topic.
/Password: Password Specifies the password of the service account.

Note: This parameter is optional if you are using a system account or an account that does not have a password, such as Network Service.
/SQLInstance: ServerName Used only with /ResetOwner. Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. You must specify the name and instance in the following format:

ServerName\InstanceName.
/DatabaseName: DatabaseName Used only with /ResetOwner. Specifies the name of the database whose ownership you want to change. By using this command, you reset the ownership of the database that you specify to the account under which you are running the command.
/continue Updates any groups that are not available when you run the command. This option is usually used in NLB scenarios.
/usesqlalwayson Used only with /ResetOwner in conjunction with /SQLInstance and /DatabaseName. Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the Accounts command, you must be a member of

  • the Team Foundation Administrators security group
  • the sysadmin role for all SQL Server instances that your Azure DevOps Server instance uses.

If you use the /proxy option, you must be an administrator on the proxy server.

For more information, see Permission reference for Azure DevOps Server>.

Remarks

Use the Accounts command to automate changes to the service accounts, databases, and service account groups of Azure DevOps Server. You can configure accounts that you have already created, but you can't create accounts.

Before you change the domain or workgroup of an account, the account must have the Account is sensitive and cannot be delegated permission on the application-tier server. For more information, see this page on the Microsoft Web site: Enabling Delegated Authentication.

The Accounts command supports on-premises Azure DevOps Server deployments. To change the account owner of a Azure DevOps Services account, see Change account ownership.

Examples

Change the service account of data sources for Reporting Services to a new account in the Contoso domain, Contoso\NewAccount, and the password, to Password.

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

Add the Network Service system account to the service account groups for Azure DevOps Server. (System accounts don't have passwords.)

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

Change the ownership of the "TFS_Warehouse" database on the "ContosoMain" SQL Server in the "TeamDatabases" named instance to the user account under which you are running the command.

Note

You can't specify what account to set as the owner of the databases when you use this command. The owner will be set to the account under which you are running the command.

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

AddProjectReports

Note

The addProjectReports command is available with TFS 2017.1 and later versions.

You use the addProjectReports command to add or overwrite reports for an existing team project.

TfsConfig addProjectReports /collection:<teamProjectCollectionUrl> /teamProject:<projectName> /template:<templateName>
    [/force]
Option Description
collection Required. URL of Team Project Collection.
teamproject Required. Specifies the name of the team project.
template Required. Specifies the name of the process template. Available options are Agile, CMMI and Scrum.
force Optional. Specifies that reports should be overwritten if they already exist.

Prerequisites

To use the addProjectReports command, you must have permissions to run TFSConfig and to upload reports to the Reporting Service.

Remarks

You use the addProjectReports command when your project does not have reports or you want to update the reports defined for a process.

You may need to use this command when:

  • The project was created in the Azure DevOps portal and not from Visual Studio
  • The project was created from Visual Studio, however reporting was not configured in Azure DevOps Server.

If you would like to overwrite reports in your project with default reports because you upgraded Azure DevOps Server and old reports in your project are no longer compatible, use the /force option. If you have customized reports, please make a backup before doing this.

To learn more about adding reports to an on-premises Azure DevOps Server, see Add reports to a project.

Example

The following example shows how to add Agile reports to MyProject project in http://myTfsServer:8080/tfs/DefaultCollection project collection.

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

You use the AddProjectReports command to add or overwrite reports for an existing project.

TfsConfig addProjectReports
	/collection:teamProjectCollectionUrl
	/teamProject:projectName
	/template:templateName
	[/force]
Option Description
/collection Required. URL of Project Collection.
/teamProject Required. Specifies the name of the project.
/template Required. Specifies the name of the process template. Available options are Agile, CMMI and Scrum
/force Optional. Specifies that reports should be overwritten if they already exist.

Prerequisites

To use the AddProjectReports command, you must have permissions to run TFSConfig and to upload reports to the Reporting Service.

Remarks

You use the AddProjectReports command when your project does not have reports or you want to update the reports defined for a process.

You may need to use this command when:

  • the project was created in the web portal and not from Visual Studio
  • the project was created from Visual Studio, however reporting was not configured in Azure DevOps Server.

If you would like to overwrite reports in your project with default reports because you upgraded Azure DevOps Server and old reports in your project are no longer compatible, use the /force option. If you have customized reports, please make a backup before doing this.

To learn more about adding reports to an on-premises Azure DevOps Server, see Add reports to a project.

Example

The following example shows how to add Agile reports to MyProject project in http://myTfsServer:8080/tfs/DefaultCollection project collection.

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

Authentication

The Authentication command changes the network authentication protocol that the Azure DevOps Server application tier or proxy website uses.

TFSConfig Authentication [/provider:NTLM|Negotiate] [/viewAll] [/siteType:ApplicationTier|Proxy]
Option Description
/viewAll Displays the current authentication settings for Azure DevOps Server.
/provider: { NTLM | Negotiate } Specifies the authentication provider you want to configure for the website.
  • NTLM: Use the NTML authentication protocol
  • Negotiate: Use the Negotiate (Kerberos) authentication protocol
/siteType Specifies the website (application tier or proxy) whose network authentication protocol you want to change. The application tier is the default.

Prerequisites

To use the Authentication command, you must be a member of the Azure DevOps Administrators security group and a local administrator on the application-tier server or proxy server, depending on the value of the siteType option.

Remarks

The Authentication command is used by an administrator who wants to change the network authentication protocol for one or more websites on which Azure DevOps Server relies. The administrator runs this command from the application tier to update those websites that require a change in their network authentication protocol. The command changes the NTAuthenticationProviders property in the IIS metabase.

Before you use the Authentication command to change the authentication protocol, you can run the command with the /viewAll option to see what the existing settings are.

Example

The following example displays the current value that is assigned for the network authentication protocol.

TFSConfig Authentication /viewAll

The Authentication command changes the network authentication protocol that the TFS application tier or proxy website uses.

TFSConfig Authentication [/provider:NTLM|Negotiate] [/viewAll] [/siteType:ApplicationTier|Proxy]
Option Description
/viewAll Displays the current authentication settings for Azure DevOps Server.
/provider: { NTLM | Negotiate } Specifies the authentication provider you want to configure for the website.
  • NTLM: Use the NTML authentication protocol
  • Negotiate: Use the Negotiate (Kerberos) authentication protocol
/siteType Specifies the website (application tier or proxy) whose network authentication protocol you want to change. The application tier is the default.

Prerequisites

To use the Authentication command, you must be a member of the Team Foundation Administrators security group and a local administrator on the application-tier server or proxy server, depending on the value of the siteType option.

Remarks

The Authentication command is used by an administrator who wants to change the network authentication protocol for one or more websites on which Azure DevOps Server relies. The administrator runs this command from the application tier to update those websites that require a change in their network authentication protocol. The command changes the NTAuthenticationProviders property in the IIS metabase.

Before you use the Authentication command to change the authentication protocol, you can run the command with the /viewAll option to see what the existing settings are.

Example

The following example displays the current value that is assigned for the network authentication protocol.

TFSConfig Authentication /viewAll

Certificates

Use the certificates command to change how certificates are configured for client authentication in a deployment of Azure DevOps Server that utilizes HTTPS, secure sockets layer (SSL), and certificates.

TfsConfig certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]
Option Description
machine Specifies that the certificate list will be from the local machine context instead of the current user context.
disable Specifies that the client authentication certificate setting will be disabled.
autoSelect Specifies that a certificate will be automatically selected from the certificate list. The Manage Client Certificates window will not open.
noprompt Specifies that the Manage Client Certificates window will not open when the Certificates command is run.
thumbprints Specifies that the certificate that matches the specified thumbprint will be used. You can specify more than one certificate by separating individual thumbprints with a comma.

Prerequisites

To use the certificates command, you must be a member of the Azure DevOps Administrators security group and the local Administrators group on the computer from which you run the command. For more information, see Permission reference for Azure DevOps Server.

Remarks

By default, the certificates command will automatically select a client certificate from the certificate list for the current user. However, you can use the options for the command to specify a specific certificate or certificates from the current user context or from the local machine context.

Before you use the certificates command, you must first configure the servers in your deployment of Azure DevOps Server to utilize certificates. For more information, see Setting up HTTPS with Secure Sockets Layer (SSL) for Azure DevOps Server.

You use the certificates command to configure the client certificates that are used by a deployment of Azure DevOps Server that has been configured to use HTTPS/SSL and certificates. If you use the Certificates command with no options, a client certificate will be automatically selected from the current user context from which you run the command.

Examples

The following example shows how to specify the local machine certificate that has the thumbprint aa bb cc dd ee with no prompting.

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

The following example shows how to specify using automatic selection of a client certificate from the current user store.

TfsConfig certificates /autoselect

Use the Certificates command to change how certificates are configured for client authentication in a deployment of Azure DevOps Server that utilizes HTTPS, secure sockets layer (SSL), and certificates.

TFSConfig Certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]
Option Description
/machine Specifies that the certificate list will be from the local machine context instead of the current user context.
/disable Specifies that the client authentication certificate setting will be disabled.
/autoSelect Specifies that a certificate will be automatically selected from the certificate list. The Manage Client Certificates window will not open.
/noprompt Specifies that the Manage Client Certificates window will not open when the Certificates command is run.
/thumbprints: thumbprint Specifies that the certificate that matches the specified thumbprint will be used. You can specify more than one certificate by separating individual thumbprints with a comma.

Prerequisites

To use the Certificates command, you must be a member of the Team Foundation Administrators security group and the local Administrators group on the computer from which you run the command. For more information, see Permission reference for Azure DevOps Server.

Remarks

By default, the Certificates command will automatically select a client certificate from the certificate list for the current user. However, you can use the options for the command to specify a specific certificate or certificates from the current user context or from the local machine context.

Before you use the Certificates command, you must first configure the servers in your deployment of Azure DevOps Server to utilize certificates. For more information, see Setting up HTTPS with Secure Sockets Layer (SSL) for Azure DevOps Server.

You use the Certificates command to configure the client certificates that are used by a deployment of Azure DevOps Server that has been configured to use HTTPS/SSL and certificates. If you use the Certificates command with no options, a client certificate will be automatically selected from the current user context from which you run the command.

Examples

The following example shows how to specify the local machine certificate that has the thumbprint "aa bb cc dd ee" with no prompting.

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

The following example shows how to specify using automatic selection of a client certificate from the current user store.

TFSConfig Certificates /autoselect

ChangeServerID

The changeServerID command changes the GUIDs that are associated with the databases for Azure DevOps Server. GUIDs must be unique within a deployment of Azure DevOps Server. If more than one database has the same GUID, your deployment can become unstable or unusable. You can change the GUID for the configuration database, the GUIDs for all project collection databases in the deployment, or both.

Although you would not typically use this command in daily operations, you might use this command in the following circumstances:

  • You restored your deployment to new hardware, the old deployment is still operational, and you want to utilize both deployments. This scenario is sometimes referred to as cloning the server.

  • You want to test a software update or a hardware configuration on a duplicate deployment so that you do not risk disrupting your production environment.

  • You want to fully test the restoration of databases to new hardware in a test lab or separate environment, to ensure that your deployment can be restored.

  • You must reset the GUID for a collection database after moving it to another deployment for which that GUID is already reserved.

Note

The changeServerID command is not reversible. After a GUID has been changed, you cannot undo that change except by restoring a previous version of that database.

TfsConfig changeServerID /sqlInstance:<serverName> /databaseName:<configurationDatabaseName>
	[/projectCollectionsOnly] [/configDBOnly] [/collectionName]
Option Description
sqlInstance Required. Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the format: ServerName\InstanceName.
databaseName Required. Specifies the name of the configuration database for Azure DevOps Server. By default, the name of this database is TFS_ConfigurationDB.
projectCollectionsOnly Specifies that only the GUIDs for collections will be changed.
configDBOnly Specifies that only the GUID for the configuration database will be changed.
collectionName Specifies to create a new instance id for the specific collection but not for Azure DevOps instance and the other collections.

Prerequisites

To use the changeServerID command, you must be a member of the Azure DevOps Administrators security group and a member of the sysadmin security role for all SQL Server instances that Azure DevOps Server uses. For more information, see Permission reference for Azure DevOps.

Remarks

You use the changeServerID command to create a discrete duplicate of a deployment of Azure DevOps Server for testing or cloning purposes. After you use the changeServerID command, you must direct clients to create a connection to the changed server before it can be used.

Example

The following example shows how to change the GUIDs of all databases in the Contoso1 deployment of Azure DevOps Server, where the configuration database is hosted on the server that is named ContosoMain on the named instance TeamDatabases in SQL Server.

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

The ChangeServerID command changes the GUIDs that are associated with the databases for TFS. GUIDs must be unique within a deployment of TFS. If more than one database has the same GUID, your deployment can become unstable or unusable. You can change the GUID for the configuration database, the GUIDs for all project collection databases in the deployment, or both. Although you would not typically use this command in daily operations, you might use this command in the following circumstances:

  • You restored your deployment to new hardware, the old deployment is still operational, and you want to utilize both deployments. This scenario is sometimes referred to as cloning the server.

  • You want to test a software update or a hardware configuration on a duplicate deployment so that you do not risk disrupting your production environment.

  • You want to fully test the restoration of databases to new hardware in a test lab or separate environment, to ensure that your deployment can be restored.

  • You must reset the GUID for a collection database after moving it to another deployment for which that GUID is already reserved.

    Note

    The ChangeServerID command is not reversible. After a GUID has been changed, you cannot undo that change except by restoring a previous version of that database.

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

Option Description
/SQLInstance: ServerName Required. Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the format: ServerName\InstanceName
/DatabaseName: DatabaseName Required. Specifies the name of the configuration database for Azure DevOps Server. By default, the name of this database is TFS_ConfigurationDB.
/ProjectCollectionsOnly Specifies that only the GUIDs for collections will be changed.
/ConfigDBOnly Specifies that only the GUID for the configuration database will be changed.
/usesqlalwayson Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the ChangeServerID command, you must be a member of the Team Foundation Administrators security group and a member of the sysadmin security role for all SQL Server instances that Azure DevOps Server uses. For more information, see Permission reference for Azure DevOps.

Remarks

You use the ChangeServerID command to create a discrete duplicate of a deployment of Azure DevOps Server for testing or cloning purposes. After you use the ChangeServerID command, you must direct clients to create a connection to the changed server before it can be used.

Example

The following example shows how to change the GUIDs of all databases in the Contoso1 deployment of Azure DevOps Server, where the configuration database is hosted on the server that is named "ContosoMain" on the named instance "TeamDatabases" in SQL Server.

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

CodeIndex

Use the codeIndex command to manage code indexing on Azure DevOps Server. For example, you might want to reset the index to fix CodeLens information, or turn off indexing to investigate server performance issues.

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>]
Option Description
indexingStatus Show the status and configuration of the code indexing service.
setIndexing on: Start indexing all changesets.
off: Stop indexing all changesets.
keepupOnly: Stop indexing previously created changesets and start indexing new changesets only.
ignoreList Specifies a list of code files and their paths that you don't want indexed.

add: Add the file that you don't want indexed to the ignored file list.
remove: Remove the file that you want indexed from the ignored file list.
removeAll: Clear the ignored file list and start indexing all files.
view: See all the files that aren't being indexed.
ServerPath: Specifies the path to a code file.

You can use the wildcard character (*) at the start, end, or both ends of the server path.
listLargeFiles Shows the specified number of files that exceeds the specified size in KB. You can then use the /ignoreList option to exclude these files from indexing.

For this, you'll need Team Foundation Server 2013 with Update 3.
reindexAll Clear previously indexed data and restart indexing.
destroyCodeIndex Delete the code index and remove all indexed data. Does not require confirmation if you use the /noPrompt option.
temporaryDataSizeLimit Control how much temporary data that CodeLens creates when processing changesets. The default limit is 6 GB (2 GB in Update 5).

view: Show the current size limit.
SizeInGBs: Change the size limit.
disable: Remove the size limit.

This limit is checked before CodeLens processes a new changeset. If temporary data exceeds this limit, CodeLens will pause processing past changesets, not new ones. CodeLens will restart processing after the data is cleaned up and falls below this limit. Cleanup runs automatically once a day. This means temporary data might exceed this limit until cleanup starts running.

For this, you'll need Team Foundation Server 2013 with Update 4.
indexHistoryPeriod Control how long to index your change history. This affects how much history CodeLens shows you. The default limit is 12 months. This means CodeLens shows your change history from the last 12 months only.

view: Show the current number of months.
all: Index all change history.
NumberOfMonths: Change the number of months used to index change history.

For this, you'll need Team Foundation Server 2013 with Update 4.
collectionName Specifies the name of the project collection on which to run the CodeIndex command. Required if you don't use /CollectionId.
collectionId Specifies the identification number of the project collection on which to run the CodeIndex command. Required if you don't use /CollectionName

Prerequisites

To use the codeIndex command, you must be a member of the Azure DevOps Administrators security group. See Permission reference for Azure DevOps Server.

Examples

To see the code indexing status and configuration:

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

To start indexing all changesets:

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

To stop indexing previously created changesets and start indexing new changesets only:

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

To find up to 50 files that are larger than 10 KB:

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

To exclude a specific file from indexing and add it to the ignored file list:

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

To see all the files that aren't indexed:

TfsConfig codeIndex /ignoreList:view

To clear previously indexed data and restart indexing:

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

To save all changeset history:

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

To remove the size limit on CodeLens temporary data and continue indexing regardless of temporary data size:

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

To delete the code index with confirmation:

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

Command availability: TFS 2015 and TFS 2013

Use the CodeIndex command to manage code indexing on Azure DevOps Server. For example, you might want to reset the index to fix CodeLens information, or turn off indexing to investigate server performance issues.

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]
Option Description

/indexingStatus

Show the status and configuration of the code indexing service.

/setIndexing:[ on | off | keepupOnly ]

  • on: Start indexing all changesets.

  • off: Stop indexing all changesets.

  • keepupOnly: Stop indexing previously created changesets and start indexing new changesets only.

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

</td>
<td data-th="Description">
<p>Specifies a list of code files and their paths that you don't want indexed.</p>
<ul>
    <li>
    <p>
        <strong>add</strong>: Add the file that you don't want indexed to the ignored file list.</p>
    </li>
    <li>
    <p>
        <strong>remove</strong>: Remove the file that you want indexed from the ignored file list.</p>
    </li>
    <li>
    <p>
        <strong>removeAll</strong>: Clear the ignored file list and start indexing all files.</p>
    </li>
    <li>
    <p> <strong>view</strong>: See all the files that aren't being indexed.</p>
    </li>
	<li>
	<p><strong>ServerPath</strong>: Specifies the path to a code file.</p>
	<p>You can use the wildcard character (*) at the start, end, or both ends of the server path.</p>
	</li>
 </ul>
</td>

/listLargeFiles [/fileCount: FileCount /minSize: MinSize]

Shows the specified number of files that exceeds the specified size in KB. You can then use the /ignoreList option to exclude these files from indexing.

For this, you'll need Team Foundation Server 2013 with Update 3.

/reindexAll

Clear previously indexed data and restart indexing.

/destroyCodeIndex [/noPrompt]

Delete the code index and remove all indexed data. Does not require confirmation if you use the /noPrompt option.

/temporaryDataSizeLimit:[ view | <SizeInGBs> | disable ]

Control how much temporary data that CodeLens creates when processing changesets. The default limit is 6 GB (2 GB in Update 5).

  • view: Show the current size limit.

  • SizeInGBs: Change the size limit.

  • disable: Remove the size limit.

This limit is checked before CodeLens processes a new changeset. If temporary data exceeds this limit, CodeLens will pause processing past changesets, not new ones. CodeLens will restart processing after the data is cleaned up and falls below this limit. Cleanup runs automatically once a day. This means temporary data might exceed this limit until cleanup starts running.

For this, you'll need Team Foundation Server 2013 with Update 4.

/indexHistoryPeriod:[ view | all | <NumberOfMonths> ]

Control how long to index your change history. This affects how much history CodeLens shows you. The default limit is 12 months. This means CodeLens shows your change history from the last 12 months only.

  • view: Show the current number of months.

  • all: Index all change history.

  • NumberOfMonths: Change the number of months used to index change history.

For this, you'll need Team Foundation Server 2013 with Update 4.

/collectionName: CollectionName

Specifies the name of the project collection on which to run the CodeIndex command. Required if you don't use /CollectionId.

/collectionId: CollectionId

Specifies the identification number of the project collection on which to run the CodeIndex command. Required if you don't use /CollectionName.

Prerequisites

To use the CodeIndex command, you must be a member of the Team Foundation Administrators security group. See Permission reference for Azure DevOps Server.

Examples

To see the code indexing status and configuration:

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

To start indexing all changesets:

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

To stop indexing previously created changesets and start indexing new changesets only:

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

To find up to 50 files that are larger than 10 KB:

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

To exclude a specific file from indexing and add it to the ignored file list:

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

To see all the files that aren't indexed:

TFSConfig CodeIndex /ignoreList:view

To clear previously indexed data and restart indexing:

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

To save all changeset history:

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

To remove the size limit on CodeLens temporary data and continue indexing regardless of temporary data size:

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

To delete the code index with confirmation:

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

Collection

You can use the collection command to attach, detach, or delete a project collection from a deployment of Azure DevOps Server. You can also use the collection command to duplicate the database of an existing collection, rename it, and attach it to the deployment. This process is sometimes referred to as cloning a collection.

TfsConfig collection {/attach | /create | /detach | /delete} [/collectionName:<collectionName>]
    [/description:<collectionDescription>]
    [/collectionDB:<serverName>;<databaseName>]
    [/processModel:Inheritance|Xml]
    [/reportingFolder:<reportingFolderPath>]
    [/clone] [/verify] [/continue]
Option Description
attach Required if neither /detach nor /delete is used. If you specify this option, you must also use the /collectionDB option. As an option, you can also use /collectionName and /clone with this option. If you use the /attach option, the specified collection database will be added to your deployment of Azure DevOps Server.
create Creates a collection.
detach Required if neither /attach nor /delete is used. If you specify this option, you must also use the /collectionName option. If you use the /detach option, the database for the specified collection will be stopped, and the collection will be detached from your deployment of Azure DevOps Server.
delete Required if neither /detach nor /attach is used. If you specify this option, you must also use the /collectionName option. If you use the /delete option, the database for the specified collection will be stopped, and the collection will be permanently detached from Azure DevOps Server. You will not be able to re-attach the collection database to this or any other deployment.
CollectionName Specifies the name of the project collection. If the name of the collection contains spaces, you must enclose the name in quotation marks (for example, "My Collection"). Required if either /detach or /delete is used. If you use this option with /detach or /delete, it specifies the collection that will be detached or deleted. If you use this option with /attach, it specifies a new name for the collection. If you use this option with both /attach and /clone, it specifies the name for the duplicated collection.
CollectionDB Required if /attach is used. This option specifies the name of the server that is running SQL Server and the name of the collection database that is hosted on that server.
ServerName Specifies the name of the server that hosts the configuration database for Azure DevOps Server, and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the format: ServerName\InstanceName.
DatabaseName Specifies the name of the configuration database. By default, the name of this database is TFS_ConfigurationDB.
clone If you specify this option, the original collection database will be attached as a clone in SQL Server, and this database will be attached to Azure DevOps Server. This option is primarily used as part of splitting a project collection.

Tip

The /delete option will not delete the collection database from SQL Server. After deleting the collection database from Azure DevOps Server, you can delete the database manually from SQL Server.

Prerequisites

To use the collections command, you must be a member of the Team Foundation Administrators security group as well as the local Administrators group on the machine running TfsConfig. You must also be a member of the sysadmin security role for all instances of SQL Server used by Azure DevOps Server databases. If your deployment is integrated with SharePoint and you are using the /delete option, you must also be a member of the Farm Administrators group for the SharePoint farm from which you are deleting the site collection.

For more information, see Permission reference for Azure DevOps Server.

Remarks

To manage collections interactively or to create a collection, you can use the Project Collections node in the administration console for Azure DevOps. See Manage project collections.

Examples

The following example shows how to permanently remove the Contoso Summer Intern Projects project collection from a deployment of 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.

The following example shows how to duplicate the Contoso Summer Interns Projects project collection, name it Contoso Winter Interns Projects, and attach the duplicate collection to the deployment of Azure DevOps Server.

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

You can use the Collection command to attach, detach, or delete a project collection from a deployment of TFS. You can also use the Collection command to duplicate the database of an existing collection, rename it, and attach it to the deployment. This process is sometimes referred to as cloning a collection. However, you cannot use the Collection command to create a project collection.

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

Parameters

Option Description
/attach Required if neither /detach nor /delete is used. If you specify this option, you must also use the /collectionDB option. As an option, you can also use /collectionName and /clone with this option. If you use the /attach option, the specified collection database will be added to your deployment of Azure DevOps Server.
/detach Required if neither /attach nor /delete is used. If you specify this option, you must also use the /collectionName option. If you use the /detach option, the database for the specified collection will be stopped, and the collection will be detached from your deployment of Azure DevOps Server.
/delete Required if neither /detach nor /attach is used. If you specify this option, you must also use the /collectionName option. If you use the /delete option, the database for the specified collection will be stopped, and the collection will be permanently detached from Azure DevOps Server. You will not be able to re-attach the collection database to this or any other deployment.

Tip: The /delete option will not delete the collection database from SQL Server. After deleting the collection database from Azure DevOps Server, you can delete the database manually from SQL Server.
/CollectionName: CollectionName Specifies the name of the project collection. If the name of the collection contains spaces, you must enclose the name in quotation marks (for example, "My Collection"). Required if either /detach or /delete is used. If you use this option with /detach or /delete, it specifies the collection that will be detached or deleted. If you use this option with /attach, it specifies a new name for the collection. If you use this option with both /attach and /clone, it specifies the name for the duplicated collection.
/CollectionDB: ServerName;DatabaseName Required if /attach is used. This option specifies the name of the server that is running SQL Server and the name of the collection database that is hosted on that server.
  • ServerName: Specifies the name of the server that hosts the configuration database for Azure DevOps Server, and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the format: ServerName\InstanceName.
  • DatabaseName: Specifies the name of the configuration database. By default, the name of this database is TFS_ConfigurationDB.
/clone If you specify this option, the original collection database will be attached as a clone in SQL Server, and this database will be attached to Azure DevOps Server. This option is primarily used as part of splitting a project collection.

Prerequisites

To use the Collections command, you must be a member of the Team Foundation Administrators security group as well as the local Administrators group on the machine running TFSConfig. You must also be a member of the sysadmin security role for all instances of SQL Server used by Azure DevOps Server databases. If your deployment is integrated with SharePoint and you are using the /delete option, you must also be a member of the Farm Administrators group for the SharePoint farm from which you are deleting the site collection.

For more information, see Permission reference for Azure DevOps Server.

Remarks

To manage collections interactively or to create a collection, you can use the Project Collections node in the administration console for Azure DevOps. See Manage project collections.

Examples

The following example shows how to permanently remove the "Contoso Summer Intern Projects" project collection from a deployment of 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.

The following example shows how to duplicate the "Contoso Summer Interns Projects" project collection, name it "Contoso Winter Interns Projects," and attach the duplicate collection to the deployment of Azure DevOps Server.

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

ColumnStoreIndex

Note

Command availability: Requires TFS 2015.2 and later versions.

You use the columnStoreIndex command to enable or disable column store indexes for the databases used by your Azure DevOps Server deployment.

TfsConfig columnStoreIndex /enabled:<true|false>
	/sqlInstance:<serverName>
	/databaseName:<databaseName>
Option Description
enabled Specifies whether you are enabling or disabling column store index for the given SQL instance and database.
sqlInstance Specifies the name of the server that hosts the database for which column store index is being enabled or disabled, and the name of the instance if an instance other than the default is used. If you specify an instance, you must use the format: ServerName\InstanceName.
databaseName Specifies the name of the database for which column store index is being enabled or disabled.

Prerequisites

To use the columnStoreIndex command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

You would typically use the columnStoreIndex command if you were moving a database from a SQL instance which supported column store index to one which did not. In this case, you would need to disable all column store indexes before you could successfully move the databases. Similarly, if you were moving a database back to a SQL instance which supported column store index you might wish to re-enable column store index in order to save space and gain performance.

Example

The following example shows how to enable column store index, for a database named TFS_DefaultCollection on a SQL instance running on a server named ContosoMain on the named instance TeamDatabases.

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

You use the ColumnStoreIndex command to enable or disable column store indexes for the databases used by your TFS deployment.

TfsConfig columnStoreIndex /enabled:{true|false}
	/sqlInstance:ServerName
	/databaseName:DatabaseName
Option Description
/enabled Specifies whether you are enabling or disabling column store index for the given SQL instance and database.
/sqlInstance Specifies the name of the server that hosts the database for which column store index is being enabled or disabled, and the name of the instance if an instance other than the default is used. If you specify an instance, you must use the format: ServerName\InstanceName
/databaseName Specifies the name of the database for which column store index is being enabled or disabled.

Prerequisites

To use the ColumnStoreIndex command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

You would typically use the ColumnStoreIndex command if you were moving a database from a SQL instance which supported column store index to one which did not. In this case, you would need to disable all column store indexes before you could successfully move the databases. Similarly, if you were moving a database back to a SQL instance which supported column store index you might wish to re-enable column store index in order to save space and gain performance.

Example

The following example shows how to enable column store index, for a database named TFS_DefaultCollection on a SQL instance running on a server named "ContosoMain" on the named instance "TeamDatabases".

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

ConfigureMail

Configure the server that runs Azure DevOps Server to use an existing SMTP server for email alerts.

TfsConfig configureMail /Enabled:<true|false> /FromEmailAddress:<emailAddress> /SmtpHost:<SMTPHostName>
Option Description
FromEmailAddress Specifies the address from which to send email notifications from Azure DevOps Server for a check in, work item assigned to you, or other notifications. This address is also checked for validity and, depending on your server configuration, might have to represent a valid email account on the mail server. If the address does not exist or is not valid, the default email address is used.
SmtpHost Specifies the name of the server that hosts the mail server.

Prerequisites

To use the configureMail command, you must be a member of the Team Foundation Administrators security group on the Azure DevOps application-tier server. For more information, see Permission reference for Azure DevOps Server

Remarks

You can also use the administration console to configure Azure DevOps Server to use an SMTP server.

Example

The following example shows the syntax used to configure the from email address to TFS@contoso.com and the SMTP mail server as ContosoMailServer:

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

DBCompression

You use the dbCompression command to enable or disable database page compression for the databases used by your Azure DevOps Server deployment.

TfsConfig dbCompression /pageCompression:[enable|disable]
	/sqlInstance:<serverName>
	/databaseName:<databaseName>
	[/rebuildNow [/offline]]
Option Description
pageCompression Specifies whether you are enabling or disabling page compression for the given SQL instance and database.
sqlInstance Specifies the name of the server that hosts the database for which page compression is being enabled or disabled, and the name of the instance if an instance other than the default is used. If you specify an instance, you must use the format: ServerName\InstanceName
databaseName Specifies the name of the database for which page compression is being enabled or disabled.
rebuildNow Optional. Specifies whether database indexes should be rebuilt (and compressed or decompressed as necessary) immediately. If not used, indexes will be rebuilt by a background job which runs weekly.
offline Optional. Used only in combination with /rebuildNow. If /offline is not specified, indexes will be rebuilt online. If /offline is specified, indexes will be rebuilt offline. This will block other operations, but may be faster than an online index rebuild.

Prerequisites

To use the dbCompression command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

You would typically use the dbCompression command if you were moving a database from a SQL instance which supported compression to one which did not. In this case, you would need to disable compression and decompress all indexes before you could successfully move the databases. Similarly, if you were moving a database back to a SQL instance which supported compression you might wish to re-enable compression in order to save space.

This command only changes whether Azure DevOps Server prefers to use database page compression or not - your databases must still be hosted in a SQL instance whose edition supports compression. See Features Supported by the Editions of SQL Server for more information.

Example

The following example shows how to enable page compression immediately, with indexes rebuilt online, for a database named TFS_DefaultCollection on a SQL instance running on a server named ContosoMain on the named instance TeamDatabases.

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

For TFS 2012 and earlier versions, see https://support.microsoft.com/kb/2712111.

You use the DBCompression command to enable or disable database page compression for the databases used by your Azure DevOps Server deployment.

TFSConfig dbCompression /pageCompression:{enable|disable}
	/sqlInstance:ServerName
	/databaseName:DatabaseName
	[/rebuildNow [/offline]]
Option Description
/pageCompression Specifies whether you are enabling or disabling page compression for the given SQL instance and database.
/sqlInstance Specifies the name of the server that hosts the database for which page compression is being enabled or disabled, and the name of the instance if an instance other than the default is used. If you specify an instance, you must use the format: ServerName\InstanceName
/databaseName Specifies the name of the database for which page compression is being enabled or disabled.
/rebuildNow Optional. Specifies whether database indexes should be rebuilt (and compressed or decompressed as necessary) immediately. If not used, indexes will be rebuilt by a background job which runs weekly.
/offline Optional. Used only in combination with /rebuildNow. If /offline is not specified, indexes will be rebuilt online. If /offline is specified, indexes will be rebuilt offline. This will block other operations, but may be faster than an online index rebuild.

Prerequisites

To use the DBCompression command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

You would typically use the DBCompression command if you were moving a database from a SQL instance which supported compression to one which did not. In this case, you would need to disable compression and decompress all indexes before you could successfully move the databases. Similarly, if you were moving a database back to a SQL instance which supported compression you might wish to re-enable compression in order to save space.

This command only changes whether Azure DevOps Server prefers to use database page compression or not - your databases must still be hosted in a SQL instance whose edition supports compression. See Features Supported by the Editions of SQL Server for more information.

Example

The following example shows how to enable page compression immediately, with indexes rebuilt online, for a database named TFS_DefaultCollection on a SQL instance running on a server named "ContosoMain" on the named instance "TeamDatabases".

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

DeleteTestResults

You use the deleteTestResults command to delete old stored test results from your collection store. This is typically done to reduce the store size or to reduce the time taken when migrating test results to a new schema.

TfsConfig deleteTestResults /ageInDays:<number> /sqlInstance:<serverName> /databaseName:<databaseName>
    [/type:[automated|manual|all]]
    [/preview]
Option Description
ageInDays Test results older than the specified number of days will be deleted or previewed.
sqlInstance The name of the server that hosts the database for which test results are being deleted or previewed, and the name of the instance if an instance other than the default is used. If you specify an instance, you must use the format: ServerName\InstanceName.
databaseName The name of the database for which test results are being deleted or previewed.
type Optional. The type of test results to delete. Valid values are automated, manual, and all.
preview Optional. Display the number of test results that would be deleted based on the age in days, but do not delete these results.

Prerequisites

To use the deleteTestResults command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

Use the /preview parameter to see the test results sorted by project name and year without deleting these results.

Example

The following example shows how to delete manual test results older than 60 days for a database named TFS_DefaultCollection on a SQL instance running on a server named ContosoMain on the named instance TeamDatabases.

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

Command availability: TFS 2017 and later

You use the DeleteTestResults command to delete old stored test results from your collection store. This is typically done to reduce the store size or to reduce the time taken when migrating test results to a new schema.

TFSConfig DeleteTestResults /ageInDays:{number} 
    /sqlInstance:ServerName
    /databaseName:DatabaseName
    [/type:{automated|manual|all}]
    [/preview]
Option Description
/ageInDays Test results older than the specified number of days will be deleted or previewed.
/sqlInstance The name of the server that hosts the database for which test results are being deleted or previewed, and the name of the instance if an instance other than the default is used. If you specify an instance, you must use the format: ServerName\InstanceName
/databaseName The name of the database for which test results are being deleted or previewed.
/type Optional. The type of test results to delete. Valid values are automated, manual, and all.
/preview Optional. Display the number of test results that would be deleted based on the age in days, but do not delete these results.

Prerequisites

To use the DeleteTestResults command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

Use the /preview parameter to see the test results sorted by project name and year without deleting these results.

Example

The following example shows how to delete manual test results older than 60 days for a database named TFS_DefaultCollection on a SQL instance running on a server named "ContosoMain" on the named instance "TeamDatabases".

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

DeploymentPool

The deploymentPool command is designed to migrate all deployment groups from one deployment pool to another.

TfsConfig deploymentpool /migrateDeploymentGroups /fromPool:<source pool name> /toPool:<destination pool name>
Option Description
fromPool Source pool name.
toPool Destination pool name.

Identities

The identities command lists or changes the security identifier (SID) of users and groups in your deployment of Azure DevOps Server. You might need to change or update the SID for users and groups in one of the following scenarios:

  • Changing the domain of your deployment

  • Changing from a workgroup to a domain or from a domain to a workgroup

  • Migrating accounts across domains in Active Directory

Note

You do not need to run this command if you are changing domains within the same Active Directory forest. Azure DevOps Server will automatically handle SID changes for moves within the same forest.

TfsConfig identities [/change /fromdomain:<domainName1> /todomain:<domainName2>
    [/account:<accountName> [/toaccount:<accountName>]] [/sqlInstance:<serverName> /databaseName:<databaseName>]
Option Description
change Specifies that you want to change identities instead of listing them.
fromdomain Required when using /change. Specifies the original domain of the identities that you want to change. If you are changing from a workgroup environment, specifies the name of the computer.
todomain Required when using /change. Specifies the domain to which you want to change identities. If you are changing to a workgroup environment, specifies the name of the computer.
account Specifies the name of an account for which you want to list or change identities.
toaccount Specifies the name of an account to which you want to change identities.
SQLInstance Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the following format:

ServerName\InstanceName
DatabaseName Specifies the name of the configuration database for Azure DevOps Server.

Prerequisites

To use the identities command, you must be a member of the Team Foundation Administrators security group and a member of the sysadmin role for all SQL Server instances that Team Foundation Server uses. For more information, see Set administrator permissions for Azure DevOps Server.

Remarks

You can optionally specify the database to change identities before you configure an application-tier server for the deployment. For example, you might specify the database to change the service account when you clone a deployment of Azure DevOps Server.

When you change identities, the target account or accounts must already exist in Windows.

You must wait for the next identity synchronization with Windows before the properties of accounts that you change with this command will be updated. This requirement includes changes from group to user, user to group, and domain account to local account.

Examples

The following example shows how to list the names of all Windows users and groups that are stored in Azure DevOps Server and to display whether the SID for each user or group matches the SID in Windows. The Contoso1 domain administrators created domain groups such as Contoso1\\Developers and Contoso1\\Testers to help ease the management of permissions across Azure DevOps Server, SQL Server Reporting Services, and 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.

The following example shows how to change the SIDs for all accounts in Azure DevOps Server from the Contoso1 domain to the SIDs for accounts that have matching names in the ContosoPrime domain. Only account names that match will have their SIDs updated. For example, if the hholt account exists as Contoso1\hholt and ContosoPrime\hholt, the account SID will be changed to the SID for ContosoPrime\hholt. If the ContosoPrime\hholt account does not exist, the SID will not be updated for Contoso1\hholt.

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

The following example shows how to change the account for a single user account, Contoso1\hholt, to the account for another user account, ContosoPrime\jpeoples.

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

The following example shows how to change the SID of the NT AUTHORITY\NETWORK SERVICE service account that is used in the deployment of Azure DevOps Server when changing the domain of the deployment from Contoso1 to ContosoPrime. To change a system account such as Network Service, you must follow a two-stage process. You first change the service account from NT AUTHORITY\NETWORK SERVICE to a domain account in the new domain TempSVC, and then you change the account back to NETWORK SERVICE on the server in the new domain. The configuration database is hosted on the server that is named ContosoMain on the named instance TeamDatabases in 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"

The Identities command lists or changes the security identifier (SID) of users and groups in your deployment of TFS. You might need to change or update the SID for users and groups in one of the following scenarios:

  • changing the domain of your deployment

  • changing from a workgroup to a domain or from a domain to a workgroup

  • migrating accounts across domains in Active Directory

    Note

    You do not need to run this command if you are changing domains within the same Active Directory forest. Azure DevOps Server will automatically handle SID changes for moves within the same forest.

    TFSConfig Identities [/change /fromdomain:DomainName1 /todomain:DomainName2 [/account:AccountName] [/toaccount:AccountName]] [/sqlInstance:ServerName /databaseName:DatabaseName] [/account:AccountName] [/usesqlalwayson]

Option Description
/change Specifies that you want to change identities instead of listing them.
/fromdomain: DomainName Required when using /change. Specifies the original domain of the identities that you want to change. If you are changing from a workgroup environment, specifies the name of the computer.
/todomain: DomainName Required when using /change. Specifies the domain to which you want to change identities. If you are changing to a workgroup environment, specifies the name of the computer.
/account: AccountName Specifies the name of an account for which you want to list or change identities.
/toaccount: AccountName Specifies the name of an account to which you want to change identities.
/SQLInstance: ServerName Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the following format:

ServerName\InstanceName
/DatabaseName: DatabaseName Specifies the name of the configuration database for Azure DevOps Server.
/usesqlalwayson Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the Identities command, you must be a member of the Team Foundation Administrators security group and a member of the sysadmin role for all SQL Server instances that Azure DevOps Server uses. For more information, see Set administrator permissions for Azure DevOps Server.

Remarks

You can optionally specify the database to change identities before you configure an application-tier server for the deployment. For example, you might specify the database to change the service account when you clone a deployment of Azure DevOps Server.

When you change identities, the target account or accounts must already exist in Windows.

You must wait for the next identity synchronization with Windows before the properties of accounts that you change with this command will be updated. This requirement includes changes from group to user, user to group, and domain account to local account.

Examples

The following example shows how to list the names of all Windows users and groups that are stored in Azure DevOps Server and to display whether the SID for each user or group matches the SID in Windows. The Contoso1 domain administrators created domain groups such as "Contoso1\Developers" and "Contoso1\Testers" to help ease the management of permissions across Azure DevOps Server, SQL Server Reporting Services, and SharePoint Products.

TFSConfig Identities

Sample output:

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.

The following example shows how to change the SIDs for all accounts in Azure DevOps Server from the Contoso1 domain to the SIDs for accounts that have matching names in the ContosoPrime domain. Only account names that match will have their SIDs updated. For example, if the "hholt" account exists as Contoso1\hholt and ContosoPrime\hholt, the account SID will be changed to the SID for ContosoPrime\hholt. If the "ContosoPrime\hholt" account does not exist, the SID will not be updated for Contoso1\hholt.

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

The following example shows how to change the account for a single user account, Contoso1\hholt, to the account for another user account, ContosoPrime\jpeoples.

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

The following example shows how to change the SID of the "NT AUTHORITY\NETWORK SERVICE" service account that is used in the deployment of Azure DevOps Server when changing the domain of the deployment from Contoso1 to ContosoPrime. To change a system account such as Network Service, you must follow a two-stage process. You first change the service account from NT AUTHORITY\NETWORK SERVICE to a domain account in the new domain (TempSVC), and then you change the account back to NETWORK SERVICE on the server in the new domain. The configuration database is hosted on the server that is named "ContosoMain" on the named instance "TeamDatabases" in 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"

Jobs

You can use the jobs command to create a log file that provides the details of the most recent job activity for a specific project collection, or to retry a job for one or all project collections.

TfsConfig jobs /retry|dumplog [/CollectionName:<collectionName>] [/CollectionId:<id>]
Option Description
retry Required if /dumplog is not used. Specifies that the most recent job will be reattempted for the specified project collection. If you use this option, you must also use either the /CollectionName or the /CollectionID option.
dumplog Required if /retry is not used. Specifies that the most recent job activity for the collection will be sent to a log file. If you use this option, you must also use either the /CollectionName or /CollectionID option.
CollectionName Required if /CollectionID is not used. Specifies the name of the collection for which the most recent job will be either retried (/retry) or logged (/dumplog). If you want to specify all collections, you can use an asterisk (*).
CollectionID Required if /CollectionName is not used. Specifies the identification number of the collection for which the most recent job will be either retried (/retry) or logged (/dumplog).

Prerequisites

To use the jobs command, you must be a member of the Azure DevOps Administrators security group. For more information, see Permission reference for Azure DevOps Server.

Remarks

To retry a job interactively, you can open the administration console for Azure DevOps, select the Status tab for the collection, and then select Retry Job. For more information, see Open the Azure DevOps Administration Console.

Example

The following example shows how to create a log file that lists the most recent job activity for the Contoso Summer Intern Projects project collection in Azure DevOps Server.

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

You can use the Jobs command to create a log file that provides the details of the most recent job activity for a specific project collection, or to retry a job for one or all project collections.

TFSConfig Jobs /retry|dumplog [/CollectionName:CollectionName] [/CollectionID:ID]
Option Description
/retry Required if /dumplog is not used. Specifies that the most recent job will be reattempted for the specified project collection. If you use this option, you must also use either the /CollectionName or the /CollectionID option.
/dumplog Required if /retry is not used. Specifies that the most recent job activity for the collection will be sent to a log file. If you use this option, you must also use either the /CollectionName or /CollectionID option.
/CollectionName: CollectionName Required if /CollectionID is not used. Specifies the name of the collection for which the most recent job will be either retried (/retry) or logged (/dumplog). If you want to specify all collections, you can use an asterisk (*).
/CollectionID: ID Required if /CollectionName is not used. Specifies the identification number of the collection for which the most recent job will be either retried (/retry) or logged (/dumplog).

Prerequisites

To use the Jobs command, you must be a member of the Team Foundation Administrators security group. For more information, see Permission reference for Azure DevOps Server.

Remarks

To retry a job interactively, you can open the administration console for Azure DevOps, click the Status tab for the collection, and then click Retry Job. For more information, see Open the Azure DevOps Administration Console.

Example

The following example shows how to create a log file that lists the most recent job activity for the "Contoso Summer Intern Projects" project collection in Azure DevOps Server.

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

Lab /delete

Use the TfsConfig Lab /Delete option to remove all group hosts, library shares, and environments from a specified project collection. By default, the associated objects in the System Center Virtual Machine Manager (SCVMM) are not deleted. You can add the /External option to the command line to remove the objects from the project collection and from SCVMM.

TfsConfig Lab /Delete /CollectionName:collectionName [/External] [/NoPrompt]
Option Description
CollectionName:collectionName Required. Specifies the name of the project collection on the application tier of Azure DevOps Server.
External Optional. When specified, removes the library shares and host groups in SCVMM in addition to the objects in the project collection. When /External is not specified, the TfsConfig Lab /Delete command only removes the objects in the project collection.
NoPrompt Optional. When specified, does not display progress and success information.

Remarks

Use the /Delete command to remove the lab assets from a project collection when you want to detach the lab configuration of a project collection. This is useful when moving a project collection from one Azure DevOps Server instance to another, and where the new Azure DevOps Server instance uses a different SCVMM server than the original one. In this case, you will have to delete all the lab assets and reconfigure lab for the project collection.

Note

The /Delete option works on all lab assets in a project collection only when the /LibraryShare and /GroupHost options are not specified on the command line. For more information, see TFSConfig Lab /LibraryShare Commands and TFSConfig Lab /HostGroup Commands.

Example

In the following example, all lab objects in the DefaultCollection project collection are removed. Because the /External option is not specified, the objects are retained in SCVMM.

tfsconfig lab /delete /collectionName:DefaultCollection

Use the TfsConfig Lab /Delete option to remove all group hosts, library shares, and environments from a specified project collection. By default, the associated objects in the System Center Virtual Machine Manager (SCVMM) are not deleted. You can add the /External option to the command line to remove the objects from the project collection and from SCVMM.

TfsConfig Lab /Delete /CollectionName:collectionName [/External] [/NoPrompt]
Option Description
CollectionName:collectionName Required. Specifies the name of the project collection on the application tier of Azure DevOps Server.
External Optional. When specified, removes the library shares and host groups in SCVMM in addition to the objects in the project collection. When /External is not specified, the TfsConfig Lab /Delete command only removes the objects in the project collection.
NoPrompt Optional. When specified, does not display progress and success information.

Remarks

Use the /Delete command to remove the lab assets from a project collection when you want to detach the lab configuration of a project collection. This is useful when moving a project collection from one Azure DevOps Server instance to another, and where the new Azure DevOps Server instance uses a different SCVMM server than the original one. In this case, you will have to delete all the lab assets and reconfigure lab for the project collection.

Note

The /Delete option works on all lab assets in a project collection only when the /LibraryShare and /GroupHost options are not specified on the command line. For more information, see TFSConfig Lab /LibraryShare Commands(../tfsconfig-cmd.md#lab-libraryshare) and TFSConfig Lab /HostGroup Commands.

Example

In the following example, all lab objects in the DefaultCollection project collection are removed. Because the /External option is not specified, the objects are retained in SCVMM.

tfsconfig lab /delete /collectionName:DefaultCollection 

Lab /dns

The TfsConfig Lab /DNS command adds, deletes, or displays DNS records that were created by Visual Studio Lab Management for network-isolated environments.

	TfsConfig Lab /DNS 
	{/Add | /Delete | /List}
	    [/CollectionName:collectionName |
	    / CollectionName:collectionName /TeamProject:projectName |
	    / CollectionName:collectionName /TeamProject:projectName /LabEnvironment:environmentUri |
	    /Name:FQDN /IP:IpAddress]
	    [/NoPrompt]
Option Description
Add Adds the specified DNS records. To use the /Add option, the targeted environments must be running.
Delete Removes the specified DNS records.
List Displays the specified DNS records.
LabEnvironment: environmentUri Targets the /Add, /Delete, or /List options to an individual network-isolated environment that is specified by environmentUri.

To use the LabEnvironment option, you must also specify the /Collection and /TeamProject options.
TeamProject: projectName When used without /LabEnvironment, targets the /Add, /Delete, or /List options to all of the network-isolated environments in the project that is specified by projectName. Otherwise, /TeamProject specifies the project that contains the environment.

To use the /TeamProject option, you must also specify the /Collection option
CollectionName: collectionName When used without /TeamProject, targets the /Add, /Delete, or /List options to all of the network-isolated environments in the project collection that is specified by collectionName. Otherwise, /Collection specifies the project collection that contains the project.
Name: FQDN Specifies the fully qualified domain name of the network location that contains the environment to target.

You must specify the /Name and /IP options together.
IP: IPAddress Specifies the IP address of the environment to target.

You must specify the /Name and /IP options together.

Remarks

Azure DevOps Server uses the suffix you enter when it registers a unique external name with DNS for each virtual machine in a network-isolated environment. The DNS alias record makes it possible for machines and other objects outside the isolated network to communicate with machines inside the isolated network. Because Azure DevOps Server goes into the DNS zone to register the alias record, the service account under which Azure DevOps runs must have permissions to add or delete alias records in the specified DNS zone.

If your Team Foundation Server deployment has more than one application tier and each application tier runs under a different service account, then each application-tier service account must have permission to edit the DNS alias records created by the other application tiers.

Note

DNS record management is performed automatically by Lab Management. You should use the /DNS command only in the following situations:

  • You change the account under which Azure DevOps Server runs.
  • You move a project collection from one instance of Azure DevOps Server to another.

In both these cases, the DNS records that were created by using the old Azure DevOps Server service account have to be removed, and then the same DNS records have to be re-created by using the new Azure DevOps Server service account. If these steps are not performed in the previous scenarios, the new Azure DevOps Server service account will not be able to perform automatic management of those DNS records. As a result, users will not be able connect to virtual environments.

Specify only one of the /Add, /Delete, or /List options on a TfsConfig Lab /DNS command line. If you do not specify any target options, the operation acts on all virtual machines of all network isolated environments that belong to all project collections in the Team Foundation Server database.

To target the DNS entries of network isolated environments of an object in the Lab Management object hierarchy, use the appropriate combination of /Collection, /TeamProject, and /LabEnvironment options

  • The /LabEnvironment option targets the command to the specified network-isolated environment. You must use the /CollectionName and /TeamProject options with the /LabEnvironment option to specify the project collection and the project that contain the environment.

    Use the format vstfs:///LabManagement/LabEnvironment/ environmentID to specify the environment URI. You can view the environment identifier (environmnetID) in the Environment Viewer of Lab Management or from the description of the virtual machine in SCVMM Administrator Console.

  • The /TeamProject option targets the operation to isolated network environments in the specified project. The /TeamProject option must be used with the /CollectionName option and the /CollectionName option must specify the project collection that contains the project.

  • The /CollectionName option targets the operation to network isolated environments in the specified project collection.

The second way to target a network isolated environment is to use the /Name and /IP options to specify the fully qualified external name and external IP address of an individual virtual machine. You must specify both the /Name and /IP options on the command line. You can view the external name and external IP address of a virtual machine in the Environment Viewer of Lab Management or from the description of the virtual machine in SCVMM Administrator Console.

Examples

In the first example, records for all network-isolated environments in a project are added to DNS. In the second example, an individual DNS record is removed.

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

The TfsConfig Lab /DNS command adds, deletes, or displays DNS records that were created by Visual Studio Lab Management for network-isolated environments.

TfsConfig Lab /DNS 
{/Add | /Delete | /List}
    [/CollectionName:collectionName |
    / CollectionName:collectionName /TeamProject:projectName |
    / CollectionName:collectionName /TeamProject:projectName /LabEnvironment:environmentUri |
    /Name:FQDN /IP:IpAddress]
    [/NoPrompt]
Option Description
Add Adds the specified DNS records. To use the /Add option, the targeted environments must be running.
Delete Removes the specified DNS records.
List Displays the specified DNS records.
LabEnvironment: environmentUri Targets the /Add, /Delete, or /List options to an individual network-isolated environment that is specified by environmentUri.

To use the LabEnvironment option, you must also specify the /Collection and /TeamProject options.
TeamProject: projectName When used without /LabEnvironment, targets the /Add, /Delete, or /List options to all of the network-isolated environments in the project that is specified by projectName. Otherwise, /TeamProject specifies the project that contains the environment.

To use the /TeamProject option, you must also specify the /Collection option
CollectionName: collectionName When used without /TeamProject, targets the /Add, /Delete, or /List options to all of the network-isolated environments in the project collection that is specified by collectionName. Otherwise, /Collection specifies the project collection that contains the project.
Name: FQDN Specifies the fully qualified domain name of the network location that contains the environment to target.

You must specify the /Name and /IP options together.
IP: IPAddress Specifies the IP address of the environment to target.

You must specify the /Name and /IP options together.

Remarks

Azure DevOps Server uses the suffix you enter when it registers a unique external name with DNS for each virtual machine in a network-isolated environment. The DNS alias record makes it possible for machines and other objects outside the isolated network to communicate with machines inside the isolated network. Because Azure DevOps Server goes into the DNS zone to register the alias record, the service account under which Azure DevOps runs must have permissions to add or delete alias records in the specified DNS zone.

If your Azure DevOps Server deployment has more than one application tier and each application tier runs under a different service account, then each application-tier service account must have permission to edit the DNS alias records created by the other application tiers.

Note

DNS record management is performed automatically by Lab Management. You should use the /DNS command only in the following situations:

  • You change the account under which Azure DevOps Server runs.
  • You move a project collection from one instance of Azure DevOps Server to another.

In both these cases, the DNS records that were created by using the old Azure DevOps Server service account have to be removed, and then the same DNS records have to be re-created by using the new Azure DevOps Server service account. If these steps are not performed in the previous scenarios, the new Azure DevOps Server service account will not be able to perform automatic management of those DNS records. As a result, users will not be able connect to virtual environments.

Specify only one of the /Add, /Delete, or /List options on a TfsConfig Lab /DNS command line. If you do not specify any target options, the operation acts on all virtual machines of all network isolated environments that belong to all project collections in the Azure DevOps Server database.

To target the DNS entries of network isolated environments of an object in the Lab Management object hierarchy, use the appropriate combination of /Collection, /TeamProject, and /LabEnvironment options

  • The /LabEnvironment option targets the command to the specified network-isolated environment. You must use the /CollectionName and /TeamProject options with the /LabEnvironment option to specify the project collection and the project that contain the environment.

    Use the format vstfs:///LabManagement/LabEnvironment/ environmentID to specify the environment URI. You can view the environment identifier (environmnetID) in the Environment Viewer of Lab Management or from the description of the virtual machine in SCVMM Administrator Console.

  • The /TeamProject option targets the operation to isolated network environments in the specified project. The /TeamProject option must be used with the /CollectionName option and the /CollectionName option must specify the project collection that contains the project.

  • The /CollectionName option targets the operation to network isolated environments in the specified project collection.

The second way to target a network isolated environment is to use the /Name and /IP options to specify the fully qualified external name and external IP address of an individual virtual machine. You must specify both the /Name and /IP options on the command line. You can view the external name and external IP address of a virtual machine in the Environment Viewer of Lab Management or from the description of the virtual machine in SCVMM Administrator Console.

Examples

In the first example, records for all network-isolated environments in a project are added to DNS. In the second example, an individual DNS record is removed.

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

Lab /hostgroup

Use the TfsConfig Lab /HostGroup commands to add, edit, or delete the assignment of a System Center Virtual Machine Manager (SCVMM) host group to a project collection. Host groups that are assigned in this manner are managed by 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 }

Option

Description

CollectionName: collectionName

Required. The name of the project collection on the application-tier Azure DevOps Server.

Add

Adds the specified SCVMM host group to the project collection host groups. You must specify the /SCVmmHostGroup and /Name options with Add.

Delete

Removes the specified host group from the project collection. You must specify the /Name option with Delete.

Edit

Sets one or both of the Lab Management AutoProvision and LabEnvironmentPlacementPolicy properties for the host group.

You must specify the /Name option and at least one of the /AutoProvision or /LabEnvironmentPlacementPolicy options with Edit.

SCVMMHostGroup:vmmH ostGroupPath

Required with the /Add option. Specifies the host path of the SCVMM host group.

Name: name

Required with the /Add, /Delete, or /Edit options. Specify the name of the project collection host group to add, delete, or edit.

AutoProvision:{True|False}

Optional with the /Add or /Edit options. Sets (True) or clears (False) the AutoProvision property of the host group. AutoProvision specifies whether the host group is automatically assigned to each project in the collection. By default, host groups are assigned to the projects in a collection when you use the TfsConfig Lab/HostGroup command.

LabEnvironmentPlacementPolicy:{Conservative|Aggressive}

Optional with the /Add or /Edit options. Specifies how Lab Management treats the physical machines in a host group on which it deploys new virtual lab environments.

  • Conservative (Default). Consider non-running virtual environments in deployment decisions. This includes all virtual machines which are part of environments which are in "Stopped" state also.

  • Aggressive Do not consider non-running virtual environments in deployment decisions.

DNSSuffix:[dnsSuffix]

Optional. Sets or the DNS suffix of the virtual computers in the host group.

  • If the /DNSSuffix: option is specified without a dnsSuffix value, sets or resets the DNS suffix the suffix of the virtual computers to the suffix of the host computer in the host group.

  • If the /DNSSuffix option is not specified with the /Add option, the suffix of virtual computers are set to the suffixes of the their host computers in the host group.

  • If the /DNSSuffix option is not specified with the /Edit option, the suffix of virtual computers is not changed.

NoPrompt

Optional with the /Delete or /Edit options. Do not prompt user for confirmation.

List

Displays the host groups assigned to the project collection.

ListSCVmmHostGroups

Displays the host groups available from SCVMM.

Remarks

Host groups are containers that an administrator creates within SCVMM to group a set of virtual machine hosts for easy management. Host groups are hierarchical; a host group can contain other host groups.

Each host group is identified by its host path, a sequence of host group names that specifies the location of a host or host group within the hierarchy of host groups in SCVMM. All host paths begin with the root host group. For example, the host path All Hosts\\New York\\Site21\\VMHost05 indicates that the host VMHost05 belongs to the host group Site21, which is a child host group of the host group New York.

Use only one of the /Add, /Delete, or /Edit options on a command line. Use separate TfsConfig Lab /HostGroup command lines to assign multiple host groups to a project collection.

You can also use TfsConfig Lab /HostGroup commands to set properties that are specific to Lab Management:

  • AutoProvision specifies whether the host group is assigned to each project in the project collection. By default, AutoProvision is on. To assign a host group in a project collection to an individual project, use the TFSLabConfig CreateTeamProjectHostGroup Command.

    • True (Default). The host group is assigned to each project in the project collection.

    • False. The host group is not assigned to each project in the project collection.

  • LabEnvironmentPlacementPolicy specifies whether Lab Management considers the existing virtual machines when it deploys new environments on a physical machine in a host group.

    • Conservative (Default). Consider non-running virtual environments in deployment decisions. This includes all virtual machines that are part of environments and that are in "Stopped" state also.

    • Aggressive Do not consider non-running virtual environments in deployment decisions.

  • DNSSuffix specifies a DNS suffix to use for the virtual computers created in the host group. The following table describes how the DNS suffixes of virtual computers are affected by the /DNSSuffix setting.

DNSSuffix /Add /Edit
DNSSuffix: dnsValue The DNS suffix is set to dnsValue. The DNS suffix is set to dnsValue.
DNSSuffix: The DNS suffix is inherited from host computer. The existing suffix value is removed and the DNS suffix is inherited from host computer.
<Not Specified> The DNS suffix is inherited from host computer. DNS suffix not changed.

Example

In the following example a SCVMM host group is assigned to a project collection. Because the /AutoProvision options is not specified, the host group is automatically assigned to all projects in the collection.

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

Use the TfsConfig Lab /HostGroup commands to add, edit, or delete the assignment of a System Center Virtual Machine Manager (SCVMM) host group to a project collection. Host groups that are assigned in this manner are managed by 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 }

Option

Description

CollectionName: collectionName

Required. The name of the project collection on the application-tier Azure DevOps Server.

Add

Adds the specified SCVMM host group to the project collection host groups. You must specify the /SCVmmHostGroup and /Name options with Add.

Delete

Removes the specified host group from the project collection. You must specify the /Name option with Delete.

Edit

Sets one or both of the Lab Management AutoProvision and LabEnvironmentPlacementPolicy properties for the host group.

You must specify the /Name option and at least one of the /AutoProvision or /LabEnvironmentPlacementPolicy options with Edit.

SCVMMHostGroup:vmmH ostGroupPath

Required with the /Add option. Specifies the host path of the SCVMM host group.

Name: name

Required with the /Add, /Delete, or /Edit options. Specify the name of the project collection host group to add, delete, or edit.

AutoProvision:{True|False}

Optional with the /Add or /Edit options. Sets (True) or clears (False) the AutoProvision property of the host group. AutoProvision specifies whether the host group is automatically assigned to each project in the collection. By default, host groups are assigned to the projects in a collection when you use the TfsConfig Lab/HostGroup command.

LabEnvironmentPlacementPolicy:{Conservative|Aggressive}

Optional with the /Add or /Edit options. Specifies how Lab Management treats the physical machines in a host group on which it deploys new virtual lab environments.

  • Conservative (Default). Consider non-running virtual environments in deployment decisions. This includes all virtual machines which are part of environments which are in "Stopped" state also.

  • Aggressive Do not consider non-running virtual environments in deployment decisions.

DNSSuffix:[dnsSuffix]

Optional. Sets or the DNS suffix of the virtual computers in the host group.

  • If the /DNSSuffix: option is specified without a dnsSuffix value, sets or resets the DNS suffix the suffix of the virtual computers to the suffix of the host computer in the host group.

  • If the /DNSSuffix option is not specified with the /Add option, the suffix of virtual computers are set to the suffixes of the their host computers in the host group.

  • If the /DNSSuffix option is not specified with the /Edit option, the suffix of virtual computers is not changed.

NoPrompt

Optional with the /Delete or /Edit options. Do not prompt user for confirmation.

List

Displays the host groups assigned to the project collection.

ListSCVmmHostGroups

Displays the host groups available from SCVMM.

Remarks

Host groups are containers that an administrator creates within SCVMM to group a set of virtual machine hosts for easy management. Host groups are hierarchical; a host group can contain other host groups.

Each host group is identified by its host path, a sequence of host group names that specifies the location of a host or host group within the hierarchy of host groups in SCVMM. All host paths begin with the root host group. For example, the host path All Hosts\\New York\\Site21\\VMHost05 indicates that the host VMHost05 belongs to the host group Site21, which is a child host group of the host group New York.

Use only one of the /Add, /Delete, or /Edit options on a command line. Use separate TfsConfig Lab /HostGroup command lines to assign multiple host groups to a project collection.

You can also use TfsConfig Lab /HostGroup commands to set properties that are specific to Lab Management:

  • AutoProvision specifies whether the host group is assigned to each project in the project collection. By default, AutoProvision is on. To assign a host group in a project collection to an individual project, use the TFSLabConfig CreateTeamProjectHostGroup Command.

    • True (Default). The host group is assigned to each project in the project collection.

    • False. The host group is not assigned to each project in the project collection.

  • LabEnvironmentPlacementPolicy specifies whether Lab Management considers the existing virtual machines when it deploys new environments on a physical machine in a host group.

    • Conservative (Default). Consider non-running virtual environments in deployment decisions. This includes all virtual machines that are part of environments and that are in "Stopped" state also.

    • Aggressive Do not consider non-running virtual environments in deployment decisions.

  • DNSSuffix specifies a DNS suffix to use for the virtual computers created in the host group. The following table describes how the DNS suffixes of virtual computers are affected by the /DNSSuffix setting.

DNSSuffix /Add /Edit
DNSSuffix: dnsValue The DNS suffix is set to dnsValue. The DNS suffix is set to dnsValue.
DNSSuffix: The DNS suffix is inherited from host computer. The existing suffix value is removed and the DNS suffix is inherited from host computer.
<Not Specified> The DNS suffix is inherited from host computer. DNS suffix not changed.

Example

In the following example a SCVMM host group is assigned to a project collection. Because the /AutoProvision options is not specified, the host group is automatically assigned to all projects in the collection.

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

Lab /libraryshare

You can use the TfsConfig Lab /LibraryShare command to add, remove, or edit the assignment of a library share from System Center Virtual Machine Manager (SCVMM) to a project collection. You can also use this command set properties that are specific to Visual Studio Lab Management and to display the library shares that are currently assigned to a collection in Lab Management or to display all the library shares in 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 }
Option Description
Add Adds the specified library share to the project collection. You must specify the /SCVMMLibraryShare and /Name options with Add.
Delete Removes the specified library share from the project collection. You must specify the /Name option with Delete.
Edit Sets or clears the AutoProvision property of the library share. You must specify the /Name and /AutoProvision options with Edit.

By default, library shares are assigned to the projects in a collection.

Changing auto-provision does impact existing projects.
CollectionName: collectionName Required. Specify the name of the project collection on the application-tier Azure DevOps Server.
SCVMMLibraryShare: librarysharePath Required with Add. Specifies the path to the Virtual Machine Manager library share.
Name: libraryShareName Required with Add, Delete, and Edit. Specifies the name of library share in the project collection.
AutoProvision Optional with Add; required with Edit. Specifies whether the library shares are automatically assigned to each project in the collection. By default, library shares are assigned to the projects.
NoPrompt Optional with Add and Edit. Do not prompt the user for confirmation.
List Lists all library shares that are assigned to the specified project collection.
ListSCVMMLibraryShares Lists all library shares that are available in Virtual Machine Manager.

Remarks

A library share is a designated share on a Virtual Machine Manager library server. A library share provides access to file-based resources for virtual Lab Management environments that are stored on your library servers, such as ISO images and virtual hard disks. Library shares are created in Virtual Machine Manager. Visual Studio Lab Management uses library shares to provision virtual machines in the lab.

Use only one of the /Add, /Edit, or /Delete options on a TfsConfig Lab /LibraryShare command line. Use separate TfsConfig Lab /LibraryShare command lines to assign multiple library shares to a collection.

By default, library shares in a project collection are automatically assigned to each of the projects in the collection. You can use the /AutoProvision option with the /Add and /Edit commands to change the library shares are assigned.

  • Set the /AutoProvision option to False to disable the automatic assignment of the library share to projects. To assign or remove a library share in an individual project, use the TfsLabConfig TFSLabConfig CreateTeamProjectLibraryShare Command.

  • Set the /AutoProvision option to True to enable the automatic assignments.

You can use the TfsConfig Lab /LibraryShare command to add, remove, or edit the assignment of a library share from System Center Virtual Machine Manager (SCVMM) to a project collection. You can also use this command set properties that are specific to Visual Studio Lab Management and to display the library shares that are currently assigned to a collection in Lab Management or to display all the library shares in 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 }
Option Description
Add Adds the specified library share to the project collection. You must specify the /SCVMMLibraryShare and /Name options with Add.
Delete Removes the specified library share from the project collection. You must specify the /Name option with Delete.
Edit Sets or clears the AutoProvision property of the library share. You must specify the /Name and /AutoProvision options with Edit.

By default, library shares are assigned to the projects in a collection.

[!NOTE] Changing auto-provision does impact existing projects.
CollectionName: collectionName Required. Specify the name of the project collection on the application-tier Azure DevOps Server.
SCVMMLibraryShare: librarysharePath Required with Add. Specifies the path to the Virtual Machine Manager library share.
Name: libraryShareName Required with Add, Delete, and Edit. Specifies the name of library share in the project collection.
AutoProvision Optional with Add; required with Edit. Specifies whether the library shares are automatically assigned to each project in the collection. By default, library shares are assigned to the projects.
NoPrompt Optional with Add and Edit. Do not prompt the user for confirmation.
List Lists all library shares that are assigned to the specified project collection.
ListSCVMMLibraryShares Lists all library shares that are available in Virtual Machine Manager.

Remarks

A library share is a designated share on a Virtual Machine Manager library server. A library share provides access to file-based resources for virtual Lab Management environments that are stored on your library servers, such as ISO images and virtual hard disks. Library shares are created in Virtual Machine Manager. Visual Studio Lab Management uses library shares to provision virtual machines in the lab.

Use only one of the /Add, /Edit, or /Delete options on a TfsConfig Lab /LibraryShare command line. Use separate TfsConfig Lab /LibraryShare command lines to assign multiple library shares to a collection.

By default, library shares in a project collection are automatically assigned to each of the projects in the collection. You can use the /AutoProvision option with the /Add and /Edit commands to change the library shares are assigned.

  • Set the /AutoProvision option to False to disable the automatic assignment of the library share to projects. To assign or remove a library share in an individual project, use the TfsLabConfig TFSLabConfig CreateTeamProjectLibraryShare Command.

  • Set the /AutoProvision option to True to enable the automatic assignments.


Lab /settings

You can configure Visual Studio Lab Management by using the TFSConfig Lab /Settings option. The Settings option

  • Sets the name of the System Center Virtual Machine Manager (SCVMM) Server that controls the administration of virtual machines in your lab.

  • Sets the network location, such as the network domain or workgroup, that the physical computers in all host groups can connect to.

  • Sets the IP addresses and virtual DNS suffix for network-isolated networks in your lab.

TfsConfig Lab
	/Settings
	    [/ScVmmServerName:VMMServerName]
	    [/NetworkLocation:networkLocation]
	    [/IpBlock:networkIsolationIpRange]
	    [/DnsSuffix:networkIsolationDnsSuffix] 
	    [/NoPrompt]
	    [/List]
Option Description
ScvmmServerName: VMMServerName Optional. Sets the fully qualified name of the System Center Virtual Machine Manager 2008 (SCVMM) server that will be used by Azure DevOps Server. This is the name of the SCVMM server that will be used to manage the virtual machines. For Azure DevOps Server to communicate with SCVMM, you must add the account under which Azure DevOps Server is running to the Administrator role in SCVMM.
NetworkLocation: networkLocation Optional. Sets the fully qualified name of a network, such as a network domain or workgroup, that is available on all the hosts in your lab network. When it provisions a virtual machine, Lab Management automatically connects the virtual machine to the specified network. You can find the available network locations on a host using SCVMM Administrator Console.
IpBlock: networkIsolationIpRange Optional. Sets the range of IP addresses to be assigned to the virtual machines in an environment when an isolated network is created. Because the IP addresses are used only for internal routing among virtual machines and are not exposed beyond the boundaries of an environment, you can specify any IP range that is not used within the network specified by the /NetworkLocation option. In most cases, the default range of 192.168.23.0/24 should work. If you encounter problems connecting to network isolated environments, you might have to choose a different range.
DnsSuffix: networkIsolationDnsSuffix Optional. Sets the DNS suffix that will be used to register the names of virtual machines on the isolated network for the virtual environment. To confirm that the suffix is configured correctly in the DNS hierarchy, contact your network administrator.
NoPrompt Optional. Do not prompt for confirmation. Do not use with the /List option.
List Lists the current configuration values for Lab Management.

Remarks

One of the /ScvmmServerName, /NetworkLocation, /IpBlock, /DnsSuffix, or /List options must be specified on each TfsConfig Lab /Settings command line.

To set up Lab Management, you must specify both /ScVmmServerName and the /NetworkLocation options. However, you can specify these options on separate command lines.

To set up network isolation, you must specify both the /IpBlock and /DnsSuffix options. However, you can specify these options on separate command lines.

Network isolation enables you to use multiple copies of a virtual machine without machine name or IP address conflicts. You must assign both a DNS suffix and an IP range for an isolated network. Because the IP addresses are used only for internal routing among virtual machines and are not exposed beyond the boundaries of an environment, you can specify any IP range that is not used within your public network. In most cases, the default range of 192.168.1.0/24 should work. If you encounter problems connecting to network-isolated environments, you might have to choose a different range.

Examples

In the this example, Lab Management is set up by using the /ScvmmServerName and /NetworkLocation options on a single command line.

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

In this example, network isolation is configured by using the /IpBlock and /DNSSuffix options on separate command lines.

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

You can configure Visual Studio Lab Management by using the TFSConfig Lab /Settings option. The Settings option

  • Sets the name of the System Center Virtual Machine Manager (SCVMM) Server that controls the administration of virtual machines in your lab.

  • Sets the network location, such as the network domain or workgroup, that the physical computers in all host groups can connect to.

  • Sets the IP addresses and virtual DNS suffix for network-isolated networks in your lab.

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

Option Description
ScvmmServerName: VMMServerName Optional. Sets the fully qualified name of the System Center Virtual Machine Manager 2008 (SCVMM) server that will be used by Azure DevOps Server. This is the name of the SCVMM server that will be used to manage the virtual machines. For Azure DevOps Server to communicate with SCVMM, you must add the account under which Azure DevOps Server is running to the Administrator role in SCVMM.
NetworkLocation: networkLocation Optional. Sets the fully qualified name of a network, such as a network domain or workgroup, that is available on all the hosts in your lab network. When it provisions a virtual machine, Lab Management automatically connects the virtual machine to the specified network. You can find the available network locations on a host using SCVMM Administrator Console.
IpBlock: networkIsolationIpRange Optional. Sets the range of IP addresses to be assigned to the virtual machines in an environment when an isolated network is created. Because the IP addresses are used only for internal routing among virtual machines and are not exposed beyond the boundaries of an environment, you can specify any IP range that is not used within the network specified by the /NetworkLocation option. In most cases, the default range of 192.168.23.0/24 should work. If you encounter problems connecting to network isolated environments, you might have to choose a different range.
DnsSuffix: networkIsolationDnsSuffix Optional. Sets the DNS suffix that will be used to register the names of virtual machines on the isolated network for the virtual environment. To confirm that the suffix is configured correctly in the DNS hierarchy, contact your network administrator.
NoPrompt Optional. Do not prompt for confirmation. Do not use with the /List option.
List Lists the current configuration values for Lab Management.

Remarks

One of the /ScvmmServerName, /NetworkLocation, /IpBlock, /DnsSuffix, or /List options must be specified on each TfsConfig Lab /Settings command line.

To set up Lab Management, you must specify both /ScVmmServerName and the /NetworkLocation options. However, you can specify these options on separate command lines.

To set up network isolation, you must specify both the /IpBlock and /DnsSuffix options. However, you can specify these options on separate command lines.

Network isolation enables you to use multiple copies of a virtual machine without machine name or IP address conflicts. You must assign both a DNS suffix and an IP range for an isolated network. Because the IP addresses are used only for internal routing among virtual machines and are not exposed beyond the boundaries of an environment, you can specify any IP range that is not used within your public network. In most cases, the default range of 192.168.1.0/24 should work. If you encounter problems connecting to network-isolated environments, you might have to choose a different range.

Examples

In the this example, Lab Management is set up by using the /ScvmmServerName and /NetworkLocation options on a single command line.

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

In this example, network isolation is configured by using the /IpBlock and /DNSSuffix options on separate command lines.

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

OfflineDetach

You use the offlineDetach command to make an offline collection database into a detached offline collection database.

TfsConfig offlineDetach /configurationDB:<databaseName>
    /collectionDB:<databaseName>
Option Description
configurationDB Specifies the name of the configuration database to be used.
collectionDB Specifies the name of the collection database to be detached.

Prerequisites

To use the offlineDetach command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

This command modifies the schema of the specified collection database and should never be run against databases which are in use by a Team Foundation Server deployment. If your databases are in use by a Team Foundation Server deployment, use TfsConfig collection /detach instead.

This command is useful when you need to restore an individual collection database from backup without restoring other collection databases that are part of the same Azure DevOps Server deployment. Previously this required restoring a complete and consistent set of databases (configuration and all collections) to a staging environment, configuring a Azure DevOps Server deployment using those databases, and detaching the one collection of interest.

Instead, you can now restore consistent copies of the configuration database and the collection database of interest and run the offlineDetach command. The detached collection database can then be attached to any Azure DevOps Server deployment at an appropriate version.

Example

The following example illustrates detaching a collection database named TFS_PrimaryCollection, using a configuration database named TFS_Configuration, with both on a SQL instance running on a server named ContosoTemp on the named instance Backups.

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

Command availability: TFS 2015 Update 3 and newer

You use the OfflineDetach command to make an offline collection database into a detached offline collection database.

TFSConfig offlineDetach /configurationDB:DatabaseName
	/collectionDB:DatabaseName
Option Description
/configurationDB Specifies the name of the configuration database to be used.
/collectionDB Specifies the name of the collection database to be detached.

Prerequisites

To use the OfflineDetach command, you must be a member of the sysadmin role for the specified SQL Server instance.

Remarks

This command modifies the schema of the specified collection database and should never be run against databases which are in use by a Azure DevOps Server deployment. If your databases are in use by a Azure DevOps Server deployment, use TfsConfig collection /detach instead.

This command is useful when you need to restore an individual collection database from backup without restoring other collection databases that are part of the same Azure DevOps Server deployment. Previously this required restoring a complete and consistent set of databases (configuration and all collections) to a staging environment, configuring a Azure DevOps Server deployment using those databases, and detaching the one collection of interest.

Instead, you can now restore consistent copies of the configuration database and the collection database of interest and run the OfflineDetach command. The detached collection database can then be attached to any Azure DevOps Server deployment at an appropriate version.

Example

The following example illustrates detaching a collection database named TFS_PrimaryCollection, using a configuration database named TFS_Configuration, with both on a SQL instance running on a server named "ContosoTemp" on the named instance "Backups".

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

Proxy

You can use the proxy command to update or change the settings used by Azure DevOps Proxy Server. Azure DevOps Proxy Server provides support for distributed teams to use version control by managing a cache of downloaded version control files in the location of the distributed team. By configuring Azure DevOps Proxy Server, you can significantly reduce the bandwidth needed across wide area connections. In addition, you do not have to manage downloading and caching of version files; management of the files is transparent to the developer who is using the files. Meanwhile, any metadata exchanges and file uploads continue to appear in Azure DevOps Server. If you use the Azure DevOps Services to host your development project in the cloud, you can use the Proxy command to not only manage the cache for projects in the hosted collection, but also to manage some of the settings used by that service.

For more information about installing Azure DevOps Proxy Server and initial configuration of the proxy, see How to: Install Azure DevOps Proxy Server and set up a remote site . For more information about configuring proxy on client computers, see Azure DevOps Version Control Command Reference.

TfsConfig proxy /add|delete|change [/Collection:<teamProjectCollectionURL> /account:<accountName>]
	/Server:<TeamFoundationServerURL> [/inputs:Key1=Value1; Key2=Value2;...] [/continue]
Option Description
add Adds the specified server or collection to the proxy list in the Proxy.config file. You can run /add multiple times to include more collections or servers. When using /add with a collection hosted on Azure DevOps Services, you will be prompted for your credentials on Azure DevOps Services.
change Changes the credentials stored as the service account for Azure DevOps Services. The /change option is only used for Azure DevOps Services; it should not be used for local deployments of Azure DevOps Server.
delete Removes the specified server or collection from the proxy list in the Proxy.config file.
account Specifies the account used as the service account for the proxy in Azure DevOps Services. This option is only used for Azure DevOps Services in conjunction with the /change option.

The default service account used for Azure DevOps Services is "Account Service."
continue Continues the execution of the command even if the verification process produces warnings.
Collection Specifies the URL of the project collection that is hosted on Azure DevOps Services, in AccountName.DomainName/CollectionName format.
account Specifies the name of the account that is used as the service account for Azure DevOps Services. If the account name has spaces, the name must be enclosed within quotation marks (""). All special characters in account names must be specified in accordance with command-line syntax.
account Specifies the URL of a Azure DevOps Server deployment, in ServerURL:Port/tfs format.
PersonalAccessTokenFile Optionally specifies the path to a file that contains a personal access token. This token will be used authenticate to the collection or account while registering a proxy. (Added in TFS 2018 Update 1)
inputs Optional. Specifies additional settings and values to use while configuring the proxy.

For example, values for GvfsProjectName and GvfsRepositoryName can be used to configure a Git repository for use with Git Virtual File System (GVFS) (Added in TFS 2018 Update 1)

Prerequisites

To use the proxy command, you must be a member of the Azure DevOps Administrators security group and an administrator on the proxy server. For more information, see Permission reference for Azure DevOps Server .

Remarks

You use the proxy command to update the existing configuration of Azure DevOps Server Proxy. You cannot use the proxy command for initial installation and configuration of the proxy.

Examples

The following example shows how to add a Azure DevOps Server deployment named FABRIKAM to the proxy list.

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

The following example shows how to add a project collection hosted on Azure DevOps Services to the proxy list using a Personal Access Token to authenticate. This token will be used only to register the proxy with the Azure DevOps Services account - the default service account will still be used to run the proxy. This parameter was added in TFS 2018 Update 1 to support registering a Proxy with Azure DevOps Services without requiring a login prompt.

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

The following example shows how to add a project collection to the proxy list. This example uses a personal access token to authenticate against the collection specified with the /Collection parameter. The personal access token to be used is saved to a file at 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.

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

The following example shows how to add a Git repository for use with GVFS.

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

You can use the TFSConfig Proxy command to update or change the settings used by Team Foundation Server Proxy. Team Foundation Server Proxy provides support for distributed teams to use version control by managing a cache of downloaded version control files in the location of the distributed team. By configuring Team Foundation Server Proxy, you can significantly reduce the bandwidth needed across wide area connections. In addition, you do not have to manage downloading and caching of version files; management of the files is transparent to the developer who is using the files. Meanwhile, any metadata exchanges and file uploads continue to appear in Azure DevOps Server. If you use the Azure DevOps Services to host your development project in the cloud, you can use the Proxy command to not only manage the cache for projects in the hosted collection, but also to manage some of the settings used by that service.

For more information about installing Azure DevOps Proxy Server and initial configuration of the proxy, see How to: Install Azure DevOps Proxy Server and set up a remote site . For more information about configuring proxy on client computers, see Team Foundation Version Control Command Reference.

TFSConfig Proxy /add|delete|change [/Collection:TeamProjectCollectionURL /account:AccountName]
	/Server:TeamFoundationServerURL [/inputs:Key1=Value1; Key2=Value2;...] [/Continue]
Option Description
/add Adds the specified server or collection to the proxy list in the Proxy.config file. You can run /add multiple times to include more collections or servers. When using /add with a collection hosted on Azure DevOps Services, you will be prompted for your credentials on Azure DevOps Services.
/change Changes the credentials stored as the service account for Azure DevOps Services. The /change option is only used for Azure DevOps Services; it should not be used for local deployments of Azure DevOps Server.
/delete Removes the specified server or collection from the proxy list in the Proxy.config file.
/account Specifies the account used as the service account for the proxy in Azure DevOps Services. This option is only used for Azure DevOps Services in conjunction with the /change option.

The default service account used for Azure DevOps Services is "Account Service."
/continue Continues the execution of the command even if the verification process produces warnings.
/Collection:TeamProjectCollectionURL Specifies the URL of the project collection that is hosted on Azure DevOps Services, in AccountName.DomainName/CollectionName format.
/account:AccountName Specifies the name of the account that is used as the service account for Azure DevOps Services. If the account name has spaces, the name must be enclosed within quotation marks (""). All special characters in account names must be specified in accordance with command-line syntax.
/account:ServerURL Specifies the URL of a Azure DevOps Server deployment, in ServerURL:Port/tfs format.
/PersonalAccessTokenFile:PathToFileWithPAT Optionally specifies the path to a file that contains a personal access token. This token will be used authenticate to the collection or account while registering a proxy. (Added in TFS 2018 Update 1)
/inputs:Key1=Value1;Key2=Value2;... Optional. Specifies additional settings and values to use while configuring the proxy.

For example, values for "GvfsProjectName" and "GvfsRepositoryName" can be used to configure a Git repository for use with Git Virtual File System (GVFS) (Added in TFS 2018 Update 1)

Prerequisites

To use the Proxy command, you must be a member of the Team Foundation Administrators security group and an administrator on the proxy server. For more information, see Permission reference for Azure DevOps Server .

Remarks

You use the Proxy command to update the existing configuration of Azure DevOps Proxy Server. You cannot use the Proxy command for initial installation and configuration of the proxy.

Examples

The following example shows how to add a Azure DevOps Server deployment named FABRIKAM to the proxy list.

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

The following example shows how to add a project collection hosted on Azure DevOps Services to the proxy list using a Personal Access Token to authenticate. This token will be used only to register the proxy with the Azure DevOps Services account - the default service account will still be used to run the proxy. This parameter was added in TFS 2018 Update 1 to support registering a Proxy with Azure DevOps Services without requiring a login prompt.

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

The following example shows how to add a project collection to the proxy list. This example uses a personal access token to authenticate against the collection specified with the "/Collection" parameter. The personal access token to be used is saved to a file at "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.

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

The following example shows how to add a Git repository for use with GVFS.

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

RebuildWarehouse

You can use the rebuildWarehouse command to rebuild the SQL Server Reporting Services and SQL Server Analysis Services databases that Azure DevOps Server uses.

TfsConfig rebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]
Option Description
analysisServices Required if /all is not used. Specifies that only the database for Analysis Services will be rebuilt. If no database exists for Analysis Services, you must also use the /reportingDataSourcePassword option.
all Required if /analysisServices is not used. Specifies that all reporting and analysis databases that Azure DevOps Server uses will be rebuilt.
reportingDataSourcePassword Required if the TFS_Analysis database does not exist. Specifies the password of the account that is used as the data sources account for SQL Server Reporting Services (TFSReports). For more information, see Service accounts and dependencies in Azure DevOps Server.

Prerequisites

To use the rebuildWarehouse command, you must be a member of the following groups:

  • The Azure DevOps Administrators security group and the Administrators security group on the server or servers that are running the administration console for Azure DevOps

  • The sysadmin group on the server or servers that are running the instance of SQL Server that hosts the databases for Azure DevOps Server

For more information, see Permission reference for Azure DevOps Server.

Remarks

You might use this command when moving or splitting a project collection, restoring data, or otherwise changing the configuration of your deployment.

To start the rebuild of these databases interactively, you can use the Reporting node in the administration console for Azure DevOps. For more information, see Open the Azure DevOps Administration Console.

Example

The following example shows how to rebuild the Analysis Services database for a deployment of 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.

You can use the RebuildWarehouse command to rebuild the SQL Server Reporting Services and SQL Server Analysis Services databases that Visual Studio Team Foundation Server (TFS) uses.

TFSConfig RebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]
Option Description
/analysisServices Required if /all is not used. Specifies that only the database for Analysis Services will be rebuilt. If no database exists for Analysis Services, you must also use the /reportingDataSourcePassword option.
/all Required if /analysisServices is not used. Specifies that all reporting and analysis databases that Azure DevOps Server uses will be rebuilt.
/reportingDataSourcePassword: Password Required if the TFS_Analysis database does not exist. Specifies the password of the account that is used as the data sources account for SQL Server Reporting Services (TFSReports). For more information, see Service accounts and dependencies in Azure DevOps Server.

Prerequisites

To use the RebuildWarehouse command, you must be a member of the following groups:

  • the Team Foundation Administrators security group and the Administrators security group on the server or servers that are running the administration console for Azure DevOps

  • the sysadmin group on the server or servers that are running the instance of SQL Server that hosts the databases for Azure DevOps Server

For more information, see Permission reference for Azure DevOps Server.

Remarks

You might use this command when moving or splitting a project collection, restoring data, or otherwise changing the configuration of your deployment.

To start the rebuild of these databases interactively, you can use the Reporting node in the administration console for Azure DevOps. For more information, see Open the Azure DevOps Administration Console>.

Example

The following example shows how to rebuild the Analysis Services database for a deployment of 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

Use registerDB to update name of the server that hosts the configuration database in Azure DevOps Server. You might use this command when restoring the configuration database to new hardware or when changing the domain of a deployment.

TfsConfig registerDB /sqlInstance:<serverName> /databaseName:<databaseName>
Option Description
SQLInstance Required. Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the format: ServerName\InstanceName.
databaseName Required. Specifies the name of the configuration database. By default, this is Tfs_Configuration.

Prerequisites

To use the registerDB command, you must be a member of the Azure DevOps Administrators group on the application-tier server for Azure DevOps and a member of the sysadmin group in SQL Server on the data-tier server for Azure DevOps. For more information, see Permission reference for Azure DevOps Server.

Remarks

Back up the databases for Azure DevOps Server before you use this command.

For the registerDB command to succeed, the following application pools and programs must be running:

  • Azure DevOps Server Application Pool (application pool)
  • ReportServer (application pool)
  • SQL Server Reporting Services (program)

You must provide the exact name or address of the configuration database for this command to operate correctly. If you must change the server on which this database is stored, you must ensure that Azure DevOps Server points to the new location.

Example

The following example redirects Azure DevOps Server to a configuration database that is located on the server ContosoMain in the SQL Server instance TeamDatabases.

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

Use RegisterDB to update name of the server that hosts the configuration database in Visual Studio Team Foundation Server (TFS). You might use this command when restoring the configuration database to new hardware or when changing the domain of a deployment.

TFSConfig RegisterDB /SQLInstance:ServerName /databaseName: DatabaseName [/usesqlalwayson]
Argument Description
/SQLInstance: ServerName Required. Specifies the name of the server that is running SQL Server and the name of the instance if you want to use an instance other than the default instance. If you specify an instance, you must use the format: ServerName\InstanceName.
/databaseName: DatabaseName Required. Specifies the name of the configuration database. By default, this is Tfs_Configuration.
/usesqlalwayson Optional. Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the RegisterDB command, you must be a member of the Team Foundation Administrators group on the application-tier server for Azure DevOps and a member of the sysadmin group in SQL Server on the data-tier server for Azure DevOps. For more information, see Permission reference for Azure DevOps Server.

Remarks

Back up the databases for Azure DevOps Server before you use this command.

For the RegisterDB command to succeed, the following application pools and programs must be running:

  • Azure DevOps Server Application Pool (application pool)
  • ReportServer (application pool)
  • SQL Server Reporting Services (program)

You must provide the exact name or address of the configuration database for this command to operate correctly. If you must change the server on which this database is stored, you must ensure that Azure DevOps Server points to the new location.

Example

The following example redirects Azure DevOps Server to a configuration database that is located on the server ContosoMain in the SQL Server instance TeamDatabases.

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

RemapDBs

The remapDBs command redirects Azure DevOps Server to its databases when they are stored on more than one server and you are restoring, moving, or otherwise changing the configuration of your deployment. For example, you must redirect Azure DevOps Server to any databases for project collections if they are hosted on a separate server or servers from the configuration database. You must also redirect Azure DevOps Server to the server or servers that are running SQL Server Analysis Services or SQL Server Reporting Services if those databases are hosted on a separate server or instance from the configuration database.

TfsConfig remapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,ServerName2
	[/AnalysisInstance:<serverName>] [/AnalysisDatabaseName:<databaseName>]
	[/preview] [/continue]
Option Description
DatabaseName Specifies the name of the server that hosts the database that you want to map for Azure DevOps Server, in addition to the name of the database itself.
SQLInstances Specifies the name of the server that is running SQL Server, in addition to the name of the instance if you want to use an instance other than the default instance.

If you are specifying more than one server, you must use a comma to separate multiple pairs of server and instance names.
AnalysisInstance Optional. Specifies the name of the server and instance that hosts SQL Server Analysis Services. Use this option to specify the server and instance that hosts the Analysis Services database.
AnalysisDatabaseName Optional. Specifies the name of the Analysis Services database that you want to use with Azure DevOps Server if you have more than one such database on the server that you specified with the /AnalysisInstance option.
preview Optional. Displays the actions that you must take to update the configuration.
continue Optional. Specifies that the RemapDB command should continue even if an error occurs during the attempt to locate one or more databases. If you use the /continue option, any collections whose databases are not found on the server or servers that you specify will be reconfigured to use the server and instance that hosts the configuration database.

Prerequisites

To use the remapDBs command, you must be a member of the Azure DevOps Administrators security group and a member of the sysadmin security group for any SQL Server databases that Azure DevOps Server uses. For more information, see Permission reference for Azure DevOps Server.

Remarks

You use the remapDBs command to reconfigure Azure DevOps Server to use different servers and instances of SQL Server from the servers and instances in the original installation.

Example

The following example shows how to redirect Azure DevOps Server to its configuration database TFS_Configuration. This database is hosted on ContosoMain on the named instance TeamDatabases. Its project collection databases are stored on both ContosoMain\TeamDatabases and the default instance on Contoso2.

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

The RemapDBs command redirects Azure DevOps Server to its databases when they are stored on more than one server and you are restoring, moving, or otherwise changing the configuration of your deployment. For example, you must redirect TFS to any databases for project collections if they are hosted on a separate server or servers from the configuration database. You must also redirect TFS to the server or servers that are running SQL Server Analysis Services or SQL Server Reporting Services if those databases are hosted on a separate server or instance from the configuration database.

TFSConfig RemapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,ServerName2
	[/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName]
	[/preview] [/continue] [/usesqlalwayson]
Option Description
/DatabaseName Specifies the name of the server that hosts the database that you want to map for Azure DevOps Server, in addition to the name of the database itself.
/SQLInstances: ServerName1,ServerName2 Specifies the name of the server that is running SQL Server, in addition to the name of the instance if you want to use an instance other than the default instance.

If you are specifying more than one server, you must use a comma to separate multiple pairs of server and instance names.
/AnalysisInstance: ServerName Optional. Specifies the name of the server and instance that hosts SQL Server Analysis Services. Use this option to specify the server and instance that hosts the Analysis Services database.
/AnalysisDatabaseName: DatabaseName Optional. Specifies the name of the Analysis Services database that you want to use with Azure DevOps Server if you have more than one such database on the server that you specified with the /AnalysisInstance option.
/preview Optional. Displays the actions that you must take to update the configuration.
/continue Optional. Specifies that the RemapDB command should continue even if an error occurs during the attempt to locate one or more databases. If you use the /continue option, any collections whose databases are not found on the server or servers that you specify will be reconfigured to use the server and instance that hosts the configuration database.
/usesqlalwayson Optional. Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the RemapDBs command, you must be a member of the Team Foundation Administrators security group and a member of the sysadmin security group for any SQL Server databases that Azure DevOps Server uses. For more information, see Permission reference for Azure DevOps Server.

Remarks

You use the RemapDBs command to reconfigure Azure DevOps Server to use different servers and instances of SQL Server from the servers and instances in the original installation.

Example

The following example shows how to redirect Azure DevOps Server to its configuration database TFS_Configuration. This database is hosted on ContosoMain on the named instance TeamDatabases. Its project collection databases are stored on both ContosoMain\TeamDatabases and the default instance on Contoso2.

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

RepairJobQueue

You use the repairJobQueue command to fix scheduled jobs that have stopped running for deployment and collection hosts.

TfsConfig repairJobQueue

Prerequisites

To use the repairJobQueue command, you must be a member of the local administrators group on the machine running TfsConfig. You must also be a member of the sysadmin security role for all the SQL Server instances used by the Azure DevOps Server deployment.

Remarks

You would typically use the repairJobQueue command if you notice any scheduled jobs are not running.
The command does not take any arguments, and requires the Azure DevOps Server deployment to be configured.

Example

TfsConfig repairJobQueue

Command availability: TFS 2015

You use the RepairJobQueue command to fix scheduled jobs that have stopped running for deployment and collection hosts.

TfsConfig repairJobQueue

Prerequisites

To use the RepairJobQueue command, you must be a member of the local administrators group on the machine running TfsConfig. You must also be a member of the sysadmin security role for all the SQL Server instances used by the Azure DevOps Server deployment.

Remarks

You would typically use the RepairJobQueue command if you notice any scheduled jobs are not running.
The command does not take any arguments, and requires the Azure DevOps Server deployment to be configured.

Example

TFSConfig repairJobQueue

Settings

You can use the settings command to automate changes to the uniform resource locator (URL) that is used by the notification interface and for the server address for Azure DevOps Server. By default, the notification interface URL and the server URL match in Azure DevOps Server, but you can configure separate URLs. For example, you might want to use a different URL for the automatic e-mails that Azure DevOps Server generates. You must run this tool from the application tier to update all servers so that they use the new URLs.

To change these URLs interactively or to just view the current settings, you can use the administration console for Azure DevOps. See Administrative task quick reference.

TfsConfig settings [/publicURL:URL]
Option Description
publicUrl Specifies the URL of the application-tier server for Azure DevOps. This value is stored in the configuration database for Azure DevOps.

Prerequisites

You must be a member of the Azure DevOps Administrators security group and the Administrators group on the application-tier server. For more information, see Set administrator permissions for Azure DevOps Server.

Remarks

The settings command changes connection information for server-to-server communication in a deployment of Azure DevOps Server. The URL that is specified in /publicURL must be available to all servers within the deployment.

Example

The following example changes the value of NotificationURL to http://contoso.example.com/tfs and the value of ServerURL to http://contoso.example.com:8080/tfs.

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

You can use the Settings command to automate changes to the uniform resource locator (URL) that is used by the notification interface and for the server address for Azure DevOps Server. By default, the notification interface URL and the server URL match in Azure DevOps Server, but you can configure separate URLs. For example, you might want to use a different URL for the automatic e-mails that Azure DevOps Server generates. You must run this tool from the application tier to update all servers so that they use the new URLs.

To change these URLs interactively or to just view the current settings, you can use the administration console for Azure DevOps. See Administrative task quick reference.

TFSConfig Settings [/ServerURL:URL] [/NotificationURL:URL]
Option Description
/ServerURL: URL Specifies the URL of the application-tier server for Azure DevOps. This value is stored in the configuration database for Azure DevOps.
/NotificationURL: URL Specifies the URL to use in the text of e-mail alerts, if that URL differs from the URL of the application-tier server for Azure DevOps. This value is stored in the configuration database.

Prerequisites

You must be a member of the Team Foundation Administrators security group and the Administrators group on the application-tier server. For more information, see Set administrator permissions for Azure DevOps Server.

Remarks

The Settings command changes connection information for server-to-server communication in a deployment of Azure DevOps Server. The URL that is specified in /ServerURL must be available to all servers within the deployment.

Example

The following example changes the value of NotificationURL to http://contoso.example.com/tfs and the value of ServerURL to http://contoso.example.com:8080/tfs.

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

Setup

You use the setup command to uninstall features which are currently configured on the machine where you run the command.

TfsConfig setup /uninstall:<feature[,feature,...]>
Option Description
uninstall Specifies one or more features to be uninstalled from the machine where you run the command. Options include: All, ApplicationTier, Search, and VersionControlProxy.
Option Description
/uninstall Specifies one or more features to be uninstalled from the machine where you run the command. Options include: All, ApplicationTier, SharePointExtensions, Search, TeamBuild, and VersionControlProxy.
Option Description
/uninstall Specifies one or more features to be uninstalled from the machine where you run the command. Options include: All, ApplicationTier, SharePointExtensions, TeamBuild, VersionControlProxy.

Prerequisites

To use the setup command, you must be a member of the Azure DevOps Administrators security group.

Examples

The following example uninstalls all Azure DevOps Server features from the current machine.

TfsConfig setup /uninstall:ALL

The following example uninstalls the application tier and build features from the current machine.

TfsConfig setup /uninstall:ApplicationTier,TeamBuild

TCM

When upgrading to the latest version of Azure DevOps Server, the system automatically attempts to upgrade the Test Management components, including test plans and suites. If the automatic migration fails, use the TCM command to upgrade your test plans and test suites manually to their respective work item types (WITs).

TFSConfig TCM /upgradeTestPlans|upgradeStatus /CollectionName:CollectionName /TeamProject:TeamProjectName
Option Description
/upgradeTestPlans Required unless /upgradeStatus is used.

Converts existing test plan and test suites to point to the work item-based test plans and test suites. It also updates existing test management data and links between other existing test artifacts such as test points, test runs, and test results.
/upgradeStatus Required unless /upgradeTestPlans is used.

Reports the migration status of test data for the specified project. It will also indicate whether the specified project has any test plans.
/CollectionName:CollectionName Required. Specifies the project collection that contains the project for which you want to migrate test data or check the migration status.

If there are spaces in the name of the project collection, enclose the name in quotation marks, for example, "Fabrikam Fiber Collection".
/TeamProjectName:TeamProjectName Required. Specifies the project for which you want to migrate test data or check the migration status. This project must be defined in the collection that you specified by using the /collectionName parameter.

If there are spaces in the name of the project, enclose the name in quotation marks, for example, "My Project".

Prerequisites

You must be a member of the Team Foundation Administrators security group, and an administrator on the application-tier server. See Set administrator permissions for Azure DevOps Server.

Remarks

Your application-tier server must be upgraded to the latest version of Azure DevOps Server 2019 to use this command.

Before you can use the TCM command, you must first import the test plan work item definition and the test plan category into the project. To learn more about the migration and when to use this command, see Manual updates to support test management.

The TCM command is applied to individual projects. If you need to upgrade test plans in more than one project, you will have to run it against each project individually.

You must run the TCM command from the tools directory for Azure DevOps Server. By default, that location is: drive:\%programfiles%\TFS 12.0\Tools.

You use the TCM command only in the event that automatic migration of existing test data fails. To learn more about the migration and when to use this command, Manual updates to support test management.

If you can't access test plans or test suites that were defined before the server upgrade occurred, run TFSConfig TCM upgradeStatus to determine the status of the migration.

You run the TCM command for an individual project. If you need to upgrade more than one project, you will have to run it against each project in turn.

Examples

The following example shows how to check the status of test plan upgrade on the Fabrikam Fiber project hosted on the default project collection (DefaultCollection):

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

When upgrading to the latest version of Azure DevOps Server, the system automatically attempts to upgrade the Tests Management components, including test plans and suites. If the automatic migration fails, use the TCM command to upgrade your test plans and test suites manually to their respective work item types (WITs).

TFSConfig TCM /upgradeTestPlans|upgradeStatus /CollectionName:CollectionName /TeamProject:TeamProjectName
Option Description
/upgradeTestPlans Required unless /upgradeStatus is used.

Converts existing test plan and test suites to point to the work item-based test plans and test suites. It also updates existing test management data and links between other existing test artifacts such as test points, test runs, and test results.
/upgradeStatus Required unless /upgradeTestPlans is used.

Reports the migration status of test data for the specified project. It will also indicate whether the specified project has any test plans.
/CollectionName:CollectionName Required. Specifies the project collection that contains the project for which you want to migrate test data or check the migration status.

If there are spaces in the name of the project collection, enclose the name in quotation marks, for example, "Fabrikam Fiber Collection".
/TeamProjectName:TeamProjectName Required. Specifies the project for which you want to migrate test data or check the migration status. This project must be defined in the collection that you specified by using the /collectionName parameter.

If there are spaces in the name of the project, enclose the name in quotation marks, for example, "My Project".

Prerequisites

You must be a member of the Team Foundation Administrators security group, and an administrator on the application-tier server. See Set administrator permissions for Azure DevOps Server.

Remarks

Your application-tier server must be upgraded to the latest version of Azure DevOps Server to use this command.

Before you can use the TCM command, you must first import the test plan work item definition and the test plan category into the project. To learn more about the migration and when to use this command, see Manual updates to support test management.

The TCM command is applied to individual projects. If you need to upgrade test plans in more than one project, you will have to run it against each project individually.

You must run the TCM command from the tools directory for Azure DevOps Server. By default, that location is: drive:\%programfiles%\TFS 12.0\Tools.

You use the TCM command only in the event that automatic migration of existing test data fails. To learn more about the migration and when to use this command, Manual updates to support test management.

If you can't access test plans or test suites that were defined before the server upgrade occurred, run TFSConfig TCM upgradeStatus to determine the status of the migration.

You run the TCM command for an individual project. If you need to upgrade more than one project, you will have to run it against each project in turn.

Examples

The following example shows how to check the status of test plan upgrade on the Fabrikam Fiber project hosted on the default project collection (DefaultCollection):

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

Unattend

The unattend command is designed for users who are familiar with Azure DevOps Server and the configuration process, and who need to install Azure DevOps Server on different machines.

For example, if you use Azure DevOps Build, you can use the unattend command to install multiple build servers using the same configuration file.

Use the /create option to create an unattend file. This file defines all configuration parameters for a Azure DevOps Server installation. Next, use the /configure option to actually perform the configuration.

This process allows you to configure Azure DevOps Server from start to finish without having to provide input during the installation process. In the case of multiple installations, this also helps ensure that the exact same configuration parameters are used across multiple servers.

TfsConfig unattend /create|configure /type:InstallType /unattendfile:ConfigurationFileName 
    [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]
Option Description
create Creates the unattend file with the name and parameters you specify.
configure Configures Azure DevOps Server using the unattend file and parameters you specify. You must use /type or /unattendfile with this option.
type Specifies the type of configuration to use. When you use /configure, either /type or /unattendfile are required, but you cannot use both.
unattendfile Specifies the unattend file to create or use, depending on whether the initial parameter is /create or /configure. When you use /configure, either /unattendfile or /type is required.
inputs Optional. If you use /create, specifies settings and values to use when creating the unattend file. If you use /configurespecifies additional settings and values to use in conjunction with the unattend file.

As an alternative to using /inputs, you can manually edit the unattend file in any plain-text editor. This is necessary for certain input types, such as ServiceAccountPassword or PersonalAccessToken as those secret values cannot be set using the /inputs parameter.
verify Optional. Specifies a configuration run that only completes verification checks based on the unattend file, inputs, and configuration type. This is an alternative to performing a complete configuration.
continue Optional. Specifies that /create or /configure should continue regardless of warnings from verification checks.
InstallType Description
NewServerBasic Configures the essential development services for Azure DevOps Server. This includes Source Control, Work Items, Build, and optionally Search.
NewServerAdvanced Configures the essential development services and allows optional configuration of integration with Reporting Services.
Upgrade Upgrades Azure DevOps Server to the current version from a supported previous release.
PreProductionUpgrade Test the upgrade on an existing Azure DevOps Server deployment in a pre-production environment. This is typically done using databases restored from production backups. This scenario includes additional steps to ensure that the new deployment will not interfere with the production deployment.
ApplicationTierOnlyBasic Configure a new application tier using existing settings from the supplied configuration database. This option allows you to get a new application tier up and running quickly using existing settings. If you want the ability to change existing settings, use the Advanced ApplicationTierOnlyAdvanced type instead.
ApplicationTierOnlyAdvanced Configure a new application tier with full control over all settings. Settings will default to existing values from the supplied configuration database. If you want to preserve all of your existing settings, use the ApplicationTierOnlyBasic type instead.
Clone Configure a new Azure DevOps Server deployment which is a clone of an existing deployment. This is typically done, using databases restored from production backups, to create an environment where configuration changes, extensions, and other modifications can be tested. This scenario includes additional steps to ensure that the new deployment will not interfere with the production deployment.
Proxy Configures a version control proxy service.

Prerequisites

  • You must be a member of the Administrators group on the computer where you are installing the software.

  • Depending on the type of installation, you might also require additional administrator permissions.

For example, if you are using the unattend command to install Team Foundation Server, you must be a member of the sysadmin group on the instance of SQL Server that will support Azure DevOps Server. For more information, see the Q & A section of Set administrator permissions for Azure DevOps Server.

Remarks

Before you can use the unattend command to configure Azure DevOps Server, you must create the service accounts that you will use as part of your deployment. You must also install any prerequisite software for your chosen installation type. This includes Azure DevOps Server itself. You must install Azure DevOps Server but you don't have to configure it because the unattend command will do that for you.

The unattend command configures Azure DevOps Server components. It does not perform the initial installation of the software. It configures the software according to your specifications after the bits are present on the computer.

Examples

The following example shows how to create an unattend file for a basic installation of Azure DevOps Server.

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

In this example, the unattend file is created in the same directory as the command. A log file is created as part of the command, and the location of the file is returned in the command as part of executing the command.

The following example shows how to specify a Git repository for use with GVFS during configuration.

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

The following example shows how to create an unattend file for the configuration of a Azure DevOps Proxy Server.

Important

In this example, if the administrators want to use a personal access token for authentication they will need to manually edit the file to specify the personal access token value. This can be achieved by adding a line for the personal access token in the created unattend file like: PersonalAccessToken=PersonalAccessTokenValue.

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

The following example shows how to create an unattend file for the configuration of Azure DevOps Server Build on a server using FabrikamFiber\BuildSVC as the build service account, and then configure Azure DevOps Server Build using that unattend file.

Important

In this example, after creating the unattend file, the administrator manually edits the file to specify the password for the build service account. Adding the password as an input using ServiceAccountPassword=Password; doesn't add the password information to the file.

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

The first command returns the following:

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

The second command returns the following information, including the name of the server where Azure DevOps Build was configured FabrikamFiberTFS and the project collection associated with the controller 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

Command availability: TFS 2015 and TFS 2013

The Unattend command is designed for users who are familiar with Azure DevOps Server and the configuration process, and who need to install Azure DevOps Server on different machines.

For example, if you use Team Foundation Build, you can use the Unattend command to install multiple build servers using the same configuration file.

Use the Unattend /create option to create an unattend file. This file defines all configuration parameters for a Azure DevOps Server installation. Next, use the Unattend /configure option to actually perform the configuration.

This process allows you to configure Azure DevOps Server from start to finish without having to provide input during the installation process. In the case of multiple installations, this also helps ensure that the exact same configuration parameters are used across multiple servers.

TFSConfig unattend /create|unattend /type:InstallType /unattendfile:ConfigurationFileName [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]
Option Description
/create Creates the unattend file with the name and parameters you specify.
/configure Configures Azure DevOps Server using the unattend file and parameters you specify. You must use /type or /unattendfile with this option.
/type:InstallType

Specifies the type of configuration to use.

  • Basic: Configures Azure DevOps Server in the basic configuration, including SQL Server Express.

  • Standard: Configures Azure DevOps Server in the standard single-server configuration.

  • ATOnly: Configures an additional application-tier for an existing Azure DevOps Server deployment.

  • Build: Configures the Team Foundation Build Service.

  • Proxy: Configures Azure DevOps Proxy Server.

  • SPInstall: Installs and configures SharePoint Foundation 2013 for use with a Azure DevOps Server deployment.

  • Upgrade: Upgrades a previous version of Azure DevOps Server to the latest version of the software.

    You must have downloaded and installed that version locally before running this command with /configure.

  • SPExtensions: Configures the SharePoint Extensions for Azure DevOps Server.

When you use /configure, either /type or /unattendfile are required, but you cannot use both.

/unattendfile:ConfigurationFileName Specifies the unattend file to create or use, depending on whether the initial parameter is /create or /configure. When you use /configure, either /unattendfile or /type is required.
/inputs:Key1=Value1; Key2=Value2;... Optional. If you use /create, specifies settings and values to use when creating the unattend file. If you use /configurespecifies additional settings and values to use in conjunction with the unattend file.

As an alternative to using /inputs, you can manually edit the unattend file in any plain-text editor. This is necessary for certain input types, such as ServiceAccountPassword or PersonalAccessToken as those secret values cannot be set using the /inputs parameter.
/verify Optional. Specifies a configuration run that only completes verification checks based on the unattend file, inputs, and configuration type. This is an alternative to performing a complete configuration.
/continue Optional. Specifies that /create or /configure should continue regardless of warnings from verification checks.
/? Optional. Provides command-line help for the unattend command.

Prerequisites

  • You must be a member of the Administrators group on the computer where you are installing the software.

  • Depending on the type of installation, you might also require additional administrator permissions. For example, if you are using the Unattend command to install Azure DevOps Server, you must be a member of the sysadmin group on the instance of SQL Server that will support Azure DevOps Server. For more information, see the Q & A section of Set administrator permissions for Azure DevOps Server.

Remarks

Before you can use the Unattend command to configure Azure DevOps Server, you must create the service accounts that you will use as part of your deployment. You must also install any prerequisite software for your chosen installation type. This includes Azure DevOps Server itself. You must install Azure DevOps Server but you don't have to configure it because the Unattend command will do that for you.

The Unattend command configures Azure DevOps Server components. It does not perform the initial installation of the software. It configures the software according to your specifications after the bits are present on the computer.

Examples

The following example shows how to create an unattend file for a basic installation of Azure DevOps Server.

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

In this example, the unattend file is created in the same directory as the command. A log file is created as part of the command, and the location of the file is returned in the command as part of executing the command.

The following example shows how to specify a Git repository for use with GVFS during configuration.

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

The following example shows how to create an unattend file for the configuration of a Azure DevOps Proxy Server.

Important: In this example, if the administrators want to use a personal access token for authentication they will need to manually edit the file to specify the personal access token value. This can be achieved by adding a line for the personal access token in the created unattend file like: "PersonalAccessToken=PersonalAccessTokenValue".

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

The following example shows how to create an unattend file for the configuration of Team Foundation Build on a server using "FabrikamFiber\BuildSVC" as the build service account, and then configure Team Foundation Build using that unattend file.

Important:
In this example, after creating the unattend file, the administrator manually edits the file to specify the password for the build service account. Adding the password as an input using "ServiceAccountPassword=Password" doesn't add the password information to the file.

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

The first command returns the following:

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

The second command returns the following information, including the name of the server where Team Foundation Build was configured (FabrikamFiberTFS) and the project collection associated with the controller (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

The ziplogs command is designed to gather logs and drops a zip at ProgramData\Microsoft\Azure DevOps\Server Configuration.

TfsConfig zipLogs

TfsConfig zipLogs

Deprecated commands

License

You can use the License command to display, modify, or extend the licensing key for your deployment of Azure DevOps Server.

TFSConfig License [/ProductKey:Key] [/extend [NewTrialID]]
Option Description
/ProductKey: Key Specifies that the license key for the deployment will be updated with the value of Key.
/extend Specifies that the trial licensing period for Azure DevOps Server will be extended by 30 days. This option can be used only once without a getting a new trial ID. If a second extension is required, you must obtain a second trial license from Microsoft.

Prerequisites

To use the License command, you must be a member of the Azure DevOps Administrators security group. For more information, see Permission reference for Azure DevOps Server.

Remarks

To view, modify, or change the licensing for your deployment interactively, you can use the administration console for Azure DevOps. For more information, see Open the Azure DevOps Administration Console and Locate or Change the Product Key for Azure DevOps Server.

Examples

The following example shows how to view the licensing information for a deployment of Azure DevOps Server. In this example, the deployment is using a trial license.

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

When upgrading to the latest version of Azure DevOps Server, the system automatically attempts to upgrade the Tests Management components, including test plans and suites. If the automatic migration fails, use the TCM command to upgrade your test plans and test suites manually to their respective work item types (WITs).

TFSConfig TCM /upgradeTestPlans|upgradeStatus /CollectionName:CollectionName /TeamProject:TeamProjectName
Option Description
/upgradeTestPlans Required unless /upgradeStatus is used.

Converts existing test plan and test suites to point to the work item-based test plans and test suites. It also updates existing test management data and links between other existing test artifacts such as test points, test runs, and test results.
/upgradeStatus Required unless /upgradeTestPlans is used.

Reports the migration status of test data for the specified project. It will also indicate whether the specified project has any test plans.
/CollectionName:CollectionName Required. Specifies the project collection that contains the project for which you want to migrate test data or check the migration status.

If there are spaces in the name of the project collection, enclose the name in quotation marks, for example, "Fabrikam Fiber Collection".
/TeamProjectName:TeamProjectName Required. Specifies the project for which you want to migrate test data or check the migration status. This project must be defined in the collection that you specified by using the /collectionName parameter.

If there are spaces in the name of the project, enclose the name in quotation marks, for example, "My Project".

Prerequisites

You must be a member of the Azure DevOps Administrators security group, and an administrator on the application-tier server. See Set administrator permissions for Azure DevOps Server.

Remarks

Your application-tier server must be upgraded to the latest version of Azure DevOps Server to use this command.

Before you can use the TCM command, you must first import the test plan work item definition and the test plan category into the project. To learn more about the migration and when to use this command, see Manual updates to support test management.

The TCM command is applied to individual projects. If you need to upgrade test plans in more than one project, you will have to run it against each project individually.

You must run the TCM command from the tools directory for Azure DevOps Server. By default, that location is: drive:\%programfiles%\TFS 12.0\Tools.

You use the TCM command only in the event that automatic migration of existing test data fails. To learn more about the migration and when to use this command, Manual updates to support test management.

If you can't access test plans or test suites that were defined before the server upgrade occurred, run TFSConfig TCM upgradeStatus to determine the status of the migration.

You run the TCM command for an individual project. If you need to upgrade more than one project, you will have to run it against each project in turn.

Examples

The following example shows how to check the status of test plan upgrade on the Fabrikam Fiber project hosted on the default project collection (DefaultCollection):

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

Import

The import command was deprecated in TFS 2013. Earlier versions are available here:

If you need assistance with upgrading data and projects from an earlier version of Azure DevOps Server, see Upgrade Azure DevOps Server, or contact Microsoft Support.

PrepareSQL

The prepareSQL command was depracated in TFS 2012. Earlier versions are available here:

Repair

The repair command was depracated in TFS 2012. Earlier versions are available here:

If you need to repair your stored procedures after a failed database patch, contact Microsoft Support.

Diagnose

The diagnose command was deprecated in TFS 2013. Earlier versions are available here:

If you need assistance with diagnosing potential mismatches between software updates on your application-tier and data-tier servers for Azure DevOps Server, contact Developer Community support.

Updates

The updates command was deprecated in TFS 2013.Earlier versions are available here:

If you need assistance with installing any software updates that are missing from the databases for Azure DevOps Server, contact Microsoft Support.

PrepareClone

The PrepareClone command was deprecated in TFS 2017.

The PrepareClone command removes information about scheduled backups, SharePoint, and reporting resources from a Azure DevOps Server deployment. This command is used in two circumstances:

  • when you move a deployment to new hardware but want to keep using the old deployment
  • when you clone a Azure DevOps Server deployment

In either of these cases it is critical to run this command. If you don't, the original resources will be used by both the original and the new servers. If both the original and the new servers are live and point to the same SharePoint or reporting resources for any amount of time, you could end up with corrupted databases.

Important

This command should be run before configuration, whether you move or clone Azure DevOps Server. If you run it after configuration, you could end up with inconsistencies between content in your databases and content in your web.config file. These inconsistencies might take your server offline. If you have already configured your moved or cloned Azure DevOps Server deployment and realize you need to run the command, follow these steps. First, quiesce your server. Next, run PrepareClone command, ChangeServerID command, and then RemapDBs command. Finally, unquiesce your server.

TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:TFSConfigurationDatabaseName
		[/notificationURL: TFSURL] [/usesqlalwayson]
Option What it does
/DatabaseName Specifies the name of the server that hosts the database that you want to map for Azure DevOps Server, in addition to the name of the configuration database itself.
/SQLInstance: ServerName Specifies the name of the server that you want to map as a server that hosts one or more databases for Azure DevOps Server. If an instance other than the default instance hosts a database, you must also specify the name of the instance. Use this format: ServerName </strong> InstanceName.
/NotificationURL: TFSURL Optional. Specifies The notification URL for the application-tier server.
/usesqlalwayson Optional. Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the PrepareClone command, you must be a member of the Azure DevOps Administrators security group and a member of the sysadmin security group for any SQL Server databases that Azure DevOps Server uses. For more information, see Permission reference for Azure DevOps Server.

Remarks

You use the PrepareClone command to reconfigure Azure DevOps Server when you move the original installation to new hardware and want to continue to use the original deployment Azure DevOps Server and hardware, or when you want to clone your Azure DevOps Server deployment for testing purposes. You use TFSConfig PrepareClone in conjunction with TFSConfig RemapDBs and TFSConfig ChangeServerID to support the cloning configuration.

Example

The following example shows how to use the command on a moved Azure DevOps Server named NewFabrikamTFS to remove old backup, reporting, and SharePoint resource information. If this information isn't removed, the original deployment of Azure DevOps Server still uses those same resources and databases become corrupt. In the example, the SQL Server supporting the moved Azure DevOps Server is also named NewFabrikamTFS, and the instance is the default instance, so no specific instance information is required, just the server name.

TFSConfig PrepareClone /SQLInstance:NewFabrikamTFS /DatabaseName:TFS_Configuration

License

You can use the License command to display, modify, or extend the licensing key for your deployment of Azure DevOps Server.

TFSConfig License [/ProductKey:Key] [/extend [NewTrialID]]
Option Description
/ProductKey: Key Specifies that the license key for the deployment will be updated with the value of Key.
/extend Specifies that the trial licensing period for Azure DevOps Server will be extended by 30 days. This option can be used only once without a getting a new trial ID. If a second extension is required, you must obtain a second trial license from Microsoft.

Prerequisites

To use the License command, you must be a member of the Team Foundation Administrators security group. For more information, see Permission reference for Azure DevOps Server.

Remarks

To view, modify, or change the licensing for your deployment interactively, you can use the administration console for Azure DevOps. For more information, see Open the Azure DevOps Administration Console and Locate or Change the Product Key for Azure DevOps Server.

Examples

The following example shows how to view the licensing information for a deployment of Azure DevOps Server. In this example, the deployment is using a trial license.

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
Option Description
/upgradeTestPlans Required unless /upgradeStatus is used.

Converts existing test plan and test suites to point to the work item-based test plans and test suites. It also updates existing test management data and links between other existing test artifacts such as test points, test runs, and test results.
/upgradeStatus Required unless /upgradeTestPlans is used.

Reports the migration status of test data for the specified project. It will also indicate whether the specified project has any test plans.
/CollectionName:CollectionName Required. Specifies the project collection that contains the project for which you want to migrate test data or check the migration status.

If there are spaces in the name of the project collection, enclose the name in quotation marks, for example, "Fabrikam Fiber Collection".
/TeamProjectName:TeamProjectName Required. Specifies the project for which you want to migrate test data or check the migration status. This project must be defined in the collection that you specified by using the /collectionName parameter.

If there are spaces in the name of the project, enclose the name in quotation marks, for example, "My Project".

Prerequisites

You must be a member of the Team Foundation Administrators security group, and an administrator on the application-tier server. See Set administrator permissions for Team Foundation Server.

Remarks

Your application-tier server must be upgraded to the latest version of TFS to use this command.

Before you can use the TCM command, you must first import the test plan work item definition and the test plan category into the project. To learn more about the migration and when to use this command, see Manual updates to support test management.

The TCM command is applied to individual projects. If you need to upgrade test plans in more than one project, you will have to run it against each project individually.

You must run the TCM command from the tools directory for TFS. By default, that location is: drive:\%programfiles%\TFS 12.0\Tools.

You use the TCM command only in the event that automatic migration of existing test data fails. To learn more about the migration and when to use this command, Manual updates to support test management.

If you can't access test plans or test suites that were defined before the server upgrade occurred, run TFSConfig TCM upgradeStatus to determine the status of the migration.

You run the TCM command for an individual project. If you need to upgrade more than one project, you will have to run it against each project in turn.

Examples

The following example shows how to check the status of test plan upgrade on the Fabrikam Fiber project hosted on the default project collection (DefaultCollection):

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

Import

The import command was deprecated in TFS 2013. Earlier versions are available here:

If you need assistance with upgrading data and projects from an earlier version of Azure DevOps Server, see Upgrade Azure DevOps Server, or contact Microsoft Support.

PrepareSQL

The prepareSQL command was depracated in TFS 2012. Earlier versions are available here:

Repair

The repair command was depracated in TFS 2012. Earlier versions are available here:

If you need to repair your stored procedures after a failed database patch, contact Microsoft Support.

Diagnose

The diagnose command was deprecated in TFS 2013. Earlier versions are available here:

If you need assistance with diagnosing potential mismatches between software updates on your application-tier and data-tier servers for Azure DevOps Server, contact Developer Community support.

Updates

The updates command was deprecated in TFS 2013. Earlier versions are available here:

If you need assistance with installing any software updates that are missing from the databases for Azure DevOps Server, contact Microsoft Support.

PrepareClone

The PrepareClone command was deprecated in TFS 2017.

Command availability: TFS 2015 and TFS 2013

The PrepareClone command removes information about scheduled backups, SharePoint, and reporting resources from a Azure DevOps Server deployment. This command is used in two circumstances:

  • when you move a deployment to new hardware but want to keep using the old deployment
  • when you clone a Azure DevOps Server deployment

In either of these cases it is critical to run this command. If you don't, the original resources will be used by both the original and the new servers. If both the original and the new servers are live and point to the same SharePoint or reporting resources for any amount of time, you could end up with corrupted databases.

Important:
This command should be run before configuration, whether you move or clone Azure DevOps Server. If you run it after configuration, you could end up with inconsistencies between content in your databases and content in your web.config file. These inconsistencies might take your server offline. If you have already configured your moved or cloned Azure DevOps Server deployment and realize you need to run the command, follow these steps. First, quiesce your server. Next, run PrepareClone command, ChangeServerID command, and then RemapDBs command. Finally, unquiesce your server.

TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:TFSConfigurationDatabaseName
	[/notificationURL: TFSURL] [/usesqlalwayson]
Option What it does
/DatabaseName Specifies the name of the server that hosts the database that you want to map for Azure DevOps Server, in addition to the name of the configuration database itself.
/SQLInstance: ServerName Specifies the name of the server that you want to map as a server that hosts one or more databases for Azure DevOps Server. If an instance other than the default instance hosts a database, you must also specify the name of the instance. Use this format: ServerName </strong> InstanceName.
/NotificationURL: TFSURL Optional. Specifies The notification URL for the application-tier server.
/usesqlalwayson Optional. Specifies that the databases are part of an AlwaysOn Availability Group in SQL Server. If configured, this option sets MultiSubnetFailover in the connection string.

For more information, see AlwaysOn Availability Groups (SQL Server).

Prerequisites

To use the PrepareClone command, you must be a member of the Team Foundation Administrators security group and a member of the sysadmin security group for any SQL Server databases that Azure DevOps Server uses. For more information, see Permission reference for Azure DevOps Server.

Remarks

You use the PrepareClone command to reconfigure Azure DevOps Server when you move the original installation to new hardware and want to continue to use the original deployment Azure DevOps Server and hardware, or when you want to clone your Azure DevOps Server deployment for testing purposes. You use TFSConfig PrepareClone in conjunction with TFSConfig RemapDBs and TFSConfig ChangeServerID to support the cloning configuration.

Example

The following example shows how to use the command on a moved Azure DevOps Server named NewFabrikamTFS to remove old backup, reporting, and SharePoint resource information. If this information isn't removed, the original deployment of Azure DevOps Server still uses those same resources and databases become corrupt. In the example, the SQL Server supporting the moved Azure DevOps Server is also named NewFabrikamTFS, and the instance is the default instance, so no specific instance information is required, just the server name.

TFSConfig PrepareClone /SQLInstance:NewFabrikamTFS /DatabaseName:TFS_Configuration