utiliser TFSConfig pour gérer Azure DevOps localement

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

Notes

Azure DevOps Server a été précédemment nommé Visual Studio Team Foundation Server.

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

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

Important

Sélecteur de version de contenu

Pour afficher le contenu disponible pour votre plateforme, veillez à sélectionner la version appropriée de cet article à partir du sélecteur de version situé au-dessus de la table des matières. la prise en charge des fonctionnalités diffère selon que vous travaillez à partir d’Azure DevOps Services ou d’une version locale de Azure DevOps Server, renommé à partir de Team Foundation Server (TFS).

Pour savoir quelle version locale vous utilisez, consultez quelle plateforme/version suis-je utilisé ?

Notes

Pour TFS 2010 et versions antérieures, quelques-unes de ces commandes sont disponibles dans l’outil en ligne de commande TFSAdminUtils .

Emplacement de l’outil de ligne de commande

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

  • Azure DevOps Server 2020 :%programfiles%\Azure DevOps Server 2020\Tools
  • Azure DevOps Server 2019 :%programfiles%\Azure DevOps Server 2019\Tools
  • TFS 2018 : %programfiles%\Microsoft Team Foundation Server 2018\Tools
  • TFS 2017 : %programfiles%\Microsoft Team Foundation Server 15.0\Tools
  • TFS 2015 : %programfiles%\Microsoft Team Foundation Server 14.0\Tools
  • TFS 2013 : %programfiles%\Microsoft Team Foundation Server 12.0\Tools
  • TFS 2012 : %programfiles%\Microsoft Team Foundation Server 11.0\Tools
  • TFS 2010 : %programfiles%\Microsoft Team Foundation Server 2010\Tools

Prérequis

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

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

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

Répertorier les commandes et obtenir de l’aide

Pour afficher la liste complète des commandes TfsConfig , utilisez la commande Help :

TFSConfig help

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

TFSConfig help accounts

Comptes

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

  • compte de service Azure DevOps Server
  • compte de sources de données pour SQL Server Reporting Services
  • 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]
Opération Description
UpdatePassword Modifie le mot de passe d'un compte utilisé comme compte de service. Modifie le compte existant et tous les types qui s’exécutent en tant que compte donné.
Modifier Modifie le compte utilisé comme compte de service. Ajoute le nouveau compte aux ressources et groupes nécessaires, accorde les autorisations requises, puis définit le service pour l’utiliser. Cela ne supprime pas l’ancien compte des ressources.

Si vous n’utilisez pas l’option AccountType , le compte de service de la couche application sera modifié.
Ajouter Ajoute uniquement le nouveau compte aux ressources nécessaires. Utile pour les scénarios d’équilibrage de la charge réseau. Utilisez l’indicateur continue si certaines collections sont inaccessibles. Ajouter peut être réexécuté ultérieurement pour mettre à jour les regroupements manqués. Ajoute un compte aux groupes requis pour l'utilisation du compte comme compte de service.
Définissez Définit uniquement le service pour qu’il utilise un compte déjà ajouté aux ressources. Utile pour les scénarios d’équilibrage de la charge réseau.
DELETE Supprime le compte de toutes les ressources. Les précautions doivent être utilisées lors de la suppression d’un compte, car cela peut entraîner le refus du service d’autres serveurs.
ResetOwner Si les bases de données sont restaurées dans le cadre d’un déplacement, d’un clone ou d’une récupération d’urgence, le propriétaire de la base de données peut basculer vers l’administrateur restaurant le serveur. Cette option itère au sein de toutes les bases de données et définit la connexion dbo sur le propriétaire actuel.
AccountType Description
AdminConsole Les utilisateurs de la console Administration sont des utilisateurs qui ont reçu les autorisations minimales sur les différentes ressources pour utiliser la console.
ApplicationTier Modifie le compte de service sur le pool d’infrastructure pour les services Web principaux. TFSService
Proxy Modifie le compte de service sur le pool d’accès aux services Web proxy. TFSPROXY
ReportingDataSource Modifie le compte utilisé par les rapports pour accéder aux données de rapports. TFSReports

La valeur par défaut est ApplicationTier.

SqlInstance et databaseName ne sont appropriés qu’en cas d’ajout d’un compte aux bases de données avant la configuration de la couche application. Cela s’avère particulièrement utile dans les scénarios de récupération d’urgence où un autre compte est nécessaire avant d’exécuter l’uniquement Assistant Configuration.

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 la variable continue est fournie, elle se poursuit si une collection est inaccessible. Il peut être exécuté à nouveau lorsqu’il est accessible.

Notes

Les comptes doivent être au format Nomdomaine\nomutilisateur. Pour les comptes système, vous devez utiliser des guillemets autour du nom complet du compte (par exemple, « NT Authority\Network Service »). Les comptes système ne requièrent pas de mot de passe.

Paramètre Description
Compte Spécifie le nom du compte que vous souhaitez ajouter, modifier ou supprimer à partir d’un type de compte référencé, tel que /AccountType : ApplicationTier.
Mot de passe Spécifie le mot de passe du compte de service. Ce paramètre est facultatif si vous utilisez un compte système ou un compte sans un mot de passe, tel que Service réseau.
sqlInstance Utilisé uniquement avec /ResetOwner.

spécifie le nom du serveur qui exécute SQL Server et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut. Vous devez spécifier le nom et l'instance au format suivant :

Nomserveur\nominstance.
databaseName Utilisé uniquement avec /ResetOwner.

Spécifie le nom de la base de données dont vous voulez modifier la propriété. À l'aide de cette commande, vous réinitialisez la propriété de la base de données que vous spécifiez en l'attribuant au compte sous lequel vous exécutez la commande.
continue Met à jour tous les groupes qui ne sont pas disponibles lorsque vous exécutez la commande. Cette option est généralement utilisée dans des scénarios NLB.

Prérequis

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

  • groupe de sécurité administrateurs Azure DevOps
  • rôle sysadmin pour toutes les instances de SQL Server utilisées par votre instance de Azure DevOps Server.

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

Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Notes

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 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 avoir le compte est sensible et ne peut pas être une autorisation déléguée sur le serveur de couche application. Pour plus d’informations, consultez cette page sur le site Web de 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 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\NewAccount , et 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 mots de passe).

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

modifiez la propriété de la TFS_Warehouse base de données sur le ContosoMain SQL Server de l' TeamDatabases instance nommée en fonction du compte d’utilisateur sous lequel vous exécutez la commande.

Notes

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

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

Utilisez la commande comptes pour gérer ces comptes de service TFS.

  • compte de service TFS
  • compte de sources de données pour SQL Server Reporting Services
  • 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] [/usesqlalwayson]

Option

Description

change

Modifie le compte utilisé comme compte de service.

Cette option ajoute le compte que vous spécifiez à tous les groupes nécessaires, lui attribue la configuration requise, si possible, et définit le service pour qu’il utilise le compte.

Si vous n’utilisez pas l’option /AccountType avec cette option, le compte de service pour la couche application sera modifié.

/add

Ajoute un compte aux groupes requis pour l'utilisation du compte comme compte de service.

Cette option ajoute le compte que vous spécifiez aux groupes nécessaires, et lui accorde les autorisations requises pour agir en tant que compte de service (si possible).

Toutefois, cette option ne change pas le compte utilisé comme compte de service.

Cette option est généralement utilisée dans les scénarios d'équilibrage de la charge réseau (NLB).

Vous pouvez l'utiliser avec /continue si certains services ou bases de données pourraient ne pas être disponibles dans votre environnement.

/Set

Définit un compte comme compte de service. Cette option n'ajoute le compte à aucun groupe.

Par conséquent, vous devez l'utiliser uniquement avec des comptes déjà ajoutés aux groupes requis, et disposant des autorisations nécessaires.

Cette option est généralement utilisée dans des scénarios NLB.

/delete

Supprime un compte du type que vous spécifiez.

Cette supprime le compte que vous spécifiez des groupes nécessaires, et supprime les autorisations requises pour agir en tant que compte de service (si possible).

Toutefois, cette option ne change pas le compte utilisé comme compte de service.

Veillez à ne pas utiliser cette option pour un compte que les serveurs de votre déploiement utilisent actuellement comme compte de service.

/ResetOwner

modifie la propriété des bases de données que Azure DevOps Server utilise pour le compte que vous utilisez pour exécuter cette commande.

Cette option permet d’effectuer une itération sur toutes les bases de données et de définir la connexion dbo au compte que vous utilisez pour exécuter cette commande.

Il se peut que vous deviez utiliser cette option lorsque vous déplacez ou restaurez un déploiement.

/UpdatePassword

Modifie le mot de passe d'un compte utilisé comme compte de service.

cette option met à jour le mot de passe du compte que vous spécifiez pour tous les services dans Azure DevOps Server qui utilisent ce compte.

