Bonjour à vous,
Nous avons un soucis récurrent avec l’impression sous XenApp6 (Rollup Pack 1) que je n’arrive pas à régler malgré divers tentatives de résolution et appel d’une société tiers qui butent également.
Les clients (plugin Citrix v12.1.0) lancent leur appli publiée et parfois n’ont pas les imprimantes réseaux mappées dans la session mais uniquement la PDFCreator.
Dans certains cas, la fermeture/ré-ouverture de session règle le problème.
Dans d’autres (la majorité), les imprimantes réseaux sont présentes mais pdfcreator restent par défaut. Un con2prt /f permet de nettoyer les imprimantes et à la prochaine ouverture de session les imprimantes sont à nouveau présentes.
Mais au vu du nombre de personnes qui se connectent / jour (environnement hospitalier), nous ne pouvions plus tolérer ce dysfonctionnement et de demander aux utilisateurs de se déconnecter et reconnecter.
Nous avons alors basculer du script pour la mapping des imprimantes aux stratégies d’impression Xenapp, que nous avons limité à un service, le plus critique.
Verdicte nous n’avons plus de soucis avec PDFCreator par défaut.
Cependant l’utilisation des stratégies a fait apparaitre des enregisrement dans les logs :
- 1106 : Impossible d’ajouter la connexion à l’imprimante (\imp02i1imp) pour l’utilisateur (xxx24365). Condition d’erreur : (Aucune imprimante n’a été trouvée.).
- 1114 : La création automatique d’une imprimante cliente a échoué. Impossible d’installer le pilote. Causes possibles : le pilote n’est pas dans la liste de pilotes du serveur ; le pilote est introuvable ; le pilote n’a pas été mappé. Nom du client : () Imprimante : (\imp02i1imp) Pilote d’imprimante : ()
Etonnament nous constatons que les imprimantes sont présentes dans la session et fonctionnelles, mais malgré tout nous recevons régulièrement (plusieurs fois /jour) des appels d’utilisateur qui n’arrivent toujours pas à imprimer.
Pour les services qui ne sont pas basculés en stratégie, le problème de PDFCreator reste entier. C’est très embêtant car dans 2 applications publiées, le bouton Imprimer pointe sur l’imprimante par défaut.
Avez vous des suggestions, pistes à vérifier ?
D’avance merci pour votre aide.
Schwabs
Bonjour,
Quelques questions, histoire de bien comprendre…
- Le problème n’apparait que pour une application spécifique ? Ou est-ce aussi le cas pour un bête notepad ?
- Comment sont ajoutées les imprimantes dans les sessions ? Par script ou à la main depuis la session utilisateur ?
- Si c’est par script : comment est définie l’imprimante par défaut ? A la main ?
- Y a t’il un script exécuté à la fermeture pour nettoyer des imprimantes ?
- Si tu définie une imprimante par défaut, est-elle conservée après un logoff / logon ?
Au niveau des articles qui peuvent t’intéresser : http://support.citrix.com/article/CTX124885
Bonjour Davius, et merci de te pencher sur ce cas, pour te répondre :
- Le problème n’apparait que pour une application spécifique ? Ou est-ce aussi le cas pour un bête notepad ?
Quelque soit l’application exécutée, en Bureau ou Appli publiée.
- Comment sont ajoutées les imprimantes dans les sessions ? Par script ou à la main depuis la session utilisateur ?
- Une partie des utilisateurs par Script (le même que nous utilisons depuis 10ans pour la ferme Metaframe XP avec quelques ajustements)
- Une autre partie par Stratégies Citrix depuis la Management Console Xenapp6 (map par nom du client).
- Aucune imp mappé à la main, aucune remonté des imps locales.
- Si c’est par script : comment est définie l’imprimante par défaut ? A la main ?
Non, le script lit un fichier texte dans lequel est renseigné le nom du client et les imprimantes associées à ce nom. ex : nomduclient=\nomsrvimpimp03,\nomsrvimpimp01,\nomsrvimpimp04
Il prend alors la 1ere imprimante dans la liste et la désigne comme Imprimante par défaut, dans notre ex imp03 est l’imp par défaut.
- Y a t’il un script exécuté à la fermeture pour nettoyer des imprimantes ?
Non, le nettoyage se fait à l’ouverture de session avec la commande con2prt /f avant de refaire le map.
- Si tu définie une imprimante par défaut, est-elle conservée après un logoff / logon ?
Oui & non.
Pour les utilisateurs passant par script c’est totalement aléatoire. Il peut se passer plusieurs jours sans problème puis soudain la situation se dégrade.
Souvent nous devons passer par la suppression et recréation de son profil itinérant.
Pour les utilisateurs basculés via stratégie, il ne semble plus y a avoir ce problème.
Merci pour ces compléments.
Lorsque le script n’a pas défini l’imprimante par défaut, arrive-tu à la paramétrer à la main depuis la session de l’utilisateur (via le panneau de config) ?
Si ce n’est pas le cas, peux tu vérifier, avec un utilisateur sur lequel le problème se présente, l’existence de la clé :
HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows
L’utilisateur doit disposer d’un contrôle totale sur cet clé.
Lorsque le script n’a pas défini l’imprimante par défaut, arrive-tu à la paramétrer à la main depuis la session de l’utilisateur (via le panneau de config) ?
Le panneau de config est masqué, cependant dans l’interface du choix d’imprimante (Ctrl+P) on peut changer l’imp par défaut.
Mais souvent dès lors que l’utilisateur a rencontré le problème si celui-ci ferme et réouvre la session, la mauvaise imp se remet par défaut.
Une recréation du profil est souvent nécessaire.
- Comment est lancé le script d’ouverture de session ?
le script est appelé par UsrLogn2.cmd lui meme appelé dans Usrlogon.cmd
- Comment l’exécution des script est-elle configurée (asynchrone ou synchrone ?)
Le type d’exécution est celui par défaut, car je n’avais pas connaissance de cette petite subtilité.
Je pense que des tests s’imposent en basculant en Synchronous. Merci pour cette info très interessante, en espérant que cela soit la source du dysfonctionnement.
Le premier test à effectuer serait d’essayer de basculer l’imprimante par défaut dans une session qui pose problème.
Tu peux effectuer cette manipulation à partir du menu Imprimer depuis un notepad, si le panneau de configuration n’est pas disponible.
Si tu n’arrive pas à changer l’imprimante par défaut, cela peut être un problème de droits d’accès, que tu pourras déterminer avec un Procmon.
A propos des scripts synchrones / asynchrones :
L’idée est de comprendre pourquoi le comportement est aléatoire. Une exécution asynchrone peut provoquer ce type de résultat, puisqu’un script peut mettre plus de temps à s’exécuter, et peut nécessiter des ressources qui ne sont pas encore présentes.
Un traitement asynchrone t’apportera une rapidité d’ouverture de session, mais tu pourrais perdre en stabilité lors des logons.
D’autres liens sur le sujet :
http://support.microsoft.com/kb/305293/en-us
http://technet.microsoft.com/en-us/library/cc785665(v=ws.10).aspx
La configuration recommandée pour tes tests pourrait donc être :
Computer ConfigurationAdministrative TemplatesSystemLogon Always wait for the network at computer startup and logon : True
Computer ConfigurationAdministrative TemplatesSystemGroup PolicyAllow asynchronous user Group Policy processing when logging on through Remote Desktop Services : False
La configuration recommandée pour tes tests pourrait donc être :
Computer ConfigurationAdministrative TemplatesSystemLogon Always wait for the network at computer startup and logon : True
Computer ConfigurationAdministrative TemplatesSystemGroup PolicyAllow asynchronous user Group Policy processing when logging on through Remote Desktop Services : False
Cool j’allais te demander lequel activé ou désactivé (En lisant le descriptif de chacun des paramètres tu choppes une migraine, la compréhension n’est vraiment pas aisé en francais).
Sinon pour en revenir à Le premier test à effectuer serait d’essayer de basculer l’imprimante par défaut dans une session qui pose problème.
: on arrive à le faire, pas de restriction. C’est ce que j’essayais de dire.
Cet après midi, appel d’un utilisateur qui rencontre des soucis d’impression.
Je prends le contrôle à distance => pdfcreator est par défaut et les 2 imps mappées via Script sont présentes.
Je défini dans la session 1 des 2 imprimante réseau en Imp par défaut.
L’utilisateur est ravi et peut imprimer.
Il ferme sa session juste après.
J’en ai profité pour faire passer ma station de test pour l’ordinateur de l’utilisateur et me connecte avec ses identifiants.
PDFcreator est à nouveau par défaut.
Je force ensuite (via Groupe Policy local) sur 3 serveurs publiant une appli précise :
- Always wait for the network at computer startup and logon : True
- Allow asynchronous user Group Policy processing when logging on through Remote Desktop Services : False
Puis reboot des serveurs.
J’ouvre un bureau sur l’un de ses 3 serveurs mais j’ai toujours PDFCreator par défaut et les imps réseaux mappées. J’arrive toujours à switcher l’imp par défaut sur une des imps réseaux.
Je ferme la session la réouvre et pdfcreator est par défaut.
Je vérifie alors la clé de registre que tu m’as indiqué : l’utilisateur AD a le droit Full Control sur la clé. Il y a un compte Restricted qui est sur Full !
Je fais un RSOP de la session utilisateur, je vois les stratégies forcés par GPO de l’AD et pour les paramètres de login & script l’application des Groups Policy local.
Je vais tenté de monitorer la session mais je ne maitrise pas bien Procmon et Regmon et donc me trouve avec pleins d’infos inutiles.
En espérant que ce complément d’info puisse faire avancer la réflexion.
Bonne soirée.
SCHWABS
Avant que tu définisse l’imprimante par défaut pour corriger le problème, quelle sont les valeurs des clés HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindowsDevice et UserSelectedDefault ?
Question bête : on est d’accord que l’imprimante PDF Creator est bien une imprimante locale ?
Au vu des tests, les pistes qui me viennent à l’esprit porteraient plutôt sur :
- Un conflit de stratégies Citrix > Vérifie bien qu’aucune policy d’impression Citrix n’est appliquée (imprimante de session, imprimante par défaut…) pour ton utilisateur.
- Une erreur de script > Est-tu sur que le problème est aléatoire pour le même utilisateur ? Est-ce que tu pourrais activer des traces dans ce script ? (résultat de commandes dans un fichier .txt, dans le profil de l’utilisateur par exemple).
- Un problème de timing > Est-ce que ton script est visible pendant le logon ? Cela permettrait de t’assurer qu’il se déroule bien pendant le logon, et qu’aucun problème n’apparait (User ConfigurationAdministrative TemplatesSystemLogonRun legacy logon scripts hidden : False et User ConfigurationAdministrative TemplatesSystemLogonRun logon scripts visible : true)
En espérant que cela te donne des idées !..
On espère avoir trouvé la réponse.
Avec mon binome “spécialiste es script”, nous avons rajouté une pause de 2 secondes entre le mapping des imprimantes et le SetDefaultPrinter.
Résultat sur mon client de test qui bugait, j’ai l’imprimante par défaut qui est correctement positionné.
Nous étendons cette manip sur 3 autres serveurs afin de mesurer l’impact d’içi à la semaine prochaine.
Touchons du bois et croisons les doigts.
Schwabs
Bonjour,
La semaine semble démarrer sous de bons auspices.
L’ajout d’une pause dans le script d’ouverture de session avant la commande Setdefaultprinter, pour laisser le temps à l’imprimante de s’installer, semble bien fonctionner.
En tout cas le résultat escompté est bien là.
Cependant y a t il un moyen pour empêcher pdfcreator de se paramétrer en tant qu’imprimante par défaut ?
Genre empêcher l’imprimante local (donc du serveur) d’être défini par défaut.
Encore merci pour ton aide DaviuS
Schwabs
Dans tous les cas, il te faut une imprimante par défaut.
Au logon, Windows va prendre la 1e imprimante locale, si aucune imp par défaut n’est configurée.
Au niveau de la solution trouvée, la pause semble logique, puisque l’imprimante ne devait pas être montée lorsque tu essayais de la définir par défaut… Tu peux peut être jouer avec START “commande” /WAIT pour attendre la fin de la commande avant de continuer.