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

2025-06-07

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

Cet article explique comment déplacer un déploiement Azure DevOps Server d’un environnement vers un autre, par exemple changer le nom de domaine ou passer d’un groupe de travail à un domaine. Les déplacements basés sur l’environnement sont courants lorsque les organisations restructurent leur infrastructure informatique, mettent à jour les noms de domaine ou consolident les ressources.

Vous trouverez des instructions pas à pas pour préparer votre déploiement, mettre à jour les autorisations et les comptes, arrêter les services, sauvegarder des données, joindre le nouveau domaine, migrer des comptes d’utilisateur et de service, configurer les services de création de rapports et d’analyse, mettre à jour les plans de sauvegarde et redémarrer les services.

La modification de l’environnement pour Azure DevOps Server nécessite une planification minutieuse, en particulier autour de la gestion des comptes et des identités, afin d’éviter les conflits et de garantir une transition fluide. Cet article fournit des bonnes pratiques et des instructions détaillées pour vous aider à effectuer correctement le déplacement.

Important

Dans certains cas, vous souhaiterez peut-être modifier le domaine d’un déploiement Azure DevOps Server et de son matériel. La modification du matériel est une action qui repose sur la restauration et il ne faut jamais combiner les deux types d'actions. Commencez par terminer le déplacement matériel, puis modifiez l’environnement.

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. Découvrez-le dans le cadre de la planification de votre déplacement. Pour vous aider à garantir un déplacement réussi, vérifiez que vous comprenez les exigences suivantes :

Une fois qu’un compte d’utilisateur est présent dans Azure DevOps Server, il ne peut pas être supprimé ou avoir un autre compte mappé à celui-ci. Par exemple, si vous déplacez DomainA/UserA vers DomainB/UserB, la commande Identités fonctionne uniquement 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 au serveur Azure DevOps, 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, consultez ce billet de blog.

1. Vérifier les autorisations et les comptes

Pour modifier l’environnement d’Azure DevOps Server, connectez-vous en tant qu’administrateur sur l’ordinateur local, Azure DevOps Server, SQL Server, reporting et tout autre logiciel dépendant (par exemple, Project Server). Évitez d’utiliser des comptes que vous envisagez de migrer : les membres du groupe Administrateurs locaux sont automatiquement ajoutés au serveur Azure DevOps, ce qui peut entraîner des problèmes de migration. Utilisez un compte d’administration dédié pour le déplacement afin d’éviter les conflits.

Vérifier les autorisations au niveau de l’administrateur

Vérifiez que le compte que vous utilisez est membre des groupes suivants :
- Serveurs : Administrateurs (groupe Administrateurs locaux ou équivalent)
- Azure DevOps Server : Administrateurs Team Foundation et utilisateurs de la console d’administration
- SQL Server : sysadmin

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

Après avoir confirmé que votre compte dispose de toutes les autorisations nécessaires, vérifiez les conflits potentiels avec les noms de compte ou de groupe dans l’environnement cible. Étant donné que les comptes du groupe Administrateurs locaux ne peuvent pas être migrés, supprimez tous les comptes que vous envisagez de migrer à partir de ce groupe avant de continuer.

Supprimer les comptes à migrer du groupe Administrateurs local

Ouvrez le groupe Administrateurs local et supprimez tous les comptes que vous envisagez de migrer vers le nouvel environnement. Répétez ce processus pour tous les autres groupes susceptibles d’être affectés.

Ensuite, passez en revue la liste des identités dans votre environnement Azure DevOps Server actuel. Identifiez les conflits potentiels avec des groupes ou des comptes d’utilisateur qui peuvent déjà exister dans le nouvel environnement.

Conseil / Astuce

Créez une table ou une carte de migration des identités à migrer. Incluez des détails sur les comptes qui ne peuvent pas être migrés automatiquement pour faciliter le suivi et la résolution des problèmes pendant le déplacement.

Vérifier les identités

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

Une liste d’identités s’affiche.

Passez en revue les utilisateurs et les groupes pour identifier les identités en double ou en conflit dans l’environnement cible avant de déplacer Azure DevOps Server. Résolvez les conflits potentiels pour garantir une migration fluide.

2. Arrêter les services

L’arrêt des services empêche les utilisateurs d’apporter des modifications aux éléments de travail ou de vérifier le code source vers le déploiement d’origine pendant ou après le processus de déplacement.

Ouvrez une fenêtre d’invite de commandes sur l’ordinateur de la couche Application et modifiez les répertoires en Drive:\\%programfiles%\\TFS 12.0\\Tools.
Entrez la commande TFSServiceControl suivante :
```
TFSServiceControl quiesce
```

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

Ouvrez la console d’administration pour Azure DevOps Server et accédez à la page Sauvegardes planifiées . Effectuez une sauvegarde complète pour sauvegarder immédiatement tout ce qui est spécifié dans votre plan de sauvegarde. Si votre déploiement utilise la création de rapports, incluez la clé de chiffrement dans ce jeu de sauvegarde.

Remarque

Si vous n’avez jamais configuré de sauvegardes, créez un plan de sauvegarde avant d’effectuer une sauvegarde complète.
Une fois la sauvegarde terminée, vérifiez que la sauvegarde est disponible sur votre périphérique de stockage ou votre partage réseau et vérifiez que vous pouvez y accéder à partir du nouveau matériel.

