Partager via

Passer d’un environnement à un autre pour Azure DevOps local

  • Article

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

Le scénario de déplacement basé sur l’environnement le plus courant consiste à changer le domaine du déploiement Azure DevOps Server, qu’il s’agisse d’un changement de nom de domaine ou d’un groupe de travail vers un domaine.

Important

Dans certaines situations, vous pouvez modifier le domaine d’un déploiement Azure DevOps Server ainsi que son matériel. Changer le matériel est un déplacement basé sur la restauration, et vous ne devez jamais combiner les deux types de déplacement. Commencez par effectuer le déplacement du matériel, puis modifiez l’environnement.

En outre, la modification des identités dans Azure DevOps Server dans le cadre d’un déplacement environnemental est l’aspect qui provoque le plus souvent des conflits ou des problèmes. La commande Identités est un outil puissant, mais il présente certaines limitations. Informez-vous au sujet de cette commande dans le cadre de la planification du déplacement. Pour aider à garantir le succès du déplacement, veillez à bien comprendre les conditions requises suivantes :

  • Une fois qu’un compte d’utilisateur est présent dans Azure DevOps Server, il ne peut pas être supprimé ou mappé à un autre compte. Par exemple, si vous déplacez DomainA/UserA vers DomainB/UserB, la commande Identities ne fonctionne que pour migrer l’utilisateur si DomainB/UserB n’est pas déjà présent dans Azure DevOps Server.
  • Étant donné que les membres du groupe Administrateurs local sont automatiquement ajoutés à Azure DevOps Server, veillez à supprimer tous les comptes que vous souhaitez migrer de ce groupe avant de modifier le domaine ou l’environnement.

Pour plus d’informations générales, accédez ici pour obtenir une description détaillée du fonctionnement de l’identité dans Azure DevOps Server, y compris les limitations de l’outil.

Nous allons suivre les étapes pour modifier l’environnement de votre déploiement Azure DevOps Server dans les sections suivantes :

  1. Vérifier les autorisations et les comptes
  2. Arrêter Azure DevOps Server services
  3. Sauvegarder des données
  4. Joindre Azure DevOps Server à son nouveau domaine
  5. Déplacer Azure DevOps Server comptes d’utilisateur et de service
  6. Configurer les services Reporting Services et Analysis Services
  7. Redémarrer Azure DevOps Server services

Vérifier les autorisations et les comptes

Pour réussir à modifier l’environnement de Azure DevOps Server, vous devez être administrateur sur l’ordinateur local, ainsi que pour Azure DevOps Server et tous les logiciels dont dépend votre déploiement : SQL Server, la création de rapports et tout autre logiciel avec lequel votre déploiement interopère, comme Project Server. Toutefois, tous les membres du groupe Administrateurs local sont automatiquement inclus dans Azure DevOps Server, ce qui peut entraîner des problèmes lors de la tentative de migration de comptes. Par conséquent, vous devez utiliser un compte que vous n'envisagez pas de migrer dans le cadre du déplacement d'environnement. Vous pourriez ajouter un compte d'administration spécial uniquement pour le déplacement et utiliser ce compte pour effectuer la migration.

Pour vérifier les autorisations de niveau administrateur

  • Vérifiez que le compte que vous utilisez est membre des groupes suivants :
    • Serveurs : administrateurs (groupe Administrateurs local ou équivalent)
    • Azure DevOps Server : Administrateurs Team Foundation et utilisateurs de la console Administration
    • SQL Server : sysadmin

Si vous n’êtes pas membre d’un ou plusieurs de ces groupes, obtenez des autorisations maintenant.

Maintenant que vous utilisez un compte qui dispose de toutes les autorisations requises, vous devez commencer à vérifier les comptes pour savoir s'il risque d'y avoir des conflits au niveau des noms ou des groupes dans l'environnement vers lequel vous allez effectuer le déplacement. Nous savons déjà que les comptes qui sont membres du groupe Administrateurs local ne peuvent pas être migrés. Nous allons donc commencer par les supprimer.

Supprimer les comptes à migrer du groupe Administrateurs local

  • Ouvrez le groupe Administrateurs local et supprimez tous les comptes que vous souhaitez migrer vers le nouvel environnement. Répétez cette étape pour tous les autres groupes concernés.

Maintenant, case activée la liste des identités dans l’environnement de Azure DevOps Server actuel et recherchez les éventuels problèmes liés aux groupes ou aux comptes d’utilisateurs individuels qui peuvent exister dans le nouvel environnement.

Conseil

Créez un tableau ou une carte de migration des identités à déplacer dans le cadre du déplacement d'environnement, avec notamment les détails des comptes dont la migration automatique risque de ne pas être possible.

