passer d’un environnement à un autre pour 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.

le scénario de déplacement basé sur l’environnement le plus courant consiste à modifier 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 dans un domaine.

Important

dans certains cas, vous souhaiterez peut-être modifier le domaine d’un déploiement de 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. Procédez d’abord au 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 cause le plus souvent des conflits ou des problèmes. La commande Identities est un outil puissant, mais elle 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 être associé à un autre compte. Par exemple, si vous déplacez DomaineA/UtilisateurA vers DomaineB/b-b, la commande Identities ne fonctionnerait que pour migrer l’utilisateur si DomaineB/b 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 à partir de ce groupe avant de modifier le domaine ou l’environnement.

pour plus d’informations, rendez -vous ici pour obtenir une description détaillée de la façon dont les modifications d’identité dans Azure DevOps Server fonctionnent, y compris les limitations de l’outil.

nous allons examiner les étapes de modification de l’environnement de votre déploiement Azure DevOps Server dans les sections suivantes :

  1. Vérifier les autorisations et les comptes
  2. arrêter les services Azure DevOps Server
  3. Sauvegarder des données
  4. joindre Azure DevOps Server à son nouveau domaine
  5. Configurer les produits SharePoint pour le nouvel environnement
  6. déplacer Azure DevOps Server comptes d’utilisateur et de service
  7. Configurer les services Reporting Services et Analysis Services
  8. redémarrer les services Azure DevOps Server

Vérifier les autorisations et les comptes

pour modifier correctement l’environnement pour 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, les produits SharePoint (si votre déploiement utilise la création de rapports ou la SharePoint) et tout autre logiciel avec lequel votre déploiement interagit, par exemple Project serveur. toutefois, tous les membres du groupe administrateurs local sont automatiquement inclus dans Azure DevOps Server, ce qui peut provoquer des problèmes lors de la tentative de migration des 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 administrateur
    • SQL Server : sysadmin
    • SharePoint produits : administrateurs de batterie de serveurs (si votre déploiement Azure DevOps Server s’intègre aux produits SharePoint)

Si vous n’êtes pas membre d’un ou de plusieurs de ces groupes, obtenir 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.

vérifiez à présent la liste des identités dans l’environnement de Azure DevOps Server actuel et recherchez les éventuels problèmes avec les groupes ou les 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 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 \ outils et exécutez la commande suivante pour afficher les identités actuellement présentes dans le système :

    TFSConfig Identities
    
  2. Une liste d'identités s'affiche. vérifiez ces utilisateurs et ces groupes pour vous assurer qu’il n’existe aucun doublon potentiel ou problème avec les identités dans l’environnement vers lequel vous allez déplacer Azure DevOps Server, et prenez les mesures nécessaires 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, puis accédez au répertoire lecteur: \ % programfiles% \ tfs 12,0 \ Tools.

  2. Tapez la commande TFSServiceControl suivante :

    TFSServiceControl suspendre

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

  1. ouvrez la console administration de Azure DevOps Server puis, 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 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.

Configurer les produits SharePoint pour le nouvel environnement

si vous remplacez l’environnement par un environnement dans lequel il n’existe aucune relation d’approbation avec votre environnement précédent, vous devrez peut-être configurer SharePoint produits avant qu’il ne fonctionne correctement. Les informations relatives aux utilisateurs importés à partir des services d'annuaire sont disponibles sur les sites SharePoint à partir du contrôle Web Sélecteur de personnes. Les administrateurs de site et autres utilisateurs se servent du Sélecteur de personnes pour sélectionner des personnes et des groupes lors de l'assignation d'autorisations. Lorsque les informations relatives aux utilisateurs se trouvent dans plusieurs forêts ou dans une forêt sans relation d'approbation pour l'ensemble des utilisateurs, des étapes supplémentaires peuvent être nécessaires afin de vérifier que toutes les personnes et tous les groupes sont disponibles à partir de ce contrôle Web.

ignorez cette procédure si vous n’utilisez pas SharePoint produits dans votre déploiement, si vous êtes un nouvel environnement qui a une relation d’approbation bidirectionnelle avec l’ancien environnement, ou si aucune erreur ne s’affiche pour votre application Web SharePoint dans la console administration de Azure DevOps.

  1. sur chaque serveur qui fait partie de la batterie de SharePoint qui prend en charge votre déploiement de Azure DevOps Server, ouvrez une fenêtre d’invite de commandes avec des autorisations d’administration et accédez au répertoire% programfiles% \ Common Files \ Microsoft shared \ Web server Extensions \ 15 \ BIN.

  2. tapez la commande suivante, où clé est la clé de chiffrement que vous souhaitez utiliser dans votre déploiement de SharePoint produits :

    stsadm.exe-o clé setapppassword-Password

    Notes

    Cette clé est une chaîne de chiffrement utilisée pour chiffrer le mot de passe du compte utilisé pour accéder à la forêt ou au domaine. La chaîne de chiffrement doit être la même pour chaque serveur de la batterie de serveurs, mais une chaîne unique doit être utilisée pour chaque batterie de serveurs.

  3. Tapez la commande suivante, où domaine : dNSName est la forêt ou le domaine cible et son nom DNS, utilisateur, mot de passe , le nom d’utilisateur et le mot de passe d’un compte qui a accès à la forêt ou au domaine cible, et webapp est le nom de l’application Web qui prend en charge votre déploiement de Azure DevOps Server :

    stsadm.exe-o setproperty-pn Peoplepicker-searchadforests-PV domaine : dNSName,utilisateur,mot de passe -URL http://webapp

  4. Tapez la commande suivante, où URL est l’URL d’une collection de sites qui prend en charge une collection de projets, port est le numéro de port assigné à cette collection de sites, et username est le nom d’utilisateur du compte qui agit en tant que propriétaire de cette collection de sites :

    stsadm.exe-o siteowner-URL http:// URL : port -ownerlogin nom_utilisateur

  5. répétez l’étape précédente pour chaque collection de sites que votre déploiement de Azure DevOps Server utilise.

Déplacer les comptes d’utilisateur et les 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 TfsConfig Identities ne peut pas migrer un 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 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 sur 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 de la commande Identities.

  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 contenant une ou plusieurs identités dont le nom change entre les environnements, vous devez mettre à jour manuellement les SID de chacune de ces identités. Par exemple, si le compte d’utilisateur de Christie église était Fabrikam \ CChurch dans l’environnement précédent, mais qu’il est NewFabrikam \ ChristieC dans le nouvel environnement, vous devez 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 Azure DevOps serveur proxy, 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 effectuez un déplacement vers un domaine non approuvé, vous devrez peut-être également ajouter manuellement des utilisateurs et des groupes aux équipes, projets, 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 projetset 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 assigner des autorisations pour prendre en charge TFS-Project server integration et configurer-Project server integration.

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 administration de 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 régénération 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 administration de, accédez au nœud sauvegardes planifiées et reconfigurez les sauvegardes planifiées pour sauvegarder les bases de données de Azure DevOps Server sur le nouveau serveur. Pour plus d’informations, consultez créer une planification et un plan de sauvegarde.

Redémarrer les services

maintenant que vous avez mis à jour Azure DevOps Server avec toutes les informations pour le 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 accédez au répertoire lecteur: \ % programfiles% \ TFS 12,0 \ Tools.

  2. Tapez la commande TFSServiceControl suivante :

    TFSServiceControl devrez démarrer

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 que l’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.