/AccountType : {AdminConsole | ApplicationTier | ReportingDataSource | Procur

  • AdminConsole: groupe d’utilisateurs disposant des autorisations minimales requises pour ouvrir et utiliser la console administration de Azure DevOps (AdminConsole)
  • ApplicationTier: compte de service utilisé pour Azure DevOps Server (TFSService).
  • ReportingDataSource: compte de sources de données pour Reporting Services (TFSReports)
  • proxy: compte de service pour le proxy de Azure DevOps Server (TFSProxy)

La valeur par défaut est ApplicationTier.

/Account : AccountName

Spécifie le nom du compte que vous souhaitez ajouter, modifier ou supprimer à partir d’un type de compte référencé, tel que /AccountType : ApplicationTier.

Spécifiez le compte sous l’une des formes suivantes : Domain\AccountName ou Computer\AccountName.

Si vous souhaitez utiliser un compte système, tel que Service réseau ou Système Local, utilisez le format Ordinateur\Nom de compte.

Pour plus d'informations sur la spécification d'un compte système, consultez les exemples d'utilisation plus loin dans cette rubrique.

/Password : De

Spécifie le mot de passe du compte de service.

Remarque : Ce paramètre est facultatif si vous utilisez un compte système ou un compte qui n’a pas de mot de passe, tel que service réseau.

/SqlInstance : Nom du serveur

Utilisé uniquement avec /ResetOwner.

spécifie le nom du serveur qui exécute SQL Server et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut.

Vous devez spécifier le nom et l'instance au format suivant :

Nomserveur\nominstance.

/DatabaseName : DatabaseName

Utilisé uniquement avec /ResetOwner.

Spécifie le nom de la base de données dont vous voulez modifier la propriété.

À l'aide de cette commande, vous réinitialisez la propriété de la base de données que vous spécifiez en l'attribuant au compte sous lequel vous exécutez la commande.

/continue

Met à jour tous les groupes qui ne sont pas disponibles lorsque vous exécutez la commande. Cette option est généralement utilisée dans des scénarios NLB.

/usesqlalwayson

Utilisé uniquement avec /ResetOwner conjointement avec /SqlInstance et /DatabaseName.

Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server.

Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

pour plus d’informations, consultez [groupes de disponibilité AlwaysOn (SQL Server)] (/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Prérequis

Pour utiliser la commande Accounts , vous devez être membre de

  • Groupe de sécurité Team Foundation Administrators
  • rôle sysadmin pour toutes les instances de SQL Server utilisées par votre instance de Azure DevOps Server.

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

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

Notes

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 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 avoir le compte est sensible et ne peut pas être une autorisation déléguée sur le serveur de couche application. Pour plus d’informations, consultez cette page sur le site Web de 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 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 \ NewAccount et le mot de passe, par mot de passe.

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 mots de passe.)

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

modifiez la propriété de la base de _ données « entrepôt TFS » sur le SQL Server « ContosoMain » de l’instance nommée « TeamDatabases » par le compte d’utilisateur sous lequel vous exécutez la commande.

Notes

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

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

AddProjectReports

Notes

La commande addProjectReports est disponible avec TFS 2017,1 et versions ultérieures.

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

TfsConfig addProjectReports /collection:<teamProjectCollectionUrl> /teamProject:<projectName> /template:<templateName>
[/force]
Option Description
collection Obligatoire. URL de la Collection d’Project d’équipe.
TeamProject Obligatoire. Spécifie le nom du projet d’équipe.
template Obligatoire. Spécifie le nom du modèle de processus. Les options disponibles sont agile, CMMI et Scrum.
force facultatif. Spécifie que les rapports doivent être remplacés s’ils existent déjà.

Prérequis

Pour utiliser la commande addProjectReports , vous devez disposer des autorisations pour exécuter TfsConfig et Télécharger des rapports sur le service de créationde rapports.

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 les Azure DevOps Server et les anciens rapports dans votre projet ne sont plus compatibles, utilisez l’option /force . Si vous avez des rapports personnalisés, effectuez une sauvegarde avant d’effectuer cette procédure.

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

Vous utilisez la commande AddProjectReports pour ajouter ou remplacer des rapports pour un projet existant.

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

Option

Description

/collection

Obligatoire. URL de Project Collection.

/teamProject

Obligatoire. Spécifie le nom du projet.

/Template

Obligatoire. Spécifie le nom du modèle de processus. Les options disponibles sont agile, CMMI et Scrum

/Force

facultatif. Spécifie que les rapports doivent être remplacés s’ils existent déjà.

Prérequis

Pour utiliser la commande AddProjectReports , vous devez disposer des autorisations pour exécuter TfsConfig et Télécharger des rapports sur le service de créationde rapports.

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 Web 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 les Azure DevOps Server et les anciens rapports dans votre projet ne sont plus compatibles, utilisez l’option /force . Si vous avez des rapports personnalisés, effectuez une sauvegarde avant d’effectuer cette procédure.

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 agiles au projet MyProject dans la http://myTfsServer:8080/tfs/DefaultCollection collection de projets.

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

Authentification

la commande d’authentification modifie le protocole d’authentification réseau que la couche application Azure DevOps Server ou le site web proxy utilise.

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

Option

Description

/viewAll

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

/Provider: {NTLM | Prescrit

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

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

/siteType

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

Prérequis

pour utiliser la commande d’authentification , vous devez être membre du groupe de sécurité Azure DevOps administrateurs et d’un administrateur local sur le serveur de couche application ou le serveur proxy, 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 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 d' authentification pour modifier le protocole d’authentification, vous pouvez exécuter la commande avec l’option /viewall pour voir les paramètres existants.

Exemple

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

TFSConfig Authentication /viewAll

La commande d’authentification modifie le protocole d’authentification réseau que la couche application TFS ou le site Web proxy utilise.

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

Option

Description

/viewAll

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

/Provider: {NTLM | Prescrit

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

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

/siteType

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

Prérequis

Pour utiliser la commande d’authentification , vous devez être membre du groupe de sécurité Team Foundation Administrators et d’un administrateur local sur le serveur de couche application ou le serveur proxy, 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 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 d' authentification pour modifier le protocole d’authentification, vous pouvez exécuter la commande avec l’option /viewall pour voir les paramètres existants.

Exemple

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

TFSConfig Authentication /viewAll

Certificats

utilisez la commande certificats pour modifier la façon dont les certificats sont configurés pour l’authentification du client dans un déploiement de Azure DevOps Server qui utilise le protocole https, le protocole SSL (secure sockets layer) et les certificats.

TfsConfig certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]
Option Description
ordinateur Spécifie que la liste de certificats sera à partir du contexte de l’ordinateur local au lieu du contexte de l’utilisateur actuel.
disable Spécifie que le paramètre du certificat d’authentification client sera désactivé.
Sélection automatique Spécifie qu’un certificat sera automatiquement sélectionné dans la liste certificat. La fenêtre gérer les certificats clients ne s’ouvre pas.
commutateur noprompt Spécifie que la fenêtre gérer les certificats clients ne s’ouvre pas lorsque la commande certificats est exécutée.
empreintes numériques Spécifie que le certificat qui correspond à l’empreinte numérique spécifiée sera utilisé. Vous pouvez spécifier plusieurs certificats en séparant les empreintes numériques individuelles par une virgule.

Prérequis

pour utiliser la commande certificats , vous devez être membre du groupe de sécurité Azure DevOps administrateurs et du groupe administrateurs local sur l’ordinateur à partir duquel vous exécutez la commande. Pour plus d’informations, consultez référence des 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 des certificats spécifiques dans le contexte de l’utilisateur actuel ou dans le contexte de l’ordinateur local.

avant d’utiliser la commande certificats , vous devez d’abord configurer les serveurs de votre déploiement de Azure DevOps Server pour utiliser des certificats. Pour plus d’informations, consultez configuration de HTTPS avec SSL (Secure Sockets Layer) (SSL) 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 le protocole https/SSL et les certificats. Si vous utilisez la commande certificats sans option, un certificat client est automatiquement sélectionné dans le contexte de l’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 dans le magasin de l’utilisateur actuel.

TfsConfig certificates /autoselect

utilisez la commande certificats pour modifier la façon dont les certificats sont configurés pour l’authentification du client dans un déploiement de Azure DevOps Server qui utilise le protocole https, le protocole SSL (secure sockets layer) et les certificats.

TFSConfig Certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]

Option

Description

/machine

Spécifie que la liste de certificats sera à partir du contexte de l’ordinateur local au lieu du contexte de l’utilisateur actuel.

/Disable

Spécifie que le paramètre du certificat d’authentification client sera désactivé.

/autoSelect

Spécifie qu’un certificat sera automatiquement sélectionné dans la liste certificat. La fenêtre gérer les certificats clients ne s’ouvre pas.

/noprompt

Spécifie que la fenêtre gérer les certificats clients ne s’ouvre pas lorsque la commande certificats est exécutée.

/thumbprints : empreinte numérique

Spécifie que le certificat qui correspond à l’empreinte numérique spécifiée sera utilisé. Vous pouvez spécifier plusieurs certificats en séparant les empreintes numériques individuelles par une virgule.

Prérequis

Pour utiliser la commande certificats , vous devez être membre du groupe de sécurité Team Foundation Administrators et du groupe Administrateurs local sur l’ordinateur à partir duquel vous exécutez la commande. Pour plus d’informations, consultez référence des 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 des certificats spécifiques dans le contexte de l’utilisateur actuel ou dans le contexte de l’ordinateur local.

avant d’utiliser la commande certificats , vous devez d’abord configurer les serveurs de votre déploiement de Azure DevOps Server pour utiliser des certificats. Pour plus d’informations, consultez configuration de HTTPS avec SSL (Secure Sockets Layer) (SSL) 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 le protocole https/SSL et les certificats. Si vous utilisez la commande certificats sans option, un certificat client est automatiquement sélectionné dans le contexte de l’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 dans le magasin de l’utilisateur actuel.

TFSConfig Certificates /autoselect

ChangeServerID

La commande changeServerID modifie les GUID associés aux bases de données pour Azure DevOps Server. Les GUID doivent être uniques au sein d’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 pour toutes les bases de données de la collection de projets dans le déploiement, ou les deux.

Même si vous n’utilisez 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 dupliqué 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 dans 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 l’avoir déplacée vers un autre déploiement pour lequel ce GUID est déjà réservé.

Notes

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

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

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 référence des 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. Une fois que vous avez utilisé la commande changeServerID , vous devez demander aux clients de créer une connexion au serveur modifié avant de pouvoir les 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 l’instance nommée TeamDatabases dans SQL Server.

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

La commande ChangeServerID modifie les GUID associés aux bases de données pour TFS. Les GUID doivent être uniques au sein d’un déploiement de TFS. 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 pour toutes les bases de données de la collection de projets dans le déploiement, ou les deux. Même si vous n’utilisez 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 dupliqué 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 dans 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 l’avoir déplacée vers un autre déploiement pour lequel ce GUID est déjà réservé.

    Notes

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

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

Option

Description

/SqlInstance: nom_serveur

Obligatoire. spécifie le nom du serveur qui exécute SQL Server et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut. Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName

/DatabaseName: DatabaseName

Obligatoire. Spécifie le nom de la base de données de configuration pour Azure DevOps Server. Par défaut, le nom de cette base de données est TFS_ConfigurationDB.

/ProjectCollectionsOnly

Spécifie que seuls les GUID pour les collections seront modifiés.

/ConfigDBOnly

Spécifie que seul le GUID de la base de données de configuration sera modifié.

/usesqlalwayson

Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server. Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

Pour plus d’informations, consultez Groupes de disponibilité AlwaysOn (SQL Server).

Prérequis

pour utiliser la commande ChangeServerID , vous devez être membre du groupe de sécurité Team Foundation administrators et membre du rôle de sécurité sysadmin pour toutes les instances de SQL Server que Azure DevOps Server utilise. Pour plus d’informations, consultez référence des 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. Une fois que vous avez utilisé la commande ChangeServerID, vous devez demander aux clients de créer une connexion au serveur modifié avant de pouvoir les 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 l’instance nommée « TeamDatabases » dans SQL Server.

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

CodeIndex

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

TfsConfig codeIndex /indexingStatus | /setIndexing:[on|off|keepupOnly] |
    /ignoreList:[ add | remove | removeAll | view ] <serverPath> |
    /listLargeFiles [/fileCount:FileCount] [/minSize:MinSize] |
    /reindexAll | 
    /destroyCodeIndex [/noPrompt] |
    /temporaryDataSizeLimit:[ view | <SizeInGBs> | disable ] |
    /indexHistoryPeriod:[ view | all | <NumberOfMonths> ] [/collectionName:<collectionName> | /collectionId:<collectionId>]
Option Description
indexingStatus Affichez l'état et la configuration du service d'indexation de code.
setIndexing on : démarrer l’indexation de tous les ensembles de modifications.
off : arrêter l’indexation de tous les ensembles de modifications.
off : arrêter l’indexation des ensembles de modifications créés précédemment et commencer l’indexation de nouveaux ensembles de modifications uniquement.
ignoreList Spécifie une liste de fichiers de code et leurs chemins d’accès à ne pas indexer.

add : ajouter le fichier à ne pas indexer à la liste des fichiers ignorés.
remove : supprimer le fichier à indexer de la liste des fichiers ignorés.
removeAll : effacer la liste des fichiers ignorés et démarrer l’indexation de tous les fichiers.
view : afficher tous les fichiers qui ne sont pas indexés.
ServerPath: spécifie le chemin d’accès à un fichier de code.

Vous pouvez utiliser le caractère générique (*) au début, à la fin ou aux deux extrémités du chemin d’accès au serveur.
listLargeFiles Indique le nombre spécifié de fichiers qui dépassent la taille spécifiée en Ko. Vous pouvez ensuite utiliser l’option /ignoreList pour exclure ces fichiers de l’indexation.

pour cela, vous avez besoin de Team Foundation Server 2013 avec Update 3.
reindexAll Effacez les données indexées précédemment et redémarrez l'indexation.
destroyCodeIndex Supprimez l'index de code et supprimez toutes les données indexées. Confirmation inutile si vous utilisez l’option /noPrompt.
temporaryDataSizeLimit Contrôle la quantité de données temporaires que CodeLens crée lors du traitement des ensembles de modifications. La limite par défaut est 6 Go (2 Go dans Update 5).

view : afficher la limite de taille actuelle.
SizeInGBs: modifier la limite de taille.
disable : supprimer la limite de taille.

Cette limite est vérifiée avant que CodeLens ne traite un nouvel ensemble de modifications. Si les données temporaires dépassent cette limite, CodeLens suspend le traitement des ensembles de modifications passés, pas celui des nouveaux. CodeLens redémarre le traitement une fois que les données sont nettoyées et que leur taille est inférieure à cette limite. Le nettoyage s'exécute automatiquement une fois par jour. Cela signifie que les données temporaires peuvent dépasser cette limite tant que l'opération de nettoyage n'a pas commencé.

pour cela, vous avez besoin de Team Foundation Server 2013 avec Update 4.
indexHistoryPeriod Contrôler la durée d'indexation de votre historique des modifications. Cela affecte la quantité d'historique que CodeLens affiche. La limite par défaut est 12 mois. Cela signifie que l'historique des modifications affiché par CodeLens englobe uniquement les 12 derniers mois.

view : afficher le nombre de mois actuel.
all : indexer tout l’historique des modifications.
NumberOfMonths: modifier le nombre de mois utilisés pour indexer l’historique des modifications.

pour cela, vous avez besoin de Team Foundation Server 2013 avec Update 4.
collectionName Spécifie le nom de la collection de projets sur laquelle exécuter la commande CodeIndex. Nécessaire si vous n’utilisez pas /CollectionId.
collectionId Spécifie le numéro d’identification de la collection de projets sur laquelle exécuter la commande CodeIndex. Obligatoire si vous n’utilisez pas /CollectionName

Prérequis

pour utiliser la commande codeIndex , vous devez être membre du groupe de sécurité administrateurs Azure DevOps. Consultez les 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"

Disponibilité des commandes : TFS 2015 et TFS 2013

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

TFSConfig CodeIndex /indexingStatus | /setIndexing:[ on | off | keepupOnly ] |
        /ignoreList:[ add | remove | removeAll | view ] ServerPath |
        /listLargeFiles [/fileCount:FileCount] [/minSize:MinSize] |
        /reindexAll | /destroyCodeIndex [/noPrompt] |
        /temporaryDataSizeLimit:[ view | <SizeInGBs> | disable ] |
        /indexHistoryPeriod:[ view | all | <NumberOfMonths> ] [/collectionName:CollectionName | /collectionId:CollectionId]

Option

Description

/indexingStatus

Affichez l'état et la configuration du service d'indexation de code.

/setIndexing :[on | off | keepupOnly]

  • on : démarrer l’indexation de tous les ensembles de modifications.
  • off : arrêter l’indexation de tous les ensembles de modifications.
  • off : arrêter l’indexation des ensembles de modifications créés précédemment et commencer l’indexation de nouveaux ensembles de modifications uniquement.

ignoreList[ add | remove | removeAll | view ] ServerPath

Spécifie une liste de fichiers de code et leurs chemins d’accès à ne pas indexer.

  • add : ajouter le fichier à ne pas indexer à la liste des fichiers ignorés.
  • remove : supprimer le fichier à indexer de la liste des fichiers ignorés.
  • removeAll : effacer la liste des fichiers ignorés et démarrer l’indexation de tous les fichiers.
  • view : afficher tous les fichiers qui ne sont pas indexés.
  • ServerPath: spécifie le chemin d’accès à un fichier de code.

Vous pouvez utiliser le caractère générique (*) au début, à la fin ou aux deux extrémités du chemin d’accès au serveur.

/listLargeFiles
/FileCount: FileCount /MinSize :MinSize

Indique le nombre spécifié de fichiers qui dépassent la taille spécifiée en Ko. Vous pouvez ensuite utiliser l’option /ignoreList pour exclure ces fichiers de l’indexation.
pour cette option, vous avez besoin de Team Foundation Server 2013 avec la version Update 3 ou une version ultérieure.

/reindexAll

Effacez les données indexées précédemment et redémarrez l'indexation.

/destroyCodeIndex [/noPrompt]

Supprimez l'index de code et supprimez toutes les données indexées. Confirmation inutile si vous utilisez l’option /noPrompt.

/temporaryDataSizeLimit:[view | SizeInGBs | disable]

Contrôle la quantité de données temporaires que CodeLens crée lors du traitement des ensembles de modifications. La limite par défaut est 6 Go (2 Go dans Update 5).

  • view : afficher la limite de taille actuelle.
  • SizeInGBs: modifier la limite de taille.
  • disable : supprimer la limite de taille.

Cette limite est vérifiée avant que CodeLens ne traite un nouvel ensemble de modifications. Si les données temporaires dépassent cette limite, CodeLens suspend le traitement des ensembles de modifications passés, pas celui des nouveaux. CodeLens redémarre le traitement une fois que les données sont nettoyées et que leur taille est inférieure à cette limite. Le nettoyage s'exécute automatiquement une fois par jour. Cela signifie que les données temporaires peuvent dépasser cette limite tant que l'opération de nettoyage n'a pas commencé.

pour cette option, vous avez besoin de Team Foundation Server 2013 avec Update 4 ou une version ultérieure.

/indexHistoryPeriod:[view | all | NumberOfMonths]

Contrôler la durée d'indexation de votre historique des modifications. Cela affecte la quantité d'historique que CodeLens affiche. La limite par défaut est 12 mois. Cela signifie que l'historique des modifications affiché par CodeLens englobe uniquement les 12 derniers mois.

  • view : afficher le nombre de mois actuel.
  • all : indexer tout l’historique des modifications.
  • NumberOfMonths: modifier le nombre de mois utilisés pour indexer l’historique des modifications.

pour cette option, vous avez besoin de Team Foundation Server 2013 avec Update 4 ou une version ultérieure.

CollectionNameCollectionName

Spécifie le nom de la collection de projets sur laquelle exécuter la commande CodeIndex. Nécessaire si vous n’utilisez pas /CollectionId.

CollectionIdCollectionId

Spécifie le numéro d’identification de la collection de projets sur laquelle exécuter la commande CodeIndex. Nécessaire si vous n’utilisez pas /CollectionName.

Prérequis

Pour utiliser la CodeIndex commande, vous devez être membre du groupe de sécurité Team Foundation Administrators. Consultez les informations de référence sur les autorisations pour Azure DevOps Server.

Exemples

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

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

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

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

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

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

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

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

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

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

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

TFSConfig CodeIndex /ignoreList:view

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

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

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

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

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

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

Pour supprimer l'index de code avec confirmation :

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

Collection

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

Conseil

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

Prérequis

Pour utiliser la commande Collections , vous devez être membre du groupe de sécurité Team Foundation Administrators et 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 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 pour la batterie de serveurs SharePoint à partir de laquelle vous supprimez la collection de sites.

Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Remarques

pour gérer des regroupements de manière interactive ou pour créer un regroupement, vous pouvez utiliser le nœud regroupements Project dans la console administration de 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 Contoso Summer Interns Projects collection de projets, la nommer Contoso Winter Interns Projects et attacher la collection dupliquée au déploiement de Azure DevOps Server.

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

Vous pouvez utiliser la commande de collection pour attacher, détacher ou supprimer une collection de projets d’un déploiement de TFS. 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 ». Toutefois, vous ne pouvez pas utiliser la commande de collection pour créer une collection de projets.

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

Paramètres

Option

Description

/Attach

Obligatoire si ni /Detach ni /Delete n’est utilisé.

Si vous spécifiez cette option, vous devez également utiliser l’option /collectionDB .

En guise d’option, vous pouvez également utiliser /CollectionName et /clone. avec cette option.

Si vous utilisez l’option /Attach , la base de données de collection spécifiée sera ajoutée à votre déploiement de Azure DevOps Server.

/Detach

Obligatoire si vous ne utilisez pas /Attach ni /Delete .

Si vous spécifiez cette option, vous devez également utiliser l’option /CollectionName .

Si vous utilisez l’option /Detach , la base de données pour la collection spécifiée est arrêtée, et la collection est détachée de votre déploiement de Azure DevOps Server.

/delete

Obligatoire si ni /Detach ni /Attach ne sont utilisés.

Si vous spécifiez cette option, vous devez également utiliser l’option /CollectionName .

Si vous utilisez l’option /Delete , la base de données pour la collection spécifiée est arrêtée, et la collection est détachée définitivement de Azure DevOps Server.

Vous ne pourrez donc plus rattacher la base de données de collection à ce déploiement ou à un autre.

Conseil : L’option /Delete ne supprime pas la base de données de collection de SQL Server.

après avoir supprimé la base de données de collection de Azure DevOps Server, vous pouvez supprimer la base de données manuellement à partir de SQL Server.

/CollectionName : CollectionName

Spécifie le nom de la collection de projets. Si le nom de la collection contient des espaces, vous devez placer le nom entre guillemets (par exemple, " ma collection " ).

Obligatoire si /Detach ou /Delete est utilisé.

Si vous utilisez cette option avec /Detach ou /Delete, elle spécifie la collection qui sera détachée ou supprimée.

Si vous utilisez cette option avec /Attach, elle spécifie un nouveau nom pour la collection.

Si vous utilisez cette option avec /Attach et /clone., elle spécifie le nom de la collection dupliquée.

/CollectionDB : Nom_serveur ; DatabaseName

Obligatoire si /Attach est utilisé.

cette option spécifie le nom du serveur qui exécute SQL Server et le nom de la base de données de collection hébergée sur ce serveur.

  • ServerName: spécifie le nom du serveur qui héberge la base de données de configuration pour Azure DevOps Server, et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut.

Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName .

  • DatabaseName: spécifie le nom de la base de données de configuration. Par défaut, le nom de cette base de données est TFS_ConfigurationDB.

/Clone.

si vous spécifiez cette option, la base de données de collection d’origine est attachée en tant que clone dans SQL Server, et cette base de données est attachée à Azure DevOps Server. Cette option est principalement utilisée dans le cadre du fractionnement d’une collection de projets.

Prérequis

Pour utiliser la commande Collections , vous devez être membre du groupe de sécurité Team Foundation Administrators et 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 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 pour la batterie de serveurs SharePoint à partir de laquelle vous supprimez la collection de sites.

Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Remarques

pour gérer des regroupements de manière interactive ou pour créer un regroupement, vous pouvez utiliser le nœud regroupements Project dans la console administration de Azure DevOps. Consultez gérer les collections de projets.

Exemples

L’exemple suivant montre comment supprimer définitivement la collection de projets « Contoso Summer Intern Projects » 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 projets « Contoso Summer Internies Projects », la nommer « contoso Winter Internies Projects » et attacher la collection dupliquée au déploiement de Azure DevOps Server.

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

ColumnStoreIndex

Notes

Disponibilité des commandes : requiert TFS 2015,2 et versions ultérieures.

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

TfsConfig columnStoreIndex /enabled:<true|false>
    /sqlInstance:<serverName>
    /databaseName:<databaseName>
Option Description
enabled spécifie si vous activez ou désactivez l’index de la banque des colonnes pour l’instance de SQL et la base de données spécifiées.
sqlInstance Spécifie le nom du serveur qui héberge la base de données pour laquelle l’index de la Banque des colonnes est activé ou désactivé, et le nom de l’instance si une instance autre que la valeur par défaut est utilisée. Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName .
databaseName Spécifie le nom de la base de données pour laquelle l’index de la Banque des colonnes est activé ou désactivé.

Prérequis

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

Remarques

en général, vous utilisez la commande columnStoreIndex si vous déplacez une base de données à partir d’une instance de SQL qui prenait en charge l’index de la banque des colonnes vers une base de données qui ne l’a pas fait. Dans ce cas, vous devez désactiver tous les index de banque de colonnes avant de pouvoir déplacer correctement les bases de données. de même, si vous transférez une base de données vers une instance de SQL qui prenait en charge l’index de la banque des colonnes, vous souhaiterez peut-être réactiver l’index de la banque des colonnes afin d’économiser de l’espace et d’obtenir des performances optimales.

Exemple

l’exemple suivant montre comment activer l’index de la banque des colonnes, pour une base de données nommée TFS_DefaultCollection sur une instance de SQL s’exécutant 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 ColumnStoreIndex pour activer ou désactiver les index de la Banque des colonnes pour les bases de données utilisées par votre déploiement TFS.

TfsConfig columnStoreIndex /enabled:{true|false}
        /sqlInstance:ServerName
        /databaseName:DatabaseName

Option

Description

/Enabled

spécifie si vous activez ou désactivez l’index de la banque des colonnes pour l’instance de SQL et la base de données spécifiées.

/sqlInstance

Spécifie le nom du serveur qui héberge la base de données pour laquelle l’index de la Banque des colonnes est activé ou désactivé, et le nom de l’instance si une instance autre que la valeur par défaut est utilisée.

Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName

/databaseName

Spécifie le nom de la base de données pour laquelle l’index de la Banque des colonnes est activé ou désactivé.

Prérequis

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

Remarques

en général, vous utilisez la commande ColumnStoreIndex si vous déplacez une base de données à partir d’une instance de SQL qui prenait en charge l’index de la banque des colonnes vers une base de données qui ne l’a pas fait. Dans ce cas, vous devez désactiver tous les index de banque de colonnes avant de pouvoir déplacer correctement les bases de données. de même, si vous transférez une base de données vers une instance de SQL qui prenait en charge l’index de la banque des colonnes, vous souhaiterez peut-être réactiver l’index de la banque des colonnes afin d’économiser de l’espace et d’obtenir des performances optimales.

Exemple

l’exemple suivant montre comment activer l’index de la banque des colonnes, pour une base de données nommée TFS _ DefaultCollection sur une instance de SQL s’exécutant sur un serveur nommé « ContosoMain » sur l’instance nommée « TeamDatabases ».

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

ConfigureMail configurez le serveur qui exécute Azure DevOps Server pour utiliser un serveur SMTP existant pour les alertes par courrier électronique.TfsConfig configureMail /Enabled:<true|false> /FromEmailAddress:<emailAddress> /SmtpHost:<SMTPHostName>### Prérequispour utiliser la commande configureMail , vous devez être membre du groupe de sécurité Team Foundation administrators sur le serveur de couche application Azure DevOps. Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server### Remarquesvous pouvez également utiliser la console administration de pour configurer Azure DevOps Server pour utiliser un serveur SMTP.### ExempleL’exemple suivant illustre la syntaxe utilisée pour configurer l’adresse de messagerie à TFS@contoso.com et le serveur de messagerie SMTP en tant que ContosoMailServer :TfsConfig configureMail /FromEmailAddress:TFS@contoso.com /SmtpHost:ContosoMailServer


DBCompression

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]]
Option Description
pageCompression spécifie si vous activez ou désactivez la compression de page pour l’instance de SQL et la base de données spécifiées.
sqlInstance Spécifie le nom du serveur qui héberge la base de données pour laquelle la compression de page est activée ou désactivée, et le nom de l’instance si une instance autre que la valeur par défaut est utilisée. Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName
databaseName Spécifie le nom de la base de données pour laquelle la compression de page est activée ou désactivée.
rebuildNow facultatif. Spécifie si les index de base de données doivent être reconstruits (et compressés ou décompressés si nécessaire) immédiatement. S’il n’est pas utilisé, les index sont reconstruits par une tâche en arrière-plan qui s’exécute toutes les semaines.
hors connexion facultatif. Utilisé uniquement en association avec /rebuildNow. Si /Offline n’est pas spécifié, les index sont reconstruits en ligne. Si /Offline est spécifié, les index sont reconstruits en mode hors connexion. Cela bloquera les autres opérations, mais peut être plus rapide qu’une reconstruction d’index en ligne.

