Serveur d'impression

Le guide ultime de l’impression Terminal Server – Bien choisir son serveur d impression

Le 3 mai 2019 - 78 minutes de lecture

À un moment donné, au cours de la conception de votre système Terminal Server, vous vous souviendrez que vos utilisateurs voudront probablement imprimer quelque chose tôt ou tard. L'impression est une fonction importante pour les utilisateurs au sein de leurs sessions Terminal Server, mais elle représente traditionnellement le plus grand cauchemar des administrateurs de systèmes informatiques basés sur serveur. Idéalement, l'impression à partir d'applications via des sessions RDP ne devrait pas être différente de l'impression à partir d'une autre application. Il devrait être relativement transparent pour les utilisateurs, leur permettant de cliquer sur le bouton Imprimer dans leur application, de sélectionner facilement une imprimante et de recevoir rapidement leurs impressions.

Tous les environnements informatiques basés sur serveur posent des problèmes d'impression uniques. Cela n’est pas dû à un défaut de conception de Microsoft, mais à la manière dont le traitement est effectué dans les architectures basées sur serveur. Étant donné que tout le traitement de l'application se produit sur le serveur, les travaux d'impression des utilisateurs sont également créés sur le serveur. Toutefois, les imprimantes des utilisateurs sont généralement situées à proximité et configurées sur leurs périphériques clients. Il peut être compliqué d'obtenir des travaux d'impression générés par le serveur sur une imprimante spécifiée par le client.

De plus, Windows Server 2003 utilise le même sous-système d’impression que celui qui a été conçu à l’époque des jours Windows NT. Les architectes d'origine de NT ont conçu le moteur d'impression Windows sous la forme d'un processus unique destiné à s'exécuter sur un seul périphérique. Cela convient très bien pour l'impression sur le bureau, mais peut entraîner des problèmes dans les environnements informatiques basés sur serveur.

Dans ce chapitre, nous examinerons le fonctionnement de l'impression Windows et les options d'impression disponibles lors de l'utilisation de Terminal Server. Nous verrons également ce qu'il faut faire pour affecter des imprimantes à des utilisateurs lorsque vous avez des dizaines voire des centaines d'utilisateurs se connectant au même serveur. Nous terminerons ce chapitre par une étude de cas approfondie qui examine les défis auxquels est confronté l'environnement d'impression à multiples facettes d'une entreprise.

Avant d'explorer les défis de l'impression Terminal Server et les nombreuses solutions, vous devez comprendre le fonctionnement de l'impression Windows. Après tout, le processus réel par lequel un serveur Terminal Server imprime n'est pas différent de tout autre ordinateur Windows.

Quand on regarde sous le capot, il y a un nombre surprenant d'étapes à suivre chaque fois qu'un document est imprimé. Nous pourrions écrire un livre entier détaillant le processus d’impression exact qui se déroule, mais pour réussir à concevoir des environnements Terminal Server, il vous suffit de connaître les bases.

Le processus d'impression varie légèrement selon que vous imprimez sur une imprimante locale ou sur une imprimante réseau, mais les mêmes étapes élémentaires ont lieu dans chaque cas. En coulisse, trois phases se déroulent du moment où vous appuyez sur le bouton "Imprimer" de votre application jusqu'au moment où le travail d'impression terminé apparaît sur l'imprimante:

• Phase 1. Application Windows.

• Phase 2. Spouleur d'impression.

• Phase 3. Imprimante (ou «Périphérique d'impression» comme Microsoft l'appelle).

Figure 8.1 Processus d'impression Windows

Phase 1. Application Windows

