Mapper une imprimante réseau avec un driver spécifique

Mon problème est un peu complexe, je vais tâcher de l’exposer simplement :



Je dois dans des sessions “terminal server” (pas citrix donc) mapper des imprimantes réseau par NET USE ou par Con2Prnt.exe



Ces deux méthodes présentent un inconvénient important :



serveur d’impression ET client (le client étant une session TSE) doivent avoir le MEME driver.



Or, mon serveur TSE est un Windows 2003-64bits et le serveur d’impression est un Linux-Samba.



Le serveur Linux accèpte sans problème les drivers x64. Pour une nouvelle imprimante donc pas de problème, il suffit de passer le driver 32 et 64, tout va bien.



Pour les imprimantes existantes (et il y en a un paquet), les drivers 32bits sont déjà définis et sont accèdés par des postes lourds en Windows XP.

Le poste client peut donc se connecter à la queue partagée, télécharger le driver adapté et hop, ça marche.



LE problème c’est que ces modèles là ne disposent pas de driver x64.



Par exemple, pour une HP8150 nous utilisons le driver PCL5e en 32 bits…

HP ne fournit que du PCL6 pour ce modèle



PCL5e d’un coté, PCL6 de l’autre : ça ne marche pas.



L’idée serait donc de forcer le TSE à utiliser le driver HP Universel qui marche trèèèèèès bien chaque fois qu’on essaie de mapper une imprimante Réseau dont le driver x64 n’est pas installé.



Un peu à la manière du “fallback” driver pour les imprimantes auto-créées.



Y’a un warrior qui a une idée ?

bonjour



tu peux essayer le Terminal Server PCL Fallback Printer introduit avec WIn2003 SP1

http://download.microsoft.com/download/8/2/f/82f0bbb9-1c53-4f2b-8a6a-9864cb4c73a5/TSWhatsNew.doc





http://www.printingsupport.com/mambo/index.php?option=com_content&task=view&id=56&Itemid=49

"ThinIsFat" wrote:
bonjour

tu peux essayer le Terminal Server PCL Fallback Printer introduit avec WIn2003 SP1
http://download.microsoft.com/download/8/2/f/82f0bbb9-1c53-4f2b-8a6a-9864cb4c73a5/TSWhatsNew.doc


http://www.printingsupport.com/mambo/index.php?option=com_content&task=view&id=56&Itemid=49

J'ai déjà testé ce système... et ça ne solutionne pas mon problème :(

En fait, le fallback driver ne fonctionne que sur les imprimantes auto-mappées, donc uniquement pour les imprimantes liés au poste de travail.

Or, dans mon cas les imprimantes sont partagées sur un "print server" et montées via un login-script en fonction de divers paramètres (appartenance à des groupes, IP du poste client, username...). De plus, l'utilisateur doit pouvoir dans sa session se monter une imprimante supplémentaire. Avec le procédé "auto création" il faudrait
1 - fermer la session TS
2 - connecter l'imprimante réseau sur son poste de travail
3 - r'ouvrir une session TS pour prendre en compte la nouvelle imprimante.

Bref, ce n'est pas utilisable.

En fait, le problème est que

Lorsqu'on se connecte sur une queue partagée le job d'impression se scinde en deux
1- La partie conversion de l'info en code "matériel" pour communiquer avec l'imprimante. Cette partie reste dédiée au print server.
2- La partie utilisateur, qui permet aux applis de connaitre les capacités de l'imprimante et donc à l'utilisateur de formater son doc. cette partie là tourne sur le poste utilisateur, TSE ou pas.

Il est impératif que ces deux partie sachent communiquer, DONC lors du mappage, Windows vérifie que le driver coté serveur ET coté client est identique.
Si on a d'un côté "HP 8150 PCL5" et de l'autre "HP 8150 series PCL 5", ça ne marche pas.

Donc, j'ai deux possibilités : de toute façon il va faloir truander.
1- Soit trouver un moyen de lui dire que "HP 8150 PCL5" et "HP 8150 series PCL5" c'est pareil et de me fiche la paix (faire une sorte de fichier "alias de drivers")
2- Soit trouver un moyen de lui faire croire que mon "HP 8150 PCL5" est en fait un "HP 8150 PCL5" (en modifiant le fichier .INF du driver par exemple)

il va de soit que la première solution serait idéale : c'est plus souple et on s'y retrouve plus facilement.

Reste à voir comment on peut faire ???

Et là ... je sèche. :-

Donc voilà, toute idée de point de départ menant au commencement d'un début d'hypthèse de solution potentielle est la bienvenue, parce que moi je n'ai plus assez d'imagination... :'(

A bientot, tous ;)

ok dans ton cas précis, il faut que tu modifies la façon dont tu connecte tes imprimantes dans ton script de logon.



peux tu me (nous pardon) donner la méthode utilisée ?



je pense que l’utilisation de printui.dll http://www.microsoft.com/windowsserver2003/techinfo/overview/printuidll.mspx