Prérequis

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

Remarques

en général, vous utilisez la commande dbCompression si vous déplacez une base de données à partir d’une instance de SQL qui prenait en charge la compression vers une base de données 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 transférez une base de données vers une instance de SQL qui prenait en charge la compression, vous souhaiterez peut-être réactiver la compression pour é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 la compression de page immédiatement, avec les index reconstruits en ligne, pour une base de données nommée TFS_DefaultCollection sur une instance de SQL s’exécutant sur un serveur nommé ContosoMain sur l’instance nommée TeamDatabases .

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

Pour TFS 2012 et versions antérieures, consultez https://support.microsoft.com/kb/2712111 .

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

Option

Description

/pageCompression

spécifie si vous activez ou désactivez la compression de page pour l’instance de SQL et la base de données spécifiées.

/sqlInstance

Spécifie le nom du serveur qui héberge la base de données pour laquelle la compression de page est activée ou désactivée, et le nom de l’instance si une instance autre que la valeur par défaut est utilisée.

Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName

/databaseName

Spécifie le nom de la base de données pour laquelle la compression de page est activée ou désactivée.

/rebuildNow

facultatif. Spécifie si les index de base de données doivent être reconstruits (et compressés ou décompressés si nécessaire) immédiatement. S’il n’est pas utilisé, les index sont reconstruits par une tâche en arrière-plan qui s’exécute toutes les semaines.

/Offline

facultatif. Utilisé uniquement en association avec /rebuildNow. Si /Offline n’est pas spécifié, les index sont reconstruits en ligne. Si /Offline est spécifié, les index sont reconstruits en mode hors connexion. Cela bloquera les autres opérations, mais peut être plus rapide qu’une reconstruction d’index en ligne.

Prérequis

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

Remarques

en général, vous utilisez la commande DBCompression si vous déplacez une base de données à partir d’une instance de SQL qui prenait en charge la compression vers une base de données 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 transférez une base de données vers une instance de SQL qui prenait en charge la compression, vous souhaiterez peut-être réactiver la compression pour é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 la compression de page immédiatement, avec les index reconstruits en ligne, pour une base de données nommée TFS _ DefaultCollection sur une instance de SQL s’exécutant sur un serveur nommé « ContosoMain » sur l’instance nommée « TeamDatabases ».

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

DeleteTestResults

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

TfsConfig deleteTestResults /ageInDays:<number> /sqlInstance:<serverName> /databaseName:<databaseName>
    [/type:[automated|manual|all]]
    [/preview]
Option Description
ageInDays Les résultats des tests plus anciens que le nombre de jours spécifié seront supprimés ou prévisualisés.
sqlInstance Nom du serveur qui héberge la base de données pour laquelle les résultats des tests sont supprimés ou prévisualisés, et le nom de l’instance si une instance autre que la valeur par défaut est utilisée. Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName .
databaseName Nom de la base de données pour laquelle les résultats des tests sont supprimés ou prévisualisés.
type facultatif. Type de résultats des tests à supprimer. Les valeurs valides sont automatique, manuelle et tout.
preview facultatif. Affichez le nombre de résultats des tests qui seraient supprimés en fonction de l’ancienneté en jours, mais ne supprimez pas ces résultats.

Prérequis

pour utiliser la commande deleteTestResults , vous devez être membre du rôle sysadmin pour l’instance de 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 des résultats de tests manuels antérieurs à 60 jours pour une base de données nommée TFS_DefaultCollection sur une instance de SQL s’exécutant sur un serveur nommé ContosoMain sur l’instance nommée TeamDatabases .

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

Disponibilité des commandes : TFS 2017 et versions ultérieures

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

TFSConfig DeleteTestResults /ageInDays:{number} 
    /sqlInstance:ServerName
    /databaseName:DatabaseName
    [/type:{automated|manual|all}]
    [/preview]

Option

Description

/ageInDays

Les résultats des tests plus anciens que le nombre de jours spécifié seront supprimés ou prévisualisés.

/sqlInstance

Nom du serveur qui héberge la base de données pour laquelle les résultats des tests sont supprimés ou prévisualisés, et le nom de l’instance si une instance autre que la valeur par défaut est utilisée.

Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName

/databaseName

Nom de la base de données pour laquelle les résultats des tests sont supprimés ou prévisualisés.

/type

facultatif. Type de résultats des tests à supprimer. Les valeurs valides sont automatique, manuelle et tout.

/Preview

facultatif. Affichez le nombre de résultats des tests qui seraient supprimés en fonction de l’ancienneté en jours, mais ne supprimez pas ces résultats.

Prérequis

pour utiliser la commande DeleteTestResults , vous devez être membre du rôle sysadmin pour l’instance de 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 des résultats de tests manuels antérieurs à 60 jours pour une base de données nommée TFS _ DefaultCollection sur une instance de SQL s’exécutant sur un serveur nommé « ContosoMain » sur l’instance nommée « TeamDatabases ».

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

DeploymentPool

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

TfsConfig deploymentpool /migrateDeploymentGroups /fromPool:<source pool name> /toPool:<destination pool name>
Option Description
fromPool Nom du pool source.
toPool Nom du pool de destination.

Identities

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

  • Modification du domaine de votre déploiement

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

  • Migration de comptes entre domaines dans Active Directory

Notes

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

