Cas d’utilisation de Profile Management
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 applications publiées
-
Citrix Virtual Apps avec bureaux publiés
-
Citrix Virtual Apps avec applications diffusées en continu dans un environnement d’isolation
-
Applications diffusées en continu vers les bureaux virtuels Citrix™
-
Applications installées sur les bureaux virtuels Citrix
-
Applications diffusées en continu vers les bureaux physiques
-
Applications installées localement sur les bureaux 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 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 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 difficiles à gérer, 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, ce comportement 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 en continu 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 à 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 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 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.
La gestion des profils peut généralement empêcher cette situation de se produire. La 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. Ainsi, le seul conflit potentiel qui pourrait survenir serait 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 la gestion des profils est utilisée dans ce scénario.
Problèmes de cohérence des profils itinérants et de « dernière écriture gagnante »
Ce scénario est similaire au premier de ce sujet. Les problèmes de « dernière écriture gagnante » 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.
La 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. La 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.