Bonjour à tous,
C’est en désespoir de cause que je viens poster sur le forum, n’ayant trouvé aucune solution à mon problème.
J’espère que vous allez réussir à m’aider ;D
Notre environnement : Domaine Windows 2000, serveur mixte en production 2000/2003, Citrix CPS4.
Problème : Incohérence dans les Sessions multiples, suivant que la connexion soit effectuée sur un serveur Windows 2000 ou 2003.
Détails :
Nos utilisateurs se connectent via une Secure-Gateway à notre portail. Ils accèdent ensuite à leurs applications publiées et/ou des bureaux Citrix. A la connexion, un script était joué afin d’empêcher les connexions multiples, sans empêcher le lancement de plusieurs applicatifs publiés.
Nous rencontrons le problème suivant, problème qui a évolué et qui c’est modifié et amplifié aujourd’hui.
Problème 1 : Nous détectons que le script qui empêche les sessions multiples ne se joue plus sur les serveurs Windows 2003.
Nous avons vérifié le script, le réseau (Nous sommes hébergé), rien à faire. Comme nous sommes en phase de migration vers Windows 2003, sur 2 VM de tests qui sont actuellement en AD 2003, nous avons testé le script, avec lequel nous n’avons pas d’erreur. Nous en sommes resté la, en nous disans, sa s’arrangera lorsque nous allons migrer, l’impact n’était pas bloquant ;
Problème 2 : Aujourd’hui, le problème c’est amplifié. Nous sommes obligé de désactiver le script de contrôle des sessions multiples sur l’ensemble de nos serveurs, car si nous ne le faisons pas, il est impossible au client de lancer plusieurs applications publiées. La réponse que renvoie le script est : Vous avez atteint le nombre maximal de session autorisé, soit 1.
Cela ne devrait pas être le cas, car le script n’interdit pas aux utilisateurs de lancer plusieurs applicatifs publiés, qui sont lancé sous le même ID de session. Le problème est le même sous 2000-2003.
Problème 3 : Suite du problème 2, nous remarquons que tous nos clients qui lancent plusieurs applicatif publiés, le sont sous des ID de session différent ???
Nous avons retourné le problème dans tous les sens, stratégies AD (Aucune en ce qui concerne TS ou Citrix), stratégies Citrix (Il en existe une, dans Users Workspace/Connections/Limit total concurrent sessions > paramétrer à 1. Cette police est appliquées sur les utilisateurs, les serveurs et une adresse IP (Celle que les client empruntent via notre Secure Gateway). Je ne maitrise pas ces paramétrages, ils ont été positionné ainsi à la création de la ferme.
Rien de particulier dans les paramétrages en local sur les serveurs, pour les propriétés RDP/ICA. Sur les serveur Windows 2003 (1 seul Paramétre à : restric each user to one session) rien sur les Windows 2000, et que ce paramètre soit la ou pas, cela ne change rien !
Si vous avez une idée sur ce problème, elle est la bienvenue !
Merci à vous !
je pense que ta limitation est avant tout présente dans ta nouvelle ferme et non du a ton script, vu que l’erreur qu’il remonte est typiquement celle de citrix dans une config à session definie.
pour ton deuxieme problem, c’est le session sharing qui a sauté
tu peu regarder ici :
http://support.citrix.com/article/CTX159159
Attention : “Sur les serveur Windows 2003 (1 seul Paramétre à : restric each user to one session)” tu as paramétré cela au niveau terminal serveur ou au niveau des stratégies (policies) Citrix dans la console ???
Ce paramètre a été testé, car des utilisateurs se voyaient reprendre leur session. Ce qui est un comportement normal de TS lorsque ce paramètre est activé. Soit une double session est active, soit la session est reprise lors d’un logon multiple. En fait, suivant les serveurs et suivant les besoins de nos utilisateurs (serveur non Citrix, accès à ces serveurs via RDP) le paramètre est actif au niveau stratégie TS.
C’est dans le lien donné par FLO, mais c’est le cas le plus courant: Toutes tes applications on la même configuration du nombre de couleurs ?
Oui, toutes les applications sont paramétrées de la même façon. on y perd un peu notre latin. En se penchant un peu plus sur ce problème, nous pouvons nous rendrons compte qu’il est aléatoire. En fait tous les serveurs ne sont pas impactés et c’est aléatoire 2000-2003 ? Lorsque l’on vérifie la configuration des environnements, ceux-ci on les mêmes paramètres ICA/RDP, ils sont impactés dans notre AD par les mêmes polices, que ce soit au niveau Users ou Computers ???
j’en profite pour vous remercier pour vos réponses, concernant le session sharing, il semble que la conf n’est pas sautée, nous avions déjà investigués sur ce sujet sans trouver de piste.
Bonjour !
je reviens vers vous pour vous indiquer que nous avons fini par trouver la solution.
Merci à FLO pour sa suggestion concernant la CTX159159, en fait la solution à notre problème était bien lié à cette résolution.
Nous avons juste eu un petit problème d’interprétation de la KB Citrix, dixit la KB :
le point 1, pour modification du registre :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixwfshellTWI
Name: SeamlessFlags
Type: REG_DWORD
Data: 0 x 100 < c’est ici que nous avons péché
Il s’agissait en fait d’une valeur dword par défaut…Soit 100 (hexadecimal) ou 256 (décimal)
La valeur n’est pas très clairement indiqué dans la KB à mon avis (Soit : 0x00000100 à l’afficage de la valeur Dword).
Nous ne savons pas pourquoi ce problème nous à impacté pour l’instant…
Nous avons déployé une modification du registre sur l’ensemble de nos serveurs via une GPO en action corrective.
Encore merci à FLO :-*
la KB est parfaitement claire.
les valeurs sont toutes indiquées sous la forme 0x0000000 qui est de l’hexadecimal
Je sais…c’est une erreur d’interprétation toute bête, mea-culpa
t’es pas tout seul va… j’ai passé jeudi UNE heure a tenter de diagnostiquer un gros souci d’autocréation d’imprimante avant de me rendre compte que le cher monsieur n’avait pas utilisé Citrix Print DefaultPrnFlags tool pour gérer le DefaultPrnFlags et bien évidement avait entré une valeur décimale au lieu d’hexa…
Puisque tu en parles…je l’avais oublié…au sujet du DefaultPrnFlags…
A partir de la KB de FLO, nous avons rebondis sur celle-ci :
http://support.citrix.com/article/CTX106744
Nous avons remarqués que nos valeur de PrnFlags étaient bien mal paramétrées…
cqfd