TfsConfig identities [/change /fromdomain:<domainName1> /todomain:<domainName2>
    [/account:<accountName> [/toaccount:<accountName>]] [/sqlInstance:<serverName> /databaseName:<databaseName>]
Option Description
Modifier Spécifie que vous pouvez modifier des identités au lieu de les répertorier.
fromdomain Obligatoire lors de l’utilisation de /change. Spécifie le domaine d'origine des identités que vous souhaitez changer. Si vous changez à partir d'un environnement de groupe de travail, spécifie le nom de l'ordinateur.
todomain Obligatoire lors de l’utilisation de /change. Spécifie le domaine pour lequel vous souhaitez modifier des identités. Si vous changez pour un environnement de groupe de travail, spécifie le nom de l'ordinateur.
account Spécifie le nom d'un compte pour lequel vous souhaitez répertorier ou modifier des identités.
toaccount Spécifie le nom d'un compte pour lequel vous souhaitez modifier des identités.
SQLInstance spécifie le nom du serveur qui exécute SQL Server et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut. Si vous spécifiez une instance, vous devez utiliser le format suivant :

nom_serveur\nom_instance
nom_base_de_données Spécifie le nom de la base de données de configuration pour Azure DevOps Server.

Prérequis

pour utiliser la commande identities , vous devez être membre du groupe de sécurité Team Foundation administrators et membre du rôle sysadmin pour toutes les instances de SQL Server que Team Foundation Server utilise. Pour plus d’informations, consultez définir des autorisations d’administrateur pour Azure DevOps Server.

Notes

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 Windows utilisateurs et groupes stockés dans Azure DevOps Server et pour indiquer si le sid de chaque utilisateur ou groupe correspond au sid dans Windows. les administrateurs de domaine Contoso1 ont créé des groupes de domaine tels que Contoso1\\Developers et Contoso1\\Testers pour faciliter la gestion des autorisations sur les produits Azure DevOps Server, SQL Server Reporting Services et 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 pour tous les comptes dans Azure DevOps Server du domaine Contoso1 aux sid des 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 ne sera pas mis à jour pour Contoso1\hholt .

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

L’exemple suivant montre comment modifier le compte d’un compte d’utilisateur unique, Contoso1\hholt , en compte pour 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 de Contoso1 à ContosoPrime . Pour modifier un compte système tel que le Service réseau, vous devez suivre un processus à deux étapes. Vous devez d’abord remplacer le compte de service par NT AUTHORITY\NETWORK SERVICE un compte de domaine dans le nouveau domaine TempSVC , puis redéfinir le compte sur 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 l’instance nommée TeamDatabases 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"

La commande Identities répertorie ou modifie l’identificateur de sécurité (SID) des utilisateurs et des groupes dans votre déploiement de TFS. 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

  • transformation d'un groupe de travail à un domaine ou d'un domaine en un groupe de travail

  • migration de comptes à travers des domaines dans Active Directory

    Notes

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

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

Option

Description

change

Spécifie que vous pouvez modifier des identités au lieu de les répertorier.

/fromdomain : NomDomaine

Obligatoire lors de l’utilisation de /change. Spécifie le domaine d'origine des identités que vous souhaitez changer. Si vous changez à partir d'un environnement de groupe de travail, spécifie le nom de l'ordinateur.

/todomain : NomDomaine

Obligatoire lors de l’utilisation de /change. Spécifie le domaine pour lequel vous souhaitez modifier des identités. Si vous changez pour un environnement de groupe de travail, spécifie le nom de l'ordinateur.

/Account : AccountName

Spécifie le nom d'un compte pour lequel vous souhaitez répertorier ou modifier des identités.

/toaccount : AccountName

Spécifie le nom d'un compte pour lequel vous souhaitez modifier des identités.

/SqlInstance : Nom du serveur

spécifie le nom du serveur qui exécute SQL Server et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut. Si vous spécifiez une instance, vous devez utiliser le format suivant :

nom_serveur\nom_instance

/DatabaseName : DatabaseName

Spécifie le nom de la base de données de configuration pour Azure DevOps Server.

/usesqlalwayson

Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server. Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

pour plus d’informations, consultez [groupes de disponibilité AlwaysOn (SQL Server)] (/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Prérequis

pour utiliser la commande Identities , vous devez être membre du groupe de sécurité Team Foundation administrators et membre du rôle sysadmin pour toutes les instances de SQL Server que Azure DevOps Server utilise. Pour plus d’informations, consultez définir des autorisations d’administrateur pour Azure DevOps Server.

Notes

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 Windows utilisateurs et groupes stockés dans Azure DevOps Server et pour indiquer si le sid de chaque utilisateur ou groupe correspond au sid dans Windows. les administrateurs de domaine contoso1 ont créé des groupes de domaine tels que les « \ développeurs contoso1 » et les \ testeurs contoso1 pour faciliter la gestion des autorisations sur les produits Azure DevOps Server, SQL Server Reporting Services et SharePoint.

TFSConfig Identities

Exemple de sortie :

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 pour tous les comptes dans Azure DevOps Server du domaine Contoso1 vers les sid pour les comptes qui ont des noms correspondants dans le domaine ContosoPrime. 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 remplacé par le SID pour ContosoPrime \ hholt. Si le compte « ContosoPrime \ hholt » n’existe pas, le SID ne sera pas mis à jour pour Contoso1 \ hholt.

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

L’exemple suivant montre comment modifier le compte d’un compte d’utilisateur unique, Contoso1 \ hholt, en compte pour 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 service « NT AUTHORITY \ NETWORK service » utilisé dans le déploiement de Azure DevOps Server lors de la modification du domaine du déploiement de Contoso1 en ContosoPrime. Pour modifier un compte système tel que le Service réseau, vous devez suivre un processus à deux étapes. Vous commencez par modifier le compte de service du SERVICE réseau de l’autorité NT \ à un compte de domaine dans le nouveau domaine (TempSVC), puis vous replacez le compte sur 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 l’instance nommée « TeamDatabases » dans SQL Server.

TFSConfig Identities /change /fromdomain:"NT AUTHORITY" /todomain:ContosoPrime /account:"NETWORK SERVICE"
    /toaccount:TempSVC /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB
TFSConfig Identities /change /fromdomain:ContosoPrime /todomain:"NT AUTHORITY" /account:TempSVC
    /toaccount:"NETWORK SERVICE"

travaux

Vous pouvez utiliser la commande 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 retenter une tâche pour une ou toutes les collections de projets.

TfsConfig jobs /retry|dumplog [/CollectionName:<collectionName>] [/CollectionId:<id>]
Option Description
retry Obligatoire si /dumplog. n’est pas utilisé. Spécifie que le travail le plus récent sera retenté pour la collection de projets spécifiée. Si vous utilisez cette option, vous devez également utiliser l’option /CollectionName ou /CollectionId .
dumplog Obligatoire si /Retry n’est pas utilisé. Spécifie que l’activité la plus récente du travail pour le regroupement sera envoyée à un fichier journal. Si vous utilisez cette option, vous devez également utiliser l’option /CollectionName ou /CollectionId .
CollectionName Obligatoire si /CollectionId n’est pas utilisé. Spécifie le nom de la collection pour laquelle la tâche la plus récente sera retentée (/Retry) ou consignée (/dumplog.). Si vous souhaitez spécifier toutes les collections, vous pouvez utiliser un astérisque (*).
CollectionID Obligatoire si /CollectionName n’est pas utilisé. Spécifie le numéro d’identification de la collection pour laquelle la tâche la plus récente sera retentée (/Retry) ou consignée (/dumplog.).

Prérequis

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

Remarques

pour réexécuter une tâche de manière interactive, vous pouvez ouvrir la console administration de Azure DevOps, sélectionner l’onglet état pour le regroupement, puis sélectionner nouvelle tentative de travail. pour plus d’informations, consultez ouvrir la Console Administration de Azure DevOps.

Exemple

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

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

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 retenter une tâche pour une ou toutes les collections de projets.

TFSConfig Jobs /retry|dumplog [/CollectionName:CollectionName] [/CollectionID:ID]

Option

Description

/Retry

Obligatoire si /dumplog. n’est pas utilisé. Spécifie que le travail le plus récent sera retenté pour la collection de projets spécifiée. Si vous utilisez cette option, vous devez également utiliser l’option /CollectionName ou /CollectionId .

/dumplog.

Obligatoire si /Retry n’est pas utilisé. Spécifie que l’activité la plus récente du travail pour le regroupement sera envoyée à un fichier journal. Si vous utilisez cette option, vous devez également utiliser l’option /CollectionName ou /CollectionId .

/CollectionName : CollectionName

Obligatoire si /CollectionId n’est pas utilisé. Spécifie le nom de la collection pour laquelle la tâche la plus récente sera retentée (/Retry) ou consignée (/dumplog.). Si vous souhaitez spécifier toutes les collections, vous pouvez utiliser un astérisque (*).

/CollectionId : IDENTIFI

Obligatoire si /CollectionName n’est pas utilisé. Spécifie le numéro d’identification de la collection pour laquelle la tâche la plus récente sera retentée (/Retry) ou consignée (/dumplog.).

Prérequis

Pour utiliser la commande Jobs , vous devez être membre du groupe de sécurité Team Foundation Administrators. Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Remarques

pour réessayer une tâche de manière interactive, vous pouvez ouvrir la console administration de Azure DevOps, cliquer sur l’onglet état du regroupement, puis cliquer sur réessayer le travail. pour plus d’informations, consultez ouvrir la Console Administration de Azure DevOps.

Exemple

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

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

Lab/Delete

Utilisez l’option TfsConfig Lab/Delete pour supprimer tous les hôtes de groupe, partages de bibliothèque et environnements d’une collection de projets spécifiée. par défaut, les objets associés dans le System Center Virtual Machine Manager (SCVMM) ne sont pas supprimés. Vous pouvez ajouter l’option /External à la ligne de commande pour supprimer les objets de la collection de projets et de SCVMM.

TfsConfig Lab /Delete /CollectionName:collectionName [/External] [/NoPrompt]
Option Description
CollectionName: CollectionName Obligatoire. Spécifie le nom de la collection de projets sur la couche application de Azure DevOps Server.
Externe facultatif. Lorsqu’il est spécifié, supprime les partages de bibliothèque et les groupes hôtes dans SCVMM en plus des objets de la collection de projets. Quand /External n’est pas spécifié, la commande TfsConfig Lab/Delete supprime uniquement les objets de la collection de projets.
Commutateur noprompt facultatif. Lorsqu’il est spécifié, n’affiche pas les informations relatives à la progression et à la réussite.

Remarques

Utilisez la commande /Delete pour supprimer les ressources Lab d’une collection de projets lorsque vous souhaitez détacher la configuration Lab d’une collection de projets. cela est utile lors du déplacement d’une collection de projets d’une instance de Azure DevOps Server vers une autre, et où la nouvelle instance de Azure DevOps Server utilise un serveur SCVMM différent de celui d’origine. Dans ce cas, vous devez supprimer toutes les ressources de laboratoire et reconfigurer le Lab pour la collection de projets.

Notes

L’option /Delete fonctionne sur toutes les ressources Lab dans une collection de projets uniquement lorsque les options /LibraryShare et /GroupHost ne sont pas spécifiées sur la ligne de commande. Pour plus d’informations, consultez commandes TfsConfig Lab/LibraryShare et commandes TfsConfig Lab/HostGroup.

Exemple

Dans l’exemple suivant, tous les objets Lab de la collection de projets DefaultCollection sont supprimés. Étant donné que l’option /External n’est pas spécifiée, les objets sont conservés dans SCVMM.

tfsconfig lab /delete /collectionName:DefaultCollection

Utilisez l’option TfsConfig Lab/Delete pour supprimer tous les hôtes de groupe, partages de bibliothèque et environnements d’une collection de projets spécifiée. par défaut, les objets associés dans le System Center Virtual Machine Manager (SCVMM) ne sont pas supprimés. Vous pouvez ajouter l’option /External à la ligne de commande pour supprimer les objets de la collection de projets et de SCVMM.

TfsConfig Lab /Delete /CollectionName:collectionName [/External] [/NoPrompt]
Option Description
CollectionName: CollectionName Obligatoire. Spécifie le nom de la collection de projets sur la couche application de Azure DevOps Server.
Externe facultatif. Lorsqu’il est spécifié, supprime les partages de bibliothèque et les groupes hôtes dans SCVMM en plus des objets de la collection de projets. Quand /External n’est pas spécifié, la commande TfsConfig Lab/Delete supprime uniquement les objets de la collection de projets.
Commutateur noprompt facultatif. Lorsqu’il est spécifié, n’affiche pas les informations relatives à la progression et à la réussite.

Remarques

Utilisez la commande /Delete pour supprimer les ressources Lab d’une collection de projets lorsque vous souhaitez détacher la configuration Lab d’une collection de projets. cela est utile lors du déplacement d’une collection de projets d’une instance de Azure DevOps Server vers une autre, et où la nouvelle instance de Azure DevOps Server utilise un serveur SCVMM différent de celui d’origine. Dans ce cas, vous devez supprimer toutes les ressources de laboratoire et reconfigurer le Lab pour la collection de projets.

Notes

L’option /Delete fonctionne sur toutes les ressources Lab dans une collection de projets uniquement lorsque les options /LibraryShare et /GroupHost ne sont pas spécifiées sur la ligne de commande. Pour plus d’informations, consultez commandes TfsConfig Lab/LibraryShare(.. Commandes/TFSConfig-cmd.MD # Lab-LibraryShare) et TfsConfig Lab/HostGroup.

Exemple

Dans l’exemple suivant, tous les objets Lab de la collection de projets DefaultCollection sont supprimés. Étant donné que l’option /External n’est pas spécifiée, les objets sont conservés dans SCVMM.

tfsconfig lab /delete /collectionName:DefaultCollection

/DNS Lab

la commande TfsConfig Lab/DNS ajoute, supprime ou affiche les enregistrements DNS créés par Visual Studio Lab Management pour les environnements isolés du réseau.

    TfsConfig Lab /DNS 
    {/Add | /Delete | /List}
        [/CollectionName:collectionName |
        / CollectionName:collectionName /TeamProject:projectName |
        / CollectionName:collectionName /TeamProject:projectName /LabEnvironment:environmentUri |
        /Name:FQDN /IP:IpAddress]
        [/NoPrompt]
Option Description
Ajouter Ajoute les enregistrements DNS spécifiés. Pour utiliser l’option /Add , les environnements ciblés doivent être en cours d’exécution.
Supprimer Supprime les enregistrements DNS spécifiés.
Liste Affiche les enregistrements DNS spécifiés.
LabEnvironment : environmentUri Cible les options /Add, /Delete ou /List dans un environnement isolé du réseau individuel spécifié par environmentUri.

Pour utiliser l’option LabEnvironment , vous devez également spécifier les options /collection et /TeamProject .
Teamproject : ProjectName En cas d’utilisation sans /LabEnvironment, cible les options /Add, /Delete ou /List pour tous les environnements isolés du réseau dans le projet spécifié par ProjectName. Sinon, /TeamProject spécifie le projet qui contient l’environnement.

Pour utiliser l’option /TeamProject , vous devez également spécifier l’option /collection .
CollectionName : CollectionName En cas d’utilisation sans /TeamProject, cible les options /Add, /Delete ou /List pour tous les environnements isolés du réseau dans la collection de projets spécifiée par NomCollection. Dans le cas contraire, /collection spécifie la collection de projets qui contient le projet.
Nom : DOMAINE complet Spécifie le nom de domaine complet de l’emplacement réseau qui contient l’environnement à cibler.

Vous devez spécifier les options /Name et /IP ensemble.
Adresse IP : IPAddress Spécifie l’adresse IP de l’environnement à cibler.

Vous devez spécifier les options /Name et /IP ensemble.

Remarques

Azure DevOps Server utilise le suffixe que vous entrez lorsqu’il enregistre un nom externe unique avec DNS pour chaque ordinateur virtuel dans un environnement isolé du réseau. L'enregistrement d'alias DNS permet aux ordinateurs et autres objets en dehors du réseau isolé de communiquer avec des ordinateurs situés dans le réseau isolé. étant donné que Azure DevOps Server accède à la zone DNS pour enregistrer l’alias, le compte de service sous lequel Azure DevOps s’exécute doit disposer des autorisations pour ajouter ou supprimer des enregistrements d’alias dans la zone dns spécifiée.

Si votre déploiement Team Foundation Server a plusieurs couches Application et que chaque couche Application s’exécute sous un compte de service différent, chaque compte de service de couche Application doit avoir l’autorisation de modifier les enregistrements d’alias DNS créés par les autres couches Application.

Notes

La gestion des enregistrements DNS est effectuée automatiquement par Lab Management. Vous ne devez utiliser la commande /DNS que dans les cas suivants :

  • vous modifiez le compte sous lequel Azure DevOps Server s’exécute.
  • vous déplacez une collection de projets d’une instance de Azure DevOps Server vers une autre.

dans ces deux cas, les enregistrements dns créés à l’aide de l’ancien compte de service Azure DevOps Server doivent être supprimés, puis les mêmes enregistrements dns doivent être recréés à l’aide du nouveau compte de service Azure DevOps Server. si ces étapes ne sont pas effectuées dans les scénarios précédents, le nouveau compte de service Azure DevOps Server ne sera pas en mesure d’effectuer la gestion automatique de ces enregistrements DNS. Par conséquent, les utilisateurs ne seront pas en mesure de se connecter à des environnements virtuels.

Spécifiez une seule des options /Add, /Delete ou /List sur une ligne de commande TfsConfig Lab/DNS . si vous ne spécifiez pas d’options cibles, l’opération agit sur toutes les machines virtuelles de tous les environnements isolés du réseau qui appartiennent à toutes les collections de projets de la base de données Team Foundation Server.

Pour cibler les entrées DNS des environnements isolés du réseau d’un objet dans la hiérarchie d’objets Lab Management, utilisez la combinaison appropriée des options /collection, /TeamProject et /LabEnvironment

  • L’option /LabEnvironment cible la commande dans l’environnement isolé du réseau spécifié. Vous devez utiliser les options /CollectionName et /TeamProject avec l’option /LabEnvironment pour spécifier la collection de projets et le projet qui contiennent l’environnement.

    Utilisez le format vstfs:///LabManagement/LabEnvironment/ environmentID pour spécifier l’URI de l’environnement. Vous pouvez afficher l’identificateur d’environnement (environmnetID) dans la visionneuse d’environnement de Lab Management ou à partir de la description de l’ordinateur virtuel dans SCVMM Console Administrateur.

  • L’option /TeamProject cible l’opération pour isoler les environnements réseau dans le projet spécifié. L’option /TeamProject doit être utilisée avec l’option /CollectionName et l’option /CollectionName doit spécifier la collection de projets qui contient le projet.

  • L’option /CollectionName cible l’opération pour les environnements isolés du réseau dans la collection de projets spécifiée.

La deuxième façon de cibler un environnement isolé du réseau consiste à utiliser les options /Name et /IP pour spécifier le nom externe complet et l’adresse IP externe d’une machine virtuelle individuelle. Vous devez spécifier à la fois les options /Name et /IP sur la ligne de commande. Vous pouvez afficher le nom externe et l’adresse IP externe d’un ordinateur virtuel dans la visionneuse d’environnement de Lab Management ou à partir de la description de l’ordinateur virtuel dans SCVMM Console Administrateur.

Exemples

Dans le premier exemple, les enregistrements de tous les environnements isolés du réseau d’un projet sont ajoutés à DNS. Dans le deuxième exemple, un enregistrement DNS individuel est supprimé.

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

la commande TfsConfig Lab/DNS ajoute, supprime ou affiche les enregistrements DNS créés par Visual Studio Lab Management pour les environnements isolés du réseau.

TfsConfig Lab /DNS 
{/Add | /Delete | /List}
    [/CollectionName:collectionName |
    / CollectionName:collectionName /TeamProject:projectName |
    / CollectionName:collectionName /TeamProject:projectName /LabEnvironment:environmentUri |
    /Name:FQDN /IP:IpAddress]
    [/NoPrompt]
Option Description
Ajouter Ajoute les enregistrements DNS spécifiés. Pour utiliser l’option /Add , les environnements ciblés doivent être en cours d’exécution.
Supprimer Supprime les enregistrements DNS spécifiés.
Liste Affiche les enregistrements DNS spécifiés.
LabEnvironment : environmentUri Cible les options /Add, /Delete ou /List dans un environnement isolé du réseau individuel spécifié par environmentUri.

Pour utiliser l’option LabEnvironment , vous devez également spécifier les options /collection et /TeamProject .
Teamproject : ProjectName En cas d’utilisation sans /LabEnvironment, cible les options /Add, /Delete ou /List pour tous les environnements isolés du réseau dans le projet spécifié par ProjectName. Sinon, /TeamProject spécifie le projet qui contient l’environnement.

Pour utiliser l’option /TeamProject , vous devez également spécifier l’option /collection .
CollectionName : CollectionName En cas d’utilisation sans /TeamProject, cible les options /Add, /Delete ou /List pour tous les environnements isolés du réseau dans la collection de projets spécifiée par NomCollection. Dans le cas contraire, /collection spécifie la collection de projets qui contient le projet.
Nom : DOMAINE complet Spécifie le nom de domaine complet de l’emplacement réseau qui contient l’environnement à cibler.

Vous devez spécifier les options /Name et /IP ensemble.
Adresse IP : IPAddress Spécifie l’adresse IP de l’environnement à cibler.

Vous devez spécifier les options /Name et /IP ensemble.

Remarques

Azure DevOps Server utilise le suffixe que vous entrez lorsqu’il enregistre un nom externe unique avec DNS pour chaque ordinateur virtuel dans un environnement isolé du réseau. L'enregistrement d'alias DNS permet aux ordinateurs et autres objets en dehors du réseau isolé de communiquer avec des ordinateurs situés dans le réseau isolé. étant donné que Azure DevOps Server accède à la zone DNS pour enregistrer l’alias, le compte de service sous lequel Azure DevOps s’exécute doit disposer des autorisations pour ajouter ou supprimer des enregistrements d’alias dans la zone dns spécifiée.

si votre déploiement de Azure DevOps Server a plusieurs couches application et que chaque couche application s’exécute sous un compte de service différent, chaque compte de service de la couche application doit avoir l’autorisation de modifier les enregistrements d’alias DNS créés par les autres couches application.

Notes

La gestion des enregistrements DNS est effectuée automatiquement par Lab Management. Vous ne devez utiliser la commande /DNS que dans les cas suivants :

  • vous modifiez le compte sous lequel Azure DevOps Server s’exécute.
  • vous déplacez une collection de projets d’une instance de Azure DevOps Server vers une autre.

dans ces deux cas, les enregistrements dns créés à l’aide de l’ancien compte de service Azure DevOps Server doivent être supprimés, puis les mêmes enregistrements dns doivent être recréés à l’aide du nouveau compte de service Azure DevOps Server. si ces étapes ne sont pas effectuées dans les scénarios précédents, le nouveau compte de service Azure DevOps Server ne sera pas en mesure d’effectuer la gestion automatique de ces enregistrements DNS. Par conséquent, les utilisateurs ne seront pas en mesure de se connecter à des environnements virtuels.

Spécifiez une seule des options /Add, /Delete ou /List sur une ligne de commande TfsConfig Lab/DNS . si vous ne spécifiez pas d’options cibles, l’opération agit sur toutes les machines virtuelles de tous les environnements isolés du réseau qui appartiennent à toutes les collections de projets de la base de données Azure DevOps Server.

Pour cibler les entrées DNS des environnements isolés du réseau d’un objet dans la hiérarchie d’objets Lab Management, utilisez la combinaison appropriée des options /collection, /TeamProject et /LabEnvironment

  • L’option /LabEnvironment cible la commande dans l’environnement isolé du réseau spécifié. Vous devez utiliser les options /CollectionName et /TeamProject avec l’option /LabEnvironment pour spécifier la collection de projets et le projet qui contiennent l’environnement.

    Utilisez le format vstfs:///LabManagement/LabEnvironment/ environmentID pour spécifier l’URI de l’environnement. Vous pouvez afficher l’identificateur d’environnement (environmnetID) dans la visionneuse d’environnement de Lab Management ou à partir de la description de l’ordinateur virtuel dans SCVMM Console Administrateur.

  • L’option /TeamProject cible l’opération pour isoler les environnements réseau dans le projet spécifié. L’option /TeamProject doit être utilisée avec l’option /CollectionName et l’option /CollectionName doit spécifier la collection de projets qui contient le projet.

  • L’option /CollectionName cible l’opération pour les environnements isolés du réseau dans la collection de projets spécifiée.

La deuxième façon de cibler un environnement isolé du réseau consiste à utiliser les options /Name et /IP pour spécifier le nom externe complet et l’adresse IP externe d’une machine virtuelle individuelle. Vous devez spécifier à la fois les options /Name et /IP sur la ligne de commande. Vous pouvez afficher le nom externe et l’adresse IP externe d’un ordinateur virtuel dans la visionneuse d’environnement de Lab Management ou à partir de la description de l’ordinateur virtuel dans SCVMM Console Administrateur.

Exemples

Dans le premier exemple, les enregistrements de tous les environnements isolés du réseau d’un projet sont ajoutés à DNS. Dans le deuxième exemple, un enregistrement DNS individuel est supprimé.

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

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

/HostGroup Lab

utilisez les commandes TfsConfig Lab/HostGroup pour ajouter, modifier ou supprimer l’assignation d’un groupe hôte System Center Virtual Machine Manager (SCVMM) à une collection de projets.

les groupes hôtes affectés de cette manière sont gérés par Visual Studio Lab Management.

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

Option

Description

CollectionName : CollectionName

Obligatoire. Nom de la collection de projets sur le Azure DevOps Server de la couche application.

Ajouter

Ajoute le groupe hôte SCVMM spécifié aux groupes hôtes de la collection de projets. Vous devez spécifier les options /SCVmmHostGroup et /Name avec Add.

Supprimer

Supprime le groupe hôte spécifié de la collection de projets. Vous devez spécifier l’option /Name avec Delete.

Modifier

Définit l’une des Lab Management les propriétés AutoProvision et LabEnvironmentPlacementPolicy du groupe hôte, ou les deux.

Vous devez spécifier l’option /Name et au moins l’une des options /AutoProvision ou /LabEnvironmentPlacementPolicy avec Edit.

SCVMMHostGroup : vmmH ostGroupPath

Obligatoire avec l’option /Add . Spécifie le chemin d'accès d'ordinateur hôte du groupe hôte SCVMM.

Nom : nom

Obligatoire avec les options /Add, /Delete ou /Edit . Spécifiez le nom du groupe hôte de la collection de projets à ajouter, supprimer ou modifier.

Mise en service :{true | false}

Facultatif avec les options /Add ou /Edit . Définit (true) ou efface (false) la propriété AutoProvision du groupe hôte. AutoProvision spécifie si le groupe hôte est automatiquement attribué à chaque projet dans la collection. Par défaut, les groupes hôtes sont assignés aux projets d’une collection lorsque vous utilisez la commande TfsConfig Lab/HostGroup .

LabEnvironmentPlacementPolicy :{ | agressif classique}

Facultatif avec les options /Add ou /Edit . Spécifie comment Lab Management traite les ordinateurs physiques dans un groupe hôte sur lequel il déploie de nouveaux environnements Lab virtuels.

  • Conservateur (valeur par défaut). Tenir compte des environnements virtuels qui ne sont pas en cours d'exécution dans les décisions de déploiement. Cela comprend également toutes les machines virtuelles qui font partie d’environnements qui sont à l' " " état arrêté.
  • Agressive Ne tenez pas compte des environnements virtuels non exécutés dans les décisions de déploiement.

DNSSuffix :[DNSSuffix]

facultatif. Définit le suffixe DNS des ordinateurs virtuels dans le groupe hôte.

  • Si l’option /DNSSuffix : est spécifiée sans valeur DNSSuffix, définit ou réinitialise le suffixe DNS du suffixe des ordinateurs virtuels sur le suffixe de l’ordinateur hôte dans le groupe hôte.
  • Si l’option /DNSSuffix n’est pas spécifiée avec l’option /Add , le suffixe des ordinateurs virtuels est défini sur les suffixes des ordinateurs hôtes dans le groupe hôte.
  • Si l’option /DNSSuffix n’est pas spécifiée avec l’option /Edit , le suffixe des ordinateurs virtuels n’est pas modifié.

Commutateur noprompt

Facultatif avec les options /Delete ou /Edit . Ne pas demander à l'utilisateur de confirmer.

Liste

Affiche les groupes hôtes affectés à la collection de projets.

ListSCVmmHostGroups

Affiche les groupes hôtes disponibles à partir de SCVMM.

Remarques

Les groupes hôtes sont des conteneurs créés par un administrateur dans SCVMM pour regrouper un ensemble d'hôtes d'ordinateurs virtuels afin de les gérer plus aisément.

Les groupes hôtes sont hiérarchiques ; un groupe hôte peut contenir d'autres groupes hôtes.

Chaque groupe hôte est identifié par son chemin d'accès d'ordinateur hôte, une séquence de noms de groupe hôte qui spécifie l'emplacement d'un hôte ou d'un groupe hôte dans la hiérarchie de groupes hôtes dans SCVMM.

Tous les chemins d'accès d'ordinateur hôte commencent par le groupe hôte racine.

Par exemple, le chemin d’accès d’ordinateur hôte All Hosts\\New York\\Site21\\VMHost05 indique que l’hôte VMHost05 appartient au groupe hôte Site21, qui est un groupe hôte enfant du groupe hôte New York.

Utilisez une seule des options /Add, /Delete ou /Edit sur une ligne de commande. Utilisez des lignes de commande TfsConfig Lab/HostGroup distinctes pour affecter plusieurs groupes hôtes à une collection de projets.

Vous pouvez également utiliser les commandes TfsConfig Lab/HostGroup pour définir des propriétés spécifiques à Lab Management :

  • AutoProvision spécifie si le groupe hôte est assigné à chaque projet de la collection de projets.

Par défaut, AutoProvision est activé.

Pour assigner un groupe hôte d’une collection de projets à un projet individuel, utilisez la commande TFSLabConfig CreateTeamProjectHostGroup.

  • True (valeur par défaut). Le groupe hôte est assigné à chaque projet de la collection de projets.

  • Faux. Le groupe hôte n’est pas assigné à chaque projet de la collection de projets.

  • LabEnvironmentPlacementPolicy spécifie si Lab Management prend en compte les ordinateurs virtuels existants lorsqu’il déploie de nouveaux environnements sur un ordinateur physique dans un groupe hôte.

  • Conservateur (valeur par défaut). Tenir compte des environnements virtuels qui ne sont pas en cours d'exécution dans les décisions de déploiement. Cela comprend tous les ordinateurs virtuels qui font aussi partie d'environnements et dont l'état est « Arrêté ».

  • Agressive Ne tenez pas compte des environnements virtuels non exécutés dans les décisions de déploiement.

  • DNSSuffix spécifie un suffixe DNS à utiliser pour les ordinateurs virtuels créés dans le groupe hôte. Le tableau suivant décrit comment les suffixes DNS d'ordinateurs virtuels sont affectés par le paramètre /DnsSuffix.

DNSSuffix /Add /Edit
DNSSuffix : dnsValue Le suffixe DNS est défini sur dnsValue. Le suffixe DNS est défini sur dnsValue.
DnsSuffix Le suffixe DNS est hérité de l'ordinateur hôte. La valeur de suffixe existante est supprimée et le suffixe DNS est hérité de l'ordinateur hôte.
<Non spécifié> Le suffixe DNS est hérité de l'ordinateur hôte. Le suffixe DNS n'est pas modifié.

Exemple

Dans l’exemple suivant, un groupe hôte SCVMM est assigné à une collection de projets.

Étant donné que les options /AutoProvision ne sont pas spécifiées, le groupe hôte est automatiquement attribué à tous les projets de la collection.

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

utilisez les commandes TfsConfig Lab/HostGroup pour ajouter, modifier ou supprimer l’assignation d’un groupe hôte System Center Virtual Machine Manager (SCVMM) à une collection de projets.

les groupes hôtes affectés de cette manière sont gérés par Visual Studio Lab Management.

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

Option

Description

CollectionName : CollectionName

Obligatoire. Nom de la collection de projets sur le Azure DevOps Server de la couche application.

Ajouter

Ajoute le groupe hôte SCVMM spécifié aux groupes hôtes de la collection de projets. Vous devez spécifier les options /SCVmmHostGroup et /Name avec Add.

Supprimer

Supprime le groupe hôte spécifié de la collection de projets. Vous devez spécifier l’option /Name avec Delete.

Modifier

Définit l’une des Lab Management les propriétés AutoProvision et LabEnvironmentPlacementPolicy du groupe hôte, ou les deux.

Vous devez spécifier l’option /Name et au moins l’une des options /AutoProvision ou /LabEnvironmentPlacementPolicy avec Edit.

SCVMMHostGroup : vmmH ostGroupPath

Obligatoire avec l’option /Add . Spécifie le chemin d'accès d'ordinateur hôte du groupe hôte SCVMM.

Nom : nom

Obligatoire avec les options /Add, /Delete ou /Edit . Spécifiez le nom du groupe hôte de la collection de projets à ajouter, supprimer ou modifier.

Mise en service :{true | false}

Facultatif avec les options /Add ou /Edit . Définit (true) ou efface (false) la propriété AutoProvision du groupe hôte. AutoProvision spécifie si le groupe hôte est automatiquement attribué à chaque projet dans la collection. Par défaut, les groupes hôtes sont assignés aux projets d’une collection lorsque vous utilisez la commande TfsConfig Lab/HostGroup .

LabEnvironmentPlacementPolicy :{ | agressif classique}

Facultatif avec les options /Add ou /Edit . Spécifie comment Lab Management traite les ordinateurs physiques dans un groupe hôte sur lequel il déploie de nouveaux environnements Lab virtuels.

  • Conservateur (valeur par défaut). Tenir compte des environnements virtuels qui ne sont pas en cours d'exécution dans les décisions de déploiement. Cela comprend également toutes les machines virtuelles qui font partie d’environnements qui sont à l' " " état arrêté.
  • Agressive Ne tenez pas compte des environnements virtuels non exécutés dans les décisions de déploiement.

DNSSuffix :[DNSSuffix]

facultatif. Définit le suffixe DNS des ordinateurs virtuels dans le groupe hôte.

  • Si l’option /DNSSuffix : est spécifiée sans valeur DNSSuffix, définit ou réinitialise le suffixe DNS du suffixe des ordinateurs virtuels sur le suffixe de l’ordinateur hôte dans le groupe hôte.
  • Si l’option /DNSSuffix n’est pas spécifiée avec l’option /Add , le suffixe des ordinateurs virtuels est défini sur les suffixes des ordinateurs hôtes dans le groupe hôte.
  • Si l’option /DNSSuffix n’est pas spécifiée avec l’option /Edit , le suffixe des ordinateurs virtuels n’est pas modifié.

Commutateur noprompt

Facultatif avec les options /Delete ou /Edit . Ne pas demander à l'utilisateur de confirmer.

Liste

Affiche les groupes hôtes affectés à la collection de projets.

ListSCVmmHostGroups

Affiche les groupes hôtes disponibles à partir de SCVMM.

Remarques

Les groupes hôtes sont des conteneurs créés par un administrateur dans SCVMM pour regrouper un ensemble d'hôtes d'ordinateurs virtuels afin de les gérer plus aisément.

Les groupes hôtes sont hiérarchiques ; un groupe hôte peut contenir d'autres groupes hôtes.

Chaque groupe hôte est identifié par son chemin d'accès d'ordinateur hôte, une séquence de noms de groupe hôte qui spécifie l'emplacement d'un hôte ou d'un groupe hôte dans la hiérarchie de groupes hôtes dans SCVMM.

Tous les chemins d'accès d'ordinateur hôte commencent par le groupe hôte racine.

Par exemple, le chemin d’accès d’ordinateur hôte All Hosts\\New York\\Site21\\VMHost05 indique que l’hôte VMHost05 appartient au groupe hôte Site21, qui est un groupe hôte enfant du groupe hôte New York.

Utilisez une seule des options /Add, /Delete ou /Edit sur une ligne de commande. Utilisez des lignes de commande TfsConfig Lab/HostGroup distinctes pour affecter plusieurs groupes hôtes à une collection de projets.

Vous pouvez également utiliser les commandes TfsConfig Lab/HostGroup pour définir des propriétés spécifiques à Lab Management :

  • AutoProvision spécifie si le groupe hôte est assigné à chaque projet de la collection de projets.

Par défaut, AutoProvision est activé.

Pour assigner un groupe hôte d’une collection de projets à un projet individuel, utilisez la commande TFSLabConfig CreateTeamProjectHostGroup.

  • True (valeur par défaut). Le groupe hôte est assigné à chaque projet de la collection de projets.

  • Faux. Le groupe hôte n’est pas assigné à chaque projet de la collection de projets.

  • LabEnvironmentPlacementPolicy spécifie si Lab Management prend en compte les ordinateurs virtuels existants lorsqu’il déploie de nouveaux environnements sur un ordinateur physique dans un groupe hôte.

  • Conservateur (valeur par défaut). Tenir compte des environnements virtuels qui ne sont pas en cours d'exécution dans les décisions de déploiement. Cela comprend tous les ordinateurs virtuels qui font aussi partie d'environnements et dont l'état est « Arrêté ».

  • Agressive Ne tenez pas compte des environnements virtuels non exécutés dans les décisions de déploiement.

  • DNSSuffix spécifie un suffixe DNS à utiliser pour les ordinateurs virtuels créés dans le groupe hôte. Le tableau suivant décrit comment les suffixes DNS d'ordinateurs virtuels sont affectés par le paramètre /DnsSuffix.

DNSSuffix /Add /Edit
DNSSuffix : dnsValue Le suffixe DNS est défini sur dnsValue. Le suffixe DNS est défini sur dnsValue.
DnsSuffix Le suffixe DNS est hérité de l'ordinateur hôte. La valeur de suffixe existante est supprimée et le suffixe DNS est hérité de l'ordinateur hôte.
<Non spécifié> Le suffixe DNS est hérité de l'ordinateur hôte. Le suffixe DNS n'est pas modifié.

Exemple

Dans l’exemple suivant, un groupe hôte SCVMM est assigné à une collection de projets.

Étant donné que les options /AutoProvision ne sont pas spécifiées, le groupe hôte est automatiquement attribué à tous les projets de la collection.

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

/LibraryShare Lab

vous pouvez utiliser la commande TfsConfig Lab/LibraryShare pour ajouter, supprimer ou modifier l’assignation d’un partage de bibliothèque d’System Center Virtual Machine Manager (SCVMM) à une collection de projets. vous pouvez également utiliser cette commande pour définir des propriétés spécifiques à Visual Studio Lab Management et pour afficher les partages de bibliothèque qui sont actuellement assignés à une collection dans Lab Management ou pour afficher tous les partages de bibliothèque dans SCVMM.

TfsConfig Lab /LibraryShare
    /CollectionName:collectionName
     { /Add 
       /SCVMMLibraryShare:librarySharePath 
       /Name:name 
        [/AutoProvision:{True|False}]
    | /Delete 
       /Name:name 
        [/NoPrompt]
    | /Edit 
       /Name:name 
       /AutoProvision:{True|False} 
        [/NoPrompt]
    | /List
    | /ListSCVMMLibraryShares }
Option Description
Ajouter Ajoute le partage de bibliothèque spécifié à la collection de projets. Vous devez spécifier les options /SCVMMLibraryShare et /Name avec Add.
Supprimer Supprime le partage de bibliothèque spécifié de la collection de projets. Vous devez spécifier l’option /Name avec Delete.
Modifier Définit ou efface la propriété AutoProvision du partage de bibliothèque. Vous devez spécifier les options /Name et /AutoProvision avec Edit.

Par défaut, les partages de bibliothèque sont affectés aux projets d’une collection.

La modification de la configuration automatique affecte les projets existants.
CollectionName : CollectionName Obligatoire. Spécifiez le nom de la collection de projets sur le Azure DevOps Server de la couche application.
SCVMMLibraryShare : librarysharePath Obligatoire avec Add. spécifie le chemin d’accès au partage de bibliothèque Virtual Machine Manager.
Nom : paramètres LibraryShareName Obligatoire avec les ajouts, les suppressions et les modifications. Spécifie le nom du partage de bibliothèque dans la collection de projets.
AutoProvision Facultatif avec Add; obligatoire avec Edit. Spécifie si les partages de bibliothèque sont affectés automatiquement à chaque projet de la collection. Par défaut, les partages de bibliothèque sont affectés aux projets.
Commutateur noprompt Facultatif avec Add et Edit. Ne demandez pas à l'utilisateur de confirmer.
Liste Répertorie tous les partages de bibliothèque assignés à la collection de projets spécifiée.
ListSCVMMLibraryShares Répertorie tous les partages de bibliothèque disponibles dans Virtual Machine Manager.

Remarques

un partage de bibliothèque est un partage désigné sur un serveur de bibliothèque Virtual Machine Manager. Un partage de bibliothèque fournit un accès aux ressources de fichiers pour les environnements de Lab Management virtuels qui sont stockés sur vos serveurs de bibliothèque, tels que les images ISO et les disques durs virtuels. Les partages de bibliothèque sont créés dans Virtual Machine Manager. Visual Studio Lab Management utilise des partages de bibliothèque pour approvisionner des machines virtuelles dans le laboratoire.

Utilisez une seule des options /Add, /Edit ou /Delete sur une ligne de commande TfsConfig Lab/LibraryShare. Utilisez des lignes de commande TfsConfig Lab/LibraryShare distinctes pour assigner plusieurs partages de bibliothèque à une collection.

Par défaut, les partages de bibliothèque d’une collection de projets sont affectés automatiquement à chacun des projets de la collection. Vous pouvez utiliser l’option /AutoProvision avec les commandes /Add et /Edit pour modifier les partages de bibliothèque qui sont affectés.

  • Affectez à l’option /AutoProvision la valeur false pour désactiver l’attribution automatique du partage de bibliothèque aux projets. Pour affecter ou supprimer un partage de bibliothèque dans un projet individuel, utilisez la commande TFSLabConfig TFSLabConfig CreateTeamProjectLibraryShare.

  • Affectez la valeur true à l’option /AutoProvision pour activer les affectations automatiques.

vous pouvez utiliser la commande TfsConfig Lab/LibraryShare pour ajouter, supprimer ou modifier l’assignation d’un partage de bibliothèque d’System Center Virtual Machine Manager (SCVMM) à une collection de projets. vous pouvez également utiliser cette commande pour définir des propriétés spécifiques à Visual Studio Lab Management et pour afficher les partages de bibliothèque qui sont actuellement assignés à une collection dans Lab Management ou pour afficher tous les partages de bibliothèque dans SCVMM.

TfsConfig Lab /LibraryShare
        /CollectionName:collectionName
        { /Add
            /SCVMMLibraryShare:librarySharePath
            /Name:name
            [/AutoProvision:{True|False}]
        | /Delete
            /Name:name
            [/NoPrompt]
        | /Edit
            /Name:name
            /AutoProvision:{True|False}
            [/NoPrompt]
        | /List
        | /ListSCVMMLibraryShares }
Option Description
Ajouter Ajoute le partage de bibliothèque spécifié à la collection de projets. Vous devez spécifier les options /SCVMMLibraryShare et /Name avec Add.
Supprimer Supprime le partage de bibliothèque spécifié de la collection de projets. Vous devez spécifier l’option /Name avec Delete.
Modifier Définit ou efface la propriété AutoProvision du partage de bibliothèque. Vous devez spécifier les options /Name et /AutoProvision avec Edit.

Par défaut, les partages de bibliothèque sont affectés aux projets d’une collection.

[!NOTE] La modification de la configuration automatique affecte les projets existants.
CollectionName : CollectionName Obligatoire. Spécifiez le nom de la collection de projets sur le Azure DevOps Server de la couche application.
SCVMMLibraryShare : librarysharePath Obligatoire avec Add. spécifie le chemin d’accès au partage de bibliothèque Virtual Machine Manager.
Nom : paramètres LibraryShareName Obligatoire avec les ajouts, les suppressions et les modifications. Spécifie le nom du partage de bibliothèque dans la collection de projets.
AutoProvision Facultatif avec Add; obligatoire avec Edit. Spécifie si les partages de bibliothèque sont affectés automatiquement à chaque projet de la collection. Par défaut, les partages de bibliothèque sont affectés aux projets.
Commutateur noprompt Facultatif avec Add et Edit. Ne demandez pas à l'utilisateur de confirmer.
Liste Répertorie tous les partages de bibliothèque assignés à la collection de projets spécifiée.
ListSCVMMLibraryShares Répertorie tous les partages de bibliothèque disponibles dans Virtual Machine Manager.

Remarques

un partage de bibliothèque est un partage désigné sur un serveur de bibliothèque Virtual Machine Manager. Un partage de bibliothèque fournit un accès aux ressources de fichiers pour les environnements de Lab Management virtuels qui sont stockés sur vos serveurs de bibliothèque, tels que les images ISO et les disques durs virtuels. Les partages de bibliothèque sont créés dans Virtual Machine Manager. Visual Studio Lab Management utilise des partages de bibliothèque pour approvisionner des machines virtuelles dans le laboratoire.

Utilisez une seule des options /Add, /Edit ou /Delete sur une ligne de commande TfsConfig Lab/LibraryShare. Utilisez des lignes de commande TfsConfig Lab/LibraryShare distinctes pour assigner plusieurs partages de bibliothèque à une collection.

Par défaut, les partages de bibliothèque d’une collection de projets sont affectés automatiquement à chacun des projets de la collection. Vous pouvez utiliser l’option /AutoProvision avec les commandes /Add et /Edit pour modifier les partages de bibliothèque qui sont affectés.

  • Affectez à l’option /AutoProvision la valeur false pour désactiver l’attribution automatique du partage de bibliothèque aux projets. Pour affecter ou supprimer un partage de bibliothèque dans un projet individuel, utilisez la commande TFSLabConfig TFSLabConfig CreateTeamProjectLibraryShare.

  • Affectez la valeur true à l’option /AutoProvision pour activer les affectations automatiques.


Atelier/Settings

vous pouvez configurer Visual Studio Lab Management à l’aide de l’option TFSConfig Lab/Paramètres . l’option Paramètres

  • définit le nom du serveur System Center Virtual Machine Manager (SCVMM) qui contrôle l'administration des ordinateurs virtuels dans votre laboratoire ;

  • définit l'emplacement réseau, tel que le domaine de réseau ou groupe de travail, auquel les ordinateurs physiques dans tous les groupes hôtes peuvent se connecter ;

  • définit les adresses IP et suffixe DNS virtuel pour les réseaux isolés par réseau dans votre laboratoire.

TfsConfig Lab
    /Settings
        [/ScVmmServerName:VMMServerName]
        [/NetworkLocation:networkLocation]
        [/IpBlock:networkIsolationIpRange]
        [/DnsSuffix:networkIsolationDnsSuffix] 
        [/NoPrompt]
        [/List]
Option Description
ScvmmServerName : VMMServerName facultatif. définit le nom qualifié complet du serveur System Center Virtual Machine Manager 2008 (SCVMM) qui sera utilisé par Azure DevOps Server. Il s'agit du nom du serveur SCVMM qui sera utilisé pour gérer les ordinateurs virtuels. pour que Azure DevOps Server communiquent avec SCVMM, vous devez ajouter le compte sous lequel Azure DevOps Server s’exécute au rôle administrateur dans SCVMM.
NetworkLocation : NetworkLocation facultatif. Définit le nom qualifié complet d'un réseau, tel qu'un domaine de réseau ou groupe de travail, qui est disponible sur tous les hôtes dans votre réseau de laboratoire. Quand il configure un ordinateur virtuel, Lab Management connecte automatiquement l’ordinateur virtuel au réseau spécifié. Vous pouvez rechercher les emplacements réseau disponibles sur un hôte à l'aide de la console Administrateur SCVMM.
IpBlock : networkIsolationIpRange facultatif. Définit la plage d'adresses IP à assigner aux ordinateurs virtuels dans un environnement quand un réseau isolé est créé. Étant donné que les adresses IP sont utilisées uniquement pour le routage interne entre les machines virtuelles et ne sont pas exposées au-delà des limites d’un environnement, vous pouvez spécifier n’importe quelle plage IP qui n’est pas utilisée dans le réseau spécifié par l’option /NetworkLocation . Dans la plupart des cas, la plage par défaut 192.168.23.0/24 devrait fonctionner. Si vous rencontrez des problèmes pour vous connecter à des environnements isolés du réseau, vous devrez peut-être choisir une autre plage.
DNSSuffix : networkIsolationDnsSuffix facultatif. Définit le suffixe DNS qui sera utilisé pour inscrire les noms des ordinateurs virtuels sur le réseau isolé pour l'environnement virtuel. Pour vérifier que le suffixe est correctement configuré dans la hiérarchie DNS, contactez votre administrateur réseau.
Commutateur noprompt facultatif. Ne pas demander de confirmation. N’utilisez pas avec l’option /List .
Liste Répertorie les valeurs de configuration actuelles pour Lab Management.

Remarques

l’une des options /ScvmmServerName, /NetworkLocation, /IpBlock, /DnsSuffix ou /list doit être spécifiée sur chaque ligne de commande TfsConfig Lab/Paramètres .

Pour configurer Lab Management, vous devez spécifier les options /ScvmmServerName et /NetworkLocation . Toutefois, vous pouvez spécifier ces options sur des lignes de commande séparées.

Pour configurer l’isolement réseau, vous devez spécifier les options /IpBlock et /DNSSuffix . Toutefois, vous pouvez spécifier ces options sur des lignes de commande séparées.

L'isolement réseau vous permet d'utiliser plusieurs copies d'un ordinateur virtuel sans conflits de nom d'ordinateur ou d'adresse IP. Vous devez assigner un suffixe DNS et une plage IP pour un réseau isolé. Dans la mesure où les adresses IP ne sont utilisées que pour un routage entre ordinateurs virtuels et qu'elles ne sont pas exposées au-delà des limites d'un environnement, vous pouvez spécifier n'importe quelle plage IP qui n'est pas utilisée dans votre réseau public. Dans la plupart des cas, la plage par défaut 192.168.1.0/24 devrait fonctionner. Si vous rencontrez des problèmes pour vous connecter à des environnements isolés du réseau, vous devrez peut-être choisir une autre plage.

Exemples

Dans cet exemple, Lab Management est configurée à l’aide des options /ScvmmServerName et /NetworkLocation sur une seule ligne de commande.

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

Dans cet exemple, l’isolement réseau est configuré à l’aide des options /IpBlock et /DNSSuffix sur des lignes de commande distinctes.

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

vous pouvez configurer Visual Studio Lab Management à l’aide de l’option TFSConfig Lab/Paramètres . l’option Paramètres

  • définit le nom du serveur System Center Virtual Machine Manager (SCVMM) qui contrôle l'administration des ordinateurs virtuels dans votre laboratoire ;

  • définit l'emplacement réseau, tel que le domaine de réseau ou groupe de travail, auquel les ordinateurs physiques dans tous les groupes hôtes peuvent se connecter ;

  • définit les adresses IP et suffixe DNS virtuel pour les réseaux isolés par réseau dans votre laboratoire.

    TfsConfig Lab/Paramètres [/ScVmmServerName : VMMServerName] [/NetworkLocation : NetworkLocation] [/IpBlock : networkIsolationIpRange] [/DnsSuffix : networkIsolationDnsSuffix] [/noprompt] [/list]

Option Description
ScvmmServerName : VMMServerName facultatif. définit le nom qualifié complet du serveur System Center Virtual Machine Manager 2008 (SCVMM) qui sera utilisé par Azure DevOps Server. Il s'agit du nom du serveur SCVMM qui sera utilisé pour gérer les ordinateurs virtuels. pour que Azure DevOps Server communiquent avec SCVMM, vous devez ajouter le compte sous lequel Azure DevOps Server s’exécute au rôle administrateur dans SCVMM.
NetworkLocation : NetworkLocation facultatif. Définit le nom qualifié complet d'un réseau, tel qu'un domaine de réseau ou groupe de travail, qui est disponible sur tous les hôtes dans votre réseau de laboratoire. Quand il configure un ordinateur virtuel, Lab Management connecte automatiquement l’ordinateur virtuel au réseau spécifié. Vous pouvez rechercher les emplacements réseau disponibles sur un hôte à l'aide de la console Administrateur SCVMM.
IpBlock : networkIsolationIpRange facultatif. Définit la plage d'adresses IP à assigner aux ordinateurs virtuels dans un environnement quand un réseau isolé est créé. Étant donné que les adresses IP sont utilisées uniquement pour le routage interne entre les machines virtuelles et ne sont pas exposées au-delà des limites d’un environnement, vous pouvez spécifier n’importe quelle plage IP qui n’est pas utilisée dans le réseau spécifié par l’option /NetworkLocation . Dans la plupart des cas, la plage par défaut 192.168.23.0/24 devrait fonctionner. Si vous rencontrez des problèmes pour vous connecter à des environnements isolés du réseau, vous devrez peut-être choisir une autre plage.
DNSSuffix : networkIsolationDnsSuffix facultatif. Définit le suffixe DNS qui sera utilisé pour inscrire les noms des ordinateurs virtuels sur le réseau isolé pour l'environnement virtuel. Pour vérifier que le suffixe est correctement configuré dans la hiérarchie DNS, contactez votre administrateur réseau.
Commutateur noprompt facultatif. Ne pas demander de confirmation. N’utilisez pas avec l’option /List .
Liste Répertorie les valeurs de configuration actuelles pour Lab Management.

Remarques

l’une des options /ScvmmServerName, /NetworkLocation, /IpBlock, /DnsSuffix ou /list doit être spécifiée sur chaque ligne de commande TfsConfig Lab/Paramètres .

Pour configurer Lab Management, vous devez spécifier les options /ScvmmServerName et /NetworkLocation . Toutefois, vous pouvez spécifier ces options sur des lignes de commande séparées.

Pour configurer l’isolement réseau, vous devez spécifier les options /IpBlock et /DNSSuffix . Toutefois, vous pouvez spécifier ces options sur des lignes de commande séparées.

L'isolement réseau vous permet d'utiliser plusieurs copies d'un ordinateur virtuel sans conflits de nom d'ordinateur ou d'adresse IP. Vous devez assigner un suffixe DNS et une plage IP pour un réseau isolé. Dans la mesure où les adresses IP ne sont utilisées que pour un routage entre ordinateurs virtuels et qu'elles ne sont pas exposées au-delà des limites d'un environnement, vous pouvez spécifier n'importe quelle plage IP qui n'est pas utilisée dans votre réseau public. Dans la plupart des cas, la plage par défaut 192.168.1.0/24 devrait fonctionner. Si vous rencontrez des problèmes pour vous connecter à des environnements isolés du réseau, vous devrez peut-être choisir une autre plage.

Exemples

Dans cet exemple, Lab Management est configurée à l’aide des options /ScvmmServerName et /NetworkLocation sur une seule ligne de commande.

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

Dans cet exemple, l’isolement réseau est configuré à l’aide des options /IpBlock et /DNSSuffix sur des lignes de commande distinctes.

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

OfflineDetach

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

TfsConfig offlineDetach /configurationDB:<databaseName>
    /collectionDB:<databaseName>
Option Description
configurationDB Spécifie le nom de la base de données de configuration à utiliser.
collectionDB Spécifie le nom de la base de données de collection à détacher.

Prérequis

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

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 à la TfsConfig collection /detach place.

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

Au lieu de cela, vous pouvez désormais restaurer des copies cohérentes de la base de données de configuration et de la base de données de collection qui vous intéressent, puis 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 de 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 une instance de SQL s’exécutant sur un serveur nommé ContosoTemp sur l’instance nommée Backups .

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

Disponibilité des commandes : TFS 2015 Update 3 et versions ultérieures

Vous utilisez la commande OfflineDetach pour créer une base de données de collection hors connexion dans une base de données de collecte hors connexion détachée.

TFSConfig offlineDetach /configurationDB:DatabaseName
        /collectionDB:DatabaseName

Option

Description

/configurationDB

Spécifie le nom de la base de données de configuration à utiliser.

/collectionDB

Spécifie le nom de la base de données de collection à détacher.

Prérequis

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

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 Azure DevOps Server. si vos bases de données sont utilisées par un déploiement Azure DevOps Server, utilisez TfsConfig collection/detach à la place.

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

Au lieu de cela, vous pouvez désormais restaurer des copies cohérentes de la base de données de configuration et de la base de données de collection qui vous intéressent, puis 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 de 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 une instance de SQL s’exécutant sur un serveur nommé « ContosoTemp » sur l’instance nommée « sauvegardes ».

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

Proxy

vous pouvez utiliser la commande proxy pour mettre à jour ou modifier les paramètres utilisés par Azure DevOps serveur proxy. Azure DevOps Le serveur proxy 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 Azure DevOps serveur Proxy, vous pouvez réduire considérablement la bande passante nécessaire sur 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 téléchargements de fichiers continuent de s’afficher dans Azure DevOps Server. si vous utilisez la Azure DevOps Services pour héberger votre projet de développement dans le cloud, vous pouvez utiliser la commande Proxy pour non seulement gérer 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 de Azure DevOps serveur proxy et la configuration initiale du proxy,

consultez procédure : installer Azure DevOps serveur Proxy et configurer un site distant. pour plus d’informations sur la configuration du proxy sur les ordinateurs clients, consultez référence des commandes de contrôle de Version de Azure DevOps.

TfsConfig proxy /add|delete|change [/Collection:<teamProjectCollectionURL> /account:<accountName>]
    /Server:<TeamFoundationServerURL> [/inputs:Key1=Value1; Key2=Value2;...] [/continue]
Option Description
add Ajoute le serveur ou la collection spécifié(e) à la liste du proxy du fichier Proxy.config. Vous pouvez exécuter la commande /add plusieurs fois pour inclure davantage de collections ou de serveurs. lorsque vous utilisez/add avec une collection hébergée sur Azure DevOps Services, vous êtes invité à entrer vos informations d’identification sur Azure DevOps Services.
Modifier Modifie les informations d’identification stockées en tant que compte de service pour Azure DevOps Services. L’option/change est utilisée uniquement pour Azure DevOps Services ; elle ne doit pas être utilisée pour les déploiements locaux de Azure DevOps Server.
supprimer Supprime le serveur ou la collection spécifié(e) de la liste de proxy dans le fichier Proxy.config.
account Spécifie le compte utilisé comme compte de service pour le proxy dans Azure DevOps Services. cette option est utilisée uniquement pour les Azure DevOps Services conjointement avec l’option/change.

le compte de service par défaut utilisé pour Azure DevOps Services est " service de compte."
continue Reprend l'exécution de la commande même si le processus de vérification produit des avertissements.
Collection spécifie l’URL de la collection de projets hébergée sur Azure DevOps Services, au AccountName.DomainName/CollectionName format.
account Spécifie le nom du compte utilisé comme compte de service pour Azure DevOps Services. Si le nom du compte contient des espaces, le nom doit être placé entre guillemets ( " " ). Tous les caractères spéciaux dans les noms du compte doivent être spécifiés conformément à la syntaxe de ligne de commande.
account spécifie l’URL d’un déploiement de Azure DevOps Server, au ServerURL:Port/tfs format.
PersonalAccessTokenFile Spécifie éventuellement le chemin d’accès à un fichier qui contient un jeton d’accès personnel. Ce jeton sera utilisé pour l’authentification auprès du regroupement ou du compte lors de l’inscription d’un proxy. (Ajouté dans TFS 2018 Update 1)
inputs facultatif. Spécifie des paramètres et des valeurs supplémentaires à utiliser lors de la configuration du proxy.
Par exemple, les valeurs de GvfsProjectName et GvfsRepositoryName peuvent être utilisées pour configurer un référentiel git à utiliser avec le système de fichiers virtuel git (gvfs) (ajouté dans TFS 2018 Update 1)

Prérequis

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

Remarques

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 de 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 s’authentifier. ce jeton sera utilisé uniquement pour inscrire le proxy avec le 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 avec Azure DevOps Services sans demander 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 de 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 de compte utilisé pour Azure DevOps Services est HelenaPetersen.fabrikam.com et le compte de service utilisé par le proxy est remplacé par My Proxy Service Account . É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 pour une utilisation avec GVFS.

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

vous pouvez utiliser la commande TFSConfig Proxy pour mettre à jour ou modifier les paramètres utilisés par Team Foundation Server Proxy. Team Foundation Server Proxy 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 multisite. en configurant Team Foundation Server Proxy, vous pouvez réduire considérablement la bande passante nécessaire sur 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 téléchargements de fichiers continuent de s’afficher dans Azure DevOps Server. si vous utilisez la Azure DevOps Services pour héberger votre projet de développement dans le cloud, vous pouvez utiliser la commande Proxy pour non seulement gérer 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 de Azure DevOps serveur proxy et la configuration initiale du proxy,

consultez procédure : installer Azure DevOps serveur Proxy et configurer un site distant. pour plus d’informations sur la configuration du proxy sur les ordinateurs clients, consultez référence de commande Team Foundation Version Control.

TFSConfig Proxy /add|delete|change [/Collection:TeamProjectCollectionURL /account:AccountName]
            /Server:TeamFoundationServerURL [/inputs:Key1=Value1; Key2=Value2;...] [/Continue]

Option

Description

/add

Ajoute le serveur ou la collection spécifié(e) à la liste du proxy du fichier Proxy.config.

Vous pouvez exécuter la commande /add plusieurs fois pour inclure davantage de collections ou de serveurs.

lorsque vous utilisez/add avec une collection hébergée sur Azure DevOps Services, vous êtes invité à entrer vos informations d’identification sur Azure DevOps Services.

change

Modifie les informations d’identification stockées en tant que compte de service pour Azure DevOps Services.

L’option/change est utilisée uniquement pour Azure DevOps Services ; elle ne doit pas être utilisée pour les déploiements locaux de Azure DevOps Server.

/delete

Supprime le serveur ou la collection spécifié(e) de la liste de proxy dans le fichier Proxy.config.

/Account

Spécifie le compte utilisé comme compte de service pour le proxy dans Azure DevOps Services.

cette option est utilisée uniquement pour les Azure DevOps Services conjointement avec l’option/change.

le compte de service par défaut utilisé pour Azure DevOps Services est " service de compte."

/continue

Reprend l'exécution de la commande même si le processus de vérification produit des avertissements.

/Collection: TeamProjectCollectionURL

spécifie l’URL de la collection de projets hébergée sur Azure DevOps Services, au AccountName.DomainName/CollectionName format.

/Account: AccountName

Spécifie le nom du compte utilisé comme compte de service pour Azure DevOps Services.

Si le nom du compte contient des espaces, le nom doit être placé entre guillemets ( " " ).

Tous les caractères spéciaux dans les noms du compte doivent être spécifiés conformément à la syntaxe de ligne de commande.

/Account: ServerURL

spécifie l’URL d’un déploiement de Azure DevOps Server, au ServerURL:Port/tfs format.

/PersonalAccessTokenFile:P athtofilewithpat

Spécifie éventuellement le chemin d’accès à un fichier qui contient un jeton d’accès personnel. Ce jeton sera utilisé pour l’authentification auprès du regroupement ou du compte lors de l’inscription d’un proxy. (Ajouté dans TFS 2018 Update 1)

/Inputs: key1 = value1 ; Key2 = value2 ;...

facultatif. Spécifie des paramètres et des valeurs supplémentaires à utiliser lors de la configuration du proxy.

Par exemple, les valeurs de " GvfsProjectName " et " GvfsRepositoryName " peuvent être utilisées pour configurer un référentiel git pour une utilisation avec le système de fichiers virtuel git (GVFS) (ajouté dans TFS 2018 Update 1)

Prérequis

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

Remarques

utilisez la commande Proxy pour mettre à jour la configuration existante de Azure DevOps serveur 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 s’authentifier. ce jeton sera utilisé uniquement pour inscrire le proxy avec le 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 avec Azure DevOps Services sans demander 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 de proxys. Cet exemple utilise un jeton d’accès personnel pour s’authentifier auprès de la collection spécifiée avec le paramètre « /collection ». 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

The following example shows how to change the service account used by the proxy for the project collection hosted on Azure DevOps Services. The collection is named PhoneSaver, the account name used for Azure DevOps Services is HelenaPetersen.fabrikam.com, and the service account used by the proxy is being changed to "My Proxy Service Account". Because the account name contains spaces, quotation marks are used to enclose the name.

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

L’exemple suivant montre comment ajouter un référentiel git pour une utilisation avec GVFS.

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

RebuildWarehouse,

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

TfsConfig rebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]
Option Description
analysisServices Obligatoire si /All n’est pas utilisé. Spécifie que seule la base de données pour Analysis Services sera régénérée. Si aucune base de données n’existe pour Analysis Services, vous devez également utiliser l’option /reportingDataSourcePassword .
all Obligatoire si /analysisServices n’est pas utilisé. spécifie que toutes les bases de données de création de rapports et d’analyse que Azure DevOps Server utilise sont reconstruites.
reportingDataSourcePassword Obligatoire si la base de données TFS_Analysis n'existe pas. spécifie le mot de passe du compte utilisé comme compte de sources de données pour SQL Server Reporting Services (TFSReports). Pour plus d’informations, consultez comptes de service et dépendances dans Azure DevOps Server.

Prérequis

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

  • le groupe de sécurité administrateurs Azure DevOps et le groupe de sécurité administrateurs sur le serveur ou les serveurs qui exécutent la console administration de Azure DevOps

  • le groupe sysadmin sur le 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 des 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 de 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 rapports dans la console Administration de Azure DevOps. pour plus d’informations, consultez ouvrir la Console Administration de Azure DevOps.

Exemple

L’exemple suivant montre comment régénérer 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.

vous pouvez utiliser la commande rebuildwarehouse, pour régénérer le SQL Server Reporting Services et SQL Server Analysis Services bases de données que Visual Studio Team Foundation Server (TFS) utilise.

TFSConfig RebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]

Option

Description

/analysisServices

Obligatoire si /All n’est pas utilisé.

Spécifie que seule la base de données pour Analysis Services sera régénérée.

Si aucune base de données n’existe pour Analysis Services, vous devez également utiliser l’option /reportingDataSourcePassword .

All

Obligatoire si /analysisServices n’est pas utilisé.

spécifie que toutes les bases de données de création de rapports et d’analyse que Azure DevOps Server utilise sont reconstruites.

/ReportingDataSourcePassword : De

Obligatoire si la base de données TFS_Analysis n'existe pas.

spécifie le mot de passe du compte utilisé comme compte de sources de données pour SQL Server Reporting Services (TFSReports).

Pour plus d’informations, consultez comptes de service et dépendances dans Azure DevOps Server.

Prérequis

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

  • le groupe de sécurité administrateurs Team Foundation et le groupe de sécurité Administrateurs sur le serveur ou les serveurs qui exécutent la console Administration de Azure DevOps

  • le groupe sysadmin sur le 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 des 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 de 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 rapports dans la console Administration de Azure DevOps. pour plus d’informations, consultez ouvrir la Console d’Administration Azure DevOps>.

Exemple

L’exemple suivant montre comment régénérer la base de données Analysis Services pour un déploiement de Azure DevOps Server.

TFSConfig RebuildWarehouse /analysisServices

TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
The Analysis Services database was successfully rebuilt.

RegisterDB

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

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

Prérequis

pour utiliser la commande registerDB , vous devez être membre du groupe administrateurs Azure DevOps sur le serveur de couche application pour Azure DevOps et 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 des autorisations pour Azure DevOps Server.

Notes

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

Pour que la commande registerDB aboutisse, 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 l’instance SQL Server TeamDatabases .

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

utilisez RegisterDB pour mettre à jour le nom du serveur qui héberge la base de données de configuration dans Visual Studio Team Foundation Server (TFS). 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 [/usesqlalwayson]

Argument

Description

/SqlInstance : Nom du serveur

Obligatoire. spécifie le nom du serveur qui exécute SQL Server et le nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut.

Si vous spécifiez une instance, vous devez utiliser le format : ServerName\InstanceName .

/DatabaseName : DatabaseName

Obligatoire. Spécifie le nom de la base de données de configuration. Par défaut, il s'agit de Tfs_Configuration.

/usesqlalwayson

facultatif. Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server.

Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

pour plus d’informations, consultez [groupes de disponibilité AlwaysOn (SQL Server)] (/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Prérequis

pour utiliser la commande RegisterDB , vous devez être membre du groupe Team Foundation administrators sur le serveur de couche application pour Azure DevOps et 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 des autorisations pour Azure DevOps Server.

Notes

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 suivants et programmes doivent s'exécuter :

  • 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 l’instance SQL Server TeamDatabases.

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

RemapDBs

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 n’importe quelle base de données pour les collections de projets s’ils sont hébergés sur un serveur ou des serveurs distincts de la base de données de configuration. vous devez également rediriger les 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 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]
Option Description
nom_base_de_données spécifie le nom du serveur qui héberge la base de données que vous souhaitez mapper pour Azure DevOps Server, en plus du nom de la base de données elle-même.
SQLInstances spécifie le nom du serveur qui exécute SQL Server, en plus du nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut.

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

Prérequis

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 que Azure DevOps Server utilise. Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Notes

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 configuration TFS_Configuration . Cette base de données est hébergée sur ContosoMain l’instance nommée TeamDatabases . Ses bases de données de collection de projets sont stockées sur ContosoMain\TeamDatabases et sur l’instance par défaut sur Contoso2 .

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

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 TFS vers n’importe quelle base de données pour les collections de projets s’ils sont hébergés sur un ou plusieurs serveurs distincts de la base de données de configuration. vous devez également rediriger TFS 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 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] [/usesqlalwayson]

