Utiliser TFSConfig pour gérer Azure DevOps en local

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

Vous pouvez utiliser l’outil en ligne de commande TFSConfig pour effectuer diverses actions administratives pour votre déploiement Local Azure DevOps.

TFSConfig peut être exécuté à partir de n’importe quel ordinateur sur lequel Azure DevOps Server a été installé.

Emplacement de l’outil en ligne de commande

Les outils en ligne de commande Azure DevOps sont installés dans le répertoire /Tools d’un serveur de couche Application Azure DevOps.

• Azure DevOps Server 2020 :%programfiles%\Azure DevOps Server 2020\Tools
• 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

Prérequis

Pour que de nombreuses commandes fonctionnent correctement, TFSConfig doit être en mesure de se connecter aux différents serveurs et services qui font partie de votre déploiement TFS, et l’utilisateur exécutant TFSConfig doit disposer d’autorisations administratives pour ces mêmes serveurs et services. Les exigences pour des commandes spécifiques sont appelées ci-dessous.

De nombreuses commandes TFSConfig doivent être exécutées à partir d’une invite de commandes avec élévation de privilèges, même si l’utilisateur en cours d’exécution possède des informations d’identification administratives. Pour ouvrir une invite de commandes avec élévation de privilèges, cliquez sur Démarrer, cliquez avec le bouton droit sur Invite de commandes, puis cliquez sur Exécuter en tant qu’administrateur. Pour plus d’informations, consultez : Contrôle de compte d’utilisateur.

Vous pouvez également effectuer des actions d’administration de manière interactive à l’aide de la console d’administration pour Azure DevOps Server. Consultez Informations de référence rapides sur les tâches d’administration.

Répertorier les commandes et obtenir de l’aide

Pour afficher la liste complète des commandes TFSConfig , utilisez la commande d’aide :

TFSConfig help

Pour obtenir de l’aide pour une commande individuelle, utilisez la commande d’aide et spécifiez le nom de la commande avec laquelle vous souhaitez obtenir de l’aide. Par exemple, pour obtenir de l’aide pour la commande accounts :

TFSConfig help accounts

Comptes

Utilisez la commande accounts pour gérer ces comptes de service Azure DevOps Server.

• le compte de service Azure DevOps Server
• le compte des sources de données pour SQL Server Reporting Services
• le compte de service Azure DevOps Proxy Server

Vous pouvez également utiliser cette commande pour modifier la propriété des bases de données Azure DevOps Server.

TfsConfig accounts /change|add|set|delete|updatepassword|resetowner
	[/accountType:<adminConsole|applicationTier|proxy|reportingDataSource>]
	[/account:<accountName>] [/password:<password>]
	[/sqlInstance:<serverName>] [/databaseName:<databaseName>] [/continue]

Opération	Description
UpdatePassword	Modifie le mot de passe d'un compte utilisé comme compte de service. Modifie le compte existant et tous les accountTypes qui s’exécutent en tant que compte donné.
Modifier	Modifie le compte utilisé comme compte de service. Ajoute le nouveau compte aux ressources et aux groupes nécessaires, accorde les autorisations requises, puis définit le service pour l’utiliser. Cela ne supprime pas l’ancien compte des ressources. Si vous n’utilisez pas l’option accountType , le compte de service pour la couche Application sera modifié.
Ajouter	Ajoute uniquement le nouveau compte aux ressources nécessaires. Utile pour les scénarios d’équilibrage de charge réseau. Utilisez l’indicateur continuer si certaines collections ne sont pas accessibles. L’ajout peut être réexécuté ultérieurement pour mettre à jour les collections manquées. Ajoute un compte aux groupes requis pour l'utilisation du compte comme compte de service.
Set	Définit uniquement le service pour qu’il utilise un compte déjà ajouté aux ressources. Utile pour les scénarios d’équilibrage de charge réseau.
Supprimer	Supprime le compte de toutes les ressources. Des précautions doivent être prises lors de la suppression d’un compte, car cela peut entraîner le refus de service d’autres serveurs.
ResetOwner	Si les bases de données sont restaurées dans le cadre d’un déplacement, d’un clone ou d’une récupération d’urgence, le propriétaire de la base de données peut basculer vers l’administrateur qui restaure le serveur. Cette option itère dans toutes les bases de données et définit la connexion dbo sur le propriétaire actuel.

AccountType	Description
AdminConsole	Console d’administration Les utilisateurs sont des utilisateurs qui ont obtenu les autorisations minimales sur différentes ressources pour utiliser la console.
ApplicationTier	Modifie le compte de service sur le pool d’applications pour les principaux services web. (TFSService)
Proxy	Modifie le compte de service sur le pool d’applications pour les services web proxy. (TFSProxy)
ReportingDataSource	Modifie le compte que les rapports utilisent pour accéder aux données de création de rapports. (TFSReports)

La valeur par défaut est ApplicationTier.

SqlInstance et databaseName sont uniquement appropriés pour une utilisation lors de l’ajout d’un compte aux bases de données avant la configuration de la couche Application. Cela est principalement utile dans les scénarios de récupération d’urgence où un autre compte est nécessaire avant d’exécuter l’Assistant Configuration AT Only.

L’option continuer est utilisée lors de l’ajout ou de la modification d’un compte. Pour ces opérations, le compte est modifié dans chaque base de données de collection. Si continue est fourni, il se poursuit si une collection est inaccessible. Il peut être exécuté à nouveau lorsqu’ils sont accessibles.

Notes

Les comptes doivent être au format domainName\userName. Pour les comptes système, vous devez utiliser des guillemets autour du nom complet du compte (par exemple, « Autorité NT\Service réseau »). Les comptes système ne nécessitent pas de mot de passe.

Paramètre	Description
Compte	Spécifie le nom du compte que vous souhaitez ajouter, modifier ou supprimer d’un type de compte référencé, tel que /AccountType :ApplicationTier.
Mot de passe	Spécifie le mot de passe du compte de service. Ce paramètre est facultatif si vous utilisez un compte système ou un compte sans un mot de passe, tel que Service réseau.
sqlInstance	Utilisé uniquement avec /ResetOwner. Spécifie le nom du serveur qui exécute SQL Server et le nom du instance si vous souhaitez utiliser un instance autre que le instance par défaut. Vous devez spécifier le nom et l'instance au format suivant : ServerName\InstanceName.
databaseName	Utilisé uniquement avec /ResetOwner. Spécifie le nom de la base de données dont vous voulez modifier la propriété. À l'aide de cette commande, vous réinitialisez la propriété de la base de données que vous spécifiez en l'attribuant au compte sous lequel vous exécutez la commande.
continue	Met à jour tous les groupes qui ne sont pas disponibles lorsque vous exécutez la commande. Cette option est généralement utilisée dans des scénarios NLB.

Prérequis

Pour utiliser la commande accounts , vous devez être membre de :

• le groupe de sécurité Administrateurs Azure DevOps
• rôle sysadmin pour toutes les instances SQL Server que votre Azure DevOps Server instance utilise.

Si vous utilisez l’option /proxy , vous devez être administrateur sur le serveur proxy.

Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Utilisez la commande accounts pour automatiser les modifications apportées aux comptes de service, aux bases de données et aux groupes de comptes de service de Azure DevOps Server. Vous pouvez configurer des comptes que vous avez déjà créés, mais vous ne pouvez pas créer de comptes.

Avant de modifier le domaine ou le groupe de travail d’un compte, le compte doit être sensible et ne peut pas être autorisé à être délégué sur le serveur de la couche Application. Pour plus d’informations, consultez cette page sur le site web Microsoft : Activation de l’authentification déléguée.

La commande accounts prend en charge les déploiements Azure DevOps Server locaux. Pour modifier le propriétaire du compte d’un compte Azure DevOps Services, consultez Modifier la propriété du compte.

Exemples

Remplacez le compte de service des sources de données pour Reporting Services par un nouveau compte dans le domaine Contoso, Contoso\NewAccountet le mot de passe par Password.

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

Ajoutez le compte système de service réseau aux groupes de comptes de service pour Azure DevOps Server (les comptes système n’ont pas de mot de passe).

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

Remplacez la propriété de la TFS_Warehouse base de données sur le ContosoMain SQL Server dans le TeamDatabases instance nommé par le compte d’utilisateur sous lequel vous exécutez la commande.

Notes

Vous ne pouvez pas spécifier le compte à définir comme propriétaire des bases de données lorsque vous utilisez cette commande. Le propriétaire est le compte sous lequel vous exécutez la commande.

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

---

AddProjectReports

Notes

La commande addProjectReports est disponible avec TFS 2017.1 et versions ultérieures.

Vous utilisez la commande addProjectReports pour ajouter ou remplacer des rapports pour un projet d’équipe existant.

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

