Product Documentation

Mettre à niveau et migrer

Jun 04, 2018

Cette section contient des procédures de mise à niveau du logiciel Profile Management ainsi que des informations sur la transition de vos profils utilisateur Windows vers les profils utilisateur Citrix. À titre d'exemple, vous pouvez facilement mettre à niveau de la version 3.x vers la version 5.x à l'aide de ces procédures.

Avant de procéder à la mise à niveau, vous devez connaître les fonctionnalités et les paramètres Profile Management qui sont disponibles dans la version que vous mettez à niveau. Pour consulter ces informations, reportez-vous à la section Stratégies Profile Management. Afin de faciliter la mise à niveau de fichiers .ini vers une stratégie de groupe, cette rubrique mappe également les noms des paramètres dans le fichier .ini avec ceux des fichiers .adm et .admx.

Ne configurez pas Profile Management (dans la stratégie de groupe ou avec le fichier .ini) alors que la mise à niveau est en cours. Séparez ces deux tâches en procédant dans un premier temps à la mise à niveau de votre déploiement et dans un deuxième temps à la configuration des paramètres, de préférence en répondant aux questions de la section Choix de la configuration.

Conseil : vous pouvez appliquer des correctifs à votre déploiement de Profile Management 2.1.1 ou version ultérieure en mettant à niveau vers la dernière version. Après mise à niveau, vous pouvez, si vous le désirez, activer toute fonctionnalité.

Déploiements mixtes

Pour les déploiements dans lesquels des versions différentes de Profile Management coexistent, vous devez :

  • Limiter la durée pendant laquelle un déploiement mixte existe.
  • Ajouter la dernière version du fichier .adm ou .admx à chaque objet de stratégie de groupe sur tous les contrôleurs de domaine, vous assurer que toutes les nouvelles fonctionnalités sont désactivées et accorder le temps nécessaire à la propagation des nouvelles stratégies.
  • Mettre à niveau tous les ordinateurs vers la dernière version de Profile Management avant d'activer des stratégies.

Les déploiements mixtes qui contiennent des versions 5.x et 3.2 sont pris en charge. Toutefois, de tels déploiements doivent être considérés comme une période transitoire qui existe uniquement durant la migration d'une version antérieure vers une version plus récente.

Important : les déploiements contenant la version 5.x avec la version 2.1.1 ou toute version antérieure, notamment les versions Bêta et Citrix Technical Preview, ne sont pas pris en charge. Cependant, si vous ne pouvez mettre à niveau et que ces versions doivent coexister dans votre déploiement, vous trouverez le reste de cette rubrique d'un intérêt tout particulier.

Déploiements mixtes utilisant Profile Management 2.1.1 ou version antérieure

Le reste de cette rubrique contient des informations sur la coexistence de Profile Management 2.1.1 ou version antérieure avec Profile Management 3.x ou 5.x. Elle vous indique comment migrer d'une version vers une autre. Dans cette rubrique, les termes version 2 et version 5 sont employés comme raccourcis pour désigner ces versions.

Isolez chaque version dans une unité d'organisation distincte et utilisez des magasins d'utilisateur distincts sur les ordinateurs exécutant chaque version. Si un seul magasin d'utilisateur dessert des ordinateurs exécutant les deux versions, assurez-vous que tous les paramètres de la version 5 sont désactivés tant que tous les ordinateurs n'ont pas été mis à niveau vers la version 5. Après avoir activé un paramètre spécifique à la version 4 dans un magasin d'utilisateur « mixte », les utilisateurs peuvent encore ouvrir une session sur un ordinateur exécutant la version 2. Toutefois, ils reçoivent un profil utilisateur Windows temporaire (pas leur réseau, profil utilisateur Citrix) et les modifications qu'ils apportent au profil ne sont pas enregistrées. Vous devez considérer les déploiements mixtes comme temporaires et procéder à la mise à niveau le plus rapidement possible de manière à limiter leur durée d'existence.

L'utilisation d'unités d'organisation et de magasins de l'utilisateur distincts peut s'avérer inappropriée. Pour éviter ces contraintes, vous pouvez utiliser l'une des deux stratégies suivantes. Vous configurez chaque groupe dans la version appropriée de Profile Management à l'aide du paramètre Groupes traités. La stratégie 2 est plus laborieuse que la stratégie 1. Elle implique que vous devez constamment actualiser les groupes d'utilisateurs traités de la version 5. Et que vous devez également gérer deux ensembles d'applications et de bureaux (mais vous pouvez automatiser ce processus en exportant des définitions d'application de XenApp). L'avantage réside dans le fait que vous pouvez prendre votre temps pour procéder à la migration.

Remarque : plutôt que d'utiliser les stratégies suivantes, avec Windows Server 2008 Active Directory, vous pouvez utiliser le filtrage WMI pour appliquer un objet de stratégie de groupe à un sous-ensemble d'ordinateurs dans une unité d'organisation, et déterminer quelle version de Profile Management est installée. Cela vous permet d'ajuster automatiquement les stratégies qui sont appliquées afin de les faire correspondre à la version.

Stratégie 1 : migration unique

Ce scénario part du principe qu'un temps d'arrêt est acceptable. Tous les ordinateurs sont migrés simultanément.

