Utiliser TFSConfig pour gérer Azure DevOps localement

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

• le compte de service Azure DevOps Server
• les sources de données prises en charge par SQL Server Reporting Services
• le compte de service du serveur proxy Azure DevOps

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 être utilisés lors de l’ajout d’un compte aux bases de données avant la configuration de la couche Application. Cela est principalement utile dans des scénarios de reprise après sinistre où il est nécessaire d'avoir un autre compte avant d'exécuter l'Assistant de 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 collecte. Si l'option continue est fournie, le processus se poursuivra si une collection est inaccessible. Il peut être réexécuter lorsqu’ils sont accessibles.

Conditions préalables

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

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

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

Pour plus d’informations, consultez Référence d’autorisation pour Azure DevOps Server.

Remarques

Utilisez la commande comptes pour automatiser les modifications apportées aux comptes de service, aux bases de données et aux groupes de comptes de service d’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 avoir l'autorisation "Le compte est sensible et ne peut pas être délégué" sur le serveur de niveau d'application. Pour plus d’informations, consultez cette page sur le site Web Microsoft : activation de l’authentification déléguée.

La commande comptes prend en charge les déploiements locaux d’Azure DevOps Server. 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 de système de service réseau aux groupes de comptes de service pour Azure DevOps Server (les comptes système n’ont pas de mots de passe).

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

Modifiez la propriété de la base de données TFS_Warehouse sur le Serveur SQL ContosoMain dans l’instance nommée TeamDatabases vers 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]

Conditions préalables

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 quand :

• 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 des rapports dans votre projet avec 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 d’effectuer cette opération.

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

Exemple :

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

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

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

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

Conditions préalables

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

Remarques

La commande d’authentification 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 ces sites web qui nécessitent une modification de leur protocole d’authentification réseau. La commande modifie la propriété NTAuthenticationProviders dans la métabase IIS.

Avant d’utiliser la commande d’authentification 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 affiche la valeur actuelle affectée pour le protocole d’authentification réseau.

TFSConfig Authentication /viewAll

Utilisez la commande certificats pour modifier la configuration des certificats pour l’authentification du client dans un déploiement d’Azure DevOps Server qui utilise HTTPS, ssl (Secure Sockets Layer) et des certificats.

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

Conditions préalables

Pour utiliser la commande certificats , 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 Référence d’autorisation 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 certificat ou des 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 d’Azure DevOps Server pour utiliser des certificats. Pour plus d’informations, consultez Configuration du protocole 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 d’Azure DevOps Server 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 de la machine locale qui a l'empreinte numérique aa bb cc dd ee sans demande de confirmation.

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

L’exemple suivant montre comment spécifier l’utilisation 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 au sein d’un déploiement d’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 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 pour 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 le déplacer vers un autre déploiement pour lequel ce GUID est déjà réservé.

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

Conditions préalables

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 utilisées par Azure DevOps Server. Pour plus d’informations, consultez Référence d’autorisation pour Azure DevOps.

Remarques

Vous utilisez la commande changeServerID pour créer un doublon discret d’un déploiement d’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 d’Azure DevOps Server, où la base de données de configuration est hébergée sur le serveur nommé ContosoMain sur l’instance TeamDatabases nommée 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 les informations CodeLens ou désactiver l’indexation pour examiner 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>]

Conditions préalables

Pour utiliser la commande codeIndex , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps. Consultez la référence d’autorisation pour Azure DevOps Server.

Exemples

Pour afficher l’état et la configuration de l’indexation du code :

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

Pour commencer à indexer tous les ensembles de modifications :

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

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

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

Pour rechercher 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 de fichiers ignorée :

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 sauvegarder l'historique de tous les dossiers de modification :

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

Pour supprimer la limite de taille des données temporaires CodeLens et continuer l’indexation, quelle que soit 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 de collection pour attacher, détacher ou supprimer une collection de projets à partir d’un déploiement d’Azure DevOps Server. Vous pouvez également utiliser la commande de 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]

Conditions préalables

Pour utiliser la commande collections , vous devez être membre du groupe de sécurité Administrateurs Team Foundation, ainsi que du groupe Administrateurs local sur l’ordinateur 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 les bases de données Azure DevOps Server. 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 Référence d’autorisation pour Azure DevOps Server.

Remarques

Pour gérer les regroupements de manière interactive ou pour créer une collection, vous pouvez utiliser le nœud Regroupements de projets 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 d’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 Contoso Winter Interns Projectsnommer et attacher la collection en double au déploiement d’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>

Conditions préalables

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

Remarques

