Utiliser TFSConfig pour gérer Azure DevOps en local

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]

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.

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.

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

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]

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

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]

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

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,...]]

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

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é.

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

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

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

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"

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]

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

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>

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

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

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

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]

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

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>

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

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

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"

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

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"

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>

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

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]

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

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]

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.

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>

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

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]

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

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

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]

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

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

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"

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]

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.

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.

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

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