La stratégie de migration est la suivante :
  1. Remplacez le fichier ADM de la version 2 avec celui de la version 5. Ce dernier est compatible avec la version précédente, de façon à ce que les ordinateurs dotés de la version 2 puissent continuer à fonctionner correctement.
  2. Assurez-vous que tous les paramètres de la version 5 sont désactivés. Ne vous fiez pas à la valeur par défaut Non activé.
  3. Commencez à mettre à niveau tous les ordinateurs de la version 2 vers la version 5. Arrangez-vous pour faire concorder la planification des mises à jour avec celle de la maintenance. À une exception près, la version 5 se comporte comme la version 2 tant que vous n'activez pas de paramètre propre à la version 3. Cette exception est la suivante. Elle est rare mais plus susceptible de se produire si cette étape de mise à niveau est échelonnée sur une longue période. Si un utilisateur accède à son profil utilisateur Citrix à partir de serveurs multiples, des sessions multiples de version 4 sont créées. C'est le cas lorsqu'un utilisateur utilise une station de travail pour accéder à un bureau virtuel sur un serveur et un ordinateur portable pour accéder à une application publiée située sur un autre serveur. Profile Management doit utiliser la zone d'attente pour la seconde session de l'ordinateur portable. À ce stade, l'unité d'organisation entière est traitée comme un déploiement de la version 5 (mais sans qu'aucune des fonctionnalités de la version 5 ne soit configurée). Et le fichier PmCompatibility.ini est mis à jour pour refléter cet état.
  4. Éventuellement, définissez votre groupe d'utilisateurs traités de la version 5 pour inclure uniquement les membres d'un petit groupe pilote. Attendez que les modifications apportées à la stratégie de groupe AD soient propagées sur le réseau (par exemple le temps d'un week-end). Il n'est pas nécessaire d'interdire l'accès à d'autres utilisateurs durant cette modification. Sauvegardez les profils du groupe pilote. Puis laissez le groupe pilote tester Profile Management.
  5. Lorsque vous êtes satisfait par les résultats du groupe pilote, n'oubliez pas de sauvegarder les profils des autres utilisateurs.
  6. Utilisez la prochaine période de maintenance planifiée pour ajouter les utilisateurs restants au groupe d'utilisateurs traités de la version 5. Patientez le temps que les modifications apportées à la stratégie de groupe AD soient propagées, puis laissez les utilisateurs restants ouvrir une session.

Stratégie 2 : migration par étapes

Ce scénario part du principe que vous ne pouvez pas migrer toutes vos machines ou tous vos utilisateurs en même temps, vous devez donc sélectionner des sous-ensembles d'utilisateurs que vous migrez par lots. Il convient aux déploiements comportant plusieurs data centers ou avec des utilisateurs géographiquement éloignés.

La stratégie de migration est la suivante :
  1. Remplacez le fichier ADM de la version 2 avec celui de la version 5. Ce dernier est compatible avec la version précédente, de façon à ce que les ordinateurs dotés de la version 2 puissent continuer à fonctionner correctement.
  2. Assurez-vous que tous les paramètres de la version 5 sont désactivés. Ne vous fiez pas à la valeur par défaut Non activé.
  3. Mettez à niveau quelques ordinateurs (le premier lot) vers la version 5. Éventuellement, installez la version 5 sur de nouveaux ordinateurs. Par défaut, votre groupe d'utilisateurs traités de la version 5 est vide, aucun utilisateur n'est donc traité en tant qu'utilisateur de la version 5. Tenez compte de l'exception décrite dans la stratégie 1, qui peut également s'appliquer lorsque vous mettez à niveau des ordinateurs à l'aide de la migration par étapes.
  4. Publiez de nouvelles applications (à l'aide de XenApp) ou de nouveaux bureaux virtuels (à l'aide de XenApp ou XenDesktop) à partir de vos ordinateurs sur lesquels la version 5 est installée. Ces applications et bureaux sont identiques à celles et ceux préalablement publiés à partir d'ordinateurs dotés de la version 2, à l'exception de leurs noms. Ces noms les identifient comme affectés aux utilisateurs de la version 5.
  5. Les utilisateurs sélectionnés dans ce lot se connectent aux applications ou bureaux (à l'aide de l'Interface Web par exemple). Ils choisissent les nouvelles applications. (Utilisez l'Interface Web pour les y contraindre, en fonction du nom d'utilisateur ou de l'appartenance à un groupe). En conséquence, leurs sessions s'exécutent sur les ordinateurs dotés de la version 4 mais sont traitées avec les paramètres de la version 2.
  6. Assurez-vous d'avoir sauvegardé tous les profils des utilisateurs.
  7. Retirez les utilisateurs du groupe d'utilisateurs traités de la version 2 et ajoutez-les au groupe de la version 4. Attendez que les modifications apportées à la stratégie de groupe AD se propagent aux ordinateurs de la version 5. À la prochaine connexion, les sessions des utilisateurs sont traitées avec les paramètres de la version 5.
  8. Mettez à niveau le lot suivant d'ordinateurs et migrez le lot suivant d'utilisateurs, comme indiqué ci-dessus.