Vérifier les identités

  1. Sur le serveur de la couche Application pour Azure DevOps, ouvrez une fenêtre d’invite de commandes avec des autorisations d’administration, accédez à %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools, puis exécutez la commande suivante pour afficher les identités actuellement dans le système :

    TFSConfig Identities

  2. Une liste d'identités s'affiche. Vérifiez ces utilisateurs et groupes pour vous assurer qu’il n’y a pas de doublons ou de problèmes potentiels avec les identités dans l’environnement vers lequel vous allez vous déplacer Azure DevOps Server, et prenez des mesures pour atténuer les conflits potentiels.

Arrêter les services

L'arrêt des services permet de s'assurer que les utilisateurs ne peuvent pas apporter de modifications aux éléments de travail ou archiver le code source dans le déploiement d'origine pendant ou après le processus de déplacement.

  1. Sur l’ordinateur de la couche Application, ouvrez une fenêtre d’invite de commandes et remplacez les répertoires par Lecteur :\%programfiles%\TFS 12.0\Tools.

  2. Tapez la commande TFSServiceControl suivante :

    ARRÊT DE TFSServiceControl

Sauvegarder les bases de données et la clé de chiffrement SQL Server Reporting Services

  1. Ouvrez la console d’administration pour Azure DevOps Server et, dans la page Sauvegardes planifiées, effectuez une sauvegarde complète. La sauvegarde enregistrera tous les éléments que vous avez configurés pour la sauvegarde dans votre plan de sauvegarde, mais cette opération sera effectuée immédiatement, et pas en fonction du délai planifié dans le plan. Si votre déploiement utilise la création de rapports, vous pouvez sauvegarder la clé de chiffrement dans le cadre de cet ensemble de sauvegardes.

    Vous pouvez fermer la fenêtre pendant que le travail se termine

    (Si vous n’avez pas de sauvegardes configurées, vous devez créer un plan avant de pouvoir effectuer une sauvegarde complète.)

  2. Une fois la sauvegarde terminée, vérifiez qu'elle est disponible sur le dispositif de stockage ou le partage réseau et que vous pouvez y accéder à partir du nouveau matériel.

Joindre le serveur de la couche Application à son nouveau domaine

  1. Sur chaque serveur, ouvrez les propriétés de l'ordinateur.

  2. Modifiez les paramètres de l'ordinateur au domaine ou au groupe de travail auquel vous souhaitez joindre le serveur.

    Si vous êtes invité à indiquer le nom d'utilisateur et le mot de passe d'un compte qui dispose des autorisations nécessaires pour joindre cet ordinateur au domaine, spécifiez les informations d'identification appropriées.

  3. Redémarrez l'ordinateur pour que les modifications apportées au domaine soient prises en compte.

    Notes

    Après le redémarrage de l'ordinateur, un avertissement peut s'afficher pour indiquer que les services ou les pilotes n'ont pas pu démarrer. Passez à la procédure suivante.

Déplacer des comptes d’utilisateur et des comptes de service

Comme mentionné au début de cette rubrique, c'est lors du déplacement des comptes que vous êtes le plus susceptible de rencontrer des difficultés, notamment si vous n'avez pas planifié soigneusement la migration des utilisateurs. La commande IDENTITÉS TFSConfig ne peut migrer aucun compte vers un compte qui existe déjà dans Azure DevOps Server.