Lorsqu'un utilisateur demande une impression à partir d'une application Windows, l'application est chargée de générer sa propre sortie en vue de l'impression. Cette sortie inclut des éléments tels que le formatage correct des pages et l’ajout de numéros de page. L'application traite les impressions via un sous-système Windows appelé GDI (Graphics Device Interface). Le GDI génère la sortie de l'application sous la forme d'un métafichier contenant des données et des instructions pour l'imprimante. (Ce métafichier est généralement appelé «données d'impression».)

Le format préféré de ces données d'impression est le métafichier amélioré de Microsoft (format EMF). Les données d'impression EMF sont préférables au format RAW car le traitement des fichiers EMF nécessite moins de ressources processeur et permet l'impression en arrière-plan.

Les fichiers EMF ne sont pas spécifiques à l’imprimante. Une application générerait le même fichier EMF pour une impression, quel que soit le type d’imprimante utilisé. Le fichier est l’intermédiaire commun entre l’application et le pilote d’imprimante. Afin de comprendre cela, examinons comment la ligne de texte suivante serait imprimée:

Tout le monde semble avoir besoin de traitement de données.

Le fichier EMF de cette ligne de texte contient des instructions pour l’impression, notamment la couleur, la police, les caractères et l’espacement. Le fichier EMF est un document vectoriel de très petite taille.

Une fois que le GDI a écrit le fichier EMF sur le disque, les données d'impression sont transmises au sous-système d'impression Windows.

Phase 2. Sous-système d'impression

Le sous-système d'impression Windows exécute de nombreuses fonctions liées à l'impression. Le moyen le plus simple de comprendre ce qu’il fait est de le diviser en étapes logiques. Ce sous-système est responsable de plusieurs tâches:

• Recevoir le fichier EMF du GDI.

• Déterminer si l’imprimante cible est une imprimante locale ou une imprimante réseau.

• Utilisation du pilote d'impression pour traduire le fichier EMF au format brut de l'imprimante. (À ce stade, les «données d'impression» deviennent un «travail d'impression».)

• Mise en attente temporaire du travail d'impression si l'imprimante est hors ligne ou indisponible.

• S'assurer que le travail d'impression est correctement transféré vers l'imprimante.

Le processus exact dépend du type d’imprimante auquel le travail d’impression est envoyé. Un composant d’impression appelé «routeur d’impression» envoie les données d’impression dans des chemins distincts, selon qu’il s’agisse d’une imprimante réseau ou locale.

Pour l'impression à distance, le fichier EMF non traité reçu de GDI est envoyé au serveur d'impression pour être restitué avec le pilote d'imprimante approprié.

En revanche, si le travail d'impression est destiné à une imprimante locale, le spouleur d'impression local utilise les pilotes d'impression pour convertir le fichier EMF au format de données brutes de l'imprimante. Ce processus fastidieux et gourmand en ressources processeur s'appelle «rendu». Le travail d'impression rendu contient les données brutes (travail d'impression) spécifiques à l'imprimante. Jetons un autre regard sur notre exemple:

Tout le monde semble avoir besoin de traitement de données.

Dans ce cas, le travail d'impression rendu contiendrait les instructions détaillées spécifiques à l'imprimante et le formatage nécessaire à l'impression dans la langue native de l'imprimante. Cela inclut la résolution, les informations sur le bac à papier, les données d’alimentation du formulaire et l’image tramée de la page. La taille des travaux d'impression rendus varie en fonction du type d'imprimante et de la qualité de l'écriture des pilotes. Toutefois, dans la plupart des cas, les fichiers de travail d'impression rendus sont beaucoup plus volumineux que les fichiers de données d'impression EMF.

Une fois le travail d'impression créé, le spouleur d'impression veille à ce que le fichier soit transféré vers l'imprimante.

Phase 3. Imprimante

Lors de la dernière phase d'impression, l'imprimante reçoit le travail d'impression rendu par le spouleur d'impression. L'imprimante imprime ce fichier quel que soit son format. C'est pourquoi les imprimantes imprimeront des ordures si les mauvais pilotes sont utilisés. L'utilisation de pilotes incorrects crée des travaux d'impression incompatibles avec l'imprimante. Cependant, l’imprimante ne le sait pas et essaie d’imprimer ce qu’elle reçoit.

Maintenant que vous avez compris le fonctionnement de l'impression dans les environnements Windows standard, voyons comment configurer l'impression dans des environnements Terminal Server. Avant d'entrer trop dans les détails relatifs à l'impression Terminal Server, nous devons «redéfinir» certains termes d'impression standard pour l'environnement Terminal Server.

Même avec le nombre infini de scénarios d'impression disponibles dans le monde réel, il n'existe que deux types principaux de scénarios d'impression disponibles avec Terminal Server. L’impression sur tous les serveurs Terminal Server est une variante de l’un des deux thèmes suivants:

Imprimantes Serveur . Les imprimantes serveur dans les environnements Terminal Server sont des imprimantes dans lesquelles le serveur Terminal Server a un accès direct à la file d'attente d'impression. Cela peut inclure des imprimantes réseau standard accessibles via un partage \ nomserveur printerna me. Il peut également inclure des imprimantes dont la file d'attente d'impression est localement située sur un serveur Terminal Server même, y compris des imprimantes directement connectées au serveur Terminal Server. Considérez les imprimantes de serveur comme des imprimantes «installées» sur le serveur.

Imprimantes clientes . Il s'agit d'imprimantes disponibles sur le périphérique client d'un utilisateur avant le lancement d'une session RDP. Cela peut inclure des imprimantes physiquement connectées à un périphérique client ou des imprimantes logiquement mappées sur le réseau. Considérez-les comme des imprimantes «installées» sur le client RDP.

Figure 8.2 Les différents types d’imprimantes Terminal Server

Il est important que vous compreniez les différences entre les imprimantes clientes et serveur dans les environnements Terminal Server. Chaque type présente des avantages et des inconvénients et est utilisé ou configuré différemment. Pour ces raisons, nous examinerons séparément les imprimantes de serveur et les imprimantes clientes dans ce chapitre, en commençant maintenant par les imprimantes de serveur.

Imprimantes Serveur

Une «imprimante serveur» est une imprimante installée sur un serveur Terminal Server. En termes techniques, cela signifie que le serveur a un accès direct à la file d'attente d'impression. Cette file d'impression peut être Windows ou NetWare, basée sur un client ou un serveur. Fondamentalement, toute imprimante accessible via un \ computername printername share est une imprimante serveur.

Une imprimante serveur peut également être une imprimante ayant une file d'attente d'impression directement sur un serveur Terminal Server. Il peut s'agir d'une imprimante physiquement connectée à un port LPT ou USB local d'un serveur ou d'une imprimante IP disposant d'une file d'attente d'impression localement sur un serveur Terminal Server.

Dans les environnements Terminal Server, les imprimantes de serveur fonctionnent comme des imprimantes «ordinaires» dans les environnements traditionnels. La figure 8.3 décrit ce processus.

Figure 8.3 Imprimantes serveur dans un environnement Terminal Server

1. L'utilisateur imprime à partir de son application s'exécutant sur le serveur Terminal Server.

2. Le GDI crée le fichier EMF sur le serveur Terminal Server.

3. GDI envoie le fichier EMF au sous-système de l'imprimante.

4. Le routeur d'impression du serveur Terminal Server envoie le fichier EMF au serveur d'impression réseau.

5. Le serveur d'impression réseau reçoit le fichier EMF et le transfère à son spouleur d'impression. Le spouleur rend le travail d'impression en préparation pour l'impression.

6. Le travail d'impression est transféré sur un port d'imprimante où un service de contrôle d'impression le transfère sur l'imprimante physique.

Dans la plupart des environnements, les imprimantes réseau des utilisateurs sont déjà mappées via des scripts d'ouverture de session ou sont configurées dans le cadre du profil itinérant d'un utilisateur. Dans ces cas, vous n'avez rien de spécial à faire pour les rendre disponibles via des sessions Terminal Server. Les utilisateurs peuvent même configurer leurs propres imprimantes réseau s'ils disposent des autorisations nécessaires pour se connecter à eux.

En général, vous remarquerez que si les serveurs d'impression sont sur le même réseau que les serveurs Terminal Server, les performances d'impression sont excellentes. En fait, l'impression dans ce type d'environnement n'est pas différente de l'impression dans n'importe quel environnement réseau. Cela se produit le plus souvent lorsque les utilisateurs, les serveurs Terminal Server et les imprimantes sont tous situés dans le même bâtiment.

Malheureusement, les performances de cette imprimante serveur sont moins bonnes dans les environnements distants où les utilisateurs et l’imprimante sont situés d’un côté du réseau étendu et où le serveur Terminal Server est situé de l’autre. Dans de tels cas (comme illustré à la figure 8.4), les travaux d'impression volumineux doivent atteindre le serveur d'impression via le lien WAN, qui est également partagé avec tout le trafic de session RDP.

Figure 8.4 Les imprimantes de serveur ne sont pas efficaces lorsque les serveurs Terminal Server sont distants

Avantages de l'utilisation des imprimantes serveur

• Performances décentes lorsque le serveur Terminal Server et le serveur d'impression se trouvent sur le même réseau local.

• Fiable.

• Les utilisateurs reçoivent les mêmes imprimantes, peu importe où ils se connectent.

Inconvénients de l'utilisation des imprimantes serveur

• Si des clients «gras» sont utilisés, vous devez configurer l'imprimante pour l'utilisateur du client et du serveur Terminal Server.

• Les utilisateurs doivent parcourir le réseau pour rechercher des imprimantes non préconfigurées.

• Les imprimantes doivent être configurées manuellement par utilisateur ou par groupe.

• Pour obtenir de bonnes performances, le serveur d'impression et l'imprimante doivent être situés sur le même réseau local que le serveur Terminal Server.

• Les utilisateurs reçoivent les mêmes imprimantes, peu importe où ils se connectent.

Imprimantes clientes

Dans les environnements Terminal Server, toute imprimante disponible sur le périphérique client d'un utilisateur est appelée «imprimante cliente». Les imprimantes clientes peuvent être des imprimantes physiquement connectées au périphérique client (par exemple via un port USB ou LPT) ou être en réseau. les imprimantes mappées avant le démarrage de la session RDP de l'utilisateur. Quoi qu'il en soit, Terminal Server 2003 peut automatiquement rendre les imprimantes client disponibles sur le serveur via la session RDP d'un utilisateur. Cela permet aux utilisateurs d’imprimer sur des imprimantes avec lesquelles ils sont familiers.

Le contrôle ActiveX RDP (client Web) et le client RDC complet prennent en charge l’impression sur les imprimantes clientes. Certains logiciels clients RDP tiers sont disponibles pour d'autres systèmes d'exploitation, mais leurs capacités d'impression sont très variées. (Ces clients sont décrits en détail au chapitre 10.) Pour les besoins de ce chapitre, nous nous concentrerons uniquement sur les clients RDP de Microsoft.

Comment fonctionnent les imprimantes clientes

Avant de pouvoir examiner la configuration des imprimantes clientes, il est important de comprendre comment les imprimantes clientes sont utilisées par Terminal Server.

Lorsqu'un utilisateur se connecte à un serveur Terminal Server, son logiciel client RDP local met automatiquement à sa disposition les imprimantes qu'il a installées localement à partir de sa session de serveur. Pour ce faire, il crée de manière dynamique des imprimantes imprimant sur des ports d'imprimante spéciaux (également créés dynamiquement) qui renvoient vers la machine cliente. Ces imprimantes auront un nom comme " Nom de l'imprimante (à partir du nom du client) dans la session # . "(Par exemple," Lexmark Optra E312 (de LAPTOP42) dans la session 14. ") En outre, ces imprimantes sont configurées sur des ports spéciaux portant des noms tels que" TS001 "et" TS002 "(comme indiqué dans l'onglet" Ports "du page de propriétés de l’imprimante. Chaque imprimante est créée avec des autorisations permettant uniquement à cet utilisateur d’imprimer sur celle-ci.

Techniquement, les utilisateurs expérimentés et les administrateurs peuvent imprimer sur n’importe quelle imprimante. Ils voient ainsi toutes les imprimantes de tous les utilisateurs du serveur. Les utilisateurs réguliers, cependant, ne verront que leurs propres imprimantes. Lorsqu'un utilisateur doit imprimer un document à partir d'une application Terminal Server, il appelle le travail d'impression comme d'habitude. À partir de sa session, il verra les imprimantes de son périphérique client répertoriées dans l'interface d'impression de l'application. Pour l'utilisateur, ces imprimantes ressemblent à des imprimantes ordinaires. L'utilisateur n'a aucune idée que ces imprimantes sont réellement mappées vers ses imprimantes locales via le protocole RDP.

Lorsque l'utilisateur imprime sur l'une de ses imprimantes clientes, le processus décrit à la figure 8.5 (page suivante) est exécuté.

Figure 8.5 Impression sur une imprimante cliente reliée localement à un périphérique client

1. L'utilisateur imprime à partir de son application s'exécutant sur le serveur Terminal Server.

2. Le GDI crée le fichier EMF sur le serveur Terminal Server.

3. Le fichier EMF est envoyé au spouleur d'impression (via le routeur d'impression) sur le serveur Terminal Server.

4. Si les pilotes d'impression de l'imprimante client sont chargés sur le serveur Terminal Server, le spouleur d'impression de ce dernier rend le travail d'impression. Si les pilotes appropriés ne sont pas chargés sur le serveur Terminal Server, le travail d'impression de l'utilisateur ne peut pas être terminé.

5. Le travail d'impression est envoyé du serveur Terminal Server à la machine cliente via un canal virtuel d'impression dans le cadre du protocole RDP.

6. Le périphérique client reçoit le travail d'impression. Etant donné que les pilotes d'impression étaient chargés sur le serveur pour l'imprimante du client, le travail d'impression était rendu spécifiquement pour l'imprimante du client et le sous-système d'imprimante locale du périphérique client pouvait immédiatement traiter le travail et l'envoyer à l'imprimante.

En regardant le processus d'impression du client dans la figure 8.5, vous pouvez probablement voir qu'il existe un risque de grave problème de performances. Le travail d'impression brut est généralement assez volumineux et la transmission à l'imprimante du client peut prendre beaucoup de temps, en particulier si l'utilisateur est connecté via une ligne d'accès à distance. En outre, les performances de la session RDP peuvent être dégradées car la bande passante est utilisée par le travail d'impression envoyé au client.

Examinons maintenant ce qui se passe lors de l’impression sur une imprimante réseau cliente. (N'oubliez pas qu'une imprimante réseau client est une imprimante réseau mappée à partir du poste de travail client de l'utilisateur avant le démarrage de sa session avec le serveur Terminal Server.)

Conceptuellement, ce processus est similaire à l’impression sur une imprimante cliente rattachée localement. Cependant, puisqu'il s'agit d'une imprimante réseau, le client doit prendre l'étape supplémentaire consistant à envoyer le travail d'impression au serveur d'impression réseau une fois qu'il est reçu du serveur Terminal Server. La figure 8.6 décrit ce processus.

Figure 8.6 Impression d'un serveur Terminal Server sur une imprimante réseau cliente

1. L'utilisateur imprime à partir de son application s'exécutant sur le serveur Terminal Server.

2. Le GDI crée le fichier EMF sur le serveur Terminal Server.

3. Etant donné que l'imprimante est une imprimante mappée sur le client, le travail d'impression est rendu sur le serveur Terminal Server.

4. Le serveur Terminal Server envoie le travail d'impression au port mappé via le canal virtuel d'impression du protocole RDP.

5. Le périphérique client reçoit le travail d'impression et le transmet au serveur d'impression réseau.

6. Le serveur d'impression reçoit le travail d'impression et l'envoie à l'imprimante.

À première vue, vous vous demandez peut-être pourquoi Terminal Server n’est pas assez intelligent pour imprimer directement sur le serveur d’impression réseau. Il semblerait que cela réduirait la nécessité pour le fichier EMF de se rendre du serveur au client et inversement. Malheureusement, en réalité, ce n'est pas faisable. Par exemple, il peut arriver que le serveur d'impression de la figure 8.6 ne soit disponible que sur le périphérique client et non sur le serveur Terminal Server, ou qu'il existe un pare-feu sur le réseau qui autorise uniquement le trafic RDP sur le port 3389.

Indépendamment des spécificités de la situation, les concepteurs de Microsoft qui ont conçu Windows savaient qu’ils ne pouvaient garantir que Terminal Server aurait accès au serveur d’impression. Par conséquent, ils devaient prendre le plus petit dénominateur commun et envoyer les travaux d'impression au client, même si cela impliquait que, dans certains cas, le client se retournait et renvoyait les travaux d'impression au serveur.

Bien sûr, un moyen simple de lutter contre cette inefficacité potentielle serait simplement de mapper l'imprimante réseau à partir de la session Terminal Server de l'utilisateur, permettant ainsi au serveur d'envoyer le travail d'impression directement au serveur d'impression réseau. Semble familier? Cela devrait être le cas, car il s’agirait de la description exacte d’une imprimante serveur, comme indiqué à la figure 8.3.

Un autre moyen de lutter contre cette inefficacité serait d'utiliser un produit d'impression tiers, comme expliqué plus loin dans ce chapitre.

Outre les problèmes de performances, l'utilisation d'imprimantes client présente un autre inconvénient potentiel. Comme vous l'avez vu dans les figures 8.5 et 8.6, le travail d'impression d'un utilisateur est lancé sur le serveur Terminal Server lorsque des mappages d'imprimantes client sont utilisés. Pour cette raison, le serveur doit avoir les pilotes nécessaires installés pour l’imprimante du client afin qu’elle puisse créer le travail d’impression. Après tout, c’est le serveur qui créera les travaux d’impression à partir de sessions utilisateur, et non le périphérique client.

Si vous avez suffisamment d’esprit pour créer un environnement dans lequel vos utilisateurs n’ont que quelques types d’imprimantes différents, il se peut que cela ne pose pas de problème. Cependant, si vous avez des centaines d'utilisateurs avec des centaines d'imprimantes différentes, l'installation et la configuration de pilotes d'imprimante sur vos serveurs Terminal Server peuvent s'avérer un cauchemar. Nous étudierons l'utilisation et la gestion des pilotes d'imprimante sur les serveurs Terminal Server un peu plus loin dans ce chapitre.

Un autre inconvénient de l'utilisation d'imprimantes clientes dans les environnements Terminal Server est que pour qu'un utilisateur puisse utiliser une imprimante, celle-ci doit (par définition) être installée et configurée localement sur leur machine cliente. Si vos utilisateurs ont déjà beaucoup d'imprimantes configurées sur leurs postes de travail, cela pourrait être le cas. Cependant, cela pourrait également être l'exact opposé de ce que vous essayez de faire en utilisant Terminal Server. Très probablement, vous souhaitez éviter de configurer des éléments sur les postes de travail d'utilisateurs individuels. Si un utilisateur installe, supprime ou modifie de toute autre manière ses imprimantes de poste de travail locales (pas votre problème), la manière dont ils imprimeront à partir de leur session Terminal Server (définitivement votre problème) aura une incidence.

Avantages de l'impression avec des imprimantes clientes mappées

• Connexion transparente des imprimantes.

• Les utilisateurs voient des imprimantes avec lesquelles ils sont familiers.

• Toutes les imprimantes locales prises en charge sont disponibles.

• Configuration rapide pour les imprimantes clientes existantes.

Inconvénients de l'impression avec des imprimantes clientes mappées

• Mauvaise performance d'impression.

• Utilisation intensive de la bande passante.

• Les travaux d'impression doivent être rendus sur le serveur, ce qui sollicite beaucoup le processeur.

• Les pilotes d'imprimante doivent être installés sur le serveur Terminal Server.

• Les imprimantes doivent être installées et configurées sur des clients locaux.

• Les utilisateurs peuvent mettre à jour, modifier ou supprimer leurs imprimantes locales, ce qui a un impact direct sur les mappages des imprimantes clientes.

Activation de la prise en charge des imprimantes clientes

Par définition, les imprimantes clientes sont déjà configurées et configurées sur les périphériques client. Vous ne devez donc rien faire d’autre. Toutes les configurations de mappage d'imprimantes clientes sont effectuées sur vos serveurs Terminal Server. À partir d'un niveau élevé, permettre aux utilisateurs d'imprimer sur leurs imprimantes clientes s'effectue en deux étapes:

1. Installez les pilotes d’imprimante sur vos serveurs Terminal Server.

2. Configurez vos serveurs pour utiliser des imprimantes clientes.

Étape 1. Installez les pilotes d'imprimante

Etant donné que les imprimantes clientes ne fonctionnent que lorsque les pilotes d’imprimante sont installés sur le serveur Terminal Server, la première chose à faire lorsque vous utilisez des imprimantes clientes est de vous assurer que les pilotes appropriés sont installés sur votre serveur. Dans la réalité, il existe de nombreux problèmes liés à l’installation et à la gestion des pilotes d’imprimante sur les serveurs Terminal Server. Nous examinerons les détails spécifiques dans la section «Gestion des pilotes d’imprimante» de ce chapitre.

Étape 2. Configurez le serveur Terminal Server pour connecter des imprimantes clientes

Une fois les pilotes d'imprimante installés, vous devez configurer votre serveur Terminal Server pour connecter les imprimantes des clients au démarrage de leurs sessions RDP. Pour ce faire, vous devez configurer les autorisations du serveur Terminal Server, le port d'écoute de connexion RDP et les propriétés du compte de domaine de l'utilisateur.

Étape 2A: Vérifier les autorisations du serveur Terminal Server pour l'impression

Pour que les utilisateurs puissent imprimer sur un serveur Terminal Server, ils doivent avoir un accès en lecture, écriture, exécution et liste du contenu du dossier au répertoire du spouleur d'impression. % SystemRoot% System32 Spool . Même si ce ne sont pas les paramètres par défaut de Windows Server 2003 «prêts à l'emploi», ces paramètres constituent une pratique recommandée pour les services Terminal Server depuis le début de ceux-ci.

Étape 2B: Vérifier la configuration du programme d'écoute RDP pour l'utilisation de l'imprimante cliente

Avec l'outil de configuration des services Terminal Server, vous pouvez configurer les options de l'imprimante cliente pour tous les utilisateurs utilisant une connexion particulière. Dans la section "Paramètres du client" des propriétés de la connexion, assurez-vous que les cases "Mappage d’imprimante Windows" et "Mappage de port LPT" sont ne pas coché dans la section «Désactiver ce qui suit». De toute évidence, cocher l'une ou l'autre de ces cases empêchera les imprimantes clientes d'être mappées.

De plus, si l'option «Utiliser les paramètres de connexion des paramètres utilisateur» est cochée, vous devrez alors vérifier que le compte de l'utilisateur est correctement configuré pour le mappage des imprimantes clientes.

Au lieu de configurer ces options en tant que propriété de connexion RDP sur chaque serveur, vous pouvez les appliquer via un objet de stratégie de groupe. (Voir le chapitre 6 pour plus d'informations sur les objets de stratégie de groupe.) Ces propriétés de mappage d'imprimantes client peuvent être trouvées dans un objet de stratégie de groupe via le chemin suivant:

Configuration de l'ordinateur Modèles d'administration Composants Windows Services Terminal Server Redirection des données du serveur client

Les paramètres configurés ici s'appliqueront alors à tout serveur Windows 2003 Terminal Server situé dans une unité d'organisation à laquelle cet objet de stratégie de groupe a été appliqué.

Étape 2C: Configurer les paramètres du compte d'utilisateur

Vous pouvez également configurer les paramètres de connexion d'imprimante client pour chaque utilisateur. Dans les environnements Active Directory, les propriétés de mappage d'imprimantes clientes font partie de l'objet AD de l'utilisateur (onglet Utilisateurs et ordinateurs Active Directory | Objet utilisateur | Environnement).

Si vous sélectionnez «Connecter les imprimantes clientes à l'ouverture de session», l'imprimante cliente de l'utilisateur sera automatiquement créée lors de la connexion à un serveur Terminal Server. Lorsque l'utilisateur se déconnecte et que tous ses travaux d'impression sont imprimés, l'imprimante est automatiquement supprimée. Si vous ne définissez pas l'option «Connecter les imprimantes clientes à l'ouverture de session», un utilisateur pourra toujours mapper manuellement son imprimante cliente, mais elle ne sera tout simplement pas créée automatiquement.

Problèmes de pilote d'imprimante lors de l'utilisation du mappage d'imprimante client

N'oubliez pas que votre serveur Terminal Server doit disposer des pilotes d'imprimante appropriés pour que les utilisateurs puissent imprimer sur leurs imprimantes clientes, car les travaux d'impression sont rendus et spoulés sur le serveur.

À première vue, cela ne semble pas trop poser de problèmes. Cependant, il peut y avoir des complications. Par exemple, comment un serveur Terminal Server peut-il savoir s'il dispose du pilote approprié pour les imprimantes clientes d'un utilisateur?

Lorsqu'un utilisateur avec le mappage d'imprimante client activé démarre une session Terminal Server, le serveur vérifie les noms de pilote des imprimantes installées sur le périphérique client de l'utilisateur. Il examine ensuite tous les noms des pilotes installés sur le serveur. Si les deux noms sont identiques, le serveur sait que les pilotes appropriés sont installés pour prendre en charge cette imprimante et celle-ci est automatiquement mappée pour la session de cet utilisateur. Toutefois, s'il n'y a pas de correspondance exacte, cette imprimante est ignorée et le serveur Terminal Server passe à l'imprimante cliente suivante.

Par exemple, si un pilote appelé «HP OfficeJet 40xi» est installé sur le serveur Terminal Server et qu'une imprimante est installée sur le client RDP et utilise un pilote appelé «HP OfficeJet 40xi», le serveur saura qu'il existe une correspondance. Toutefois, si le client dispose d'une imprimante utilisant un pilote appelé «HP DeskJet 500», il est évident que le serveur sait qu'il n'y a pas de correspondance.

Cela fonctionne correctement lorsque les clients Windows 2000 et Windows XP se connectent aux serveurs de terminaux Windows 2000/2003. Étant donné que toutes ces plates-formes utilisent les mêmes pilotes d'imprimante, les noms des pilotes sont assurés d'être identiques. Toutefois, cela crée une situation intéressante si vos machines clientes exécutent une version antérieure à Windows 2000, y compris ME, 98, 95 ou NT. Le problème provient du fait qu'un même pilote d'imprimante écrit pour deux versions différentes de Windows n'utilise pas nécessairement les mêmes noms de pilote d'imprimante. Par exemple, la version Windows 95/98 du pilote d’une imprimante LaserJet 5P s’appelle «Hewlett Packard LaserJet 5P», tandis que le pilote Windows 2000 / XP / 2003 de cette imprimante s’appelle «HP LaserJet 5P». sont identiques, mais pour Terminal Server, le fait que l’imprimante du client utilise un pilote commençant par «Hewlett Packard» et le pilote du serveur commençant par «HP» signifie que le serveur pense que ces deux noms sont différents. Pour un serveur Terminal Server, ces deux noms ne sont pas plus similaires que les noms «HP LaserJet 5P» et «Tandy LP-1000».

Dans le cas d'un client se connectant à partir de Windows 98 avec une imprimante HP LaserJet 5P connectée, le serveur ne mapperait pas cette imprimante, même si les pilotes appropriés étaient installés, car les noms des pilotes d'impression ne correspondaient pas.

Solution de contournement: mappage de pilote d'impression client à serveur

Pour résoudre ce problème, il vous est possible de corréler les noms des pilotes d'imprimante sur votre serveur avec les noms des pilotes d'imprimante sur les clients de vos utilisateurs. Par exemple, vous pouvez indiquer au serveur que le pilote d’impression client «Hewlett Packard LaserJet 5P» est identique au pilote d’impression de serveur «HP LaserJet 5P». N'oubliez pas que vous ne devez le faire que si (1) vous utilisez mappages d'imprimantes client et (2) vos clients n'exécutent pas Windows 2000 ou Windows XP.

Pour activer le mappage du pilote d'imprimante, vous devez placer un fichier sur votre serveur Terminal Server contenant les paires de noms de pilote client et de serveur. Dans les versions précédentes de Terminal Server, cela était effectué via un fichier de mappage appelé « wtsuprn.inf " située dans le % systemroot% system32 dossier. Toutefois, ce fichier n'existe pas par défaut dans Windows Server 2003 et Windows ne le recherche pas.

Pour créer un fichier de mappage dans Windows 2003, vous devez ajouter deux valeurs de registre:

Clé: HKLM SYSTEM CurrentControlSet
Control Terminal Server Wds rdpwd

Type: REG_SZ

Valeur: PrinterMappingINFName

Les données: Nom du fichier .INF contenant les mappages de noms de pilotes d'imprimante. (Par exemple, c: winnt inf printsubs.inf)

Clé: HKLM SYSTEM CurrentControlSet
Control Terminal Server Wds rdpwd

Type: REG_SZ

Valeur: PrinterMappingINFSection

Les données: Nom de la section du fichier .INF contenant les mappages réels. (Par exemple: imprimantes)

Une fois que vous avez terminé d'ajouter vos entrées de registre, vous devez redémarrer le service spouleur ou redémarrer Terminal Server pour permettre à ces modifications de prendre effet. Après avoir ajouté les nouvelles valeurs de registre, vous devez créer un fichier .INF contenant les noms de pilote que vous souhaitez utiliser pour les mappages côté client sur côté serveur. Votre fichier ressemblera à quelque chose comme ça:

; PRINTSUBS.INF

; Ce fichier contient les mappages pour les connexions d’imprimante de pilote de serveur à serveur

[Printers]

; "Client Printer Driver Name" = "Nom du lecteur d’imprimante serveur"

"Hewlett Packard LaserJet 5P" = "HP LaserJet 5P"

Vous pouvez créer ce fichier avec le Bloc-notes et l'enregistrer dans une extension de nom de fichier .INF située dans le répertoire% SystemRoot% System32 . En utilisant cet exemple, vous spécifiez le nom du fichier printsubs.inf que vous venez de créer dans la valeur de registre PrinterMappingINFName et "Imprimantes" dans la valeur de registre PrinterMappingINFSection.

Les noms de pilote d'imprimante que vous placez dans ce fichier sont sensibles à la casse et à l'espace. Fondamentalement, tout ce qui se trouve entre les guillemets doit correspondre au nom de l'imprimante. exactement . Comme avec beaucoup de fichiers .INF, le point-virgule (;) indique que la ligne est un commentaire et doit être ignorée. Lorsque vous utilisez ce fichier, sachez que plusieurs imprimantes clientes peuvent être mappées sur un seul pilote d'imprimante de serveur.

La création d'un fichier de mappage de pilote d'imprimante est plus un art qu'une science. Heureusement, les personnes très gentilles gèrent un site Web appelé www.printingsupport.com. Ce site contient des fichiers de mappage d’imprimantes téléchargeables que vous pouvez utiliser dans votre environnement.

Une fois votre fichier de mappage créé, vous devez vous assurer qu'il existe sur chaque serveur Terminal Server où vous souhaitez que ces mappages de pilote d'imprimante soient appliqués. N'oubliez pas que ce fichier de mappage indique simplement au serveur quels sont les pilotes déjà installés qui correspondent aux pilotes d'imprimante client. Vous devez également installer les pilotes d’imprimante sur votre serveur Terminal Server lorsque vous utilisez ce fichier.

Si votre fichier de mappage .INF contient des erreurs de syntaxe (autres qu'un nom de pilote mal orthographié dans les guillemets), vous pouvez recevoir les messages suivants dans le journal des événements:

Événement 1110: "Erreur lors du traitement de ntprint.inf. Si le fichier sur le système est corrompu, vous pouvez le restaurer à partir du support d'installation.

Ce message est trompeur puisqu'il fait référence à «ntprint.inf» et non à votre nom de fichier personnalisé. Cette erreur signifie généralement que le fichier .INF personnalisé en cours de traitement par le système contient des erreurs. L'erreur la plus courante est que vous allez créer un fichier de mappage personnalisé sans entrées. You new .INF file must have at least one mapping in its printer name mapping section and the lines containing your mappings must not start with a semicolon. If the custom .INF file has a blank name-mapping section, you'll receive the Event 1110 errors in the event log.

Finding the Exact Printer Driver Names

In order to be able to map printer drivers between your Terminal Server and clients, you need to know the exact printer driver name for both the server and the client. You can get this information from the printer properties dialog box (Right-click Printer | Properties). On Windows 9x computers, the driver is listed in the “Print using the following driver” box. On Windows 2003 servers the driver box is on the “Advanced” tab. Because the name of the printer driver can vary on the workstation depending on the platform, make sure you have the right driver name for the each client platform that is being used. For example, if you see “HP LaserJet 4000 Series PCL 5/5e,” be sure to note all the punctuation, spaces, and case sensitivity.

If you already have the driver installed on your Terminal Server, but you do not have a printer installed where you can check the properties, you can always view the driver name from the list of drivers installed on the server. Just open the Printers applet in control panel and use the “Drivers” tab from the File | Server Proprieties applet. This will show you a complete list of drivers installed on your Terminal Server.

Once the driver names have been added to your mapping file, your users will be able to print to their client printers from Terminal Server sessions. You do not have to reboot your server after you change the mapping file. Simply log the user off and then back on.

Sequencing of Client Printer Driver M apping

When a user with client printers logs on to a Terminal Server, the server goes through several steps to try to find an appropriate printer driver to use:

1. The list of the client's local printers is enumerated from the registry.

2. The server queries the printer driver string names on the client.

3. The server looks for the client printer driver name in the printer driver mapping .INF file.

4. If no match is found, the server looks for a driver name match in the [Previous Names] section of built-in “ ntprint.in f ” file.

5. If the server still cannot find any mapping information, it checks to see if the driver is already installed. To do this, it looks at HKLMSystemCurrentControSetControlPrintEnvironmentsWindows NT x86Drivers in the registry.

6. If it can't fi nd the printer driver information in the registry, that means that the printer driver is not installed. As a last resort, the server will check to see if the client's printer is one of the hundreds of standard printers that are available with Windows. To do this, it goes back to the built-in ntprint.inf file and looks in the [Manufacturer] section. If a match is found, the server automatically installs the driver by extracting in from the built-in Driver.cab file located in the %systemroot%Driver Cachei38 6 folder on the server.

7. Once any of these steps is successful, the server creates a dynamic printer port that maps back to the real printer on the user's client device. This port is mapped through an RDP virtual channel . Then, the server creates a printer object with the appropriate permissions (and using the appropriate drivers) for the user.

8. If the server is not able to find an appropriate driver using any of the previous methods, then the client's printer is not mapped for the session and an event that states that the printer could not be redirected is written to the event log.

9. The server starts this entire process over again for the next printer on the client's list.

In general, Terminal Server 2003's printer driver installation process works fairly well. There used to be problems with incompatible drivers getting installed and crashing the server, but that hasn't really been a problem since the NT 4 days. (Back then, a lot of regular drivers would blue screen the server if multiple users tried to print at the same time. Ouch!)

Limiting the Number of Drivers Installed

One of the big concerns that many administrators have is the number of printer drivers that are installed on their servers. Since users with all types of printers cause drivers to be installed on the Terminal Server, the server will need to manage a lot of drivers. This can be a problem whenever client printers are used, regardless of the client operating system. (Remember that the mapping file is helpful when using older clients, but even new Windows XP clients still cause printer drivers to get installed on your Terminal Servers.)

In order to prevent too many drivers from getting installed on your server, there are two options that you can implement:

•  Map multiple client printer drivers to a single server driver.

•  Use a third-party “driverless” printing solution (discussed later).

Let's look at how we can use the printer driver mapping .INF file to control the number of drivers that are installed on a Terminal Server. Thinking back to the previous description of this file, you'll remember that it can contain multiple client driver entries for a single server driver. This means that you can use a single printer driver on your server to support dozens (or even hundreds) of different client printer models. For example, it's widely known that many LaserJet drivers will work with other LaserJet printers. You might decide that you want all client printers called HP LaserJet 4, HP LaserJet 4M, HP LaserJet 4 Plus, HP LaserJet 4M Plus, HP LaserJet 4L, and HP LaserJet 4ML to use the same “HP LaserJet 4” driver. This will let you provide a single server driver for six different printer models. To do this, you could configure your .INF mapping file to look like this:

[Printers]

;"Client Printer Driver Name" = " Server Printer Drive Name"

"HP LaserJet 4M" = "HP LaserJet 4"

"HP LaserJet 4 Plus" = "HP LaserJet 4"

"HP LaserJet 4M Plus" = "HP LaserJet 4"

"HP LaserJet 4L" = "HP LaserJet 4"

"HP LaserJet 4ML" = "HP LaserJet 4"

In fact, HP has a completely “generic” LaserJet driver (called “HP LaserJet”) that you could use for every single LaserJet printer, and a generic DeskJet driver (called “HP DeskJet”) that you could use for every single DeskJet printer. Adding all these entries to your .INF file would allow you to support hundreds of different types of printers with only two different drivers.

You can also use these “alternate printer mappings” to map a driver from one vendor to support a printer from another vendor. In addition to having fewer drivers to support on your servers, this can also lead to a potential performance gain. This can happen because the spooled print file, which is transmitted down the RDP stream to the RDP client, is created with the printer driver. All printer drivers are not created equal. Some printer drivers are very efficient and create very efficient spool files. This is usually the case with name-brand printers. However, the whole reason that we need to use client printer mapping in the first place is because we, as administrators, do not have control over the printers that our users have connected locally to their clients. They probably didn't buy the name brand printer that we recommended. Instead, they bought the cheapest $25 printer that they could find at Walmart. These printers tend to have very inefficient drivers, which means that they can easily create spooled print files that are several megabytes per page. (To be fair, the people who created these drivers probably never imagined that anyone would actually want to transmit the spooled print files across a slow network.)

To combat this, you can usually find alternate drivers that work for some printers that are much more efficient than the printer's native drivers. You can also use alternate black-and-white drivers for color printers. By definition, black-and-white drivers will produce smaller spool files since they're monochrome instead of full color. Of course, your users will not be able to print in color, but monochrome printing is better than nothing.

All this alternate printer driver mapping leads to one question: Which drivers can successfully be substituted for which printers?

Of course you can find out by trial and error on your own, but most likely you have better ways to spend your time. Fortunately, the Internet is full of free resources like www.printingsupport.com whose sole purpose is to provide printer driver mapping information for Terminal Server administrators.

The only real drawback to using alternate printer driver mapping is that some of the functionality of the original printer driver on the Terminal Server may not work on the printer. These functions are usually minor, like multiple paper tray settings, stapling, or duplexing options.

Advantages of Alternate Printer Driver Mapping

•  Allows u sers to print to printers whose native drivers are not supported.

•  Controls the total number of printer drivers in your server farm.

•  Allows you to substitute efficient printer drivers for inefficient ones.

Disadvantages of Alternate Printer Driver Mappi ng

•  Some printer functionality could be lost by using alternate drivers.

•  You need to figure out which alternate drivers work for each printer.

•  You must manually map the generic driver to the exact name of every driver it is to replace.

•  If you make t his change on one server, it needs to propagate to the other servers.

Improving the Performance of Client Printing

As discussed previously, the architecture behind the use of client printers is fundamentally inefficient since large spooled print jobs must be sent via the RDP stream to the client to be printed. Even though some of the other printing methods (such as server printers) are much more efficient than using client printers, the convenience of client printers is a compelling reason to use them. Because of this, there are some aspects of their performance that can be addressed, including:

•  Reducing the DPI of the printers.

•  Implementing a third party printing solution.

Reducing the Printer DPI Settings

Because the entire spooled print job must be sent to the client when client printer mapping is enabled, users with slow connections may see degraded session performance. This amount of degradation is generally proportional to the size of the print job being sent. Therefore, reducing the size of the print job reduces the impact printing has on the client session. By reducing the DPI of the printer from 600 DPI to 300 DPI, you essentially reduce the print job size by 75%.

Of course an additional benefit of this is that print jobs finish faster since the amount of data being transmitted is smaller. The drawback to this is that jobs that require a high resolution will look “grainy” and this will not be acceptable to some users. For normal text, however, 300 DPI is just fine.

Advantages of changing Printer DPI settings

•  Increases overall RDP session performance while printing, especially over slow connections.

•  Can possibly speed up printing.

Disadvantages of changing Printer DPI settings

•  Documents requiring a high-resolu tion may look grainy.

Whether you use client-mapped printers or server printers, you'll need to have printer drivers installed on each of your Terminal Servers. Consequently, you will need to spend some time thinking about how to manage those printer drivers. Before we address this issue, however, let's look at what printer drivers really are, how they work, and how they're stored on Windows servers.

How Windows Printer D rivers Work

Fundamentally, Windows printer drivers translate print jobs from an enhanced metafile format, which is printer-independent, into the native language that can be understood by a printer. This is why a printer prints garbage when you use the wrong driver. Printer drivers need to be installed and registered on a computer before they can be used.

Two things happen when you install a printer driver onto a Terminal Server or Windows 2000 server. First, the necessary printer driver files are copied from the source location to the server. The server stores printer driver files in the %systemroot%system32spooldriversw32x863 dossier. In this path, the “ w32x86 ” signifies an Intel Windows 32-bit platform, and the “ 3 ” signifies the version of the printer driver (3 = Windows 2000/XP/2003).

Second, the driver's details are written to the registry in this path: HKLMSystemCurrentControlSetControlPrint EnvironmentsWindows NT x8 6DriversVersion-3. Similar to the file path, a Version-3 key means that the driver is a Windows 2000/XP/2003 driver.

User's individual printer settings, such as print, duplexing, and paper tray options, are stored in the HKCUPrinters registry key. These settings are user-specific and stored in their profile, just like any other customized Windows settings.

Installing Printer Drivers

Installing print drivers onto a Terminal Server is no different than installing printer drivers onto any Windows computer.

The easiest way to install a driver without actually installing a printer is via the “Printers and Faxes” applet. (Start | Printers and Faxes | File Menu | Server Properties | “Drivers” tab | “Add” button) On a Terminal Server, it's only necessary to add the Windows 2000/XP/2003 version of the driver, since you're only installing the driver so you can print from server sessions.

If you have a lot of drivers to install, you can script the process using rundll32.exe to call the printui.dll (the Printer Properties User Interface).

If you're only using printers whose drivers are built-in to Windows 2003 (via the “ driver.cab ” file discussed previously) then you don't really have to worry about driver installation since the process is automatic when the printer is installed. However, if you have a number of drivers that are not part of the Windows 2003 install, you can script the following command to install a large number of printer drivers at once:

rundll32 printui.dll,PrintUIEntry /ia /m " Driver Name " /h "Intel" /v " Version of driver " /f \Sourceprint.inf

To use this command, replace Driver Name with the driver's name as it appears in the .INF file, replace Version of Driver with the platform for which it was written, (generally Windows 2000 or XP) and replace the \Sourceprint.inf with the path and .INF filename for the printer driver. For more information on using rundll32.exe for installing and removing printers and drivers, run “ rundll32 prinui.dll,PrintUIEntry /?” à partir d'une invite de commande. When using this command, note that there is a comma with is no space between the word prinui.dll et PrintUIEntry .

Removing Printer Drivers

When you delete a printer from the “Printers” folder on one of your Terminal Servers, the drivers are not uninstalled from the server. This can be a problem if you've identified that a certain printer driver causes problems, since you need to be able to remove that driver from the server to prevent clients from using it.

Fortunately, the Printers and Faxes applet in Windows 2003 (and 2000) can also be used to remove drivers from your Terminal Server. (Start | Printers and Faxes | File Menu | Server Properties | “Drivers” tab | “Remove” button) Of course this will only remove the driver if no printers are currently using it.

Alternately, you can also use the “rundll32” command we used previously to remove the print driver. All that is required is the modification of a couple of switches. The cool thing about using the rundll32 method is that it can even be done from remote machines. Here are some examples of how to use the command line to remove a local driver and a driver from a remote server.

To remove a driver from a machine you are logged into:

rundll32 printui.dll,PrintUIEntry /dd /m "HP DeskJet 500" /h "Intel" /v "Windows 2000"

To remove a driver from a remote machine:

rundll32 printui.dll,PrintUIEntry /dd /c\Computername /m "HP DeskJet 500" /h "Intel" /v "Windows 2000"

Make sure to replace Computername with the name of the server you are removing the driver from.

If all else fails (which unfortunately still happens, even with Windows 2003), you can manually remove a printer driver and all traces of its existence by following this procedure:

1. If you haven't done so already, remove the printer by deleting it form the “Printers” folder.

2. Stop the spooler service .

3. Browse to the following registry location: HKLMSystem CurrentControlSetControlPrintEnvironmentsWindows NT x86DriversVersion-x, where x is the version of th e driver (2 = NT 4.0, 3 = Windows 2000/2003).

4. Note the names of the files listed.

5. Remove the registry key yourprinterdriver .

6. Delete the referenced driver files from the %systemroot% system32 spooldriversw32x86x dossier. If you have multiple pri nters installed, you may want to copy the driver files to a temp orary location before you delete them outright, because many similar types of printers use the same driver files.

7. If you're not able to delete the files, you will need to disable the spooler, reboot, and delete the files again. After you do this, reset the spooler to “automatic” startup.

8. After the print drivers have been removed, you should reboot the server.

What driver does a Printer Use?

Occasionally you will need to figure out which drivers a printer uses that you haven't installed yet. This is especially handy if you allow your Terminal Server to automatically install any needed printer drivers .

Every Windows 2000 and Windows 2003 server has a “master list” of default printers that it supports and the drivers that each printer needs. That master list is stored in the %systemroot%infntprint.inf fichier. You can open this file in a text editor to see which drivers each printer will request. Ntprint.inf is organized by manufacturer, with individual printers and their drivers listed under the manufacturer's section, as shown below.

[HP]

“HP 2000C” = HPV2000C.GPD.ICM

Printer and Driver Replication

One of the printing-related challenges that you'll face as an administrator of a multiple server environment is that each Terminal Server maintains its own list of configured printers and locally installed print drivers . Each Terminal Server is completely unaware of the printer configuration and installed drivers of the other Terminal Servers.

Further complicating this is that as an administrator, you'll have no idea whether a printer driver has been updated or installed unless you view each server and driver individually.

In addition to this, server printers and their configurations are stored locally on each server and must be added, removed, or modified on every server to maintain a consistent environment. This leads to a management nightmare in environments with hundreds different client printers.

In a load-balanced or clustered server environment, each server must be configured identically. This means that drivers, printers, and printer configurations should match on all servers in the cluster. Doing this manually in a server cluster of 5 servers with 100 printers would be extremely time consuming. Now imagine those same printers in a 20- or 30-server cluster, and you'll quickly realize that you need a better way to manage drivers.

There are really only a couple of ways to get both the Windows print drivers and the server printers you have created on a Terminal Server to other servers:

•  Replication using Print Migrator.

•  Manual replication.

•  Use a third-party printer management tool (discussed later in this chapter).

Method 1. Using Print Migrator to Replicate Drivers

Print Migrator is a tool from Microsoft that can be used to replicate printer drivers between servers. (Since Microsoft is always changing things on their website, the easiest way to find this tool is to do a search on Microsoft.com for “Print Migrator.” The version discussed here is 3.1.)

Printer Migrator allows you to back up printers, print queues, ports, printer drivers , and printer shares to a .cab file. You can then restore the settings of that .cab file to another server. You can even use this tool to migrate printers between different versions of Terminal Server.

Advantages of Print Migrator Replication

•  Drivers and settings can be replicated to remote servers.

•  Drivers can be repl icated from network print servers to Terminal servers.

•  Print Migrator can be command-line driven, allowing you to script and schedule it with the command scheduler. (Run printmig /? for a list of command-line options.)

•  This too is really easy to use.

D isadvantages of Print Migrator Replication

•  Migration must be manually invoked.

•  The spooler service is stopped while this tool is used.

•  Since this tool packages drivers into the CAB file, the CAB file can become quite large.

•  Target Terminal Servers must be placed into “install” mode.

Method 2. Manual Print Driver Replication

The other option for replicating printer drivers is to do it manually. You must manually install or copy all of the needed printer drivers onto each of your Terminal servers.

Advantages of Manual Print Driver Replication

•  No learning curv e.

•  Allows you to install different printer drivers to different servers.

•  Works well in small environments with only a few drivers.

Disadvantages of Manual Print Driver Replication

•  Drivers must be manually installed onto each Terminal server.

Now that you've completed the work needed to ensure that various printers will be available to the users on your Terminal Servers, you need to provide a method for users to access their printers. This is easy if you're using client mapped printers because the printers are automatically created for the users.

However, client printers aren't always an option in the real world, so server printers must be used. When using server printers, you need to think about how your users will access these printers. Will you assign certain printers to certain users? If so, how will you do this? Maybe you want to allow all users to be able to use all printers? If this is the case, how will users know which printers they should use? We'll look at two strategies to answer these questions:

•  Assigning printers to users.

•  Methods of letting users choose their own printers.

Assigning Printers to Users

Once you decide that you would like to control which printers your users are able to print to, you need to determine how to provide that access. Setting permissions on printers is important, but permissions alone won't configure a printer for a user. For example, if you want the user “brian” to print to the \printerserverfastlaser printer, you can edit the properties of that print queue and grant “brian” print permissions. However, how will Brian know how to access that printer? Is he smart enough to be able to browse the network to the \printserver computer, and then select the fastlaser printer? Most likely, if you decide that Brian should use the \printserverfastlaser printer, you need a way to assign that printer to him so that when he selects “print” from a Terminal Server application, the \printserverfastlaser printer shows up in his printer list.

There are three methods that you can use to assign server-based printers to users:

•  Map printers in users' logon scripts.

•  Map printers as part of a user's profile and policy settings.

•  Install the printer locally on the server and configure its permissions.

Method 1. Configuring Printers via Logon Scripts

One of the most tried-and-true methods of making printers available to users is to map them via a logon script. (Logon scripts were covered in detail back in Chapter 6.) When it comes to printing, there are a few different ways that you can use logon scripts to map users' printers.

One of the cool things about using logon scripts to map printers is that you can incorporate conditional branching into the scripts based on a user's group membership. That way, you can give a user access to a printer simply by adding them to the appropriate Windows group. You can even set the permissions of a printer based on the same user group.

Command-Line Printer Mapping

You can use the same “rundll32” from the printer drivers section of this chapter to map user connections to network printers. (This method replaces the older, less-flexible “ con2prt.exe ” utility.) To do this, add the following line to a logon script:

rundll32 printui.dll,PrintUIEntry /in \ printserver imprimante

Again, make sure that you have a comma with no space between the words “ printui.dll " et " PrintUIEntry .” You can add this command multiple times in a script if you need to map multiple printers.

Mapping Printers with Kixtart

If you've chosen to use Kixtart as the language for your logon scripts, you can use its own native capabilities to connect to network printers. For example, the following Kixtart code checks to see whether the user is in the “ PrinterGroupName ” Windows group. If he is, it adds the \printserverfastlaser printer connection and sets it to be the default printer for the user.

if ingroup(“PrinterGroupName”)

addprinterconnection (“\printserverfastlaser”)

setdefaultprinter (“\printserverfastlaser”)

endif

Many Terminal Server administrators use code like this, adding this code segment for each printer in the environment. This can allow them to create an all-encompassing logon script that maps the proper printers based on users' group memberships.

Advantages of Assigning Printers with Logon Scripts

•  You can assign printers on a per-user or per-group basis.

•  You can assign different printers for different s ervers.

•  Logon scripts can be used in many different ways.

Disadvantages of Assigning Printers with Logon Scripts

•  Requires knowledge of the logon script language.

Method 2. Configuring Printers via User Profiles

Another option for ensuring that users can easily access their printers is to use roaming profiles. By doing so, your users will only have to connect to a printer once. After that, the printer connection will become part of their profile and will automatically be restored whenever they logon. See Chapter 6 for full information about using roaming profiles.

Advantages of Assigning Printers via Roaming Profiles

•  This method works without using logon scripts.

•  The same printers will be available to the user no matter where they log on.

Disadvantag es of Assigning Printers via Roaming Profiles

•  Roaming profiles must be configured for your environment.

•  The user (or you) will have to manually configure the printer the first time for the user.

•  The same printers will be available to the user no matter where they log on.

Method 3. Installing Printers onto the Terminal Server

The last method of assigning printers is not exactly a “best practice,” but it can work well in smaller LAN environments that don't have too many printers. To use this method, you install the printer “locally” onto a Terminal Server. This does not mean that the printer must be physically attached to the Terminal Server. It just means that you add the printer to the Terminal Server as a local printer instead of a network printer . Pour faire ça:

1. Logon to the Terminal Server as an administrator.

2. Start the “Add Printer” wizard.

3. Select “Local printer attached to this computer.”

4. Make sure that the “Automatically detect and install my Plug and Play printer” box is unchecked.

5. When asked, cr eate a new port instead of using an existing port.

6. Select Standard TCP/IP port.

7. Type in the IP address of the printer or print server.

8. Configure the options for type of port detected on the IP address you specified.

Following this procedure creates a shared print queue on the Terminal Server. Even though this queue is for a remote printer, the server treats it as a locally installed printer. By default, all users that run sessions on a Terminal Server are able to print to local printers on a server, meaning that all users will “automatically” have access to this printer.

You can modify the permissions of one of these newly-installed local printers so that only certain users or groups can print to it. What's cool about this is that users won't see a printer that they don't have rights to print to, so you don't have to worry about any additional configuration.

The major downside to this method is that since the print queue is local to the Terminal Server, the server's printing subsystem will spool the file locally and send it across the network in its raw data format instead of as an EMF file. (In some cases, such as when some types of JetDirect cards are used, this is always the case anyway.)

Advantages of Installing Printers on Each Server

•  You can assign printers to users simply by editing the permissions of the printer.

•  All users that use the Terminal Server will automatically see the printer.

Disadvantages of Installing Printers on Each Server

•  Each printer must be configured on each server. (Although printers can be replicated with tools such as Microsoft's free Print Migrator.)

•  This method bypasses the “real” print servers in your environment.

•  Print jobs are spooled on the Terminal Server instead of on the print server.

•  All users share the same print queue .

Letting Users Choose Their Own Printers

Instead of assigning printers to your users, you may have an environment in which users need to be able to choose their own printers. This makes your job much easier. If security is important, you can still set the printing permissions on the printers that you don't want everyone to be able to print to.

If you simply give a user permissions to print to a network printer , that printer will not be automatically set up for the user. However, the user will be able to browse the network and connect to the printer if he needs to print to it.

Advantages of Letting Users Choose The ir Own Printers

•  You can still set security for printers that need limited access.

•  There is less for you to configure.

Disadvantages of Letting Users Choose Their Own Printers

•  Users need to know how to connect to printers.

•  Users need to know which p rinter they are looking for.

If your users are able to configure their own printers via Windows Explorer or the “Printers” folder in the Start Menu when using a desktop session this may be fine. However, in the real world, many people choose not to allow users to connect to the Windows desktop or Windows Explorer and instead only use single application connections, and thus users are not able connect to network printers since they have no interface to do so.

With that problem in mind, many administrators will give the users a connection to the server that launches the Printers folder. Of course this is an extra step for the end user but it allows them access to a resource without giving them a full server desktop.

Configuring Printers Folder as an Initial Application

Connecting to the Printers folder is very easy to do. The Printers folder does not have its own executable; it's actually built into the Windows shell (explorer.exe). These types of Explorer shell components are called “shell extensions.” Each shell extension has its own GUID, which is like a serial number that differentiates it from all other shell extensions. Information about different shell extensions are contained in the following registry location: HKEY_CLASSES_ROOTCLSID.

In this case, the Printer folder's unique GUID is 2227A280-3AEA-1069-A2DE-08002B30309D.

Any Windows program can access a shell extension by calling explorer.exe and requesting the GUID of the extension it wants. You can even create an initial application that points to the Printers shell extension. Here's a neat trick to show how that shell extension will work:

1. Create a new folder on your Windows desktop.

2. Name the folder “Printers. 2227A280-3AEA-1069-A2DE-08002B3030 9D” with no spaces anywhere in the name.

As soon as you press Enter, the icon for the folder will change into the Printers folder icon. When you open that folder it will look just like the Printers folder from the start menu. To make the Printers folder available as a stand-alone application, you need to create a command line that launches a folder like this. Here are the steps to take:

1. Create a folder called “Printers. 2227A280-3AEA-1069-A2DE-08002B30309D.” Make sure that there are no spaces anywhere in the nam e .

2. Put that folder somewhere it can be launched. For example, use the c:print directory, so that the full path of your folder is c: printPrinters. 2227A280-3AEA-1069-A2DE-08002B30309D.

3. Now, all you need to do is launch that folder with certain command-line switches . However, you need to first make a copy of explorer.exe. Your copy can be called anything except explorer.exe. This will force your command to open a new instance of explorer.exe, since yours will have a different name than the backgr ound copy that is already running.

4. Put the new copy of explorer.exe (Let's call it printexplorer.exe) into the m:print dossier.

5. Access your new folder via the following command: C:printprintexplorer.exe /n,/root, C:printPrinters. 2227A280-3AEA-1069-A2DE-08002B30309D.

That command line begins by launching printexplorer.exe with several command-line options. le /n option tells explorer to open a single-paned window. le /root option tells explorer to open this window as the root, preventing users from being able to click the “Up” folder to browse back up through the directory structure. The command ends with the full path to your custom folder, telling explorer which folder should be used as the root.

By this point we've examined all aspects of printing in Terminal Server environments related to out-of-the-box tools and techniques. However, even considering everything we've seen so far, troubling issues can still arise, including:

•  Printer drivers must be installed and managed on every Terminal Server for each client printer in use in your environment.

•  Client printing performance is poor, both in terms of the amount of data that must be sent across the network and the server resources required to render the print jobs.

•  There are no good out-of-the-box solutions for situations in which RDP clients and print servers are on one side of the WAN while the Terminal Servers are on the other (as outlined back in Figure 8.4).

Fortunately, several third-party software printing solutions are available to address these issues. The four most popular vendors now, in alphabetical order are:

Emergent Online (EOL) : a fairly large consulting and training company that also creates various software packages to help administrators with many thin-client situations. They offer several printing products that can help with many different aspects of printing. Their website is www.go-eol.com .

ThinPrint : a German company with a large US presence. As their name implies, they focus entirely on printing in mobile and low bandwidth environments. You can find them at www.thinprint.com .

triCerat Logiciel: offers several products that can help you simplify the management of server-based computing environments, including several printing products. More information is available at www.tricerat.com .

Qnetix : a company whose Uniprint product family provides printing solutions for server-based computing environments. Visit www.uniprint.net .

Because there are drawbacks to Terminal Server's out-of-the-box printing solutions, and because third-party tools are so popular, it's worth considering them. As for recommendations, we'll study the printing challenges and how third-party tools are used to address them from a technical standpoint. Nous allons ne pas analyze each vendors' products and provide reviews. (Product review information is available online at www.brianmadden.com .)

After reading this section, you'll have a true understanding of why these products are needed and how they can help, enabling you to explore the different printing vendors and accurately assess their offerings. All four vendors named here offer 30-day trial versions of their products. You can find a complete list of links with more information in the Appendix.

The technical design information provided here together with the online information about these four vendors should provide you with enough information to decide how to support the printing challenges that arise in your environment.

Understanding the Third-Party Tools

The printing software tools of the above-named vendors can be divided into two groups:

•  Products that install a “universal” driver on the Terminal Server that works with any printer. EOL, Qnetix , and (for those interested) Citrix's universal print driver fall into this group.

•  Products that enable EMF -based printing, including those from ThinPrint and triCerat .

At first glance, it may seem that the two descriptions are the same. Products from each group differ in how they solve printing challenges.

Universal Print Driver (UDP) Products

The universal print driver products from EOL, Qnetix , and Citrix allow you to install a single “universal” print driver on your Terminal Server that is then used for every printer. (This driver does not, however, work with specialty printers such as vector plotters, label printers, and barcode printers.)

When a user prints, the Terminal Server's print subsystem uses the universal driver to render the print job into either a PDF file or PCL file (depending on the product). Then, the print job is transmitted to the client device where the local printing subsystem forwards it to the appropriate print queue. This entire process is laid out in Figure 8.7.

Figure 8.7 The Third-Party Universal Print Driver Process

1. The user prints from an application on the Terminal Server.

2. The GDI generates an EMF file.

3. The Terminal Server's printer subsystem sends the EMF file to the local print spooler.

4. The print spooler uses the “universal” driver to render the print job into a universal format. (PDF or PCL , depending on the product.)

5. The PDF/PCL file is transmitted to the RDP client. Some products send the file through a virtual channel in the RDP protocol, and some send it via TCP/IP.

6. A third-party software component on the client receives the PDF/PCL file.

7. The third-party software on the client invokes the local print process. The client device's local GDI generates an EMF file on the client device.

8. The client device's local printer spooler renders the print job with a locally installed printer driver.

9. The print job is transmitted to the client's printer, just like any print job in a non-Terminal Server environment.

Advantages of Universal Print Driver Products

•  Universal print driver products allow printing to any printer without having to install different drivers on your Terminal Servers.

•  You don't have to worry about what kind of client printer is used. It can be replaced without having to notify the server administrator.

•  PDF / PCL files are smaller than raw print jobs, thereby increasing the speed of the printout and lowering the impact on the network. (Furthermore, some of the products compress the PDF/PCL print data .)

Disadvantages of Universal Print Driver Products

•  Print jobs are rendered on the server, which means that the server must spend resources generating the printout.

•  Since the PDF / PCL documents are fully rendered, any compression that is used affects the quality of the printout.

•  Printer features are limited to the “lowest common denominator” capabilities of the universal driver.

•  These products do not work with all printers.

Metafile-Based (EMF -Based) Printing Products

ThinPrint and triCerat 's products fall into the second group of third-party printing products known as “EMF -based” printing products. TriCerat has a product called “ScrewDrivers ,” and ThinPrint's product is called “ThinPrint.”

EMF -based printing products are technically superior to UPD -based printing products, but they are also more expensive.

Both triCerat ScrewDrivers and ThinPrint install a simulated print driver on the server that receives print data from the GDI . This approach is similar to that of UPD -based products. However, unlike those products, these EMF -based products do ne pas render the print job on the server. Instead, they send the device-independent EMF file to the client device. From there, triCerat or ThinPrint client software forwards the EMF print data to the client's print subsystem. The client device renders the print job and sends it to the appropriate printer. Figure 8.8 illustrates this process.

Figure 8.8 The third-party EMF -based printing software process

1. The user prints from an application on the Terminal Server.

2. The GDI generates an EMF file.

3. The third-party software component running on the Terminal Server receives that EMF file.

4. The third-party software compresses and transmits the EMF file to the RDP client. It is usually transmitted through a virtual channel of the RDP protocol, although ThinPrint has the additional option to transmit it directly to the client via TCP/IP outside of the RDP protocol.

5. A third-party software component on the client receives the EMF file.

6. The third party software transfers the EMF file to the local print spooler on the client device.

7. The client device's local print spooler spools and renders the print job.

8. The print job is transmitted to the client's printer, just like any print job in a non-Terminal Server environment.

Advantages of EMF -Based Printing Software

•  EMF -based printing software allows printing to any printer without having to install different drivers on your Terminal Servers.

•  EMF print data is smaller than raw print jobs, thereby increasing the speed of the printout and lowering the impact on the network.

•  EMF print data is also smaller than PDF / PCL files (used by the UPD -based products). Also, the compression ratio of EMF files is higher than PDF / PCL files.

•  You don't have to worry about what kind of client printer is used. It can be replaced without having to notify the server administrator.

•  Since the print job isn't rendered until it hits the client, you can automatically use the full capabilities of your printer.

•  Since the print jobs are not rendered on the server, you will not experience as large a performance hit in heavy printing environments as compared to UPD -based products.

•  Documents are printed with 100% of the original quality, since lossless compression is used.

Disadvantages of EMF -Based Printing Software

•  More expensive than universal print driver software.

•  More complicated than universal driver solutions.

Third-Party Solutions for Low Bandwidth Clients

Often, Terminal Server environments are designed so that the users are at one location and the Terminal Servers are at another location. This design is preferred in many cases because it's desirable to place the Terminal Servers close to the data sources, usually located at corporate offices. One problem with this architecture is printing. Typically, the location that houses the users has its own print server, as is often the case with remote offices or factory floors, shown in Figure 8.9.

Figure 8.9 Terminal Server in a WAN environment

The problem with this design is that the WAN is not used efficiently. If client printers are used (see again Figure 8.5), the Terminal Server will spool the entire print job before it's sent across the WAN. Alternately, the printer could be configured as a server printer (see again Figure 8.3). However, with this configuration, the print job would still be spooled on the Terminal Server. Either way, inefficient print traffic is sent across the WAN.

The third-party tools outlined previously offer some relief in this scenario as well. The UPD -based tools send the PDF or PCL data to the client, and the client then invokes its local print subsystem and prints the document as normal.

The EMF -based solutions send the compressed EMF data to the client, where (again) the client invokes its local print subsystem and prints the document as normal.

On the surface, it doesn't appear that there are any problems with the third-party tools as outlined. But what happens if your client device is connected via a low-bandwidth connection? Or if your client device is running on a platform not supported by the products listed previously?

Fortunately, there is a solution here as well. Some third-party vendors offer products by which the print information is sent directly to the print server, completely bypassing the client device. (In effect, the print server becomes the third-party software client.)

The exact implementation of this process depends on the vendor. UPD -based vendors such as EOL and Qnetix have solutions by which they can send PDF files directly to print servers, and ThinPrint can send EMF print data directly to the print server.

The “standard” advantages and disadvantages of UPD -based and EMF -based solutions apply in this scenario also. The EMF-based solution offers better performance and quality at a higher price than the UPD-based solutions.

Dina's Gourmet Food Service

Dina's Gourmet has decided to implement Windows 2003 Terminal Servers to provide several core applications for their users. They have 13 office locations and about 950 users. At this point, the project team has taken an inventory of their locations and users. Based on inventory findings, they were able to put together the basic design of their Terminal Server environment. Now all they need to do is figure out how to print. The project team decided that it would be easiest to create a solution based on the type of printing scenario. In looking at their Terminal Server system design, they realized that there were basically four different printing scenarios:

Main Office . There is 1 main office with 550 users and 14 Terminal Servers. All printing is handled by local print servers.

Bureaux régionaux . There are 2 regional offices, each with 150 users and 5 Terminal Servers. All printing is handled by local print servers. However, these users will also need to print from sessions running on Terminal Servers at the main office.

Small Offices . There are 10 small offices, each with 5 to 15 users. These offices do not have local Terminal Servers—all their users run applications off of Terminal Servers at the main office. Each of these small offices has a local file server that doubles as a print server, with a laser printer and a color ink jet printer.

Home Users. There are fifty users that work from their homes. Each has a local printer connected to his laptop computer. The IT department had issued a “Home Office Supported Equipment” list to the departments that listed four different printer models that would be supported.

In addition to identifying the different printing scenarios, the project team also created a list of business goals for their Terminal Server printing environment. These goals included the following:

•  Users should be able to log in anywhere and be able to print.

•  The printing process cannot be too confusing for the users.

•  The printing process must work at a reasonable speed.

Keeping these three printing goals in mind, the project team decided to address each printing scenario separately, beginning with the main office.

The Main Office

All of the printers at the main office are standard network printers. Most of the print servers are running Windows 2000. The network printers are fairly standard and all have JetDirect cards.

Figure 8.10 Network printers at the Terminal Server location

At the main office, users' printers are automatically mapped via their logon scripts. Because the project team wanted the users to have the same environment when they logged onto a Terminal Server as when they logged onto their local workstation, the users will run their standard logon scripts (except for the virus update section which does not run if it detects that the user is logging on from a Terminal Server). Because the printers are configured via logon scripts, there will be no issues configuring printers for different users.

Some project team members commented that printing performance would actually be faster when printing from Terminal Server than when printing from workstations since the Terminal Servers are in the data center two racks down from the print servers. Print jobs generated by users on Terminal Servers don't even have to leave the data center.

There was only one issue with the network printers at the main office that the project team had to address. That issue dealt with printer drivers and the drivers that need to be installed onto the Terminal Servers. Some project team members wanted to install all of the drivers for all of the printers; other team members thought that only basic, generic drivers should be installed. To fully understand the difference of opinion, let's probe deeper into this issue.

Dina Gourmet has eight different types of network printers in their main office. Three-quarters of these are HP LaserJets. The rest are more specialized, such as color printers and dot-matrix printers for multipart forms. Some project team members felt that all of the LaserJet printers should use the same driver, most likely a LaserJet 4 driver. While they might lose some functionality of the more advanced printers, they would not have to support very many drivers.

Other team members felt that they could easily support eight different printer drivers . They pointed out that because these were all network printers, there was no chance that non-supported printers would ever be used. There was no risk that they would ultimately have to support hundreds of printer drivers.

In the end, this driver issue was escalated all the way up to the CTO. His vision was pretty compelling. He said, “We have already spent a lot of money on fancy printers that can duplex, collate, staple and bind. With our vision of moving everything to a server-based computing model, it seems that Terminal Server will be a key part of our infrastructure for the next few years. For that reason, we should do everything we can to ensure that we are able to realize the full benefits of our printers in the Terminal Server environment.”

With that, the project team decided to install all of the native printer drivers on their Windows 2003 Terminal Servers.

The Regional Offices

Dina Gourmet has two regional offices, each with about 150 users. Most applications that users need to access will be served from local Terminal Servers. However, a few users will need to access some database applications from Terminal Servers located at the main office. In either case, all printers at these regional offices are network printers. The print servers, which are all Windows 2000, are located locally at the regional offices.

Figure 8.11 Network printers at the regional offices

For the most part, printing in the regional offices mirror the main office, with users receiving their printer mappings via logon scripts. The users running RDP sessions on local Terminal Servers will have extremely fast and reliable access to the printers.

The only issue here relates to those users who need to print from applications running on the Terminal Servers located back in the main office. In order to figure out how printing should be configured for them, the project team conducted an interview in order to create a “printer user's profile.” Their questionnaire addressed all printing information that the project team would require to determine the type of printer support needed.

The following questions were asked of users to create the printer user's profile:

•  How many different printers do you use? Pourquoi?

•  Do you use any advanced printer features, such as duplexing, collating, copying, or hole-punching?

•  Do you print in color? À quelle fréquence?

•  Do you ever use different paper types or sizes?

•  Do you have any other special printing needs?

•  Do you print forms, Word documents, images, or presentations?

•  Who views your printouts?

•  How many times per day do you print?

•  What type of client device do you have? What operating system does it run?

•  How many pages are usually printed at once?

In addition to surveying individual users, the project team also chose to look at the printers that they used and to collect the following information about them:

•  What is the printer's rated speed, in pages per minute?

•  How often is the printer used throughout the day?

•  How is the printer connected to the network? Can it be accessed via an IP address, or must it be accessed via a print server?

•  What special features does the printer support that might be lost by using alternate generic drivers? How many people use these special features?

Remember, as far as the project team was concerned, they were only collecting printer information to evaluate printing options for users at the two regional offices (with local print servers) that had to print from applications running on Terminal Servers located at the main office.

The evaluations revealed that only about twenty people from each regional office needed to print from Terminal Servers at the main office. Most of these were using Windows XP workstations, although a few in the Customer Service Department were using HP Evo thin client terminals. Some users needed to print in color, and they did print quite often from their central applications. The printers they used were HP LaserJet 8000N's, and they often printed on both sides of the page.

Based on this analysis, and the information that the project team received from their interviews, they built this list of requirements:

•  Client platforms of Windows XP and Windows CE.

•  Monochrome and color printing.

•  High speed.

•  The printer must support duplexing.

The project team determined that a third-party printing software solution was their best choice to meet these requirements. As outlined in Figure xxx, their users would be able to print to any printer without administrator intervention.

A third party utility would provide the best overall solution for the regional office users that needed to print from applications running on the main office Terminal Servers. The only real disadvantage to that approach was the fact that the third party tool had to be purchased in addition to their Microsoft software. However, the team figured that increased performance and decreased configuration effort would allow the new software to pay for itself very quickly.

The Small Offices

All of Dina's ten small offices have local print servers, but all Terminal Server application execution takes place at the main office. Again, because the print server is not located near the Terminal Server, the spooled printer files must be sent from the Terminal Server across the WAN to the print server, which can be time consuming.

Figure 8.12 Network printers at remote office locations

In this case, the project team was able to quickly make a decision without any disagreement. They decided to use the same third-party printing utility that they will use for the regional offices, allowing the users at those facilities to make full use of their color and laser printers without the need to install any client software on users' workstations.

Home Users

Finally the project team addressed the printing needs of the home users. The home users all run Terminal Server sessions off the servers at the main office. Almost all of the fifty home users have local printers installed. The printers are connected to their laptop computers via USB or the parallel port. As the project team discussed earlier, the big challenge concerning these users was that no one can be sure of what kind of printers they have. Some team members estimated that there may be as many as thirty different types of printers out there.

Figure 8.13 Local printers attached to client devices

Fortunately, the printing technology decision for the home users was also easy to make. The project team knew that they were working with these requirements:

•  Any client computer make and model.

•  Any operating system.

•  Any printer make and model.

•  Extremely slow network connections (dial-up).

•  No user intervention.

All of these requirements naturally lead the team to one solution: third party printer management software. The server component of this software would be installed on each of the Terminal Servers. A client component would be installed on every RDC client device. Once this client software is installed, the Terminal Servers send small, unrendered metafile print jobs to the client. The third party software installed on the client computer renders the print jobs locally, allowing any printer to be used, as shown back in Figure 7.8.

Résumé

By carefully analyzing all of the unique requirements of each printing scenario, the Dina Gourmet Food Service project team was able to successfully design a Windows 2003 Terminal Server printing solution that allows users to print documents with the speed and flexibility they need.
Brian Madden – Terminal Server Printing.pdf

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.