Cas d’utilisation de Profile Management
Citrix Profile Management peut être implémenté pour gérer les profils utilisateur dans différents scénarios, quelle que soit la méthode utilisée pour mettre les applications à la disposition des utilisateurs où l’endroit où elles sont hébergées. Ci-dessous figurent des exemples de scénarios :
-
Citrix Virtual Apps avec applications publiées
-
Citrix Virtual Apps avec bureaux publiés
-
Citrix Virtual Apps avec applications streamées dans un environnement d’isolation
-
Applications streamées sur Citrix Virtual Desktops
-
Applications installées sur Citrix Virtual Desktops
-
Applications streamées sur des bureaux physiques
-
Applications installées localement sur des bureaux physiques
Parmi ces scénarios, Citrix considère ce qui suit comme les cas d’utilisation les plus courants :
- Sessions multiples : l’utilisateur accède à de multiples silos de serveurs Citrix Virtual Apps et dispose donc de plusieurs sessions ouvertes. Veuillez noter que l’isolation d’application et le streaming sur le serveur sont des alternatives aux silos de serveurs. Ce scénario est décrit avec plus de précision dans cette rubrique.
- Modèle « Last Write Wins » et problèmes d’homogénéité du profil itinérant : étant donné que 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 données adéquates si de multiples sessions sont ouvertes et que des modifications sont apportées entre-temps. Par ailleurs, il est possible que les paramètres ne soient pas écrits correctement sur le profil en raison de problèmes de réseau, de stockage ou autres. Ce scénario est décrit avec plus de précision dans cette rubrique.
- Profils volumineux et temps d’ouverture de session : l’engorgement des profils utilisateur peut les rendre difficiles à utiliser, ce qui entraîne des problèmes de stockage et de gestion. Durant l’ouverture de session, Windows copie généralement le profil utilisateur entier via le réseau sur la machine utilisateur locale. Dans le cas de profils très volumineux, cela peut contribuer à ralentir les temps d’ouverture de session des utilisateurs.
Sessions multiples
Dans les environnements de grande taille, les utilisateurs peuvent être amenés à ouvrir des sessions multiples pour accéder à des applications différentes hébergées sur des serveurs Citrix Virtual Apps différents, que ces derniers appartiennent à la même batterie où à plusieurs batteries. Dans la mesure du possible, privilégiez l’utilisation de l’isolation d’application ou du streaming pour héberger les applications sur le même serveur Citrix Virtual Apps pour permettre aux utilisateurs d’accéder à toutes les applications à partir d’un seul serveur et donc d’une session unique. Toutefois, cela n’est pas toujours possible si une unité d’entreprise contrôle certains serveurs ou que des applications ne peuvent pas être streamées.
Lorsque la nécessité pour les utilisateurs d’accéder à des applications hébergées sur des serveurs Citrix Virtual Apps différents a été identifiée, l’impact sur les profils doit être évalué.
Le diagramme suivant illustre un scénario où les paramètres d’application peuvent être perdus lorsque plusieurs sessions existent.
Par exemple, Marie veut accéder aux applications App A, App B et App C et elle est routée vers les Serveur 1, Serveur 8 et Serveur 12 respectivement. Lorsqu’elle se connecte à chaque application, le profil itinérant des services Terminal Server de Marie est chargé sur chaque serveur et les dossiers sont redirigés pour chaque session. Lorsqu’elle est connectée à l’application App A sur le Serveur 1, Marie modifie le Paramètre 1 et ferme cette session. Marie termine ensuite ses activités dans les deux autres applications et ferme la session.
Lors de la fermeture de session, les modifications que Marie a apportées dans la session sur le Serveur 1 sont écrasées car les paramètres de la dernière session fermée sont conservés, contrairement aux modifications intermédiaires. Lorsque Marie se connecte à l’application App A le lendemain, elle est surprise de ne pas voir ses modifications.
Profile Management peut généralement empêcher l’apparition de ce problème. Profile Management ne réécrit que les paramètres spécifiques qui ont été modifiés durant une session ; tous les autres paramètres non modifiés sont laissés tels quels. Par conséquent, un conflit peut uniquement survenir si Marie a modifié le Paramètre1 dans une autre session. Toutefois, l’utilisateur s’attend à ce que la dernière modification soit conservée, ce qui est le cas si Profile Management est utilisé dans ce scénario.
Modèle « Last Write Wins » et problèmes d’homogénéité du profil itinérant
Ce scénario est similaire au premier scénario développé dans cette rubrique. Les problèmes inhérents au modèle « last write wins » se manifestent de plusieurs façons et peuvent faire naître une certaine frustration chez les utilisateurs à mesure que le nombre de périphériques utilisé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 atteindre des proportions importantes. Cela entraîne non seulement un accroissement de la durée d’ouverture de session car le profil doit être téléchargé, mais exacerbe également les problèmes d’homogénéité durant la phase d’écriture de la fermeture de session, plus particulièrement en présence de problèmes réseau.
Profile Management permet d’exclure des données spécifiques du profil utilisateur, ce qui permet de limiter la taille du profil utilisateur. Étant donné que seules les différences sont écrites sur le profil, la phase d’écriture de la fermeture de session implique moins de données et elle est par conséquent plus rapide. Profile Management peut s’avérer bénéfique pour les applications qui utilisent des profils pour des données temporaires, mais n’assure pas le nettoyage des profils lors de la fermeture de l’application.