Option

Description

/DatabaseName

spécifie le nom du serveur qui héberge la base de données que vous souhaitez mapper pour Azure DevOps Server, en plus du nom de la base de données elle-même.

/SQLInstances : ServerName1,ServerName2

spécifie le nom du serveur qui exécute SQL Server, en plus du nom de l’instance si vous souhaitez utiliser une instance autre que l’instance par défaut.

Si vous spécifiez plusieurs serveurs, vous devez utiliser une virgule pour séparer plusieurs paires de noms de serveur et d’instance.

/AnalysisInstance : Nom du serveur

facultatif. spécifie le nom du serveur et de l’instance qui héberge SQL Server Analysis Services.

Utilisez cette option pour spécifier le serveur et l’instance qui héberge la base de données Analysis Services.

/AnalysisDatabaseName : DatabaseName

facultatif. spécifie le nom de la base de données Analysis Services que vous souhaitez utiliser avec Azure DevOps Server si vous avez plus d’une base de données de ce type sur le serveur que vous avez spécifiée avec l’option /AnalysisInstance .

/Preview

facultatif. Affiche les actions que vous devez effectuer pour mettre à jour la configuration.

/continue

facultatif. Spécifie que la commande RemapDB doit continuer même si une erreur se produit pendant la tentative de recherche d’une ou plusieurs bases de données.