Option	Description
collection	Obligatoire. URL de la collection de projets d’équipe.
teamproject	Obligatoire. Spécifie le nom du projet d’équipe.
template	Obligatoire. Spécifie le nom du modèle de processus. Les options disponibles sont Agile, CMMI et Scrum.
force	facultatif. Spécifie que les rapports doivent être remplacés s’ils existent déjà.

Prérequis

Pour utiliser la commande addProjectReports , vous devez disposer des autorisations nécessaires pour exécuter TFSConfig et charger des rapports dans Reporting Service.

Remarques

Vous utilisez la commande addProjectReports lorsque votre projet n’a pas de rapports ou que vous souhaitez mettre à jour les rapports définis pour un processus.

Vous devrez peut-être utiliser cette commande dans les cas suivants :

• Le projet a été créé dans le portail Azure DevOps et non à partir de Visual Studio
• Le projet a été créé à partir de Visual Studio, mais la création de rapports n’a pas été configurée dans Azure DevOps Server.

Si vous souhaitez remplacer les rapports de votre projet par des rapports par défaut, car vous avez mis à niveau Azure DevOps Server et les anciens rapports de votre projet ne sont plus compatibles, utilisez l’option /force. Si vous avez des rapports personnalisés, effectuez une sauvegarde avant de procéder.

Pour en savoir plus sur l’ajout de rapports à un Azure DevOps Server local, consultez Ajouter des rapports à un projet.

Exemple

L’exemple suivant montre comment ajouter des rapports Agile à un MyProject projet dans une http://myTfsServer:8080/tfs/DefaultCollection collection de projets.

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

---

Authentification

La commande Authentification modifie le protocole d’authentification réseau utilisé par le Azure DevOps Server niveau application ou le site web proxy.

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

Option

Description

/viewAll

Affiche les paramètres d’authentification actuels pour Azure DevOps Server.

/provider : { NTLM | Negotiate }

Spécifie le fournisseur d'authentification que vous souhaitez configurer pour le site web.

• NTLM : utiliser le protocole d’authentification NTML
• Negotiate : utiliser le protocole d’authentification Negotiate (Kerberos)

/siteType

Spécifie le site web (niveau Application ou proxy) dont vous souhaitez modifier le protocole d’authentification réseau. La couche Application est la couche par défaut.

Prérequis

Pour utiliser la commande d’authentification , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps et administrateur local sur le serveur de la couche Application ou le serveur proxy, en fonction de la valeur de l’option siteType .

Remarques

La commande Authentication est utilisée par un administrateur qui souhaite modifier le protocole d’authentification réseau pour un ou plusieurs sites web sur lesquels Azure DevOps Server s’appuie. L'administrateur exécute cette commande à partir de la couche Application pour mettre à jour les sites web dont le protocole d'authentification réseau doit être modifié. La commande modifie la propriété NTAuthenticationProviders dans la métabase IIS.

Avant d’utiliser la commande Authentication pour modifier le protocole d’authentification, vous pouvez exécuter la commande avec l’option /viewAll pour voir quels sont les paramètres existants.

Exemple

L'exemple suivant indique la valeur actuelle attribuée au protocole d'authentification réseau.

TFSConfig Authentication /viewAll

---

Certificats

Utilisez la commande certificats pour modifier la façon dont les certificats sont configurés pour l’authentification client dans un déploiement de Azure DevOps Server qui utilise HTTPS, SSL (Secure Sockets Layer) et des certificats.

TfsConfig certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]

Option	Description
ordinateur	Spécifie que la liste des certificats provient du contexte de l’ordinateur local au lieu du contexte utilisateur actuel.
disable	Spécifie que le paramètre de certificat d’authentification client sera désactivé.
autoSelect	Spécifie qu’un certificat sera automatiquement sélectionné dans la liste des certificats. La fenêtre Gérer les certificats clients ne s’ouvre pas.
noprompt	Spécifie que la fenêtre Gérer les certificats clients ne s’ouvre pas lorsque la commande Certificats est exécutée.
empreintes	Spécifie que le certificat qui correspond à l’empreinte numérique spécifiée sera utilisé. Vous pouvez spécifier plusieurs certificats en séparant les empreintes individuelles par une virgule.

Prérequis

Pour utiliser la commande certificates , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps et du groupe Administrateurs local sur l’ordinateur à partir duquel vous exécutez la commande. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Par défaut, la commande certificats sélectionne automatiquement un certificat client dans la liste des certificats de l’utilisateur actuel. Toutefois, vous pouvez utiliser les options de la commande pour spécifier un ou plusieurs certificats spécifiques à partir du contexte utilisateur actuel ou du contexte de l’ordinateur local.

Avant d’utiliser la commande certificats, vous devez d’abord configurer les serveurs dans votre déploiement de Azure DevOps Server pour utiliser des certificats. Pour plus d’informations, consultez Configuration de HTTPS avec SSL (Secure Sockets Layer) pour Azure DevOps Server.

Vous utilisez la commande certificats pour configurer les certificats clients utilisés par un déploiement de Azure DevOps Server qui a été configuré pour utiliser HTTPS/SSL et des certificats. Si vous utilisez la commande Certificats sans options, un certificat client est automatiquement sélectionné dans le contexte utilisateur actuel à partir duquel vous exécutez la commande.

Exemples

L’exemple suivant montre comment spécifier le certificat d’ordinateur local qui a l’empreinte numérique aa bb cc dd ee sans invite.

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

L’exemple suivant montre comment spécifier à l’aide de la sélection automatique d’un certificat client à partir du magasin d’utilisateurs actuel.

TfsConfig certificates /autoselect

---

ChangeServerID

La commande changeServerID modifie les GUID associés aux bases de données pour Azure DevOps Server. Les GUID doivent être uniques dans un déploiement de Azure DevOps Server. Si plusieurs bases de données ont le même GUID, votre déploiement peut devenir instable ou inutilisable. Vous pouvez modifier le GUID de la base de données de configuration, les GUID de toutes les bases de données de collection de projets dans le déploiement, ou les deux.

Bien que vous n’utilisiez généralement pas cette commande dans les opérations quotidiennes, vous pouvez utiliser cette commande dans les circonstances suivantes :

• Vous avez restauré votre déploiement sur un nouveau matériel, l’ancien déploiement est toujours opérationnel et vous souhaitez utiliser les deux déploiements. Ce scénario est parfois appelé clonage du serveur.

• Vous souhaitez tester une mise à jour logicielle ou une configuration matérielle sur un déploiement en double afin de ne pas risquer de perturber votre environnement de production.

• Vous souhaitez tester entièrement la restauration des bases de données sur un nouveau matériel dans un laboratoire de test ou un environnement distinct, afin de vous assurer que votre déploiement peut être restauré.

• Vous devez réinitialiser le GUID d’une base de données de collection après l’avoir déplacée vers un autre déploiement pour lequel ce GUID est déjà réservé.

Notes

La commande changeServerID n’est pas réversible. Une fois qu’un GUID a été modifié, vous ne pouvez pas annuler cette modification, sauf en restaurant une version précédente de cette base de données.

TfsConfig changeServerID /sqlInstance:<serverName> /databaseName:<configurationDatabaseName>
	[/projectCollectionsOnly] [/configDBOnly] [/collectionName]

Option	Description
sqlInstance	Obligatoire. Spécifie le nom du serveur qui exécute SQL Server et le nom du instance si vous souhaitez utiliser un instance autre que le instance par défaut. Si vous spécifiez un instance, vous devez utiliser le format : ServerName\InstanceName.
databaseName	Obligatoire. Spécifie le nom de la base de données de configuration pour Azure DevOps Server. Par défaut, le nom de cette base de données est TFS_ConfigurationDB.
projectCollectionsOnly	Spécifie que seuls les GUID des collections seront modifiés.
configDBOnly	Spécifie que seul le GUID de la base de données de configuration sera modifié.
collectionName	Spécifie de créer un id de instance pour la collection spécifique, mais pas pour Azure DevOps instance et les autres collections.

Prérequis

Pour utiliser la commande changeServerID, vous devez être membre du groupe de sécurité Administrateurs Azure DevOps et membre du rôle de sécurité sysadmin pour toutes les instances SQL Server que Azure DevOps Server utilise. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps.

Remarques

Vous utilisez la commande changeServerID pour créer un doublon discret d’un déploiement de Azure DevOps Server à des fins de test ou de clonage. Après avoir utilisé la commande changeServerID , vous devez diriger les clients pour créer une connexion au serveur modifié avant de pouvoir l’utiliser.

Exemple

L’exemple suivant montre comment modifier les GUID de toutes les bases de données dans le déploiement Contoso1 de Azure DevOps Server, où la base de données de configuration est hébergée sur le serveur nommé ContosoMain sur le instance TeamDatabases nommé dans SQL Server.

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

---

CodeIndex

