Planifier pour plusieurs plateformes
Pourquoi les profils utilisateur sur plusieurs plateformes sont-ils un tel défi ?
Il est courant que les utilisateurs accèdent à plusieurs appareils informatiques. Le défi avec tout type de profil itinérant découle des différences entre les systèmes sur ces appareils. Par exemple, si je crée un raccourci sur mon bureau vers un fichier local qui n’existe pas lorsque je passe à un autre appareil, j’aurai un raccourci brisé sur mon bureau.
Un problème similaire existe lors de l’itinérance entre un système d’exploitation (OS) à session unique et un OS à sessions multiples. Certains paramètres peuvent ne pas être applicables sur le serveur (tels que les paramètres d’alimentation ou les paramètres vidéo). De plus, si les applications ne sont pas installées de manière similaire sur chaque appareil, d’autres problèmes pourraient survenir lors de l’itinérance.
Certains paramètres de personnalisation (tels que Mes documents, Favoris et d’autres fichiers qui fonctionnent indépendamment de la version de l’OS ou de l’application) sont beaucoup plus faciles à gérer que d’autres. Mais même ces paramètres peuvent être difficiles à faire itinérer lorsqu’un type de document n’est pris en charge que sur un seul système. Par exemple, un utilisateur a Microsoft Project installé sur un système, mais sur un autre appareil, ce type de fichier n’est pas reconnu. Cette situation est exacerbée si la même application est présente sur deux systèmes, mais que sur l’un d’eux, différents modules complémentaires sont installés et attendus par un document.
Comment la modification de la méthode d’installation d’une application peut-elle causer des problèmes ?
Même si les plateformes sont installées de manière identique, si une application est configurée différemment sur chacune, des erreurs peuvent survenir au démarrage de l’application. Par exemple, une macro ou un module complémentaire peut s’activer dans Excel sur une plateforme mais pas sur une autre.
Le menu Démarrer
Le menu Démarrer contient des liens (fichiers LNK et LNK2). La partie spécifique à l’utilisateur du menu est stockée dans le profil et les utilisateurs peuvent modifier cette partie du menu. L’ajout de liens personnalisés (vers des exécutables ou des documents) est courant. De plus, les liens spécifiques à une langue entraînent plusieurs entrées de menu Démarrer pour la même application. En outre, les liens pointant vers des documents peuvent être invalides sur d’autres ordinateurs. La raison est que le chemin d’accès au document est relatif à un autre système, ou qu’il s’agit d’un chemin réseau inaccessible.
Par défaut, Profile Management n’enregistre pas le contenu du dossier du menu Démarrer car les liens pointant vers des exécutables dépendent souvent de l’ordinateur. Cependant, dans les situations où les systèmes sont similaires, l’inclusion du menu Démarrer dans votre configuration Profile Management améliore la cohérence lorsque les utilisateurs passent d’un bureau à l’autre. Alternativement, vous pouvez traiter le menu Démarrer avec la redirection de dossiers.
Remarque : Des effets secondaires imprévisibles peuvent souvent résulter de ce qui semble être les changements les plus inoffensifs. Par exemple, consultez l’article à l’adresse https://helgeklein.com/blog/2009/09/citrix-user-profile-manager-upm-and-the-broken-rootdrive/ sur le blog Sepago.
Toujours tester et vérifier le comportement du menu Démarrer sur toutes les plateformes.
La barre d’outils Lancement rapide
La barre d’outils Lancement rapide contient des liens et est configurable par les utilisateurs. Par défaut, la barre d’outils Lancement rapide est enregistrée par Profile Management. Dans certains environnements, l’enregistrement de la barre d’outils Lancement rapide peut ne pas être souhaitable car les liens peuvent dépendre de l’ordinateur.
Pour exclure la barre d’outils des profils, ajoutez l’entrée suivante à la liste d’exclusion des dossiers : AppData\Roaming\Microsoft\Internet Explorer\Quick Launch.
Quels types de profils créer ?
Important : En raison de la différence de leur structure, nous recommandons de créer des profils de version 1 et de version 2 distincts pour chaque utilisateur dans tout environnement contenant plusieurs plates-formes. Les différences entre les espaces de noms de profil de Windows Vista et Windows 7 rendent difficile le partage de profils entre ces plates-formes. Des échecs peuvent également survenir entre Windows XP et Windows Server 2003. Pour plus d’informations sur les profils de version 1 et de version 2, consultez À propos des profils.
La définition de plusieurs plates-formes ici inclut non seulement plusieurs systèmes d’exploitation (y compris ceux de différentes architectures) mais aussi plusieurs versions d’applications exécutées sur le même système d’exploitation. Les exemples suivants illustrent les raisons de cette recommandation :
- Les systèmes 32 bits peuvent contenir des clés de registre qui indiquent au système d’exploitation de démarrer des applications à des emplacements spécifiques aux systèmes d’exploitation 32 bits. Si les clés sont utilisées par un profil utilisateur Citrix® sur un système 64 bits, l’emplacement pourrait ne pas exister sur ce système et l’application ne démarrerait pas.
- Microsoft Office 2003, Office 2007 et Office 2010 stockent certains paramètres Word dans différentes clés de registre. Même si ces applications s’exécutent sur le même système d’exploitation, vous devez créer des profils distincts pour les trois versions différentes de l’application Word.
Nous recommandons d’utiliser la redirection de dossiers Microsoft avec les profils utilisateur Citrix pour aider à assurer l’interopérabilité des profils. Dans un environnement où Windows Vista ou Windows 7 doit coexister avec Windows XP, c’est encore plus important.
Conseil : Selon la politique de gestion des données de votre organisation, il est recommandé de supprimer les profils du magasin d’utilisateurs et du magasin de paramètres multiplateformes pour les comptes d’utilisateurs qui ont été supprimés d’Active Directory.