Si vous utilisez l’option /continue , les regroupements dont les bases de données sont introuvables sur le serveur que vous spécifiez sont reconfigurés pour utiliser le serveur et l’instance qui hébergent la base de données de configuration.

/usesqlalwayson

facultatif. Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server.

Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

pour plus d’informations, consultez [groupes de disponibilité AlwaysOn (SQL Server)] (/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Prérequis

pour utiliser la commande RemapDBs , vous devez être membre du groupe de sécurité Team Foundation administrators et membre du groupe de sécurité sysadmin pour les bases de données de SQL Server que Azure DevOps Server utilise. Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Notes

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 configuration de base de données de configuration TFS _ . Cette base de données est hébergée sur ContosoMain sur l’instance nommée TeamDatabases. Ses bases de données de collection de projets sont stockées à la fois sur ContosoMain \ TeamDatabases et sur l’instance par défaut sur Contoso2.

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

RepairJobQueue

Vous utilisez la commande repairJobQueue pour corriger les tâches planifiées qui ont cessé de s’exécuter pour les hôtes de déploiement et de regroupement.

TfsConfig repairJobQueue

Prérequis

Pour utiliser la commande repairJobQueue , vous devez être membre 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 le déploiement Azure DevOps Server.

Remarques

En général, vous utilisez la commande repairJobQueue si vous remarquez que des tâches planifiées ne sont pas en cours d’exécution.
la commande ne prend pas d’argument et requiert la configuration du déploiement Azure DevOps Server.

Exemple

TfsConfig repairJobQueue

Disponibilité des commandes : TFS 2015

Vous utilisez la commande RepairJobQueue pour corriger les tâches planifiées qui ont cessé de s’exécuter pour les hôtes de déploiement et de regroupement.

TfsConfig repairJobQueue

Prérequis

Pour utiliser la commande RepairJobQueue , vous devez être membre 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 le déploiement Azure DevOps Server.

Remarques

En général, vous utilisez la commande RepairJobQueue si vous remarquez que des tâches planifiées ne sont pas en cours d’exécution.
la commande ne prend pas d’argument et requiert la configuration du déploiement Azure DevOps Server.

Exemple

TFSConfig repairJobQueue

Paramètres

Vous pouvez utiliser la commande paramètres pour automatiser les modifications apportées à l’URL (Uniform Resource Locator) qui est utilisée par l’interface de notification et pour l’adresse du serveur de 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 messages électroniques 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 interactivement ou simplement afficher les paramètres actuels, vous pouvez utiliser la console Administration de Azure DevOps. Consultez informations de référence rapide sur les tâches d’administration.

TfsConfig settings [/publicURL:URL]
Option Description
publicUrl Spécifie l’URL du serveur de couche application pour Azure DevOps. Cette valeur est stockée dans la base de données de configuration de Azure DevOps.

Prérequis

vous devez être membre du groupe de sécurité Azure DevOps administrateurs et du groupe administrateurs sur le serveur de couche application. Pour plus d’informations, consultez définir des autorisations d’administrateur pour Azure DevOps Server.

Notes

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 dans le déploiement.

Exemple

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

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

vous pouvez utiliser la commande Paramètres pour automatiser les modifications apportées à l’URL (uniform resource locator) qui est utilisée par l’interface de notification et pour l’adresse du serveur de 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 messages électroniques 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 interactivement ou simplement afficher les paramètres actuels, vous pouvez utiliser la console Administration de Azure DevOps. Consultez informations de référence rapide sur les tâches d’administration.

TFSConfig Settings [/ServerURL:URL] [/NotificationURL:URL]

Option

Description

/ServerURL : URL

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

/NotificationURL : URL

Spécifie l’URL à utiliser dans le texte des alertes par courrier électronique, si cette URL diffère de l’URL du serveur de couche application pour Azure DevOps. Cette valeur est stockée dans la base de données de configuration.

Prérequis

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

Notes

la commande Paramètres 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 /ServerURL doit être disponible pour tous les serveurs dans le déploiement.

Exemple

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

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

Programme d’installation

Vous utilisez la commande d’installation pour désinstaller des fonctionnalités qui sont actuellement configurées sur l’ordinateur où vous exécutez la commande.

TfsConfig setup /uninstall:<feature[,feature,...]>
Option Description
uninstall Spécifie une ou plusieurs fonctionnalités à désinstaller de l’ordinateur sur lequel vous exécutez la commande. Les options sont les suivantes : All, ApplicationTier, Search et VersionControlProxy.

Option

Description

/Uninstall

Specifiesoneormorefeaturestobeuninstalledfromthemachinewhereyourunthecommand. Optionsinclude : All, ApplicationTier, SharePointExtensions, Search, TeamBuild, andVersionControlProxy.

Option

Description

/Uninstall

Specifiesoneormorefeaturestobeuninstalledfromthemachinewhereyourunthecommand. Optionsinclude : All, ApplicationTier, SharePointExtensions, TeamBuild, VersionControlProxy.

Prérequis

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

Exemples

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

TfsConfig setup /uninstall:ALL

L’exemple suivant désinstalle la couche application et les fonctionnalités de génération de l’ordinateur actuel.

TfsConfig setup /uninstall:ApplicationTier,TeamBuild

TCM

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

En cas d’échec de la migration automatique, utilisez la commande TCM pour mettre à niveau manuellement vos plans de test et suites de tests vers leurs types d’éléments de travail respectifs.

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

Option

Description

/upgradeTestPlans

Obligatoire, sauf si /upgradeStatus est utilisé.

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

/upgradeStatus

Obligatoire, sauf si /upgradeTestPlans est utilisé.

Indique l’état de la migration des données de test pour le projet spécifié. Il indique également si le projet spécifié comprend des plans de test.

/CollectionName: CollectionName

Obligatoire. Spécifie la collection de projets qui contient le projet pour lequel vous souhaitez migrer les données de test ou vérifier l’état de la migration.

S’il y a des espaces dans le nom de la collection de projets, mettez le nom entre guillemets, par exemple, " Fabrikam Fiber collection " .

/TeamProjectName: NomProjetÉquipe

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

S’il y a des espaces dans le nom du projet, placez le nom entre guillemets, par exemple, " mon Project " .

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.

Notes

votre serveur de 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 sur l’utilisation de 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 des outils pour Azure DevOps Server. Par défaut, cet emplacement est : drive:\%programfiles%\TFS 12.0\Tools .

Vous utilisez la commande TCM uniquement dans le cas où la migration automatique des données de test existantes échoue.

Pour en savoir plus sur la migration et sur l’utilisation de cette commande, les mises à jour manuelles prennent en charge la gestion des tests. Si vous ne pouvez pas accéder à des plans de test ou à des suites de tests 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 à chaque fois sur chaque projet.

Exemples

L’exemple suivant montre comment vérifier l’état de la 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"

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.

En cas d’échec de la migration automatique, utilisez la commande TCM pour mettre à niveau manuellement vos plans de test et suites de tests vers leurs types d’éléments de travail respectifs.

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

Option

Description

/upgradeTestPlans

Obligatoire, sauf si /upgradeStatus est utilisé.

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

/upgradeStatus

Obligatoire, sauf si /upgradeTestPlans est utilisé.

Indique l’état de la migration des données de test pour le projet spécifié. Il indique également si le projet spécifié comprend des plans de test.

/CollectionName: CollectionName

Obligatoire. Spécifie la collection de projets qui contient le projet pour lequel vous souhaitez migrer les données de test ou vérifier l’état de la migration.

S’il y a des espaces dans le nom de la collection de projets, mettez le nom entre guillemets, par exemple, " Fabrikam Fiber collection " .

/TeamProjectName: NomProjetÉquipe

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

S’il y a des espaces dans le nom du projet, placez le nom entre guillemets, par exemple, " mon Project " .

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.

Notes

votre serveur de couche application doit être mis à niveau vers la dernière version de Azure DevOps Server 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 sur l’utilisation de 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 des outils pour Azure DevOps Server. Par défaut, cet emplacement est : drive:\%programfiles%\TFS 12.0\Tools .

Vous utilisez la commande TCM uniquement dans le cas où la migration automatique des données de test existantes échoue.

Pour en savoir plus sur la migration et sur l’utilisation de cette commande, les mises à jour manuelles prennent en charge la gestion des tests.

Si vous ne pouvez pas accéder à des plans de test ou à des suites de tests 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 à chaque fois sur chaque projet.

Exemples

L’exemple suivant montre comment vérifier l’état de la 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"

Installation sans assistance

disponibilité des commandes : Azure DevOps Server 2019

la commande d’installation sans assistance est destinée aux utilisateurs qui sont familiarisés avec Azure DevOps Server et le processus de configuration, et qui doivent installer Azure DevOps Server sur des ordinateurs différents.

par exemple, si vous utilisez Azure DevOps build, vous pouvez utiliser la commande d’installation sans assistance pour installer plusieurs serveurs de builds à l’aide du même fichier de configuration.

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

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

TfsConfig unattend /create|configure /type:InstallType /unattendfile:ConfigurationFileName 
    [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]
Option Description
create Crée le fichier d'installation sans assistance avec le nom et les paramètres spécifiés.
CONFIGURER configure Azure DevOps Server à l’aide du fichier d’installation sans assistance et des paramètres que vous spécifiez. Vous devez utiliser/type ou/unattendfile avec cette option.
type Spécifie le type de configuration à utiliser. L'utilisation de /configure nécessite soit /type, soit /unattendfile, mais pas les deux.
unattendfile Spécifie le fichier d'installation sans assistance à créer ou à utiliser selon que le paramètre initial est /create ou /configure. L'utilisation de /configure nécessite soit /unattendfile, soit /type.
inputs facultatif. Si vous utilisez /create, spécifie les paramètres et les valeurs à utiliser lors de la création du fichier d'installation sans assistance. Si vous utilisez /configure, spécifie les paramètres et les valeurs supplémentaires à utiliser conjointement avec le fichier d'installation sans assistance.

Au lieu d'utiliser /inputs, vous pouvez modifier manuellement le fichier d'installation sans assistance dans un éditeur de texte brut. Cela est nécessaire pour certains types d’entrée, tels que ServiceAccountPassword ou PersonalAccessToken, car ces valeurs de secret ne peuvent pas être définies à l’aide du paramètre/inputs.
verify facultatif. Spécifie une passe de configuration qui procède uniquement aux contrôles de vérification en fonction du fichier autonome, des entrées et du type de configuration. Cela peut éviter de devoir effectuer une configuration complète.
continue facultatif. Spécifie que /create ou /configure doivent continuer en dépit des avertissements des contrôles de vérification.
InstallType (type d'installation) Description
NewServerBasic Configure les services de développement essentiels pour Azure DevOps Server. Cela comprend le contrôle de code source, les éléments de travail, la génération et éventuellement la recherche.
NewServerAdvanced Configure les services de développement essentiels et permet la configuration facultative de l’intégration avec Reporting Services.
Mettre à niveau met à niveau Azure DevOps Server vers la version actuelle à partir d’une version antérieure prise en charge.
PreProductionUpgrade testez la mise à niveau sur un déploiement de Azure DevOps Server existant dans un environnement de pré-production. Cette opération s’effectue généralement à l’aide de bases de données restaurées à partir de sauvegardes de production. Ce scénario comprend des étapes supplémentaires pour garantir que le nouveau déploiement n’interfère pas avec le déploiement de production.
ApplicationTierOnlyBasic Configurez une nouvelle couche application à l’aide des paramètres existants de la base de données de configuration fournie. Cette option vous permet d’obtenir rapidement une nouvelle couche application en utilisant les paramètres existants. Si vous souhaitez pouvoir modifier des paramètres existants, utilisez le type de ApplicationTierOnlyAdvanced avancé à la place.
ApplicationTierOnlyAdvanced Configurez une nouvelle couche application avec un contrôle total sur tous les paramètres. Paramètres utilise par défaut les valeurs existantes de la base de données de configuration fournie. Si vous souhaitez conserver tous vos paramètres existants, utilisez le type ApplicationTierOnlyBasic à la place.
Clone configurez un nouveau déploiement de Azure DevOps Server qui est un clone d’un déploiement existant. Cette opération est généralement effectuée à l’aide de bases de données restaurées à partir de sauvegardes de production, afin de créer un environnement dans lequel les modifications de configuration, les extensions et les autres modifications peuvent être testées. Ce scénario comprend des étapes supplémentaires pour garantir que le nouveau déploiement n’interfère pas avec le déploiement de production.
Proxy Configure un service proxy de contrôle de version.

Prérequis

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

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

par exemple, si vous utilisez la commande d’installation sans assistance 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 & d’une section Ajouter des administrateurs de niveau serveur à Azure DevOps Server.

Notes

avant de pouvoir utiliser la commande d' installation sans assistance pour configurer Azure DevOps Server, vous devez créer les comptes de service que vous allez utiliser dans le cadre de votre déploiement. Vous devez aussi installer les logiciels requis pour votre type d'installation, cela comprend Azure DevOps Server lui-même. vous devez installer Azure DevOps Server, mais vous n’êtes pas obligé de le configurer, car la commande d' installation sans assistance le fera pour vous.

la commande d' installation sans assistance 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 d’installation 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 lors de 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 d’installation sans assistance pour la configuration d’un serveur Proxy Azure DevOps.

Important

Dans cet exemple, si les administrateurs veulent utiliser un jeton d’accès personnel pour l’authentification, ils devront modifier manuellement le fichier pour spécifier la valeur du jeton d’accès personnel. Pour ce faire, vous pouvez ajouter une ligne pour le jeton d’accès personnel dans le fichier d’installation sans assistance, tel que : PersonalAccessToken=PersonalAccessTokenValue .

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

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

Important

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

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

La première commande retourne ce qui suit :

Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Command: unattend
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203133.log

la deuxième commande retourne les informations suivantes, y compris le nom du serveur sur lequel Azure DevOps Build a été configurée 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

Disponibilité des commandes : TFS 2018, TFS 2017, TFS 2015, TFS 2013

la commande d’installation sans assistance est destinée aux utilisateurs qui sont familiarisés avec Azure DevOps Server et le processus de configuration, et qui doivent installer Azure DevOps Server sur des ordinateurs différents.

Par exemple, si vous utilisez Team Foundation Build, vous pouvez utiliser la commande d’installation sans assistance pour installer plusieurs serveurs de builds à l’aide du même fichier de configuration.

Utilisez l’option Unattend /Create pour créer un fichier d’installation sans assistance. ce fichier définit tous les paramètres de configuration d’une installation Azure DevOps Server. Ensuite, utilisez l’option Unattend/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|unattend /type:InstallType /unattendfile:ConfigurationFileName [/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]

Option

Description

/Create

Crée le fichier d'installation sans assistance avec le nom et les paramètres spécifiés.

/configure

configure Azure DevOps Server à l’aide du fichier d’installation sans assistance et des paramètres que vous spécifiez.

Vous devez utiliser/type ou/unattendfile avec cette option.

/type: InstallType

Spécifie le type de configuration à utiliser.

  • de base : configure Azure DevOps Server dans la configuration de base, y compris SQL Server Express.

  • standard : configure Azure DevOps Server dans la configuration de serveur unique standard.

  • ATOnly : configure une couche application supplémentaire pour un déploiement de Azure DevOps Server existant.

  • Build : configure le service Team Foundation Build.

  • proxy : configure Azure DevOps serveur proxy.

  • réinstallation : installe et configure SharePoint Foundation 2013 pour une utilisation avec un déploiement Azure DevOps Server.

  • mise à niveau : met à niveau une version précédente de Azure DevOps Server vers la dernière version du logiciel.

Vous devez télécharger et installer cette version localement avant d'exécuter cette commande avec /configure.

  • extensions : configure les Extensions de SharePoint pour les Azure DevOps Server.

L'utilisation de /configure nécessite soit /type, soit /unattendfile, mais pas les deux.

/unattendfile: ConfigurationFileName

Spécifie le fichier d'installation sans assistance à créer ou à utiliser selon que le paramètre initial est /create ou /configure. L'utilisation de /configure nécessite soit /unattendfile, soit /type.

/Inputs: key1 = value1 ; Key2 = value2 ;...

facultatif. Si vous utilisez /create, spécifie les paramètres et les valeurs à utiliser lors de la création du fichier d'installation sans assistance.

Si vous utilisez /configure, spécifie les paramètres et les valeurs supplémentaires à utiliser conjointement avec le fichier d'installation sans assistance.

Au lieu d'utiliser /inputs, vous pouvez modifier manuellement le fichier d'installation sans assistance dans un éditeur de texte brut.

Cela est nécessaire pour certains types d’entrée, tels que ServiceAccountPassword ou PersonalAccessToken, car ces valeurs de secret ne peuvent pas être définies à l’aide du paramètre/inputs.

/Verify

facultatif. Spécifie une passe de configuration qui procède uniquement aux contrôles de vérification en fonction du fichier autonome, des entrées et du type de configuration.

Cela peut éviter de devoir effectuer une configuration complète.

/continue

facultatif. Spécifie que /create ou /configure doivent continuer en dépit des avertissements des contrôles de vérification.

/?

facultatif. Fournit de l'aide sur la ligne de commande pour la commande d'installation sans assistance.

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 d’installation sans assistance 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 & d’une section de définir des autorisations d’administrateur pour Azure DevOps Server.

Notes

avant de pouvoir utiliser la commande d' installation sans assistance pour configurer Azure DevOps Server, vous devez créer les comptes de service que vous allez utiliser dans le cadre de votre déploiement. Vous devez aussi installer les logiciels requis pour votre type d'installation, cela comprend Azure DevOps Server lui-même. vous devez installer Azure DevOps Server, mais vous n’êtes pas obligé de le configurer, car la commande d' installation sans assistance le fera pour vous.

la commande d’installation sans assistance 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 d’installation 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 lors de 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 d’installation sans assistance pour la configuration d’un serveur Proxy Azure DevOps.

Important : Dans cet exemple, si les administrateurs veulent utiliser un jeton d’accès personnel pour l’authentification, ils devront modifier manuellement le fichier pour spécifier la valeur du jeton d’accès personnel. Pour ce faire, vous pouvez ajouter une ligne pour le jeton d’accès personnel dans le fichier d’installation sans assistance créé, par exemple : " PersonalAccessToken = PersonalAccessTokenValue " .

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

L’exemple suivant montre comment créer un fichier d’installation sans assistance pour la configuration de Team Foundation Build sur un serveur à l’aide de « FabrikamFiber \ BuildSVC » comme compte de service de build, puis configurer Team Foundation Build à l’aide de ce fichier d’installation sans assistance.

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

TFSConfig Unattend /create /type:build /unattendfile:configTFSBuild.ini
        /inputs:IsServiceAccountBuiltIn=false;ServiceAccountName=FabrikamFiber\\BuildSVCTFSConfig
        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, y compris le nom du serveur où Team Foundation Build a été configuré (FabrikamFiberTFS) et la collection de projets associée au contrôleur (DefaultCollection) :

Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Command: unattend

---------------------------------------------
        Inputs:
---------------------------------------------

Feedback
        Send Feedback: True

Build Resources
        Configuration Type: create
        Agent Count: 1
        New Controller Name: FabrikamFiberTFS - Controller
        Clean Up Resources: False

Project Collection
        Collection URL: http://FabrikamFiberTFS:8080/tfs/defaultcollection

Windows Service
        Service Account: FabrikamFiber\BuildSVC
        Service Password: ********

Advanced Settings *
        Port: 9191


---------------------------------------------
        Running Readiness Checks
---------------------------------------------

[1/2] System Verifications
[2/2] Build Service Verifications

---------------------------------------------
        Configuring
---------------------------------------------

        root
[1/4] Install Team Foundation Build Service
        Installing Windows services ...
        Adding service account to groups ...
        Setting ACL on a windows service
[2/4] Enable Event Logging
        Adding event log sources ...
        Token replace a config file
        RegisterBuildEtwProvider
        Configuring ETW event sources ...
[3/4] Register with Team Foundation Server
        Registering the build service
[4/4] Start Team Foundation Build Service
        StartBuildHost
        Starting Windows services ...
        Marking feature configured status
[Info] [Register with Team Foundation Server] Firewall exception added for port
9191


TeamBuild completed successfully.
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203322.log

ZipLogs

La commande ziplogs est conçue pour collecter des journaux et dépose un fichier zip à l’adresse ProgramData\Microsoft\Azure DevOps\Server Configuration .

TfsConfig zipLogs

TfsConfig zipLogs

Commandes déconseillées

Licence

Vous pouvez utiliser la commande licence pour afficher, modifier ou étendre la clé de licence de votre déploiement de Azure DevOps Server.

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

Option

Description

/ProductKey : Essentiel

Spécifie que la clé de licence pour le déploiement sera mise à jour avec la valeur de clé.

/extend

spécifie que la période de licence d’évaluation de Azure DevOps Server sera prolongée de 30 jours. Cette option ne peut être utilisée qu’une seule fois sans obtenir de nouvel ID d’évaluation. Si une deuxième extension est requise, vous devez obtenir une deuxième licence d’évaluation de la part de Microsoft.

Prérequis

pour utiliser la commande de licence , vous devez être membre du groupe de sécurité Azure DevOps administrateurs. Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Notes

Pour afficher, modifier ou modifier de manière interactive la licence de votre déploiement, vous pouvez utiliser la console Administration de Azure DevOps. pour plus d’informations, consultez ouvrir la Console Administration de Azure DevOps et rechercher ou modifier la clé de produit pour Azure DevOps Server.

Exemples

L’exemple suivant montre comment afficher les informations de licence pour un déploiement de Azure DevOps Server. Dans cet exemple, le déploiement utilise une licence d’évaluation.

TFSConfig License

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

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

TCM

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.

En cas d’échec de la migration automatique, utilisez la commande TCM pour mettre à niveau manuellement vos plans de test et suites de tests vers leurs types d’éléments de travail respectifs.

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

Option

Description

/upgradeTestPlans

Obligatoire, sauf si /upgradeStatus est utilisé.

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

/upgradeStatus

Obligatoire, sauf si /upgradeTestPlans est utilisé.

Indique l’état de la migration des données de test pour le projet spécifié. Il indique également si le projet spécifié comprend des plans de test.

/CollectionName: CollectionName

Obligatoire. Spécifie la collection de projets qui contient le projet pour lequel vous souhaitez migrer les données de test ou vérifier l’état de la migration.

S’il y a des espaces dans le nom de la collection de projets, mettez le nom entre guillemets, par exemple, " Fabrikam Fiber collection " .

/TeamProjectName: NomProjetÉquipe

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

S’il y a des espaces dans le nom du projet, placez le nom entre guillemets, par exemple, " mon Project " .

Prérequis

vous devez être membre du groupe de sécurité administrateurs Azure DevOps et administrateur sur le serveur de couche application.

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

Notes

votre serveur de couche application doit être mis à niveau vers la dernière version de Azure DevOps Server 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 sur l’utilisation de 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 des outils pour Azure DevOps Server. Par défaut, cet emplacement est : drive:\%programfiles%\TFS 12.0\Tools .

Vous utilisez la commande TCM uniquement dans le cas où la migration automatique des données de test existantes échoue.

Pour en savoir plus sur la migration et sur l’utilisation de cette commande, les mises à jour manuelles prennent en charge la gestion des tests.

Si vous ne pouvez pas accéder à des plans de test ou à des suites de tests 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 à chaque fois sur chaque projet.

Exemples

L’exemple suivant montre comment vérifier l’état de la 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"

Importer

La commande d’importation a été dépréciée dans TFS 2013. Les versions antérieures sont disponibles ici :

si vous avez besoin d’aide pour la mise à niveau de données et de projets à partir d’une version antérieure de Azure DevOps Server, consultez mettre à niveau Azure DevOps Serverou contacter Support Microsoft.

PrepareSQL

La commande prepareSQL a été depracated dans TFS 2012. Les versions antérieures sont disponibles ici :

Réparation

La commande de réparation était depracated dans TFS 2012. Les versions antérieures sont disponibles ici :

Si vous avez besoin de réparer vos procédures stockées après l’échec d’un correctif de base de données, contactez support Microsoft.

Diagnose

La commande de diagnostic a été dépréciée dans TFS 2013. Les versions antérieures sont disponibles ici :

si vous avez besoin d’aide pour diagnostiquer les incompatibilités potentielles entre les mises à jour logicielles sur vos serveurs de couche application et de couche données pour Azure DevOps Server, contactez le support technique du Community des développeurs.

Mises à jour

La commande Updates a été dépréciée dans TFS 2013. les versions antérieures sont disponibles ici :

si vous avez besoin d’aide pour installer les mises à jour logicielles manquantes dans les bases de données pour Azure DevOps Server, contactez Support Microsoft.

PrepareClone

La commande PrepareClone a été dépréciée dans TFS 2017.

la commande PrepareClone supprime des informations sur les sauvegardes planifiées, les SharePoint et les ressources de création de rapports à partir d’un déploiement Azure DevOps Server.

Utilisez cette commande dans les situations suivantes :

  • Lorsque vous déplacez un déploiement vers un nouveau matériel, mais que vous souhaitez continuer à utiliser l’ancien déploiement
  • quand vous clonez un déploiement de Azure DevOps Server

Dans l’un ou l’autre de ces cas, il est essentiel d’exécuter cette commande.

Si vous ne le souhaitez pas, les ressources d’origine sont utilisées par les serveurs d’origine et les nouveaux.

Si le serveur d'origine et le nouveau serveur sont actifs et qu'ils pointent tous les deux vers les mêmes ressources SharePoint ou de création de rapports pendant une durée quelconque, vous pouvez vous retrouver avec des bases de données endommagées.

Important

Cette commande doit être exécutée avant la configuration, que vous déplaciez ou cloniez Azure DevOps Server. Si vous l’exécutez après la configuration, vous pouvez vous retrouver avec des incohérences entre le contenu de vos bases de données et le contenu de votre fichier web.config. Ces incohérences peuvent mettre votre serveur hors connexion. si vous avez déjà configuré votre déploiement Azure DevOps Server déplacé ou cloné et que vous vous rendez compte que vous devez exécuter la commande, procédez comme suit. Tout d'abord, suspendez votre serveur. Ensuite, exécutez la commande PrepareClone, la commande ChangeServerID, puis la commande RemapDBs. Pour terminer, annulez la suspension de votre serveur.

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

Option

Résultat

/DatabaseName

spécifie le nom du serveur qui héberge la base de données que vous souhaitez mapper pour Azure DevOps Server, en plus du nom de la base de données de configuration elle-même.

/SqlInstance : Nom du serveur

Spécifie le nom du serveur que vous souhaitez mapper en tant que serveur qui héberge une ou plusieurs bases de données pour Azure DevOps Server. Si une instance autre que l'instance par défaut héberge une base de données, vous devez aussi spécifier le nom de l'instance.

Utilisez le format suivant : NomServeur nom_instance.

/NotificationURL : URLTFS

facultatif. Spécifie l'URL de notification du serveur de couche Application.

/usesqlalwayson

facultatif. Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server. Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

pour plus d’informations, consultez [groupes de disponibilité AlwaysOn (SQL Server)] (/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Prérequis

pour utiliser la commande PrepareClone , 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 référence des autorisations pour Azure DevOps Server.

Notes

vous utilisez la commande PrepareClone pour reconfigurer Azure DevOps Server lorsque vous déplacez l’installation d’origine vers un nouveau matériel et que vous souhaitez continuer à utiliser le Azure DevOps Server de déploiement et le matériel d’origine, ou lorsque vous souhaitez cloner votre déploiement Azure DevOps Server à des fins de test. Utilisez TFSConfig PrepareClone conjointement avec TFSConfig RemapDBs et TFSConfig ChangeServerID pour prendre en charge la configuration de clonage.

Exemple

l’exemple suivant montre comment utiliser la commande sur une Azure DevOps Server déplacée nommée NewFabrikamTFS pour supprimer les anciennes informations sur les ressources de sauvegarde, de création de rapports et de SharePoint. si ces informations ne sont pas supprimées, le déploiement d’origine de Azure DevOps Server utilise toujours les mêmes ressources et bases de données endommagées. dans l’exemple, la SQL Server prenant en charge les Azure DevOps Server déplacées est également nommée NewFabrikamTFS, et l’instance est l’instance par défaut, de sorte qu’aucune information d’instance spécifique n’est requise, mais uniquement le nom du serveur.

TFSConfig PrepareClone /SQLInstance:NewFabrikamTFS /DatabaseName:TFS_Configuration

Licence

Vous pouvez utiliser la commande licence pour afficher, modifier ou étendre la clé de licence de votre déploiement de Azure DevOps Server.

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

Option

Description

/ProductKey : Essentiel

Spécifie que la clé de licence pour le déploiement sera mise à jour avec la valeur de clé.

/extend

spécifie que la période de licence d’évaluation de Azure DevOps Server sera prolongée de 30 jours. Cette option ne peut être utilisée qu’une seule fois sans obtenir de nouvel ID d’évaluation. Si une deuxième extension est requise, vous devez obtenir une deuxième licence d’évaluation de la part de Microsoft.

Prérequis

Pour utiliser la commande de licence , vous devez être membre du groupe de sécurité Team Foundation Administrators. Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Notes

Pour afficher, modifier ou modifier de manière interactive la licence de votre déploiement, vous pouvez utiliser la console Administration de Azure DevOps.

pour plus d’informations, consultez ouvrir la Console Administration de Azure DevOps et rechercher ou modifier la clé de produit pour Azure DevOps Server.

Exemples

L’exemple suivant montre comment afficher les informations de licence pour un déploiement de Azure DevOps Server. Dans cet exemple, le déploiement utilise une licence d’évaluation.

TFSConfig License

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

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

Option

Description

/upgradeTestPlans

Obligatoire, sauf si /upgradeStatus est utilisé.

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

/upgradeStatus

Obligatoire, sauf si /upgradeTestPlans est utilisé.

Indique l’état de la migration des données de test pour le projet spécifié. Il indique également si le projet spécifié comprend des plans de test.

/CollectionName: CollectionName

Obligatoire. Spécifie la collection de projets qui contient le projet pour lequel vous souhaitez migrer les données de test ou vérifier l’état de la migration.

S’il y a des espaces dans le nom de la collection de projets, mettez le nom entre guillemets, par exemple, " Fabrikam Fiber collection " .

/TeamProjectName: NomProjetÉquipe

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

S’il y a des espaces dans le nom du projet, placez le nom entre guillemets, par exemple, " mon Project " .

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 Team Foundation Server.

Notes

Votre serveur de couche application doit être mis à niveau vers la dernière version de TFS 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 sur l’utilisation de 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 d’outils de TFS. Par défaut, cet emplacement est : drive:\%programfiles%\TFS 12.0\Tools .

Vous utilisez la commande TCM uniquement dans le cas où la migration automatique des données de test existantes échoue.

Pour en savoir plus sur la migration et sur l’utilisation de cette commande, les mises à jour manuelles prennent en charge la gestion des tests.

Si vous ne pouvez pas accéder à des plans de test ou à des suites de tests 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 à chaque fois sur chaque projet.

Exemples

L’exemple suivant montre comment vérifier l’état de la 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"

Importer

La commande d’importation a été dépréciée dans TFS 2013. Les versions antérieures sont disponibles ici :

si vous avez besoin d’aide pour la mise à niveau de données et de projets à partir d’une version antérieure de Azure DevOps Server, consultez mettre à niveau Azure DevOps Serverou contacter Support Microsoft.

PrepareSQL

La commande prepareSQL a été depracated dans TFS 2012. Les versions antérieures sont disponibles ici :

Réparation

La commande de réparation était depracated dans TFS 2012. Les versions antérieures sont disponibles ici :

Si vous avez besoin de réparer vos procédures stockées après l’échec d’un correctif de base de données, contactez support Microsoft.

Diagnose

La commande de diagnostic a été dépréciée dans TFS 2013. Les versions antérieures sont disponibles ici :

si vous avez besoin d’aide pour diagnostiquer les incompatibilités potentielles entre les mises à jour logicielles sur vos serveurs de couche application et de couche données pour Azure DevOps Server, contactez le support technique du Community des développeurs.

Mises à jour

La commande Updates a été dépréciée dans TFS 2013. Les versions antérieures sont disponibles ici :

si vous avez besoin d’aide pour installer les mises à jour logicielles manquantes dans les bases de données pour Azure DevOps Server, contactez Support Microsoft.

PrepareClone

La commande PrepareClone a été dépréciée dans TFS 2017.

Disponibilité des commandes : TFS 2015 et TFS 2013

la commande PrepareClone supprime des informations sur les sauvegardes planifiées, les SharePoint et les ressources de création de rapports à partir d’un déploiement Azure DevOps Server.

Utilisez cette commande dans les situations suivantes :

  • Lorsque vous déplacez un déploiement vers un nouveau matériel, mais que vous souhaitez continuer à utiliser l’ancien déploiement
  • quand vous clonez un déploiement de Azure DevOps Server

Dans l’un ou l’autre de ces cas, il est essentiel d’exécuter cette commande.

Si vous ne le souhaitez pas, les ressources d’origine sont utilisées par les serveurs d’origine et les nouveaux.

Si le serveur d'origine et le nouveau serveur sont actifs et qu'ils pointent tous les deux vers les mêmes ressources SharePoint ou de création de rapports pendant une durée quelconque, vous pouvez vous retrouver avec des bases de données endommagées.

Important :
Cette commande doit être exécutée avant la configuration, que vous déplaciez ou cloniez Azure DevOps Server. Si vous l’exécutez après la configuration, vous pouvez vous retrouver avec des incohérences entre le contenu de vos bases de données et le contenu de votre fichier web.config. Ces incohérences peuvent mettre votre serveur hors connexion. si vous avez déjà configuré votre déploiement Azure DevOps Server déplacé ou cloné et que vous vous rendez compte que vous devez exécuter la commande, procédez comme suit. Tout d'abord, suspendez votre serveur. Ensuite, exécutez la commande PrepareClone, la commande ChangeServerID, puis la commande RemapDBs. Pour terminer, annulez la suspension de votre serveur.

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

Option

Résultat

/DatabaseName

spécifie le nom du serveur qui héberge la base de données que vous souhaitez mapper pour Azure DevOps Server, en plus du nom de la base de données de configuration elle-même.

/SqlInstance : Nom du serveur

Spécifie le nom du serveur que vous souhaitez mapper en tant que serveur qui héberge une ou plusieurs bases de données pour Azure DevOps Server. Si une instance autre que l'instance par défaut héberge une base de données, vous devez aussi spécifier le nom de l'instance.

Utilisez le format suivant : NomServeur nom_instance.

/NotificationURL : URLTFS

facultatif. Spécifie l'URL de notification du serveur de couche Application.

/usesqlalwayson

facultatif. Spécifie que les bases de données font partie d'un groupe de disponibilité AlwaysOn dans SQL Server. Si elle est configurée, cette option définit MultiSubnetFailover dans la chaîne de connexion.

pour plus d’informations, consultez [groupes de disponibilité AlwaysOn (SQL Server)] (/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.

Prérequis

pour utiliser la commande PrepareClone , vous devez être membre du groupe de sécurité Team Foundation administrators et membre du groupe de sécurité sysadmin pour les bases de données de SQL Server que Azure DevOps Server utilise.

Pour plus d’informations, consultez référence des autorisations pour Azure DevOps Server.

Notes

vous utilisez la commande PrepareClone pour reconfigurer Azure DevOps Server lorsque vous déplacez l’installation d’origine vers un nouveau matériel et que vous souhaitez continuer à utiliser le Azure DevOps Server de déploiement et le matériel d’origine, ou lorsque vous souhaitez cloner votre déploiement Azure DevOps Server à des fins de test. Utilisez TFSConfig PrepareClone conjointement avec TFSConfig RemapDBs et TFSConfig ChangeServerID pour prendre en charge la configuration de clonage.

Exemple

l’exemple suivant montre comment utiliser la commande sur une Azure DevOps Server déplacée nommée NewFabrikamTFS pour supprimer les anciennes informations sur les ressources de sauvegarde, de création de rapports et de SharePoint. si ces informations ne sont pas supprimées, le déploiement d’origine de Azure DevOps Server utilise toujours les mêmes ressources et bases de données endommagées. dans l’exemple, la SQL Server prenant en charge les Azure DevOps Server déplacées est également nommée NewFabrikamTFS, et l’instance est l’instance par défaut, de sorte qu’aucune information d’instance spécifique n’est requise, mais uniquement le nom du serveur.

TFSConfig PrepareClone /SQLInstance:NewFabrikamTFS /DatabaseName:TFS_Configuration