Utilisez la commande codeIndex pour gérer l’indexation du code sur Azure DevOps Server. Par exemple, vous pouvez réinitialiser l'index pour corriger des informations CodeLens ou pour désactiver l'indexation afin d'analyser les problèmes de performances du serveur.

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	Affichez l'état et la configuration du service d'indexation de code.
setIndexing	on : démarrer l’indexation de tous les ensembles de modifications. off : arrêter l’indexation de tous les ensembles de modifications. off : arrêter l’indexation des ensembles de modifications créés précédemment et commencer l’indexation de nouveaux ensembles de modifications uniquement.
ignoreList	Spécifie une liste de fichiers de code et leurs chemins d’accès à ne pas indexer. add : ajouter le fichier à ne pas indexer à la liste des fichiers ignorés. remove : supprimer le fichier à indexer de la liste des fichiers ignorés. removeAll : effacer la liste des fichiers ignorés et démarrer l’indexation de tous les fichiers. view : afficher tous les fichiers qui ne sont pas indexés. ServerPath : spécifie le chemin d’accès à un fichier de code. Vous pouvez utiliser le caractère générique (*) au début, à la fin ou aux deux extrémités du chemin d’accès au serveur.
listLargeFiles	Indique le nombre spécifié de fichiers qui dépassent la taille spécifiée en Ko. Vous pouvez ensuite utiliser l’option /ignoreList pour exclure ces fichiers de l’indexation. Pour cela, vous aurez besoin de Team Foundation Server 2013 avec Update 3.
réindexerTous les	Effacez les données indexées précédemment et redémarrez l'indexation.
destroyCodeIndex	Supprimez l'index de code et supprimez toutes les données indexées. Confirmation inutile si vous utilisez l’option /noPrompt.
temporaryDataSizeLimit	Contrôle la quantité de données temporaires que CodeLens crée lors du traitement des ensembles de modifications. La limite par défaut est 6 Go (2 Go dans Update 5). view : afficher la limite de taille actuelle. SizeInGBs : modifiez la limite de taille. disable : supprimer la limite de taille. Cette limite est vérifiée avant que CodeLens ne traite un nouvel ensemble de modifications. Si les données temporaires dépassent cette limite, CodeLens suspend le traitement des ensembles de modifications passés, pas celui des nouveaux. CodeLens redémarre le traitement une fois que les données sont nettoyées et que leur taille est inférieure à cette limite. Le nettoyage s'exécute automatiquement une fois par jour. Cela signifie que les données temporaires peuvent dépasser cette limite tant que l'opération de nettoyage n'a pas commencé. Pour cela, vous aurez besoin de Team Foundation Server 2013 avec Update 4.
indexHistoryPeriod	Contrôler la durée d'indexation de votre historique des modifications. Cela affecte la quantité d'historique que CodeLens affiche. La limite par défaut est 12 mois. Cela signifie que l'historique des modifications affiché par CodeLens englobe uniquement les 12 derniers mois. view : afficher le nombre de mois actuel. all : indexer tout l’historique des modifications. NumberOfMonths : modifiez le nombre de mois utilisés pour indexer l’historique des modifications. Pour cela, vous aurez besoin de Team Foundation Server 2013 avec Update 4.
collectionName	Spécifie le nom de la collection de projets sur laquelle exécuter la commande CodeIndex. Nécessaire si vous n’utilisez pas /CollectionId.
collectionId	Spécifie le numéro d’identification de la collection de projets sur laquelle exécuter la commande CodeIndex. Obligatoire si vous n’utilisez pas /CollectionName

Prérequis

Pour utiliser la commande codeIndex , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps. Consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Exemples

Pour consulter l'état et la configuration d'indexation du code :

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

Pour démarrer l'indexation de tous les ensembles de modifications :

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

Pour arrêter l'indexation des ensembles de modifications créés précédemment et commencer l'indexation de nouveaux ensembles de modifications uniquement :

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

Pour trouver jusqu'à 50 fichiers dont la taille est supérieure à 10 Ko :

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

Pour exclure un fichier spécifique de l'indexation et l'ajouter à la liste des fichiers ignorés :

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

Pour afficher tous les fichiers qui ne sont pas indexés :

TfsConfig codeIndex /ignoreList:view

Pour effacer les données précédemment indexées et redémarrer l'indexation :

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

Pour enregistrer la totalité de l'historique des ensembles de modifications :

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

Pour supprimer la limite de taille sur les données temporaire CodeLens et poursuivre l'indexation indépendamment de la taille des données temporaires :

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

Pour supprimer l'index de code avec confirmation :

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

---

Collection

Vous pouvez utiliser la commande collection pour attacher, détacher ou supprimer une collection de projets d’un déploiement de Azure DevOps Server. Vous pouvez également utiliser la commande collection pour dupliquer la base de données d’une collection existante, la renommer et l’attacher au déploiement. Ce processus est parfois appelé « clonage d'une collection ».

TfsConfig collection {/attach | /create | /detach | /delete} [/collectionName:<collectionName>]
    [/description:<collectionDescription>]
    [/collectionDB:<serverName>;<databaseName>]
    [/processModel:Inheritance|Xml]
    [/reportingFolder:<reportingFolderPath>]
    [/clone] [/verify] [/continue]

Option	Description
attacher	Obligatoire si ni /detach ni /delete n’est utilisé. Si vous spécifiez cette option, vous devez également utiliser l’option /collectionDB . En tant qu’option, vous pouvez également utiliser /collectionName et /clone avec cette option. Si vous utilisez l’option /attach, la base de données de collection spécifiée sera ajoutée à votre déploiement de Azure DevOps Server.
create	Crée une collection.
Détacher	Obligatoire si ni /attach ni /delete n’est utilisé. Si vous spécifiez cette option, vous devez également utiliser l’option /collectionName . Si vous utilisez l’option /detach, la base de données de la collection spécifiée est arrêtée et la collection est détachée de votre déploiement de Azure DevOps Server.
supprimer	Obligatoire si ni /detach ni /attach n’est utilisé. Si vous spécifiez cette option, vous devez également utiliser l’option /collectionName . Si vous utilisez l’option /delete, la base de données de la collection spécifiée sera arrêtée et la collection sera définitivement détachée de Azure DevOps Server. Vous ne pourrez donc plus rattacher la base de données de collection à ce déploiement ou à un autre.
CollectionName	Spécifie le nom de la collection de projets. Si le nom de la collection contient des espaces, vous devez mettre le nom entre guillemets (par exemple, "Ma collection"). Obligatoire si /detach ou /delete est utilisé. Si vous utilisez cette option avec /detach ou /delete, elle spécifie la collection qui sera détachée ou supprimée. Si vous utilisez cette option avec /attach, elle spécifie un nouveau nom pour la collection. Si vous utilisez cette option avec /attach et /clone, elle spécifie le nom de la collection dupliquée.
CollectionDB	Obligatoire si /attach est utilisé. Cette option spécifie le nom du serveur qui exécute SQL Server et le nom de la base de données de collection hébergée sur ce serveur.
ServerName	Spécifie le nom du serveur qui héberge la base de données de configuration pour Azure DevOps Server et le nom du instance si vous souhaitez utiliser un instance autre que le instance par défaut. Si vous spécifiez un instance, vous devez utiliser le format : ServerName\InstanceName.
nom_base_de_données	Spécifie le nom de la base de données de configuration. Par défaut, le nom de cette base de données est TFS_ConfigurationDB.
clone	Si vous spécifiez cette option, la base de données de collection d’origine sera jointe en tant que clone dans SQL Server et cette base de données sera attachée à Azure DevOps Server. Cette option est principalement utilisée dans le cadre du fractionnement d’une collection de projets.

Conseil

L’option /delete ne supprime pas la base de données de collection de SQL Server. Après avoir supprimé la base de données de collection de Azure DevOps Server, vous pouvez la supprimer manuellement de SQL Server.

Prérequis

Pour utiliser la commande collections , vous devez être membre du groupe de sécurité Administrateurs Team Foundation ainsi que du groupe Administrateurs local sur la machine exécutant TfsConfig. Vous devez également être membre du rôle de sécurité sysadmin pour toutes les instances de SQL Server utilisées par Azure DevOps Server bases de données. Si votre déploiement est intégré à SharePoint et que vous utilisez l’option /delete , vous devez également être membre du groupe Administrateurs de batterie de serveurs pour la batterie de serveurs SharePoint à partir de laquelle vous supprimez la collection de sites.

Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Pour gérer des collections de manière interactive ou créer une collection, vous pouvez utiliser le nœud Collections de projet dans la console d’administration pour Azure DevOps. Consultez Gérer les collections de projets.

Exemples

L’exemple suivant montre comment supprimer définitivement la Contoso Summer Intern Projects collection de projets d’un déploiement de 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.

L’exemple suivant montre comment dupliquer la collection de Contoso Summer Interns Projects projets, la nommer Contoso Winter Interns Projectset attacher la collection en double au déploiement de Azure DevOps Server.

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

