Cas d’utilisation de la Gestion des profils
Citrix Profile Management peut être mis en œuvre pour gérer les profils des utilisateurs dans différents scénarios, quelle que soit la manière dont les applications sont fournies 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 des bureaux virtuels Citrix™
-
Applications installées sur des bureaux virtuels Citrix
-
Applications diffusées en continu vers des bureaux physiques
-
Applications installées localement sur des bureaux physiques
Parmi ces scénarios, Citrix considère les cas suivants comme les cas d’utilisation 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 des applications et la diffusion en continu sur le serveur sont des alternatives aux silos de serveurs. Ce scénario est décrit plus en détail dans cette rubrique.
- « La dernière écriture l’emporte » et problèmes de cohérence des profils itinérants - La dernière écriture dans le profil itinérant entraîne l’enregistrement de tous les paramètres. Par conséquent, les profils itinérants risquent de 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 d’ouverture de session - L’encombrement des profils peut rendre les profils utilisateur difficiles à gérer, entraînant des problèmes de stockage et de gestion. Généralement, lors de l’ouverture de session, 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, ce comportement peut prolonger le temps d’ouverture de session 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 de serveurs ou dans plusieurs batteries de serveurs. Dans la mesure du possible, envisagez l’isolation des applications ou la diffusion en continu 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 à partir de divers serveurs d’applications virtuelles Citrix, 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 acheminé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.
Gestion des profils peut généralement empêcher cette situation de se produire. Gestion des profils 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 Gestion des profils est utilisé dans ce scénario.
Problèmes de cohérence des profils itinérants et de la règle du « dernier écrit l’emporte »
Ce scénario est similaire au premier de ce sujet. Les problèmes liés au « dernier écrit l’emporte » peuvent se présenter de diverses manières, et la frustration de l’utilisateur 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.
Gestion des profils 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. Gestion des profils 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.