Vous utiliseriez généralement la commande columnStoreIndex si vous déplaciez une base de données depuis une instance SQL qui prenait en charge l'index de stockage en colonnes vers une instance qui ne le fait pas. Dans ce cas, vous devez désactiver tous les indexes de stockage en colonnes avant de pouvoir déplacer les bases de données avec succès. De même, si vous déplacez une base de données vers une instance SQL qui prend en charge l’index de magasin de colonnes, vous souhaiterez peut-être réactiver l’index de magasin de colonnes afin d’économiser de l’espace et d’obtenir des 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 une instance SQL exécutée sur un serveur nommé ContosoMain sur l'instance nommée TeamDatabases.

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

Vous utilisez la commande dbCompression pour activer ou désactiver la compression de page 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]]

Conditions préalables

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

Remarques

Vous utilisez généralement la commande dbCompression si vous déplacez une base de données à partir d’une instance SQL qui a pris en charge la compression vers une instance qui ne l’a pas fait. 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 une instance SQL qui a pris en charge la compression, vous souhaiterez peut-être 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 une 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 immédiatement la compression de page, avec des index reconstruits en ligne, pour une base de données nommée TFS_DefaultCollection sur une instance SQL s’exécutant sur un serveur nommé ContosoMain sur l’instance TeamDatabasesnommée .

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

Vous utilisez la commande deleteTestResults pour supprimer les anciens résultats de test stockés de votre magasin de collections. Cela est généralement fait pour réduire la taille du magasin ou pour réduire le temps nécessaire lors de 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]

Conditions préalables

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

Remarques

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

Exemple :

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

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>

Les commandes identités répertorient ou modifient l’identificateur de sécurité (SID) des utilisateurs et des groupes dans votre déploiement d’Azure DevOps Server. Vous devrez peut-être modifier 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 des domaines dans Active Directory

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

Conditions préalables

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 des autorisations d’administrateur pour Azure DevOps Server.

Remarques

Vous pouvez éventuellement spécifier la base de données pour modifier les 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 d’Azure DevOps Server.

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

Vous devez attendre la prochaine synchronisation d’identité avec Windows avant que les propriétés des comptes que vous modifiez avec cette commande soient mises à jour. Cette exigence inclut les modifications du groupe à l’utilisateur, de l’utilisateur au groupe et du compte de domaine au 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 d’afficher si le SID pour 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 Azure DevOps Server, 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 compte hholt existe en tant que Contoso1\hholt et ContosoPrime\hholt, le SID du compte sera modifié vers 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 changer le compte d’un utilisateur unique, Contoso1\hholt, pour le compte d’un autre 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 d’Azure DevOps Server lors de la modification du domaine du déploiement Contoso1 vers ContosoPrime. Pour modifier un compte système tel que le service réseau, vous devez suivre un processus en deux étapes. Vous commencez par changer le compte de service de NT AUTHORITY\NETWORK SERVICE vers un compte de domaine dans le nouveau domaine TempSVC, puis vous changez à nouveau vers NETWORK SERVICE sur le serveur dans le nouveau domaine. La base de données de configuration est hébergée sur le serveur nommé ContosoMain sur l’instance TeamDatabases nommée 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 travaux 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>]

Conditions préalables

Pour utiliser la commande travaux , vous devez être membre du groupe de sécurité Administrateurs Azure DevOps. Pour plus d’informations, consultez Référence d’autorisation pour Azure DevOps Server.

Remarques

Pour réessayer de façon 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 créer une base de données de collection hors connexion en une base de données de collection hors connexion détachée.

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

Conditions préalables

Pour utiliser la commande offlineDetach :

• Vous devez être membre du rôle sysadmin pour l’instance SQL Server spécifiée.
• La version de l’outil TFSConfig doit correspondre à la version de la base de données Azure DevOps Server.

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 des bases de données qui sont utilisées par un déploiement Azure DevOps Server. Si vos bases de données sont utilisées par un déploiement Azure DevOps Server, utilisez TfsConfig collection /detach plutôt.

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

Au lieu de cela, vous pouvez maintenant restaurer des copies cohérentes de la base de données de configuration et la base de données de collecte d’intérêt 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 les deux sur une instance SQL s’exécutant sur un serveur nommé ContosoTemp sur l’instance Backupsnommée .

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 pour les connexions à large zone. En outre, vous n’avez pas besoin de gérer le téléchargement et 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 Azure DevOps Services pour héberger votre projet de développement dans le cloud, vous pouvez utiliser la commande proxy pour gérer non seulement le cache des projets dans 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,

découvrez comment : 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 la référence de commande du contrôle de version Azure DevOps.

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

Conditions préalables

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

Remarques