---

ColumnStoreIndex

Notes

Disponibilité des commandes : nécessite TFS 2015.2 et versions ultérieures.

Vous utilisez la commande columnStoreIndex pour activer ou désactiver les index de magasin de colonnes pour les bases de données utilisées par votre déploiement Azure DevOps Server.

TfsConfig columnStoreIndex /enabled:<true|false>
	/sqlInstance:<serverName>
	/databaseName:<databaseName>

Option	Description
enabled	Spécifie si vous activez ou désactivez l’index du magasin de colonnes pour la base de données et le instance SQL donnés.
sqlInstance	Spécifie le nom du serveur qui héberge la base de données pour laquelle l’index du magasin de colonnes est activé ou désactivé, ainsi que le nom du instance si un instance autre que la valeur par défaut est utilisé. Si vous spécifiez un instance, vous devez utiliser le format : ServerName\InstanceName.
databaseName	Spécifie le nom de la base de données pour laquelle l’index de magasin de colonnes est activé ou désactivé.

Prérequis

Pour utiliser la commande columnStoreIndex, vous devez être membre du rôle sysadmin pour le SQL Server instance spécifié.

Remarques

Vous utilisez généralement la commande columnStoreIndex si vous déplacez une base de données d’un instance SQL qui prend en charge l’index de magasin de colonnes vers un index qui ne l’a pas fait. Dans ce cas, vous devez désactiver tous les index de magasin de colonnes avant de pouvoir déplacer correctement les bases de données. De même, si vous déplacez une base de données vers un instance SQL qui a pris en charge l’index de magasin de colonnes, vous pouvez réactiver l’index de magasin de colonnes afin d’économiser de l’espace et d’améliorer les performances.

Exemple

L’exemple suivant montre comment activer l’index de magasin de colonnes pour une base de données nommée TFS_DefaultCollection sur un instance SQL s’exécutant sur un serveur nommé ContosoMain sur le instance TeamDatabasesnommé .

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

---

ConfigureMail

Configurez le serveur qui exécute Azure DevOps Server pour utiliser un serveur SMTP existant pour les alertes par e-mail.

TfsConfig configureMail /Enabled:<true|false> /FromEmailAddress:<emailAddress> /SmtpHost:<SMTPHostName>

Option	Description
FromEmailAddress	Spécifie l’adresse à partir de laquelle envoyer des Notifications par e-mail à partir de Azure DevOps Server pour un case activée dans, un élément de travail qui vous est attribué ou d’autres notifications. Cette adresse est également vérifiée pour la validité et, selon la configuration de votre serveur, il se peut que vous deviez représenter un compte de messagerie valide sur le serveur de messagerie. Si l’adresse n’existe pas ou n’est pas valide, l’adresse e-mail par défaut est utilisée.
SmtpHost	Spécifie le nom du serveur qui héberge le serveur de messagerie.

Prérequis

Pour utiliser la commande configureMail , vous devez être membre du groupe de sécurité Team Foundation Administrators sur le serveur de couche Application Azure DevOps. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server

Remarques

Vous pouvez également utiliser la console d’administration pour configurer Azure DevOps Server pour utiliser un serveur SMTP.

Exemple

L’exemple suivant montre la syntaxe utilisée pour configurer le à partir de l’adresse e-mail vers TFS@contoso.com et le serveur de messagerie SMTP comme ContosoMailServer:

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

---

DBCompression

Vous utilisez la commande dbCompression pour activer ou désactiver la compression des pages de base de données pour les bases de données utilisées par votre déploiement Azure DevOps Server.

TfsConfig dbCompression /pageCompression:[enable|disable]
	/sqlInstance:<serverName>
	/databaseName:<databaseName>
	[/rebuildNow [/offline]]

Option	Description
pageCompression	Spécifie si vous activez ou désactivez la compression de page pour la base de données et le instance SQL donnés.
sqlInstance	Spécifie le nom du serveur qui héberge la base de données pour laquelle la compression de page est activée ou désactivée, et le nom de la instance si une instance autre que la valeur par défaut est utilisée. Si vous spécifiez un instance, vous devez utiliser le format :ServerName\InstanceName
databaseName	Spécifie le nom de la base de données pour laquelle la compression de page est activée ou désactivée.
rebuildNow	facultatif. Spécifie si les index de base de données doivent être reconstruits (et compressés ou décompressés si nécessaire) immédiatement. S’ils ne sont pas utilisés, les index sont reconstruits par un travail en arrière-plan qui s’exécute chaque semaine.
hors connexion	facultatif. Utilisé uniquement en combinaison avec /rebuildNow. Si /offline n’est pas spécifié, les index sont reconstruits en ligne. Si /offline est spécifié, les index sont reconstruits hors connexion. Cela bloquera d’autres opérations, mais peut être plus rapide qu’une reconstruction d’index en ligne.

Prérequis

Pour utiliser la commande dbCompression, vous devez être membre du rôle sysadmin pour le SQL Server instance spécifié.

Remarques

Vous utilisez généralement la commande dbCompression si vous déplacez une base de données d’une instance SQL qui prend en charge la compression vers une base de données qui ne l’a pas prise en charge. Dans ce cas, vous devez désactiver la compression et décompresser tous les index avant de pouvoir déplacer correctement les bases de données. De même, si vous déplacez une base de données vers un instance SQL qui a pris en charge la compression, vous pouvez réactiver la compression afin d’économiser de l’espace.

Cette commande change uniquement si Azure DevOps Server préfère utiliser la compression de page de base de données ou non . Vos bases de données doivent toujours être hébergées dans un instance SQL dont l’édition prend en charge la compression. Pour plus d’informations, consultez Fonctionnalités prises en charge par les éditions de SQL Server.

Exemple

L’exemple suivant montre comment activer la compression de page immédiatement, avec la reconstruction des index en ligne, pour une base de données nommée TFS_DefaultCollection sur un instance SQL s’exécutant sur un serveur nommé ContosoMain sur le instance TeamDatabasesnommé .

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

---

DeleteTestResults

Vous utilisez la commande deleteTestResults pour supprimer d’anciens résultats de test stockés de votre magasin de collection. Cette opération est généralement effectuée pour réduire la taille du magasin ou pour réduire le temps nécessaire à la migration des résultats des tests vers un nouveau schéma.

TfsConfig deleteTestResults /ageInDays:<number> /sqlInstance:<serverName> /databaseName:<databaseName>
    [/type:[automated|manual|all]]
    [/preview]

Option	Description
ageInDays	Les résultats des tests antérieurs au nombre de jours spécifié sont supprimés ou prévisualisés.
sqlInstance	Nom du serveur qui héberge la base de données pour laquelle les résultats de test sont supprimés ou prévisualisés, et le nom du instance si une instance autre que la valeur par défaut est utilisée. Si vous spécifiez un instance, vous devez utiliser le format : ServerName\InstanceName.
databaseName	Nom de la base de données pour laquelle les résultats des tests sont supprimés ou prévisualisés.
type	facultatif. Type de résultats de test à supprimer. Les valeurs valides sont automatisées, manuelles et toutes.
preview	facultatif. Affichez le nombre de résultats de test qui seraient supprimés en fonction de l’âge en jours, mais ne supprimez pas ces résultats.

Prérequis

Pour utiliser la commande deleteTestResults, vous devez être membre du rôle sysadmin pour le SQL Server instance spécifié.

Remarques

Utilisez le paramètre /preview pour afficher les résultats des tests triés par nom de projet et par année sans supprimer ces résultats.

Exemple

L’exemple suivant montre comment supprimer des résultats de test manuels antérieurs à 60 jours pour une base de données nommée TFS_DefaultCollection sur un instance SQL s’exécutant sur un serveur nommé ContosoMain sur le instance TeamDatabasesnommé .

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

---

DeploymentPool

La commande deploymentPool est conçue pour migrer tous les groupes de déploiement d’un pool de déploiement vers un autre.

TfsConfig deploymentpool /migrateDeploymentGroups /fromPool:<source pool name> /toPool:<destination pool name>

Option	Description
fromPool	Nom du pool source.
toPool	Nom du pool de destination.

---

Identities

La commande identités répertorie ou modifie l’identificateur de sécurité (SID) des utilisateurs et des groupes dans votre déploiement de Azure DevOps Server. Vous devrez peut-être changer ou mettre à jour le SID pour les utilisateurs et les groupes dans l'un des scénarios suivants :

• Modification du domaine de votre déploiement

• Passage d’un groupe de travail à un domaine ou d’un domaine à un groupe de travail

• Migration de comptes entre domaines dans Active Directory

Notes

Vous n'avez pas besoin d'exécuter cette commande si vous modifiez des domaines dans la même forêt Active Directory. Azure DevOps Server gérera automatiquement les modifications de SID pour les déplacements au sein de la même forêt.

