Bonjour,
Sur plusieurs batterie Citrix PS4 en 2K3 avec R05, R06+R06006, utilisant les imprimantes Citrix avec driver universel et mappage dynamique.
Apres avoir ecrit un script qui au login analyse HKCUPrintersDevModePerUser il s’avere que 5% environ des connexion non pas d’imprimante au login.
Cet effet est tres aleatoire, pas de serveur en particulier, pas de user, pas de poste, pas de plage horaire en particulier.
En rajoutant la commande change client /default_printers dans le script on en regle 2 % environ.
Ce type de probleme apparait sur 5 batterie Citrix de 200 a 300 Users chacunes.
Il a souvent été signalé par les users, mais habitué a fermer puis re-ouvrir cela passe inapercu au niveaux des appels.
Cela est en effet un probleme grave et qui traine depuis longtemps chez Citrix.
Re-signer Ctx_smauser, ajout du groupe administrateurs, policy Citrix, rien y fait…
Je peut vous fournir le script pour analyser vos serveurs si besoin.
Merci.
c'est à dire ?
pour voir si j'ai compris :
5% des utilisateurs n'ont pas d'imprimantes dans leur session c'est cela ?
pour info, le DevModePerUser n'est pas le meilleur moyen pour vérifier si le user a bien des imprimantes dans sa session... la preuve? ma propre session ICA en cours (voir PJ) où malgré mes deux seules imprimantes autocrées, j'ai une jolie collection d'objets dans DevModePerUser
Bonjour,
Vous avez raison, mais vous etes administrateur.
Il est mémoriser a cet endroit toutes les actions de type “option sur l’imprimante”. il est d’ailleur possible de le purger au logout car le client citrix recreer les param au login.
Ce qui est sur, c’est que les users nous le signale depuis longtemps et qu’on a aucune indication valable dans les log windows.
Je vous joint le script en kixtart, faites un essai vous serez tres surpris …
setconsole(“Hide”)
;setconsole(“show”)
;Inclure par : run “kix32.exe Printers.kix” dans reseau.kix
sleep 5
$passe = 0
Gosub “Test_Printers"
if $printer=”"
; si pas d’imprimantes les forcer
SHELL “%COMSPEC% /C " + “change client /default_printers"
Gosub “Error"
Gosub “Test_Printers"
Endif
if $printer=””
; impossible de monter les deprimantes
Gosub “Encore_Error"
Else
Gosub “logs"
Endif
EXIT 0
:Test_Printers
:boucle
$Index = 0
@ERROR = 0
while @ERROR = 0
$KeyName = ENUMVALUE(“HKEY_CURRENT_USERPrintersDevModePerUser”, $Index)
$Index = $Index + 1
$session=instrrev($KeyName, “dans la session”)
If $KeyName”” AND $session””
$printer=$printer+";"+$KeyName
endif
loop
RETURN
:Logs
$error=RedirectOutput (“M:tempPrinters.csv”, 0)
? @USERID+";"+%CLIENTNAME%+";"+%SESSIONNAME%+";"+@WKSTA+";"+@DATE+";"+@TIME+$printer
RedirectOutput ("")
RETURN
:Error
$error=RedirectOutput (“M:tempPrinters.csv”, 0)
? @USERID+";"+%CLIENTNAME%+";"+%SESSIONNAME%+";"+@WKSTA+";"+@DATE+";"+@TIME+";PAS D’IMPRIMANTES…“
RedirectOutput (”")
RETURN
:Encore_Error
$error=RedirectOutput (“M:tempPrinters.csv”, 0)
? @USERID+";"+%CLIENTNAME%+";"+%SESSIONNAME%+";"+@WKSTA+";"+@DATE+";"+@TIME+";PAS D’IMPRIMANTES ENCORE…“
RedirectOutput (”")
RETURN
Vous avez raison, mais vous etes administrateur.
moi administrateur de la ferme de Production de ma société ? :chav_mouarf2: elle est bonne celle là
je reitère mes dires d'hier: ce contenu n'a RIEN à voir avec l'autocréation Citrix. C'est Windows qui se charge d'écrire les informations à cet endroit (en fait le Spooler).
Les propriétés d'imprimantes autocréées modifiées par l'utilisateur au sein d'une session ICA sont sauvegardées, au logoff, dans HKEY_CURRENT_USERSoftwareCitrixPrinterProperties, soit sur la machine cliente (par défaut) ou dans le profil utilisateur sur le serveur.
Cependant, si l'autocréation Citrix n'est pas utilisée, alors oui, cette clef est utilisée. Mais dans ce cas, le problème n'est pas lié à l'autocréation Citrix ...
tu n'a pas répondu à ma question :
Bonjour,
Le registre que je vous indique est bien utiliser pour stocker les params de taille papier, bac et imp par defaut au login. Maintenant vous avez raison citrix stocke ailleur selon le parametrage de la strategie.
Faites un essai simple, connectez vous sur le bureau, purger le registre HKEY_CURRENT_USERPrintersDevModePerUser, puis taper “change client /default_printers” et regarder ce registe
Le probleme de l’imprimante aleatoire, traine depuis longtemps et le fait de tracer nous met en evidence ce qu’on a du mal a constater. Un user vat se loguer 10 fois sans pb, mais la 11 !!!, il vat donc sortir puis se re-connecter. Le fait de tracer nous aide vraiment a diagnostiquer. Et le simple fait de mettre “change client /default_printers” et que cela regle des cas n’ai pas normal aussi.
S.V.P prener le temps de tracer, qu’importe le registre mais vous risqué d’etre tres etonné
Pour ce qui est du fait d’ouvrir un appel chez citrix, j’ai commencé a travailler sur citrix avec Winframe et tous les appels que j’ai pu ouvrir n’on jamais abouti, alors j’ai abandonné.
Mais si vous avez le pouvoir de faire prendre en consideration des demandes, je me permettrais de vous demander si on pouvais retablir le fonctionnement existant sous Metaframe XP SP2 et retiré en SP3 sur l’interdiction d’utiliser un driver d’imprimantes sans pour cela devoir l’installer. L’algo appliqué a encore moins de sens en DRV Universel.
Je vais meme oser parler de l’affolement de Excel lors d’une selection vers le bas qui a été signalé 2 millions de fois et …
Bon revenons a nous moutons, S.V.P je vous en prie, tracer les imprimantes auto-crees Citrix
vu que je ne travaille pas avec un environnement de production (eh oui, je n’ai aucun droit d’admin sur notre infra de Production), je vais tenter de surveiller cela sur mes fermes de test.
mais je conseillerai de faire une trace CDF sur MF_Service_cpsvc et, s’il est possible de prendre, en plus quelques users pour vérifier une théorie, d’ajouter Win32FavorRetainedPrinterSettings=Off dans l’APPSRV.INI (client 9 et inférieur) ou dans le registre HKEY_CURRENT_USERSoftwareCitrixICA ClientEngineLockdown ProfilesAll RegionsLockdownVirtual ChannelsPrinting (client 10 et sup).
Pour faire une trace CDF : http://www.doctor-citrix.com/fr/article/citrix/103-quand-et-comment-tracer-puis-lire-les-traces-cdf.html
Bonjour,
J’ai patcher tous les serveur en PSF400W2K3R06, PSF400R06W2K3006 + rajouter le compte Ctx_SmaUser dans le groupe Administrateurs. Malgré cela les resultats sont un peu mieux mais reste inacceptable.
Je vais faire des analyses sur d’autres batterie de serveurs Citrix, mais au vu les appels utilisateurs le resultat serat pareil.
Pour ce qui est de faire des analyses a travers les outils de Citrix, cela est un peu lourd et puis j’ai deja des logs trés significatifs.
Pour ce qui est d’une correction coté Citrix, par expérience et vu le nombre de personnes ayant signalé se problème sur le forum de citrix, je n’ai aucun espoir.
En espérant qu’un jour cela fontionne et qu’on ne nomme plus sur ce forum “déprimantes”.
Je t'assure que cela fonctionne correctement sur la plupart des fermes... Le nom de la catégorie est, je pense, plus un clin d'oeil qu'une réalité...
C’est aussi ce que je pensez…
Voici les logs que j’ai :
USER POSTE N°ICA SRV DATE HEURE IMPRIMANTES
LES IMPRIMANTES ON FINI PAR MONTER APRES LES AVOIR FORCER PAR SCRIPT
biehler_r STA-SLI-YILDIRI ICA-tcp#15 SRV-SLI-CTX-B5 25/05/2009 08:25:25 PAS D’IMPRIMANTES…
biehler_r STA-SLI-YILDIRI ICA-tcp#15 SRV-SLI-CTX-B5 25/05/2009 08:25:25 HP Deskjet 6980 series (de STA-SLI-YILDIRI) dans la session 9 HP 3525 PS (de STA-SLI-YILDIRI) dans la session 9
IMPOSSIBLE DE MONTER LES IMPRIMANTES
Alizard_n STA-SLI-ECOADT2 ICA-tcp#17 SRV-SLI-CTX-B4 22/05/2009 13:21:24 Microsoft Office Document Image Writer (de STA-SLI-ECOADT2) dans la session 12 Microsoft Office Document Image Writer (de STA-SLI-ECOADT2) dans la session 13
Alizard_n STA-SLI-ECOADT2 ICA-tcp#13 SRV-SLI-CTX-B4 25/05/2009 07:15:34 PAS D’IMPRIMANTES…
Alizard_n STA-SLI-ECOADT2 ICA-tcp#13 SRV-SLI-CTX-B4 25/05/2009 07:15:34 PAS D’IMPRIMANTES ENCORE…
Alizard_n STA-SLI-ECOADT2 ICA-tcp#97 SRV-SLI-CTX-B4 25/05/2009 13:42:37 Microsoft Office Document Image Writer (de STA-SLI-ECOADT2) dans la session 10
Cela concerne 5% des connexions citrix
Sur ces 5%, %2 sont reglé par la commande “change client /default_printers”. Ce qui d’ailleur n’est pas du tous normal car elle avait tout pour etre monté automatiquement au login.
Les 3% qui reste ne sont pas monté, aucun message dans le journal de logs, aucune crelation a un poste ni user, ni plage horaire.
Ces users ont regulierement appeller depuis 2005, mais a force de s’entendre dire “fermez session puis re-ouvrez” il ne genere pas d’appel, mais de l’enervement quand meme.
Ce probleme est donc assez difficile a détecter d’ou l’interet de le tracer.
%5 ce n’est pas tres important, mais sur 1 mois on ais proche de la totalité des users concernés.
Tracer vous verrez…
seulement les logs que tu prends ne permettent pas d'avancer vers la résolution, vu que l'on ne sait pas ce que retourne le service Cpsvc lors de la connexion utilisateur... mais je conçois que tracer en CDF cpsvc est contraignant.
la clef HKCUPrintersDevModePerUser est gérée par le spooler en CPS4 (et sup). C'est ce service qui se charge de l'écriture (logon) et la suppression (logoff).
je serai donc très curieux de voir ce que donne une trace CDF lorsque le souci survient...
Bonjour,
Je reviens avec plus de jours d’analyses sur plusieurs batterie Citrix :
1° batterie sur 2k3 sp1 + R06 + R06W2K3006 avec 6 srv et 4311 connexions. 1,8% on été reglé par script, 2,5% persiste
2° batterie sur 2k3 sp2 + R06 + R06W2K3006 avec 6 srv et 1052 connexions. 4,3 % réglé par script, 9,3% persiste
Apres analyse détaillé, on constate que le probleme est trés aléatoire. Mais la différence entre les 2 batteries ne s’expliquant que par un reseau plus étendu et un parc machine plus vétuste.
On a essayé de positionné une stratégie Citrix forcant la mémorisation des imprimantes dans le poste client, sinon dans le profil. Cela double le taux d’erreurs.
Ce probleme est général et traine depuis trop longtemps auprés de nos cher utilisateurs, remonter ce probleme au support Citrix ne donnera aucun resultat vu le nombre de personnes l’ayant deja signalé.
Le seul espoir reste donc ce forum avec toute l’ingéniosité des différents intervenants. Alors S.V.P pouvez vous faire une analyse sur vos batteries et remonter les résultats.
Merci d’avance.
Tu nous parle de ton script d’analyse et tu te base sur ce dernier pour baser ton raisonnement, donner des stats et pointer du doigt citrix, sans réelle preuve concrète. De plus, tu efface complètement de ton raisonnement la partie profil utilisateur. Est-ce que ce sont des profils locaux, itinérants ? un ou plusieurs par utilisateur … ?
Sans rentrer dans la trace Citrix CDF, c’est mettre en place un script de logoff qui liste les imprimantes de l’utilisateur dans un même fichier en mode append, que ce soit sur sont poste de travail ou depuis une session Citrix. Comme ça quand tu as un incident sur un utilisateur, tu peux savoir qu’elles étaient les imp de son poste, et celle qui auraient du être mappée.
Voici le script : http://www.doctor-citrix.com/forum/index.php/topic,2345.msg14992.html#msg14992
C’est la méthode que j’ai utilisé dernièrement sur un problème de mappage d’imprimantes et qui à mis en exergue les profils qui ne collait plus à l’archi en place (multi-silo, etc)…
Une fois, le comportement analysé, les problèmes récurrents et dans quelle conditions ils se produisent, tu pourras déterminer si cela vient d’une imprimante, d’un pilote, d’un serveur, d’un profil ou de la version du client citrix utilisé( hyper important).
Une chose me revient en tête, vérifie dans la stratégie Citrix appliquée, si l’option use defaut printer est activé…
PS : Cette section s’appelle déprimantes mais pas toujours pour ce que l’on croit 
Merci de votre réponse.
En effet il est très difficile de pointer un problème sans avoir des erreurs référencé dans les journaux de logs, on ne peut quand même pas ignorer cela quand les users le disent.
D’ou le but de le scripter pour le mettre en avant, merci pour le votre d’ailleurs. En effet au logoff est une bonne idée, mais je l’ai mis au login avec un délai de lancement ce qui revient au même, et en plus les applis sont en majorité avec attente de l’imprimante
Les profils sont itinérants mais cela n’as aucun impact, cela arrive sur tous les users, les srv, la batterie, le jour, l’heure, très aléatoire. Les srv sont homogène et situé sur le même site. Les users ne sont pas les même entre les batteries. On a essayé d’analyser a plusieurs admin Citrix, pour trouver un point de relation il n’y en a pas
Un user vat se loguer 20 fois du même poste avec les mêmes imprimantes sur le même srv et 1 fois cela ne passera pas !!! De plus la commande “change client /default_printers” va régler parfois le problème et cela n’est pas normal en soit.
Le paramétrage des imprimantes par stratégie est :
- Créer automatiquement toutes les imprimantes clientes
- Toujours connecter indirectement comme imprimantes clientes
- Faire de l’imprimante principale du client l’imprimante par défaut
- Ne pas installer les pilotes automatiquement
- N’utiliser que le pilote universel
Coté param. ica-tcp :
- Connecter imprimantes du client a l’ouverture de session
- Imprimantes principale du client par defaut
- Ne pas hériter de la configuration utilisateur
Bonne idée, je vais demander une mise a jour globale des clients citrix en 11.0
Le probleme ne vient pas du client ICA, On arrive meme a le reproduire !!
Sur un compte Admins, la connexion sur le bureau d’un serveur a partir du meme poste monte les imprimantes 1 fois sur 2 (25 tests similtanés) sur un autre 1 fois sur 3.
DNS bon, AD bon.
Modification du param Citrix au niveau de la batterie : Paramtres Metaframe - Activer la resolution DNS du service XML a NON.
Dsmaint recreatelhc et CtxSma20.exe.
Suite a cela les valeurs sur les 2 batteries passe a des valeur plus uniforme : 2,5% regler pas le script et 1,4 % non toujours pas d’imprimantes…
Test sur une autre batterie !!! valeur similaire.
Je confrme donc que le probleme d’imprimante est global a tous les serveurs 2k3 en PS4.0. Les users aussi.
Si vous pouvez tester les votres !!!.
je pourrais tester sur mes plateformes de test et notre plateforme de production, je ne reproduirai surement pas cela (à ma connaissance, je dois faire partie de la seule société à ne pas avoir remonté de problème d’impression :chav_mouarf2:)
plus sérieusement, j’aimerai que tu fasse une trace sur MF_Service_CpSvc (en mettant le log level à 16 soit le maxi) quand tu tentes de reproduire le probleme et de stopper la trace juste quand tu te rends compte que la session n’a pas d’imprimantes autocrées puis de m’envoyer la trace
Bonjour,
Generer une trace sur un nombre de connexions tres important pour arrive a capter le moment ou le probleme se produit risque d’etre tres gourmand en logs, trop gourmand…
A savoir si je suis le seul a l’avoir, je ne pense pas, les derniers correctifs de la PS45 et de la PS4 le signale encore. Pour ce qui est de mes logs, il sont confirmés par les appels users au support.
Maintenant on peut continuer a etre sourd aux appels utilisateurs, ce que je compend tres bien car je l’ai ete trop longtemps aussi, pretestant un driver HP, un double connexion, et appuyant sur le fait que le user ne peut pas le reproduire… Mais ce n’est pas ce que l’on demande a un admin Citrix, c’est plutot d’ecouter un peu les users.
C’est dans cette demarche que j’ai fournit un script afin que chaqu’un puisse evaluer ce probleme si il le souhaite et faire avancer Citrix dans le bon sens.
Dans cette demarche et pour le bien de tous, je prefererai largement que vous verifiez cela chez vous avant de dire que j’ai raison ou tort. Et pensez bien que j’espere avoir totalement tort.
Merci.
cependant, ce script ne permet pas de comprendre l’origine du problème, j’insiste fortement sur le fait que seul une trace MF_Service_Cpsvc permettra de nous mettre sur la voie.
Bonjour,
Je suis persuadé que vous avez raison, il n’empêche que le travail de traçage est trop important et par cela demande un contexte particulièrement propice afin de ne pas générer des logs trop important.
C’est pour cela que je demande si qqu’un pourrait aussi vérifier, quelque soit le script, si ce problème est général sur du 2K3 en PS4.0. Un problème de paramétrage citrix ou de l’environnement restant toujours possible.
A partir de ce moment, et seulement dans un contexte reproductible, il sera facile d’investir dans un traçage.
C’est pour cela que j’insiste lourdement en demandant de vérifier chez vous, et de ne pas dire qu’il n’y a pas de souci sans en être sur.
On a déjà bien avancé car la commande change client /default_printers en règle plus de la moitié, c’est déjà une bonne chose et facilement applicable.
Dès que l’on aura un peu plus avancé, bien entendu, je vais générer des traces.
Merci de votre reponse dans tout les cas.
je m’occupe (entre autres) des soucis avec l’impression et depuis l’introduction de Colorado (pardon CPS4.0) en 2005 je n’ai jamais eu de remonté sur ce problème particulier (et j’ai eu à faire à une sacré variété d’environnements de “petites” fermes allant de quelques centaines à de plusieurs dizaines de milliers de licences, configurées à la va-comme-j’te pousse)
Dans certaines circonstances, les utilisateurs peuvent observer des délais au niveau de l’ouverture de session (Exécution des scripts de connexion…) et une création automatique d’imprimantes intermittente
[Correction à chaud PSF450W2K3R04][#199957] PS 4.5
Les imprimantes créées automatiquement peuvent ne pas s’initialiser dans la session, ce qui entraîne l’affichage d’un message d’erreur du type « L’imprimante n’est pas installée ».
[Correction à chaud PSF400R05W2K3042][#195908] inclus dans le PSF400R06W2K3
Dans certaines circonstances, les utilisateurs peuvent observer des délais au niveau de l’ouverture de session (Exécution des scripts de connexion…) et une création automatique d’imprimantes intermittente.
[Correction à chaud PSF400R06W2K3006][#199957]
Donc cela n’etait pas reglé dans le R06 !!!
Ce probleme existe donc depuis avril 2005, le R06 a ameliorer les choses, le R06 3006 aussi, j’ai pu en effet le constaté mais il en manque un peu.
Dans l’attente de tests d’autres admin. A+