Vous utilisez la commande proxy pour mettre à jour la configuration existante du proxy azure DevOps Server. 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 proxy à l’aide d’un jeton d’accès personnel pour s’authentifier. 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 d’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 proxy. 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.com, et le compte de service utilisé par le proxy est en cours de modification à My Proxy Service Account. Étant donné que le nom du compte contient des espaces, les guillemets sont utilisés pour placer le nom.

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 utilisées par Azure DevOps Server.

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

Conditions préalables

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 exécutant la console d’administration pour Azure DevOps

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

Pour plus d’informations, consultez Référence d’autorisation 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 Reporting 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 d’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>

Conditions préalables

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 un membre du groupe sysadmin dans SQL Server sur le serveur de couche Données pour Azure DevOps. Pour plus d’informations, consultez Référence d’autorisation 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 du serveur Azure DevOps (pool d’applications)
• ReportServer (pool d’applications)
• SQL Server Reporting Services (programme)

Vous devez fournir le nom ou l’adresse exacts de la base de données de configuration pour que cette commande fonctionne correctement. Si vous devez modifier le serveur sur lequel cette base de données est stockée, vous devez vous assurer qu’Azure DevOps Server pointe vers le nouvel emplacement.

Exemple :

L’exemple suivant redirige Azure DevOps Server vers une base de données de configuration située sur le serveur ContosoMain dans l’instance TeamDatabasesSQL Server.

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

La commande remapDBs redirige 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 Azure DevOps Server vers toutes les bases de données pour les collections de projets si elles sont hébergées sur un serveur ou des serveurs distincts de la base de données de configuration. Vous devez également rediriger Azure DevOps Server vers le serveur ou les serveurs exécutant SQL Server Analysis Services ou SQL Server Reporting Services si ces bases de données sont hébergées sur un serveur ou une instance distinct de la base de données de configuration.

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

Conditions préalables

Pour utiliser la commande remapDBs , 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 utilisées par Azure DevOps Server. Pour plus d’informations, consultez Référence d’autorisation pour Azure DevOps Server.

Remarques

Vous utilisez la commande remapDBs pour reconfigurer Azure DevOps Server afin d’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 l’instance TeamDatabasesnommée. Ses bases de données de collection de projets sont stockées à la fois sur ContosoMain\TeamDatabases et sur l’instance par défaut 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

Conditions préalables

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 d’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 pas d’arguments et nécessite que le déploiement du serveur Azure DevOps soit configuré.

Exemple :

TfsConfig repairJobQueue

Vous pouvez utiliser la commande de paramètres pour automatiser les modifications apportées au localisateur de ressources uniforme (URL) utilisé 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 pouvez utiliser une AUTRE URL 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 la référence rapide des tâches administratives.

TfsConfig settings [/publicURL:URL]

Conditions préalables

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 paramètres modifie les informations de connexion pour la communication serveur à serveur dans un déploiement d’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 modifie 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 d’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 vos plans de test et suites de test manuellement vers leurs types d’éléments de travail respectifs (WIT).

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

Conditions préalables

Vous devez être membre du groupe de sécurité des administrateurs de Team Foundation et administrateur sur le serveur de niveau application.

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

Remarques

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

Avant de pouvoir utiliser la commande TCM, vous devez d’abord importer la définition de l’élément 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 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 devez l’exécuter individuellement sur chaque projet.

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

Vous utilisez la commande TCM uniquement si la migration automatique des données de test existantes échoue.

Pour en savoir plus sur la migration et quand utiliser cette commande, 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 test qui ont été définis avant la mise à niveau du serveur, exécutez TFSConfig TCM upgradeStatus pour déterminer l’état 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 vérifier l’état de la mise à niveau du plan de test sur le projet Fabrikam Fibre 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érentes machines.

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 d’Azure DevOps Server. Ensuite, utilisez l’option /configure pour effectuer réellement 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. Dans le cas de plusieurs installations, cela permet également de s’assurer que les mêmes paramètres de configuration sont utilisés sur plusieurs serveurs.

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

Conditions préalables

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

• Selon le type d’installation, vous pouvez également avoir besoin 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 l’instance de SQL Server qui prendra en charge Azure DevOps Server. Pour plus d’informations, consultez la section Q &A de l’ajout d’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 également installer tout logiciel requis pour votre type d’installation choisi. 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 les composants Azure DevOps Server. Il n’effectue pas l’installation initiale du logiciel. Il configure le logiciel en fonction de vos spécifications une fois que les bits sont présents sur l’ordinateur.

Exemples

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

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

Dans cet exemple, le fichier unattend 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 l’exécution de la commande.

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 d’Azure DevOps Server Build sur un serveur à l’aide FabrikamFiber\BuildSVC du 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 les éléments suivants :

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 sur lequel 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 des journaux d’activité et supprime un zip à ProgramData\Microsoft\Azure DevOps\Server Configuration.

TfsConfig zipLogs

TfsConfig zipLogs