TfsConfig identities [/change /fromdomain:<domainName1> /todomain:<domainName2>
    [/account:<accountName> [/toaccount:<accountName>]] [/sqlInstance:<serverName> /databaseName:<databaseName>]

Option	Description
Modifier	Spécifie que vous pouvez modifier des identités au lieu de les répertorier.
fromdomain	Obligatoire lors de l’utilisation de /change. Spécifie le domaine d'origine des identités que vous souhaitez changer. Si vous changez à partir d'un environnement de groupe de travail, spécifie le nom de l'ordinateur.
todomain	Obligatoire lors de l’utilisation de /change. Spécifie le domaine pour lequel vous souhaitez modifier des identités. Si vous changez pour un environnement de groupe de travail, spécifie le nom de l'ordinateur.
account	Spécifie le nom d'un compte pour lequel vous souhaitez répertorier ou modifier des identités.
toaccount	Spécifie le nom d'un compte pour lequel vous souhaitez modifier des identités.
SQLInstance	Spécifie le nom du serveur qui exécute SQL Server et le nom du instance si vous souhaitez utiliser un instance autre que le instance par défaut. Si vous spécifiez une instance, vous devez utiliser le format suivant : nom_serveur\nom_instance
nom_base_de_données	Spécifie le nom de la base de données de configuration pour Azure DevOps Server.

Prérequis

Pour utiliser la commande identités, vous devez être membre du groupe de sécurité Administrateurs Team Foundation et membre du rôle sysadmin pour toutes les instances SQL Server utilisées par Team Foundation Server. Pour plus d’informations, consultez Définir les autorisations d’administrateur pour Azure DevOps Server.

Remarques

Vous pouvez spécifier éventuellement la base de données pour modifier des identités avant de configurer un serveur de couche Application pour le déploiement. Par exemple, vous pouvez spécifier la base de données pour modifier le compte de service lorsque vous clonez un déploiement de Azure DevOps Server.

Lorsque vous changez les identités, le ou les comptes cible doivent déjà exister dans Windows.

Vous devez attendre la synchronisation d'identité suivante avec Windows pour que les propriétés des comptes que vous modifiez avec cette commande soient mises à jour. Cette spécification inclut des modifications de groupe à utilisateur, d'utilisateur à groupe, et de compte de domaine à compte local.

Exemples

L’exemple suivant montre comment répertorier les noms de tous les utilisateurs et groupes Windows stockés dans Azure DevOps Server et indiquer si le SID de chaque utilisateur ou groupe correspond au SID dans Windows. Les administrateurs de domaine Contoso1 ont créé des groupes de domaines tels que Contoso1\\Developers et Contoso1\\Testers pour faciliter la gestion des autorisations sur les Azure DevOps Server, les SQL Server Reporting Services et les produits SharePoint.

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.

L’exemple suivant montre comment modifier les SID de tous les comptes dans Azure DevOps Server du domaine Contoso1 aux SID pour les comptes qui ont des noms correspondants dans le ContosoPrime domaine. Seuls les noms de compte qui correspondent auront leurs SID mis à jour. Par exemple, si le hholt compte existe en tant que Contoso1\hholt et ContosoPrime\hholt, le SID du compte sera remplacé par le SID pour ContosoPrime\hholt. Si le ContosoPrime\hholt compte n’existe pas, le SID n’est pas mis à jour pour Contoso1\hholt.

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

L’exemple suivant montre comment remplacer le compte d’un compte d’utilisateur unique, Contoso1\hholt, par le compte d’un autre compte d’utilisateur, ContosoPrime\jpeoples.

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

L’exemple suivant montre comment modifier le SID du compte de NT AUTHORITY\NETWORK SERVICE service utilisé dans le déploiement de Azure DevOps Server lors de la modification du domaine du déploiement en Contoso1ContosoPrime. Pour modifier un compte système tel que le Service réseau, vous devez suivre un processus à deux étapes. Vous remplacez d’abord le compte de service par un compte de NT AUTHORITY\NETWORK SERVICE domaine dans le nouveau domaine TempSVC, puis vous remplacez le compte par SERVICE RÉSEAU sur le serveur dans le nouveau domaine. La base de données de configuration est hébergée sur le serveur nommé ContosoMain sur le instance TeamDatabases nommé dans 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"

---

travaux

Vous pouvez utiliser la commande jobs pour créer un fichier journal qui fournit les détails de l’activité de travail la plus récente pour une collection de projets spécifique, ou pour réessayer un travail pour une ou toutes les collections de projets.

TfsConfig jobs /retry|dumplog [/CollectionName:<collectionName>] [/CollectionId:<id>]

Option	Description
retry	Obligatoire si /dumplog n’est pas utilisé. Spécifie que le travail le plus récent sera réintégé pour la collection de projets spécifiée. Si vous utilisez cette option, vous devez également utiliser l’option /CollectionName ou /CollectionID .
dumplog	Obligatoire si /retry n’est pas utilisé. Spécifie que l’activité de travail la plus récente pour la collection sera envoyée à un fichier journal. Si vous utilisez cette option, vous devez également utiliser l’option /CollectionName ou /CollectionID .
CollectionName	Obligatoire si /CollectionID n’est pas utilisé. Spécifie le nom de la collection pour laquelle le travail le plus récent sera retenté (/nouvelle tentative) ou journalisé (/dumplog). Si vous souhaitez spécifier toutes les collections, vous pouvez utiliser un astérisque (*).
CollectionID	Obligatoire si /CollectionName n’est pas utilisé. Spécifie le numéro d’identification de la collection pour laquelle le travail le plus récent sera retenté (/nouvelle tentative) ou journalisé (/dumplog).

Prérequis

Pour utiliser la commande jobs , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Pour réessayer un travail de manière interactive, vous pouvez ouvrir la console d’administration pour Azure DevOps, sélectionner l’onglet État de la collection, puis sélectionner Réessayer le travail. Pour plus d’informations, consultez Ouvrir la console d’administration Azure DevOps.

Exemple

L’exemple suivant montre comment créer un fichier journal qui répertorie l’activité de travail la plus récente pour la collection de Contoso Summer Intern Projects projets dans Azure DevOps Server.

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

---

OfflineDetach

Vous utilisez la commande offlineDetach pour transformer une base de données de collection hors connexion dans une base de données de collection hors connexion détachée.

TfsConfig offlineDetach /configurationDB:<databaseName>
    /collectionDB:<databaseName>

Option	Description
configurationDB	Spécifie le nom de la base de données de configuration à utiliser.
collectionDB	Spécifie le nom de la base de données de collection à détacher.

Prérequis

Pour utiliser la commande offlineDetach, vous devez être membre du rôle sysadmin pour le SQL Server instance spécifié.

Remarques

Cette commande modifie le schéma de la base de données de collection spécifiée et ne doit jamais être exécutée sur les bases de données utilisées par un déploiement Team Foundation Server. Si vos bases de données sont utilisées par un déploiement Team Foundation Server, utilisez TfsConfig collection /detach à la place.

Cette commande est utile lorsque vous devez restaurer une base de données de collection individuelle à partir d’une sauvegarde sans restaurer d’autres bases de données de collection qui font partie du même déploiement Azure DevOps Server. Auparavant, cela nécessitait la restauration d’un ensemble complet et cohérent de bases de données (configuration et toutes les collections) dans un environnement intermédiaire, la configuration d’un déploiement Azure DevOps Server à l’aide de ces bases de données et le détachement de la collection d’intérêts.

Au lieu de cela, vous pouvez maintenant restaurer des copies cohérentes de la base de données de configuration et de la base de données de collection intéressante et exécuter la commande offlineDetach . La base de données de collection détachée peut ensuite être attachée à n’importe quel déploiement Azure DevOps Server à une version appropriée.

Exemple

L’exemple suivant illustre le détachement d’une base de données de collection nommée TFS_PrimaryCollection, à l’aide d’une base de données de configuration nommée TFS_Configuration, avec à la fois sur un instance SQL s’exécutant sur un serveur nommé ContosoTemp sur le instance Backupsnommé .

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

---

Proxy

Vous pouvez utiliser la commande proxy pour mettre à jour ou modifier les paramètres utilisés par le serveur proxy Azure DevOps. Le serveur proxy Azure DevOps prend en charge les équipes distribuées pour utiliser le contrôle de version en gérant un cache de fichiers de contrôle de version téléchargés à l’emplacement de l’équipe distribuée. En configurant le serveur proxy Azure DevOps, vous pouvez réduire considérablement la bande passante nécessaire entre les connexions étendues. De plus, vous n'avez pas à gérer le téléchargement ni la mise en cache des fichiers de version ; la gestion des fichiers est transparente pour le développeur qui utilise les fichiers. Pendant ce temps, les échanges de métadonnées et les chargements de fichiers continuent d’apparaître dans Azure DevOps Server. Si vous utilisez le Azure DevOps Services pour héberger votre projet de développement dans le cloud, vous pouvez utiliser la commande Proxy non seulement pour gérer le cache des projets de la collection hébergée, mais également pour gérer certains des paramètres utilisés par ce service.

Pour plus d’informations sur l’installation du serveur proxy Azure DevOps et la configuration initiale du proxy,

Consultez Guide pratique pour installer le serveur proxy Azure DevOps et configurer un site distant. Pour plus d’informations sur la configuration du proxy sur les ordinateurs clients, consultez Informations de référence sur les commandes de contrôle de version Azure DevOps.

TfsConfig proxy /add|delete|change [/Collection:<teamProjectCollectionURL> /account:<accountName>]
	/Server:<TeamFoundationServerURL> [/inputs:Key1=Value1; Key2=Value2;...] [/continue]

Option	Description
add	Ajoute le serveur ou la collection spécifié(e) à la liste du proxy du fichier Proxy.config. Vous pouvez exécuter la commande /add plusieurs fois pour inclure davantage de collections ou de serveurs. Lorsque vous utilisez /add avec une collection hébergée sur Azure DevOps Services, vous êtes invité à entrer vos informations d’identification sur Azure DevOps Services.
Modifier	Modifie les informations d’identification stockées en tant que compte de service pour Azure DevOps Services. L’option /change est utilisée uniquement pour Azure DevOps Services ; elle ne doit pas être utilisée pour les déploiements locaux de Azure DevOps Server.
supprimer	Supprime le serveur ou la collection spécifié(e) de la liste de proxy dans le fichier Proxy.config.
account	Spécifie le compte utilisé comme compte de service pour le proxy dans Azure DevOps Services. Cette option est utilisée uniquement pour Azure DevOps Services conjointement avec l’option /change. Le compte de service par défaut utilisé pour Azure DevOps Services est « Service de compte ».
continue	Reprend l'exécution de la commande même si le processus de vérification produit des avertissements.
Collection	Spécifie l’URL de la collection de projets hébergée sur Azure DevOps Services, au AccountName.DomainName/CollectionName format.
account	Spécifie le nom du compte utilisé comme compte de service pour Azure DevOps Services. Si le nom du compte a des espaces, il doit être placé entre guillemets (""). Tous les caractères spéciaux dans les noms du compte doivent être spécifiés conformément à la syntaxe de ligne de commande.
account	Spécifie l’URL d’un déploiement Azure DevOps Server, au ServerURL:Port/tfs format .
PersonalAccessTokenFile	Spécifie éventuellement le chemin d’accès à un fichier qui contient un jeton d’accès personnel. Ce jeton sera utilisé pour s’authentifier auprès de la collection ou du compte lors de l’inscription d’un proxy. (Ajouté dans TFS 2018 Update 1)
inputs	facultatif. Spécifie des paramètres et des valeurs supplémentaires à utiliser lors de la configuration du proxy. ! Par exemple, les valeurs de GvfsProjectName et GvfsRepositoryName peuvent être utilisées pour configurer un dépôt Git à utiliser avec Git Virtual File System (GVFS) (ajouté dans TFS 2018 Update 1)

Prérequis

Pour utiliser la commande proxy , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps et administrateur sur le serveur proxy. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Vous utilisez la commande proxy pour mettre à jour la configuration existante de Azure DevOps Server Proxy. Vous ne pouvez pas utiliser la commande proxy pour l’installation initiale et la configuration du proxy.

Exemples

L’exemple suivant montre comment ajouter un déploiement Azure DevOps Server nommé FABRIKAM à la liste des proxys.

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

L’exemple suivant montre comment ajouter une collection de projets hébergée sur Azure DevOps Services à la liste de proxys à l’aide d’un jeton d’accès personnel pour l’authentification. Ce jeton sera utilisé uniquement pour inscrire le proxy auprès du compte Azure DevOps Services . Le compte de service par défaut sera toujours utilisé pour exécuter le proxy. Ce paramètre a été ajouté dans TFS 2018 Update 1 pour prendre en charge l’inscription d’un proxy auprès de Azure DevOps Services sans nécessiter d’invite de connexion.

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

L’exemple suivant montre comment ajouter une collection de projets à la liste des proxys. Cet exemple utilise un jeton d’accès personnel pour s’authentifier auprès de la collection spécifiée avec le /Collection paramètre . Le jeton d’accès personnel à utiliser est enregistré dans un fichier à l’adresse c:\PersonalAccessToken.txt.

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

L’exemple suivant montre comment modifier le compte de service utilisé par le proxy pour la collection de projets hébergée sur Azure DevOps Services. La collection est nommée PhoneSaver, le nom du compte utilisé pour Azure DevOps Services est HelenaPetersen.fabrikam.comet le compte de service utilisé par le proxy est remplacé My Proxy Service Accountpar . Étant donné que le nom du compte contient des espaces, il est entouré par des guillemets.

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

L’exemple suivant montre comment ajouter un référentiel Git à utiliser avec GVFS.

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

---

RebuildWarehouse

Vous pouvez utiliser la commande rebuildWarehouse pour reconstruire les bases de données SQL Server Reporting Services et SQL Server Analysis Services que Azure DevOps Server utilise.

TfsConfig rebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]

