Mettre à niveau et migrer
Cette section contient les procédures de mise à niveau du logiciel Profile Management et des informations sur la transition de vos profils utilisateur Windows existants vers des profils utilisateur Citrix. Par exemple, vous pouvez facilement mettre à niveau de la version 3.x vers la version 5.x en utilisant les procédures.
Avant la mise à niveau, comprenez quelles fonctionnalités et quels paramètres de Profile Management sont disponibles dans la version à partir de laquelle et vers laquelle vous effectuez la mise à niveau. Pour consulter ces informations, consultez Stratégies Profile Management. Pour faciliter les mises à niveau des fichiers .ini vers la stratégie de groupe, ce sujet mappe également les paramètres du fichier .ini aux paramètres des fichiers .adm et .admx.
Ne configurez pas Profile Management (que ce soit dans la stratégie de groupe ou avec le fichier .ini) pendant la mise à niveau. Séparez ces deux tâches en mettant d’abord à niveau votre déploiement, puis en configurant les paramètres selon les besoins, idéalement en répondant aux questions de Décider d’une configuration.
Conseil : Vous pouvez appliquer un correctif à votre déploiement de Profile Management 2.1.1 ou version ultérieure en effectuant une mise à niveau vers la dernière version. Après la mise à niveau, vous pouvez activer toute fonctionnalité ultérieure selon les besoins.
Déploiements mixtes
Pour les déploiements dans lesquels différentes versions de Profile Management coexistent, procédez comme suit :
- Minimisez la durée d’existence d’un déploiement mixte.
- Ajoutez le fichier .adm ou .admx de la dernière version à chaque objet de stratégie de groupe sur tous les contrôleurs de domaine. Assurez-vous que toutes les nouvelles fonctionnalités sont désactivées et laissez le temps aux nouvelles stratégies de se propager.
- Mettez à niveau tous les ordinateurs vers la dernière version de Profile Management avant d’activer toute stratégie.
Les déploiements mixtes contenant les versions 5.x et 3.2 sont pris en charge. Cependant, considérez ces déploiements comme un état temporaire qui existe pendant la migration de la version antérieure vers la version ultérieure.
Important : Les déploiements qui contiennent la version 5.x avec la version 2.1.1 ou toute version antérieure, y compris les versions préliminaires techniques ou bêta de Citrix, ne sont pas pris en charge. Cependant, si vous ne pouvez pas effectuer la mise à niveau et que ces versions doivent coexister dans votre déploiement, le reste de ce sujet pourrait vous être utile.
Déploiements mixtes impliquant Profile Management 2.1.1 ou version antérieure
Le reste de ce sujet contient des informations sur la coexistence de Profile Management 2.1.1 ou version antérieure, et de Profile Management 3.x ou 5.x. Il vous explique comment migrer d’une version à l’autre. Dans ce sujet, les termes Version 2 et Version 5 sont utilisés comme abréviations pour ces versions.
Isolez chaque version dans une unité d’organisation (OU) distincte et maintenez des magasins d’utilisateurs séparés pour les ordinateurs exécutant chaque version. Alternativement, si un seul magasin d’utilisateurs sert des ordinateurs exécutant les deux versions, assurez-vous que tous les paramètres de la version 5 sont désactivés jusqu’à ce que tous les ordinateurs aient été mis à niveau vers la version 5. Après avoir activé un paramètre de la version 4 dans un magasin d’utilisateurs “mixte”, les utilisateurs peuvent toujours se connecter à un ordinateur exécutant la version 2. Mais ils reçoivent un profil utilisateur Windows temporaire (pas leur profil utilisateur réseau Citrix®) et les modifications qu’ils apportent à ce profil ne sont pas enregistrées. Vous devez considérer les déploiements mixtes comme temporaires et minimiser leur durée d’existence avant de terminer la mise à niveau.
L’utilisation d’unités d’organisation et de magasins d’utilisateurs distincts peut être peu pratique. 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 demande plus de travail que la stratégie 1. Avec la première, vous continuez à mettre à jour les groupes d’utilisateurs traités de la version 5. Et vous maintenez deux ensembles d’applications et de bureaux (mais vous pouvez automatiser en exportant les définitions d’applications depuis Citrix virtual apps™). L’avantage est que vous pouvez prendre votre temps pour la migration.
Remarque : Comme alternative aux stratégies suivantes, avec Windows Server 2008 Active Directory, vous pouvez utiliser le filtrage WMI pour appliquer une GPO à un sous-ensemble d’ordinateurs dans une UO, et déterminer quelle version de Profile Management est installée. Ainsi, vous pouvez ajuster automatiquement la stratégie appliquée, pour qu’elle corresponde à la version.
Stratégie 1 : Migration ponctuelle
Ce scénario suppose qu’un certain temps d’arrêt est acceptable. Tous les ordinateurs sont migrés en même temps.
La stratégie de migration est la suivante :
- Remplacez le fichier ADM de la version 2 par le fichier de la version 5. Ce dernier est compatible avec la version précédente, de sorte que les ordinateurs de la version 2 continuent de fonctionner normalement.
- Assurez-vous que tous les paramètres de la version 5 sont désactivés. Ne vous fiez pas au paramètre par défaut Non activé.
- Commencez la mise à niveau de tous les ordinateurs de la version 2 vers la version 5. Intégrez cette opération à vos calendriers de maintenance et de mise à jour habituels. À une exception près, la version 5 agit comme la version 2 jusqu’à ce que vous activiez un paramètre de la version 5. L’exception est la suivante. C’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 depuis plusieurs serveurs, plusieurs sessions de la version 4 sont créées. Par exemple, il utilise d’abord un poste de travail pour accéder à un bureau virtuel sur un serveur, puis un ordinateur portable pour accéder à une application publiée sur un autre. Profile Management doit utiliser la zone d’attente pour la deuxième session, celle de l’ordinateur portable. À ce stade, l’intégralité de l’UO est traitée comme un déploiement de la version 5 (bien que sans aucune fonctionnalité de la version 5 configurée). Et PmCompatibility.ini est mis à jour pour refléter ce changement.
- En option, configurez votre groupe d’utilisateurs traités de la version 5 pour qu’il n’inclue que les membres d’un petit groupe pilote. Attendez que les modifications de la stratégie de groupe AD se propagent sur l’ensemble du réseau (par exemple, pendant un week-end). Vous n’avez pas besoin d’empêcher l’accès aux autres utilisateurs pendant que cette modification a lieu. Sauvegardez les profils du groupe pilote. Ensuite, laissez le groupe pilote tester Profile Management.
- Lorsque vous êtes satisfait des résultats du groupe pilote, assurez-vous d’avoir sauvegardé les profils des autres utilisateurs.
- Utilisez la prochaine période de maintenance planifiée pour ajouter les utilisateurs restants au groupe d’utilisateurs traités de la version 5. Laissez suffisamment de temps pour que les modifications de la stratégie de groupe AD se propagent, et laissez les utilisateurs restants se connecter.
Stratégie 2 : Migration progressive
Ce scénario suppose que vous ne pouvez pas déplacer toutes vos machines ou tous vos utilisateurs vers la nouvelle version en une seule fois, vous sélectionnez donc des sous-ensembles d’utilisateurs que vous migrez par lots. Il convient aux déploiements avec plusieurs centres de données ou des utilisateurs géographiquement distribués.
La stratégie de migration est la suivante :
- Remplacez le fichier ADM de la version 2 par le fichier de la version 5. Ce dernier est compatible avec la version précédente, de sorte que les ordinateurs de la version 2 continuent de fonctionner normalement.
- Assurez-vous que tous les paramètres de la version 5 sont désactivés. Ne vous fiez pas au paramètre par défaut « Non activé ».
- Mettez à niveau quelques ordinateurs (le premier lot) vers la version 5. Vous pouvez également installer la version 5 sur de nouveaux ordinateurs. Par défaut, votre groupe d’utilisateurs traités par la version 5 contient un groupe vide, de sorte qu’aucun utilisateur n’est traité comme un utilisateur de la version 5. Soyez conscient de l’exception décrite dans la Stratégie 1, qui peut également s’appliquer lorsque vous mettez à niveau des ordinateurs dans une migration par étapes.
- Publiez de nouvelles applications (à l’aide de Citrix Virtual Apps) ou des bureaux virtuels (à l’aide de Citrix Virtual Apps ou Citrix Virtual Desktops™) à partir de vos ordinateurs de la version 5. Ces applications et bureaux sont identiques à ceux précédemment publiés à partir de vos ordinateurs de la version 2, à l’exception de leurs noms. Ces noms les identifient comme étant destinés aux utilisateurs de la version 5.
- Les utilisateurs sélectionnés de ce lot se connectent aux applications ou aux bureaux (par exemple, à l’aide de Web Interface). Ils choisissent les nouvelles applications. (Utilisez Web Interface pour appliquer cette étape, en fonction du nom d’utilisateur ou de l’appartenance au groupe). En conséquence, leurs sessions s’exécutent sur les ordinateurs de la version 4, mais elles sont traitées avec les paramètres de la version 2.
- Assurez-vous d’avoir sauvegardé tous les profils des utilisateurs.
- Déplacez les utilisateurs du groupe d’utilisateurs traités par la version 2 vers le groupe de la version 4. Attendez que les modifications de la stratégie de groupe AD se propagent aux ordinateurs de la version 5. La prochaine fois qu’ils se connecteront, les sessions des utilisateurs seront traitées avec les paramètres de la version 5.
- Mettez à niveau le lot suivant d’ordinateurs et migrez le lot suivant d’utilisateurs, comme décrit précédemment.