4. Joindre le serveur de la couche Application à son nouveau domaine

Sur chaque serveur, ouvrez les propriétés de l’ordinateur.
Modifiez les paramètres de l’ordinateur pour joindre le domaine ou le groupe de travail souhaités.

Si vous y êtes invité, entrez les informations d’identification d’un compte avec l’autorisation de joindre l’ordinateur au domaine.
Redémarrez l’ordinateur pour appliquer la modification du domaine.

Remarque

Après le redémarrage, vous pouvez voir un avertissement indiquant que certains services ou pilotes n’ont pas pu être démarrés. Vous pouvez continuer en toute sécurité avec la procédure suivante.

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

La migration de comptes est souvent la partie la plus difficile des environnements changeants, en particulier si vous n’avez pas prévu la migration de vos utilisateurs avec soin. La commande TFSConfig Identités ne peut pas migrer un compte vers un compte cible qui existe déjà dans Azure DevOps Server.

Si les noms de compte sont identiques dans les deux domaines (avec uniquement le nom de domaine différent), vous pouvez utiliser le mode batch des identités TFSConfig pour mettre à jour toutes les identités en même temps. Si les noms de compte diffèrent entre les environnements, vous devez mettre à jour chaque identité individuellement et spécifier le nouveau nom du compte cible, comme décrit ci-dessous.

Sur le serveur de la couche applicative pour Azure DevOps, ouvrez une fenêtre d’invite de commandes avec des droits d'administrateur. Accédez à %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools, puis exécutez la commande suivante pour mettre à jour le 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 le service réseau), vous ne pouvez pas le migrer directement, car un compte système portant le même nom existe dans le nouvel environnement. Vous devez suivre un processus en deux étapes. Consultez l’exemple dans La commande Identités.
Pour migrer tous les comptes portant le même nom dans le nouvel environnement, exécutez :
```
TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName
```
Ce lot de commandes traite les comptes.
Si votre nouveau domaine contient des identités avec des noms différents entre les environnements, mettez à jour manuellement les SID pour chacun d’eux. Par exemple, si le compte de Christie Church était Fabrikam\CChurch dans l’ancien environnement et est NewFabrikam\ChristieC dans le nouveau, mettez à jour leur SID comme suit :
```
TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName /account:OldAccountName /toaccount:NewAccountName
```

Mettez à jour le compte de service en exécutant :

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

Si votre déploiement utilise la création de rapports, mettez à jour le compte de source de données :
```
TFSConfig Accounts /change /AccountType:ReportingDataSource /account:AccountName /password:Password
```
Si votre déploiement utilise le serveur proxy Azure DevOps, mettez à jour le compte de service proxy :
```
TFSConfig Accounts /change /AccountType:Proxy /account:AccountName /password:Password
```
Remarque

Si vous passez à un domaine non approuvé, vous devrez peut-être également 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 à des projets, définir des autorisations d’administrateur pour les regroupements de projets et définir des autorisations d’administrateur pour Azure DevOps Server.
Si votre déploiement s’intègre à Project Server, vous devrez peut-être effectuer d’autres étapes pour configurer des comptes de service avec les autorisations requises. Pour plus d'informations, consultez Affecter des autorisations pour l'intégration de serveur TFS-Project et Configurer l'intégration de serveur TFS-Project.

6. Configurer les services de reporting et d'analyse

Ignorez cette procédure si votre déploiement n’utilise pas la création de rapports.

Si vous avez renommé le serveur de rapports pendant le déplacement, mettez à jour Azure DevOps Server pour qu’il pointe vers le nouvel emplacement du serveur de rapports. Vous devez également redémarrer l’entrepôt et reconstruire manuellement la base de données Analysis Services.

Ouvrez la console d’administration pour Azure DevOps, accédez au nœud Reporting et modifiez les paramètres.
Mettez à jour les valeurs sous les trois onglets pour refléter le nouveau nom du serveur. Vérifiez que vous entrez les informations de compte de source de données correctes pour le nouvel environnement.
Sélectionnez Démarrer les travaux pour redémarrer la création de rapports.
Sélectionnez Démarrer la reconstruction pour reconstruire l’entrepôt.

7. Configurer les sauvegardes

Si vous avez modifié le nom de partage réseau ou l’appareil de stockage pendant la modification du nom de domaine, mettez à jour votre plan de sauvegarde planifié pour référencer les nouvelles ressources.

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 Créer une planification et un plan de sauvegarde.

8. Redémarrer les services

Maintenant que vous avez mis à jour Azure DevOps Server avec toutes les informations relatives au nouvel environnement, pour redémarrer les services, procédez comme suit :

Sur l’ordinateur de niveau application Azure DevOps Server, ouvrez une fenêtre d’invite de commandes avec des autorisations d’administration et accédez aux répertoires Drive:\%programfiles%\TFS 12.0\Tools.
Entrez la commande TFSServiceControl suivante :
```
TFSServiceControl unquiesce
```

FAQ (questions fréquentes)

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

A: Oui, cette action est appelée une action basée 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. Commencez par terminer le déplacement matériel, puis modifiez l’environnement.

Partager via