Si des noms de comptes sont identiques dans les deux domaines et que la seule différence est le nom de domaine, vous pouvez utiliser le mode de traitement par lot de TFSConfig Identities pour modifier simultanément toutes les identités. Sinon, vous devez modifier les identités individuellement et spécifier un nom de compte cible différent, comme détaillé ci-dessous.

  1. Sur le serveur de la couche Application pour Azure DevOps, ouvrez une fenêtre d’invite de commandes avec des autorisations d’administration, accédez à %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools, puis exécutez la commande suivante pour modifier les ID de service (SID) du compte de service vers le nouveau domaine :

    TFSConfig identities /change /fromdomain:OldComputerorDomainName /todomain:NewDomainName /account:OldTFSServiceAccount /toaccount:NewTFSServiceAccount

    Avertissement

    Si votre compte de service était un compte système tel que Service réseau, vous ne pouvez pas migrer directement le compte de service, car il existe un compte système avec le même nom dans le nouvel environnement. Vous devrez effectuer un processus de modification en deux étapes. Consultez l’exemple dans Commande Identités.

  2. Pour migrer tous les comptes qui ont le même nom dans le nouvel environnement, tapez la commande suivante :

    TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName

    Cette commande effectuera un traitement par lot des comptes.

  3. Si vous êtes un nouveau domaine contient une ou plusieurs identités où le nom change entre les environnements, vous devez mettre à jour manuellement les SID pour chacune de ces identités. Par exemple, si le compte d'utilisateur de Christie Church était Fabrikam\CChurch dans l'environnement précédent, mais NewFabrikam\ChristieC dans le nouvel environnement, vous devrez mettre à jour son SID manuellement. Pour chaque compte concerné par cette exigence, tapez la commande suivante :

    TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName /account:OldAccountName /toaccount:NewAccountName

  4. Exécutez maintenant la commande suivante pour mettre à jour le compte de service :

    TFSConfig Accounts /change /AccountType:ApplicationTier /account:AccountName /password:Password

  5. Si votre déploiement utilise la création de rapports, exécutez la commande suivante pour mettre à jour le compte de source de données utilisé pour la création de rapports :

    TFSConfig Accounts /change /AccountType:ReportingDataSource /account:AccountName /password:Password

  6. Si votre déploiement utilise le serveur proxy Azure DevOps, exécutez la commande suivante pour mettre à jour le compte de service utilisé pour le proxy :

    TFSConfig Accounts /change /AccountType:Proxy /account:AccountName /password:Password

    Notes

    Si vous passez à un domaine non approuvé, vous devrez peut-être ajouter manuellement des utilisateurs et des groupes à des équipes, des projets, des collections et Azure DevOps Server lui-même. Pour plus d’informations, consultez Ajouter des utilisateurs aux projets, Définir des autorisations d’administrateur pour les collections de projets et Définir des autorisations d’administrateur pour Azure DevOps Server.

  7. Si votre déploiement est intégré à Project Server, vous devrez peut-être exécuter des étapes supplémentaires pour configurer les comptes de service avec les autorisations requises pour fonctionner. Pour plus d’informations, consultez Attribuer des autorisations pour prendre en charge l’intégration TFS-Project Server et Configurer l’intégration de Project Server.

Configurer les services Reporting Services et Analysis Services

Vous pouvez ignorer cette procédure si vous n'utilisez pas la création de rapports dans le cadre de votre déploiement.

Si vous avez renommé un serveur de rapports dans le cadre de ce type de déplacement, vous devez rediriger Azure DevOps Server vers le serveur de rapports à son nouvel emplacement. Vous devez également redémarrer l'entrepôt et régénérer manuellement la base de données pour Analysis Services.

  1. Ouvrez la console d’administration pour Azure DevOps, accédez au nœud Rapports et modifiez les paramètres.

    Les rapports pointent encore vers l'ancien serveur

  2. Modifiez les valeurs des trois onglets afin qu'ils incluent le nouveau nom du serveur. Veillez à fournir les informations appropriées pour le compte de sources de données dans le nouvel environnement.

    Vérifier l'exactitude des informations sur les 3 onglets

  3. Choisissez Démarrer les travaux pour redémarrer la création de rapports.

  4. Choisissez Démarrer la reconstruction pour reconstruire l’entrepôt.

Configurer des sauvegardes

Si le nom du partage réseau ou le dispositif de stockage a changé avec la modification du nom de domaine, vous devrez mettre à jour le plan de sauvegarde planifié pour pointer vers ces ressources renommées.

  • Dans la console d’administration, accédez au nœud Sauvegardes planifiées et reconfigurez les sauvegardes planifiées pour sauvegarder les bases de données Azure DevOps Server sur le nouveau serveur. Pour plus d’informations, consultez Create une planification et un plan de sauvegarde.

Redémarrer les services

Maintenant que vous avez mis à jour Azure DevOps Server avec toutes les informations relatives au nouvel environnement, redémarrez les services.

  1. Sur l’ordinateur de la couche application Azure DevOps Server, ouvrez une fenêtre d’invite de commandes avec des autorisations d’administration et remplacez les répertoires par Drive :\%programfiles%\TFS 12.0\Tools.

  2. Tapez la commande TFSServiceControl suivante :

    TFSServiceControl non-quiesce

Questions et réponses

Q : Je souhaite modifier le ou les serveurs physiques pour mon déploiement, et non les domaines. Est-ce possible ?

R : Oui. C’est ce qu’on appelle un déplacement basé sur le matériel, et les étapes sont fournies dans Déplacer ou cloner d’un matériel à un autre. Vous ne devez pas essayer de combiner un déplacement basé sur l'environnement avec un déplacement basé sur le matériel. Procédez d'abord au déplacement du matériel, puis modifiez l'environnement.