Option	Description
analysisServices	Obligatoire si /all n’est pas utilisé. Spécifie que seule la base de données pour Analysis Services sera régénérée. S’il n’existe aucune base de données pour Analysis Services, vous devez également utiliser l’option /reportingDataSourcePassword .
all	Obligatoire si /analysisServices n’est pas utilisé. Spécifie que toutes les bases de données de création de rapports et d’analyse que Azure DevOps Server utilisent seront reconstruites.
reportingDataSourcePassword	Obligatoire si la base de données TFS_Analysis n'existe pas. Spécifie le mot de passe du compte utilisé comme compte de sources de données pour SQL Server Reporting Services (TFSReports). Pour plus d’informations, consultez Comptes de service et dépendances dans Azure DevOps Server.

Prérequis

Pour utiliser la commande rebuildWarehouse , vous devez être membre des groupes suivants :

• Le groupe de sécurité Administrateurs Azure DevOps et le groupe de sécurité Administrateurs sur le serveur ou les serveurs qui exécutent la console d’administration pour Azure DevOps

• Le groupe sysadmin sur le serveur ou les serveurs qui exécutent le instance de SQL Server qui héberge les bases de données pour Azure DevOps Server

Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Vous pouvez utiliser cette commande lors du déplacement ou du fractionnement d’une collection de projets, de la restauration des données ou de la modification de la configuration de votre déploiement.

Pour démarrer la reconstruction de ces bases de données de manière interactive, vous pouvez utiliser le nœud Création de rapports dans la console d’administration pour Azure DevOps. Pour plus d’informations, consultez Ouvrir la console d’administration Azure DevOps.

Exemple

L’exemple suivant montre comment reconstruire la base de données Analysis Services pour un déploiement de 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

Utilisez registerDB pour mettre à jour le nom du serveur qui héberge la base de données de configuration dans Azure DevOps Server. Vous pouvez utiliser cette commande lors de la restauration de la base de données de configuration sur un nouveau matériel ou lors de la modification du domaine d'un déploiement.

TfsConfig registerDB /sqlInstance:<serverName> /databaseName:<databaseName>

Option	Description
SQLInstance	Obligatoire. Spécifie le nom du serveur qui exécute SQL Server et le nom du instance si vous souhaitez utiliser un instance autre que le instance par défaut. Si vous spécifiez un instance, vous devez utiliser le format : ServerName\InstanceName.
databaseName	Obligatoire. Spécifie le nom de la base de données de configuration. Par défaut, il s'agit de Tfs_Configuration.

Prérequis

Pour utiliser la commande registerDB, vous devez être membre du groupe Administrateurs Azure DevOps sur le serveur de la couche Application pour Azure DevOps et membre du groupe sysadmin dans SQL Server sur le serveur de la couche Données pour Azure DevOps. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Sauvegardez les bases de données pour Azure DevOps Server avant d’utiliser cette commande.

Pour que la commande registerDB réussisse, les pools d’applications et les programmes suivants doivent être en cours d’exécution :

