Cas d’utilisation de Profile Management
Citrix Profile Management peut être implémenté pour gérer les profils des utilisateurs dans différents scénarios, quelle que soit la manière dont les applications sont livrées aux utilisateurs ou l’endroit où elles sont hébergées. Voici des exemples de ces scénarios :
-
Citrix Virtual Apps™ avec des applications publiées
-
Citrix Virtual Apps avec des bureaux publiés
-
Citrix Virtual Apps avec des applications diffusées en continu dans un environnement d’isolation
-
Applications diffusées en continu vers Citrix Virtual Desktops™
-
Applications installées sur Citrix Virtual Desktops
-
Applications diffusées en continu vers des postes de travail physiques
-
Applications installées localement sur des postes de travail physiques
Parmi ces scénarios, Citrix considère les cas d’utilisation suivants comme les plus courants :
- Sessions multiples - L’utilisateur accède à plusieurs silos de serveurs Citrix Virtual Apps et a donc plusieurs sessions ouvertes. Notez cependant que l’isolation et la diffusion d’applications sur le serveur sont des alternatives aux silos de serveurs. Ce scénario est décrit plus en détail dans cette rubrique.
- « Le dernier écrit l’emporte » et problèmes de cohérence des profils itinérants - La dernière écriture sur le profil itinérant entraîne l’enregistrement de tous les paramètres. Par conséquent, les profils itinérants peuvent ne pas conserver les bonnes données si plusieurs sessions sont ouvertes et que des modifications intermédiaires sont apportées. De plus, les paramètres peuvent ne pas être correctement écrits dans le profil en raison de problèmes de réseau, de stockage ou d’autres problèmes. Ce scénario est décrit plus en détail dans cette rubrique.
- Profils volumineux et vitesse de connexion - L’encombrement des profils peut rendre les profils utilisateur ingérables, entraînant des problèmes de stockage et de gestion. Généralement, lors de la connexion, Windows copie l’intégralité du profil de l’utilisateur sur le réseau vers le périphérique utilisateur local. Pour les profils volumineux, cela peut prolonger le temps de connexion de l’utilisateur.
Sessions multiples
En particulier dans les grands environnements, il peut être nécessaire pour les utilisateurs d’ouvrir plusieurs sessions pour accéder à différentes applications hébergées sur différents serveurs Citrix Virtual Apps, que ce soit dans la même batterie ou dans plusieurs batteries. Dans la mesure du possible, envisagez l’isolation ou la diffusion d’applications pour héberger les applications sur le même serveur Citrix Virtual Apps afin de permettre aux utilisateurs d’accéder à toutes les applications à partir d’un seul serveur et donc d’une seule session. Cependant, cela peut ne pas être possible si une unité commerciale contrôle des serveurs spécifiques ou si les applications ne peuvent pas être diffusées en continu.
Une fois qu’il a été déterminé qu’il est effectivement nécessaire pour les utilisateurs d’accéder aux applications depuis divers serveurs Citrix Virtual Apps, l’impact sur les profils doit être évalué.
Le diagramme suivant illustre un exemple où les paramètres d’application peuvent être perdus lorsque plusieurs sessions existent.
Par exemple, Mary souhaite accéder aux applications A, B et C et elle est dirigée respectivement vers le serveur 1, le serveur 8 et le serveur 12. Lors de la connexion à chaque application, le profil itinérant des services Terminal Server de Mary est chargé sur chaque serveur et les dossiers sont redirigés pour chaque session. Lorsque Mary est connectée à l’application A sur le serveur 1, elle modifie le paramètre 1 et se déconnecte de cette session. Mary termine ensuite son travail dans les deux autres applications et se déconnecte.
Lors de la déconnexion, la modification que Mary a effectuée au cours de la session sur le serveur 1 est écrasée car les paramètres de la dernière session fermée sont conservés, et non la modification intermédiaire. Lorsque Mary se connecte à l’application A le lendemain, elle est frustrée car la modification qu’elle a apportée n’est pas visible.
Profile Management peut généralement empêcher cette situation de se produire. Profile Management ne réécrit que les paramètres spécifiques qui ont été modifiés au cours d’une session ; tous les autres paramètres inchangés restent intacts. Le seul conflit potentiel qui pourrait survenir serait donc si Mary modifiait le paramètre 1 au cours d’une autre session. Cependant, l’utilisateur s’attendrait probablement à ce que la modification la plus récente soit conservée, ce qui est le cas si Profile Management est utilisé dans ce scénario.
Problèmes de cohérence des profils itinérants et du « dernier écrit gagne »
Ce scénario est similaire au premier de ce sujet. Les problèmes de « dernier écrit gagne » peuvent se présenter de diverses manières, et la frustration des utilisateurs peut augmenter à mesure que le nombre d’appareils accédés augmente.
Étant donné que le profil itinérant conserve toutes les données de profil, à l’exception des dossiers qui ont été redirigés, le profil utilisateur peut devenir volumineux. Non seulement cela augmente le temps de connexion car le profil doit être téléchargé, mais le potentiel d’incohérence augmente pendant la phase d’écriture de la déconnexion, en particulier en cas de problèmes réseau.
Profile Management permet d’exclure des données spécifiques du profil utilisateur, ce qui permet de maintenir le profil utilisateur à une taille minimale. Étant donné que seules les différences sont écrites dans le profil, la phase d’écriture de la déconnexion implique moins de données et est plus rapide. Profile Management peut être bénéfique pour les applications qui utilisent des profils pour des données temporaires mais ne les nettoient pas lorsque les applications se terminent.