• pool d’applications Azure DevOps Server (pool d’applications)
• ReportServer (pool d'applications)
• SQL Server Reporting Services (programme)

Vous devez fournir le nom ou l'adresse exact(e) de la base de données de configuration pour que cette commande puisse fonctionner correctement. Si vous devez modifier le serveur sur lequel cette base de données est stockée, vous devez vous assurer que Azure DevOps Server pointe vers le nouvel emplacement.

Exemple

L’exemple suivant redirige Azure DevOps Server vers une base de données de configuration qui se trouve sur le serveur ContosoMain dans le SQL Server instance TeamDatabases.

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

---

Remappage de bases de données

La commande remappage des bases de données redirige les Azure DevOps Server vers ses bases de données lorsqu’elles sont stockées sur plusieurs serveurs et que vous restaurez, déplacez ou modifiez la configuration de votre déploiement. Par exemple, vous devez rediriger les Azure DevOps Server vers les bases de données pour les collections de projets si elles sont hébergées sur un ou plusieurs serveurs distincts de la base de données de configuration. Vous devez également rediriger Azure DevOps Server vers le ou les serveurs qui exécutent SQL Server Analysis Services ou SQL Server Reporting Services si ces bases de données sont hébergées sur un serveur distinct ou instance de la base de données de configuration.

TfsConfig remapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,ServerName2
	[/AnalysisInstance:<serverName>] [/AnalysisDatabaseName:<databaseName>]
	[/preview] [/continue]

Option	Description
nom_base_de_données	Spécifie le nom du serveur qui héberge la base de données que vous souhaitez mapper pour Azure DevOps Server, en plus du nom de la base de données elle-même.
SQLInstances	Spécifie le nom du serveur qui exécute SQL Server, en plus du nom du instance si vous souhaitez utiliser un instance autre que le instance par défaut. Si vous spécifiez plusieurs serveurs, vous devez utiliser une virgule pour séparer plusieurs paires de noms de serveurs et de instance.
AnalysisInstance	facultatif. Spécifie le nom du serveur et des instance qui hébergent SQL Server Analysis Services. Utilisez cette option pour spécifier le serveur et les instance qui hébergent la base de données Analysis Services.
AnalysisDatabaseName	facultatif. Spécifie le nom de la base de données Analysis Services que vous souhaitez utiliser avec Azure DevOps Server si vous avez plusieurs bases de données de ce type sur le serveur que vous avez spécifiées avec l’option /AnalysisInstance.
preview	facultatif. Affiche les actions que vous devez effectuer pour mettre à jour la configuration.
continue	facultatif. Spécifie que la commande RemapDB doit continuer même si une erreur se produit pendant la tentative de localisation d’une ou plusieurs bases de données. Si vous utilisez l’option /continue, tous les regroupements dont les bases de données sont introuvables sur le serveur ou les serveurs que vous spécifiez sont reconfigurés pour utiliser le serveur et instance qui héberge la base de données de configuration.

Prérequis

Pour utiliser la commande remappageDBs, vous devez être membre du groupe de sécurité Administrateurs Azure DevOps et membre du groupe de sécurité sysadmin pour toutes les bases de données SQL Server que Azure DevOps Server utilise. Pour plus d’informations, consultez Informations de référence sur les autorisations pour Azure DevOps Server.

Remarques

Vous utilisez la commande remappage de bases de données pour reconfigurer Azure DevOps Server pour utiliser différents serveurs et instances de SQL Server à partir des serveurs et des instances de l’installation d’origine.

Exemple

L’exemple suivant montre comment rediriger Azure DevOps Server vers sa base de données de TFS_Configurationconfiguration . Cette base de données est hébergée sur ContosoMain le instance TeamDatabasesnommé . Ses bases de données de collection de projets sont stockées sur les deux ContosoMain\TeamDatabases et la instance par défaut sur Contoso2.

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

---

RepairJobQueue

Vous utilisez la commande repairJobQueue pour corriger les travaux planifiés qui ont cessé de s’exécuter pour les hôtes de déploiement et de collecte.

TfsConfig repairJobQueue

Prérequis

Pour utiliser la commande repairJobQueue , vous devez être membre du groupe Administrateurs locaux sur l’ordinateur exécutant TfsConfig. Vous devez également être membre du rôle de sécurité sysadmin pour toutes les instances SQL Server utilisées par le déploiement Azure DevOps Server.

Remarques

Vous utilisez généralement la commande repairJobQueue si vous remarquez que des travaux planifiés ne sont pas en cours d’exécution.
La commande ne prend aucun argument et nécessite la configuration du déploiement Azure DevOps Server.

Exemple

TfsConfig repairJobQueue

---

Paramètres

Vous pouvez utiliser la commande settings pour automatiser les modifications apportées à l’URL (Uniform Resource Locator) utilisée par l’interface de notification et pour l’adresse du serveur pour Azure DevOps Server. Par défaut, l’URL de l’interface de notification et l’URL du serveur correspondent dans Azure DevOps Server, mais vous pouvez configurer des URL distinctes. Par exemple, vous souhaiterez peut-être utiliser une URL différente pour les e-mails automatiques générés par Azure DevOps Server. Vous devez exécuter cet outil à partir de la couche Application pour mettre à jour tous les serveurs afin qu'ils utilisent les nouvelles URL.

Pour modifier ces URL de manière interactive ou simplement afficher les paramètres actuels, vous pouvez utiliser la console d’administration pour Azure DevOps. Consultez Informations de référence rapides sur les tâches d’administration.

TfsConfig settings [/publicURL:URL]

Option	Description
publicUrl	Spécifie l’URL du serveur de la couche Application pour Azure DevOps. Cette valeur est stockée dans la base de données de configuration pour Azure DevOps.

Prérequis

Vous devez être membre du groupe de sécurité Administrateurs Azure DevOps et du groupe Administrateurs sur le serveur de la couche Application. Pour plus d’informations, consultez Définir des autorisations d’administrateur pour Azure DevOps Server.

Remarques

La commande settings modifie les informations de connexion pour la communication de serveur à serveur dans un déploiement de Azure DevOps Server. L’URL spécifiée dans /publicURL doit être disponible pour tous les serveurs au sein du déploiement.

Exemple

L’exemple suivant change la valeur de NotificationURL en http://contoso.example.com/tfs et la valeur de ServerURL en http://contoso.example.com:8080/tfs.

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

---

Programme d’installation

Vous utilisez la commande d’installation pour désinstaller les fonctionnalités actuellement configurées sur l’ordinateur sur lequel vous exécutez la commande.

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

Option

Description

/uninstall

Spécifie une ou plusieurs fonctionnalités à désinstaller de l’ordinateur sur lequel vous exécutez la commande. Les options sont les suivantes : All, ApplicationTier, Recherche et VersionControlProxy.

Prérequis

Pour utiliser la commande d’installation , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps.

Exemples

L’exemple suivant désinstalle toutes les fonctionnalités Azure DevOps Server de l’ordinateur actuel.

TfsConfig setup /uninstall:All

L’exemple suivant désinstalle la couche Application et crée des fonctionnalités de l’ordinateur actuel.

TfsConfig setup /uninstall:ApplicationTier 

---

TCM

Lors de la mise à niveau vers la dernière version de Azure DevOps Server, le système tente automatiquement de mettre à niveau les composants de gestion des tests, y compris les plans de test et les suites.

Si la migration automatique échoue, utilisez la commande TCM pour mettre à niveau manuellement vos plans de test et vos suites de tests vers leurs types d’éléments de travail respectifs (WIT).

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

Option

Description

/upgradeTestPlans

Obligatoire, sauf si /upgradeStatus est utilisé.

Convertit les plans de test et les suites de test existants de façon à ce qu'ils pointent vers des plans de test et des suites de tests basés sur des éléments de travail. Il met également à jour les données de gestion de test existants et les liens entre d'autres artefacts de test tels que les points de test, les séries de tests et les résultats des tests.

/upgradeStatus

Obligatoire, sauf si /upgradeTestPlans est utilisé.

Signale la migration status de données de test pour le projet spécifié. Il indique également si le projet spécifié comprend des plans de test.

/CollectionName :CollectionName

Obligatoire. Spécifie la collection de projets qui contient le projet pour lequel vous souhaitez migrer des données de test ou case activée le status de migration.

S’il existe des espaces dans le nom de la collection de projets, placez le nom entre guillemets, par exemple« Fabrikam Fiber Collection ».

/TeamProjectName :TeamProjectName

Obligatoire. Spécifie le projet pour lequel vous souhaitez migrer des données de test ou case activée le status de migration. Ce projet doit être défini dans la collection que vous avez spécifiée à l’aide du paramètre /collectionName .

S’il existe des espaces dans le nom du projet, placez le nom entre guillemets, par exemple « Mon projet ».

Prérequis

Vous devez être membre du groupe de sécurité Team Foundation Administrators et administrateur sur le serveur de couche Application.

Consultez Définir des autorisations d’administrateur pour Azure DevOps Server.

Remarques

Votre serveur de la couche Application doit être mis à niveau vers la dernière version de Azure DevOps Server 2019 pour utiliser cette commande.

Avant de pouvoir utiliser la commande TCM, vous devez d'abord importer la définition des éléments de travail du plan de test et la catégorie de plan de test dans le projet.

Pour en savoir plus sur la migration et savoir quand utiliser cette commande, consultez Mises à jour manuelles pour prendre en charge la gestion des tests.

La commande TCM est appliquée à des projets individuels. Si vous devez mettre à niveau des plans de test dans plusieurs projets, vous devrez les exécuter sur chaque projet individuellement.

Vous devez exécuter la commande TCM à partir du répertoire tools pour Azure DevOps Server. Par défaut, cet emplacement est : drive:\%programfiles%\TFS 12.0\Tools.

Vous utilisez la commande TCM uniquement en cas d’échec de la migration automatique des données de test existantes.

Pour en savoir plus sur la migration et quand utiliser cette commande, consultez Mises à jour manuelles pour prendre en charge la gestion des tests. Si vous ne pouvez pas accéder aux plans de test ou aux suites de tests qui ont été définis avant la mise à niveau du serveur, exécutez TFSConfig TCM upgradeStatus pour déterminer la status de la migration.

Vous exécutez la commande TCM pour un projet individuel. Si vous devez mettre à niveau plusieurs projets, vous devrez l’exécuter sur chaque projet à son tour.

Exemples

L’exemple suivant montre comment case activée le status de mise à niveau du plan de test sur le projet Fabrikam Fiber hébergé sur la collection de projets par défaut (DefaultCollection) :

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

---

Sans assistance

Disponibilité des commandes : Azure DevOps Server 2019

La commande unattend est conçue pour les utilisateurs familiarisés avec Azure DevOps Server et le processus de configuration, et qui doivent installer Azure DevOps Server sur différents ordinateurs.

Par exemple, si vous utilisez Azure DevOps Build, vous pouvez utiliser la commande unattend pour installer plusieurs serveurs de build à l’aide du même fichier de configuration.

Utilisez l’option /create pour créer un fichier sans assistance. Ce fichier définit tous les paramètres de configuration d’une installation Azure DevOps Server. Ensuite, utilisez l’option /configure pour effectuer la configuration.

Ce processus vous permet de configurer Azure DevOps Server du début à la fin sans avoir à fournir d’entrée pendant le processus d’installation. En cas d'installations multiples, vous avez aussi la garantie d'utiliser les mêmes paramètres de configuration sur tous les serveurs.

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

Option	Description
create	Crée le fichier d'installation sans assistance avec le nom et les paramètres spécifiés.
CONFIGURER	Configure Azure DevOps Server à l’aide du fichier sans assistance et des paramètres que vous spécifiez. Vous devez utiliser /type ou /unattendfile avec cette option.
type	Spécifie le type de configuration à utiliser. L'utilisation de /configure nécessite soit /type, soit /unattendfile, mais pas les deux.
unattendfile	Spécifie le fichier d'installation sans assistance à créer ou à utiliser selon que le paramètre initial est /create ou /configure. L'utilisation de /configure nécessite soit /unattendfile, soit /type.
inputs	facultatif. Si vous utilisez /create, spécifie les paramètres et les valeurs à utiliser lors de la création du fichier d'installation sans assistance. Si vous utilisez /configure, spécifie les paramètres et les valeurs supplémentaires à utiliser conjointement avec le fichier d'installation sans assistance. Au lieu d'utiliser /inputs, vous pouvez modifier manuellement le fichier d'installation sans assistance dans un éditeur de texte brut. Cela est nécessaire pour certains types d’entrée, tels que ServiceAccountPassword ou PersonalAccessToken, car ces valeurs secrètes ne peuvent pas être définies à l’aide du paramètre /input.
verify	facultatif. Spécifie une passe de configuration qui procède uniquement aux contrôles de vérification en fonction du fichier autonome, des entrées et du type de configuration. Cela peut éviter de devoir effectuer une configuration complète.
continue	facultatif. Spécifie que /create ou /configure doivent continuer en dépit des avertissements des contrôles de vérification.

InstallType (type d'installation)	Description
NewServerBasic	Configure les services de développement essentiels pour Azure DevOps Server. Cela inclut le contrôle de code source, les éléments de travail, la génération et éventuellement Recherche.
NewServerAdvanced	Configure les services de développement essentiels et autorise la configuration facultative de l’intégration à Reporting Services.
Mettre à niveau	Les mises à niveau Azure DevOps Server vers la version actuelle à partir d’une version précédente prise en charge.
PreProductionUpgrade	Testez la mise à niveau sur un déploiement Azure DevOps Server existant dans un environnement de préproduction. Cette opération est généralement effectuée à l’aide de bases de données restaurées à partir de sauvegardes de production. Ce scénario comprend des étapes supplémentaires pour s’assurer que le nouveau déploiement n’interfère pas avec le déploiement de production.
ApplicationTierOnlyBasic	Configurez une nouvelle couche Application à l’aide des paramètres existants de la base de données de configuration fournie. Cette option vous permet d’obtenir rapidement une nouvelle couche d’application en utilisant des paramètres existants. Si vous souhaitez pouvoir modifier les paramètres existants, utilisez plutôt le type Advanced ApplicationTierOnlyAdvanced.
ApplicationTierOnlyAdvanced	Configurez une nouvelle couche Application avec un contrôle total sur tous les paramètres. Les paramètres sont définis par défaut sur les valeurs existantes de la base de données de configuration fournie. Si vous souhaitez conserver tous vos paramètres existants, utilisez le type ApplicationTierOnlyBasic à la place.
Clone	Configurez un nouveau déploiement Azure DevOps Server qui est un clone d’un déploiement existant. Cette opération est généralement effectuée à l’aide de bases de données restaurées à partir de sauvegardes de production, pour créer un environnement dans lequel les modifications de configuration, les extensions et d’autres modifications peuvent être testées. Ce scénario comprend des étapes supplémentaires pour s’assurer que le nouveau déploiement n’interfère pas avec le déploiement de production.
Proxy	Configure un service proxy de contrôle de version.

Prérequis

• Vous devez être membre du groupe Administrateurs sur l'ordinateur sur lequel vous installez le logiciel.

• Selon le type d'installation, il est possible que vous deviez disposer d'autorisations d'administrateur supplémentaires.

Par exemple, si vous utilisez la commande unattend pour installer Azure DevOps Server , vous devez être membre du groupe sysadmin sur le instance de SQL Server qui prend en charge Azure DevOps Server. Pour plus d’informations, consultez la section Q & A de l’article Ajouter des administrateurs au niveau du serveur à Azure DevOps Server.

Remarques

Avant de pouvoir utiliser la commande unattend pour configurer Azure DevOps Server, vous devez créer les comptes de service que vous utiliserez dans le cadre de votre déploiement. Vous devez aussi installer les logiciels requis pour votre type d'installation, Cela inclut Azure DevOps Server lui-même. Vous devez installer Azure DevOps Server, mais vous n’avez pas besoin de le configurer, car la commande unattend le fera pour vous.

La commande unattend configure Azure DevOps Server composants. Elle n'assure pas l'installation initiale du logiciel. Elle configure le logiciel selon vos spécifications une fois les bits présents sur l'ordinateur.

Exemples

L’exemple suivant montre comment créer un fichier sans assistance pour une installation de base de Azure DevOps Server.

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

Dans cet exemple, le fichier d'installation sans assistance est créé dans le même répertoire que la commande. Un fichier journal est créé dans le cadre de la commande, et l'emplacement du fichier est retourné dans la commande dans le cadre de son exécution.

L’exemple suivant montre comment spécifier un référentiel Git à utiliser avec GVFS pendant la configuration.

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

L’exemple suivant montre comment créer un fichier sans assistance pour la configuration d’un serveur proxy Azure DevOps.

Important

Dans cet exemple, si les administrateurs souhaitent utiliser un jeton d’accès personnel pour l’authentification, ils doivent modifier manuellement le fichier pour spécifier la valeur du jeton d’accès personnel. Pour ce faire, ajoutez une ligne pour le jeton d’accès personnel dans le fichier sans assistance créé, comme : PersonalAccessToken=PersonalAccessTokenValue.

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

L’exemple suivant montre comment créer un fichier sans assistance pour la configuration de Azure DevOps Server Générer sur un serveur en utilisant FabrikamFiber\BuildSVC comme compte de service de build, puis configurer Azure DevOps Server Build à l’aide de ce fichier sans assistance.

Important

Dans cet exemple, une fois le fichier d'installation sans assistance créé, l'administrateur modifie manuellement ce fichier pour spécifier le mot de passe du compte de service de build. L’ajout du mot de passe en tant qu’entrée à l’aide ServiceAccountPassword=Password; de n’ajoute pas les informations de mot de passe au fichier.

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

TfsConfig unattend /configure /unattendfile:configTFSBuild.ini

La première commande retourne ce qui suit :

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

La deuxième commande retourne les informations suivantes, notamment le nom du serveur où Azure DevOps Build a été configuré FabrikamFiberTFS et la collection de projets associée au contrôleur 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

La commande ziplogs est conçue pour collecter les journaux et supprime un zip à l’emplacement ProgramData\Microsoft\Azure DevOps\Server Configuration.

TfsConfig zipLogs

TfsConfig zipLogs

---