Serveur d'impression

Aide-mémoire ultime pour l'impression interne de Citrix – version 2.0 – Bien choisir son serveur d impression

Le 25 juillet 2019 - 52 minutes de lecture

Temps moyen pour lire: 35 minutes

Lorsque je travaillais sur ma feuille de triche interne Citrix XenDesktop ultime il y a quelques semaines à peine, on m'a également demandé (merci, Jamie) si j'envisagerais de mettre à jour ma feuille de triche interne d'impression. Après avoir réfléchi à cette question – ce qui m'a pris environ une minute -, j'ai décidé que c'était une excellente idée et je suis allé droit au but. Bien que l’impression, en particulier sur les environnements SBC, soit relativement stable, en ce sens que peu de choses ont changé au cours des deux dernières années en ce qui concerne l’architecture, les chemins, le flux de trafic, etc., j’ai réussi à réécrire beaucoup (presque l’ensemble des documents publiés précédemment et d’inclure une série de faits, de chiffres et de «connaissances intéressantes» tout au long du processus. Tout cela, ainsi que l’aspect renouvelé, les images fraîchement créées et l’ajout d’une table des matières amélioreront considérablement votre expérience de lecture, j'en suis sûr. Si vous téléchargez une copie .PDF, c’est.

Téléchargez votre copie .PDF en cliquant sur le bouton ci-dessous

Critique d'affaires

J'aime imprimer. Là, je l’ai dit. Ce n’est pas que j’ai mis en œuvre des dizaines d’architectures d’impression complexes, non, un couple, mais pas beaucoup. J'aime juste la technologie et les processus derrière elle. D'autant que l'impression est considérée comme essentielle pour la quasi-totalité des clients que j'ai visités. Bien que les raisons de cette situation puissent varier, imaginez cela, et je suis sûr que vous l’avez également vu; un utilisateur reçoit un e-mail important, ou peut-être a-t-il trouvé un livre blanc intéressant ou un autre type de document, quelle sera l'une de ses premières choses à faire? Ils vont l'imprimer. Ensuite, ils vont le lire, l'utiliser comme référence, prendre des notes, l'emporter chez eux, le garder sur leur bureau, etc. Pas tout le monde, mais ça arrive souvent. Je sais que je le fais. Bien que je préfère le stylo et le papier au clavier, je ne suis peut-être pas la meilleure référence.

Comment je suis arrivé ici

Dans le passé, j’ai écrit plusieurs articles de blog sur l’impression, l’impression native Citrix (sans outillage tiers) pour être précis. En fait, lorsque j'ai commencé à bloguer sur basvankaam.com il y a plus de quatre ans (le temps passe vite), mon deuxième article portait sur l'impression native Citrix et les voies d'impression impliquées.

À l'époque, il était basé sur quelques expériences du monde réel décevantes (et la réponse que j'essayais de trouver) plus ce que je pouvais trouver sur les pages Citrix E-Docs. En recherchant plusieurs sujets de présentations potentiels, je me suis davantage intéressé au sujet de l'impression. Une chose en a mené une autre. J'ai donc écrit divers articles sur l'impression, dont la version 1.0 du dernier aide-mémoire Citrix pour l'impression interne et fait quelques présentations plus approfondies, dont l'une au cours de Citrix Synergy de l'année dernière.

Ce que j'ai le plus aimé dans tout cela, c'est que lorsque j'ai écrit et présenté sur l'impression Citrix, j'ai pu aider plusieurs membres de la communauté à résoudre divers problèmes d'impression, même si la plupart étaient liés aux chemins impliqués, au comportement par défaut et à la configuration physique de l'impression. et les composants du serveur impliqués. Récemment, j'ai parlé à quelqu'un qui a résolu un problème d'impression à l'aide de mon aide-mémoire, comment est-ce cool?!

Citrix natif uniquement

Lorsque Citrix est mis à contribution, les choses fonctionnent un peu différemment. Bien que les bases de l’impression Microsoft s’appliquent toujours et que je vais en parler dans un instant, la manière dont le trafic d’impression sera, ou peut être routé dans votre environnement, dépend de l’une: la configuration physique de vos machines; et deux: les stratégies Citrix (impression) configurées. Notez que je ne me concentrerai que sur l’impression native Citrix et que je n’examinerai aucune des solutions tierces disponibles sur le marché.

Formats de fichier d'impression Microsoft

CEM versus XPS

Microsoft prend en charge deux formats de fichier d'impression, EMF et XPS. EMF signifie Enhanced MetaFile et XPS signifie XML Paper Specification (souvent considérée comme la version de PDF moins compatible de Microsoft) – Dans le chemin d'impression XPS, disponible à partir de Windows Vista, Windows 7 et supérieur, pilotes d'imprimante sont basés sur la spécification du papier XML (XPS). Un format de fichier d'impression fait référence au type de sortie d'impression produite par une application et à la manière dont elle sera gérée (acheminée et rendue) par la suite par le sous-système d'impression. Bien qu’elle soit considérée comme un héritage, les champs électromagnétiques sont encore largement utilisés aujourd’hui, peut-être même le plus souvent.

Jusqu'à Windows XP et Server 2003, nous n'avions que cela (applications basées sur EMF). C'est pourquoi vous pouvez probablement imaginer le nombre d'applications qui dépendent encore du format EMF aujourd'hui. Cependant, avec la montée en puissance des applications de la plate-forme Windows universelle (UWP), de Windows 10 et de Server 2016, je devine que la norme EMF deviendra de moins en moins pertinente. XPS a été introduit avec la version de Windows Vista et Server 2008 et est pris en charge dans les versions ultérieures, telles que Windows 7,8 10 et Server 2012, 2016.

La manière dont une application est écrite, codée ou compilée, etc. déterminera le format de fichier d'impression à utiliser. Les applications Win32 GDI, basées sur un framework de création d’applications basé sur le langage C, dépendent du format de fichier d’impression EMF et en tirent parti (ainsi que de l’interface Graphics Device Interface, comme vous le découvrirez tout à l’heure). Les applications WPF (Windows Presentation Foundation) représentent toutefois un sous-système graphique (un format graphique plus moderne) permettant de restituer les interfaces utilisateur dans les applications Windows et utilisent le format de fichier d'impression XPS. La même chose s'applique aux applications Win32 XPS. Comme on peut s'y attendre, EMF et XPS se comportent de manière quelque peu différente.

Quelques autres différences entre les deux

XPS applique la compression en compressant les données d'impression dans un fichier .zip. EMF n'utilise pas de compression du tout. En outre, EMF doit dessiner séparément chaque image rencontrée, même si elle est utilisée plusieurs fois dans le même document. Cependant, XPS peut référencer une seule image plusieurs fois.

En conséquence, les travaux d'impression EMF s'avèrent être un peu plus volumineux par rapport à XPS. Dans l’ensemble, XPS convient mieux à la gestion de documents riches en graphiques. En revanche, les champs EMF sont généralement perçus comme «plus rapides», car l’impression peut commencer après la spoule de la première page du travail d’impression. XPS attend que toutes les pages aient été reçues.

Pour que XPS soit utilisé, en supposant que votre application (Windows) le supporte, le pilote d’imprimante (rappelez-vous que les pilotes d’impression sont également conçus spécifiquement pour EMF ou XPS), ainsi que le périphérique d’impression physique, doivent prendre en charge XPS (GDI / EMF est la norme). Sinon, il sera reconverti en fichier EMF – Lorsque le fichier XPS est imprimé sur un périphérique GDI, il est converti en fichier EMF via le module de conversion XPS vers GDI.

Il est ensuite envoyé via le chemin d’impression GDI de la même manière que les autres applications Win32 GDI (sera traité ultérieurement) .n vers un périphérique compatible XPS, les commandes d’impression GDI sont converties via le composant de conversion GDI vers XPS et le travail d’impression est exécuté. envoyé par le chemin d'impression XPS.

Lorsqu'un utilisateur clique sur "Imprimer"

Encore une fois, il s’agit toujours d’une perspective d’impression Microsoft (Windows). Une fois que l'utilisateur a cliqué sur «imprimer», l'application générera une forme de sortie d'impression, par exemple, des données d'impression. Ces données contiendront tous les caractères, polices, schémas de couleurs, images, etc., qui devront ensuite être «traduits» en quelque chose que le périphérique d’impression physique peut comprendre et gérer. Comme expliqué précédemment, en fonction de la manière dont l'application est écrite / codée, ces données seront basées sur GDI / EMF ou XPS.

Avec EMF, la sortie d’impression sera soit traitée, soit rendue par GDI (Graphics Device Interface). Elle appelle les fonctions GDI dans l’API Win32, la transmet au moteur graphique GDI et la spoule au format EMF – la transformant en un métafichier (basé sur XML). Ou bien, avec un pilote d’imprimante installé localement, restitue les données dans un format imprimable avant de les transférer au service de spouleur d’impression (local ou distant). Cependant, avec le format EMF, l’intervention GDI mentionnée est plus courante car la plupart des applications Windows traditionnelles (jusqu’à Windows 7) sont construites sur GDI.

Lorsqu'il traite avec une application Microsoft Win32 XPS, il appelle des fonctions XPS dans l'API d'impression XPS. Sous Windows Vista, Windows 7 et les versions ultérieures, les applications Windows Presentation Foundation (WPF) appellent les services de support d'impression WPF pour spouler les documents XPS vers le spouleur au format de fichier spouleur XPS.

L'une des principales différences par rapport à l'interface de périphérique graphique réside dans le fait qu'avec Windows Presentation Foundation ou les applications XPS (ces deux méthodes sont différentes, voir la section «Formats de fichier d'impression Microsoft» ci-dessus), le service de spouleur envoie directement le fichier spoule. (dans son format d'origine) sur le périphérique d'impression pour le rendu et la sortie, sans aucune interruption. De plus, contrairement aux applications basées sur EMF, le GDI n’a pas besoin d’interférer, la sortie d’impression de l’application sera immédiatement envoyée au service de spouleur d’impression (local ou distant).

Comme indiqué ci-dessus, lorsqu’il s’agit d’une application XPS, et donc d’une sortie imprimée, les données sont directement acheminées de l’application au service de spouleur d’impression (local ou distant), en contournant le GDI sur le périphérique d’impression pour le rendu et la sortie, sans aucune modification. interruptions. Avec la sortie d’application / d’impression basée sur GDI / EMF, une fois gérée par le GDI et envoyée au service de spouleur d’impression (local ou distant), les données seront (à nouveau) transférées à un pilote d’imprimante installé localement (qui peut être local le le serveur XenApp ou la machine virtuelle VDI, par exemple, ou à distance sur le serveur d'impression) restituent les données (si nécessaire), ce qui les transformera en travail d'impression réel avant de les renvoyer au service de spouleur d'impression.

Au cours de cette phase, il déterminera également si l’imprimante cible est connectée localement ou à distance via un serveur d’impression avant de la renvoyer au périphérique d’impression physique – une différence distincte entre les deux, EMF et XPS.

Fait FMA: Le balisage dans le fichier de spoule XPS décrivant les documents XPS est compatible avec le balisage XAML (Extensible Application Markup Language) dans Windows Presentation Foundation (WPF). Par conséquent, les documents décrits dans le fichier de spool XPS peuvent être restitués de manière native dans WPF sans perte de données ou de fidélité, car aucune conversion n'est nécessaire.

Impression en différé

Le processus où la sortie d’impression de l’application est reçue par le service de spouleur (il interprète les fichiers EMF et peut insérer des informations de mise en page et des instructions de contrôle des tâches dans le flux de données, dans le cas de GDI / EMF), qui les transfère à un serveur d’impression. pilote, en le rendant dans un travail d’impression, avant de le renvoyer au service de spouleur, sur le périphérique d’impression physique, est ce que nous appelons spoulage d’impression. Bien sûr, cela reste un peu élevé, mais cela vous donne une bonne idée de ce qui se passe sous le capot.

Mise en file d'attente d'impression locale et à distance

Lorsque, du point de vue du client, le spoulage d’impression a lieu localement, les ressources de calcul locales sont utilisées (processeur et mémoire). Sur un PC avec une imprimante connectée localement, le spouleur sera local sur le client. Lorsque ce même PC utilise une imprimante fournie par le réseau et connectée via un serveur d'impression, la mise en file d'attente a lieu à distance sur le serveur d'impression. Elle consomme donc des ressources distantes sur le serveur d'impression. Un autre exemple serait lorsque nous avons une session active sur un serveur XenApp. Ici, nous pourrions également avoir une imprimante fournie par le réseau, ce qui signifie que, du point de vue du client, le spouleur aura également lieu à distance sur un serveur d'impression, comme illustré dans l'image ci-dessous.

Lorsque la mise en file d'attente est effectuée à distance, non seulement les ressources de calcul distantes du serveur d'impression seront utilisées, mais également une certaine quantité de trafic réseau entre le client (qui peut être un serveur XenApp) et le serveur d'impression avec chaque travail d'impression. Les deux doivent être pris en compte lors du dimensionnement de votre configuration d'architecture d'impression. Contrairement à la mise en file d'attente distante, la mise en file d'attente locale n'utilise aucune ressource réseau.

Même dans un environnement non Citrix, si un réseau WAN a une latence importante, les utilisateurs auront une expérience utilisateur médiocre si les travaux d'impression sont spoulés à distance sur le réseau WAN. Toutefois, dans certaines situations, par exemple lorsque les ressources de l'ordinateur local sont nécessaires à d'autres tâches, la mise en file d'attente distante est préférable. En spooling à distance, le travail d'impression est traité sur le serveur d'impression, qui le décharge de l'ordinateur local.

Un peu d'histoire

Si nous regardons dans le passé, et peut-être même aujourd’hui, la plupart des problèmes d’impression étaient liés à des pilotes d’impression mal écrits – environ 80 à 90% même. Ils n'étaient (sont) pas optimisés pour les environnements multi-utilisateurs; non testé ou signé; les services se bloqueraient (spouleur et Citrix Print Manager); des écrans bleus apparaîtront; la création automatique d'imprimantes échouerait; nous aurions des charges de processeur élevées; etc.

À l'époque de Windows NT, nous n'avions que des pilotes en mode noyau version 2. Il n’est pas difficile d’imaginer ce qui s’est passé si l’un de ces conducteurs a mal tourné. Vous perdriez simplement tout le système et tout ce qu'il contient. Heureusement, avec Windows 2000, les pilotes en mode utilisateur de la version 3 sont encore largement utilisés.

Les pilotes d’impression de la troisième version s’exécutent en mode utilisateur. Par conséquent, l’éventualité d’un problème avec l’un de ces pilotes n’affectera pas le noyau du système. Bien que, dans certains cas, cela puisse toujours rendre le serveur inutilisable, l'impact est moins important qu'avec les pilotes en mode noyau.

Avec Windows Server 2008 R2, Microsoft a introduit un mécanisme qui bloque automatiquement l’installation des pilotes en mode noyau de la version 2: c’est une bonne chose. Ils ont également ajouté une fonctionnalité nommée Isolation du pilote d’impression, qui peut faire exactement ce que son nom implique: isolez vos pilotes d’impression. Isolation du pilote d’impression, existe en trois modes distincts: Aucun, Partagé et Isolé.

Isolation du pilote d'impression

Avec le mode Aucun (qui sera appliqué par défaut), rien ne change, tous les pilotes seront toujours en mesure d'interagir et, le cas échéant, il pourra quand même potentiellement faire tomber la machine entière ou la plus grande partie de celle-ci.

En mode partagé, toutefois, nous pouvons regrouper un certain nombre de pilotes d'impression et les laisser s'exécuter dans un processus complètement séparé de tous les autres pilotes d'impression, y compris le spouleur d'impression et le service de gestion d'impression CTX. Ces pilotes d’impression s’exécuteront de manière isolée dans le cadre du processus "PrintIsolationHost". Cela signifie également que, en cas de problème, seuls les pilotes de ce processus isolé seraient potentiellement affectés. De plus, étant donné qu’il fonctionne également séparément du service de spouleur et du service de gestion d’impression CTX, il n’a aucune incidence sur les autres utilisateurs du même système.

Les mêmes règles s’appliquent au mode Isolé, c’est là que la partie isolation sera utilisée pour chaque pilote d’impression. Pour chaque pilote d’imprimante, un processus ‘PrintIsolationHost’ distinct sera créé et s’exécutera séparément de tous les autres pilotes et services mentionnés ci-dessus.

Lors de l’isolation de plusieurs pilotes d’impression sur une base individuelle, c’est-à-dire un processus ‘PrintIsolationHost’ distinct par pilote d’impression, davantage de ressources locales seront consommées et donc nécessaires (processeur et mémoire), ce dont vous devez tenir compte avant de les implémenter. En outre, et il ne s'agit pas que de moi, vous voudrez peut-être réfléchir à la raison pour laquelle un pilote d'imprimante particulier doit être isolé de tous les autres, et s'il vaut la peine de l'implémenter dans votre environnement de production – Imprimer l'isolation de pilote est souvent utilisée à des fins de dépannage et de test.

Fait FMA: Il est peut-être préférable d'utiliser les modes Aucun et Partagé en production et d'utiliser Isolé à des fins de dépannage uniquement, ce qui bien sûr pourrait s'appliquer à la production également, que temporairement.

Pilotes d'imprimante version 4

Depuis Windows Server 2012, nous disposons également de pilotes en mode 4, qui sont des pilotes d'impression basés sur l'utilisateur et peuvent également être isolés. Tout ce qui précède s'applique ici aussi. Ils sont conçus pour gérer les applications de style métropolitain plus modernes et sont exclusivement basés sur le format de fichier d'impression XPS. Ils sont supposés supporter un plus grand nombre de types d’imprimantes différents; ils sont plus stables, prennent en charge le partage d’imprimantes amélioré et devraient être beaucoup plus faciles à installer et à entretenir.

Service de gestion d'impression Citrix

Le service de gestion de l'impression a été introduit pour la première fois en 2005, à peu près à la même époque que le pilote d'impression universel basé sur EMF. Il a de multiples responsabilités, capacités et gère différentes tâches relatives au processus d'impression CTX. D'une part, il communique directement avec le service Spouleur d'impression, comme vous pouvez le voir sur l'image ci-dessous.

Il peut communiquer avec le client ICA installé localement en cas de besoin (lorsque le chemin d'impression du client est utilisé, ce qui sera expliqué également) et compresse les données avant leur envoi sur le canal ICA. Il est responsable du canal virtuel ICA pour le mappage / la création d'imprimantes clientes au sein de votre session CTX. Ce qu'il est bon de savoir lors du dépannage de la création automatique d'échecs d'imprimante.

Qu'est-ce qui ne va pas aujourd'hui?

Maintenant que nous avons parlé de certaines des spécificités de l’impression (Microsoft) qui entrent en jeu lorsqu’il s’agit d’imprimer dans un environnement orienté Citrix, qu’est-ce qui ne va pas aujourd’hui en matière d’impression Citrix? Eh bien, pour être honnête, peu de choses ont changé. Nous devons encore faire face à des problèmes d'ouverture de session et d'impression, de services qui tombent en panne, d'écrans bleus, de pointes de processeur, d'échecs de création automatique, etc. Et si nous pouvons relier ces types de problèmes à l’impression Citrix (puisqu’il peut y avoir des dizaines de raisons pour lesquelles tout cela peut arriver), c’est toujours dans la plupart des cas à cause de pilotes d’impression défectueux et de configurations d’architecture mal conçues. Par conséquent, assurez-vous de bien comprendre comment le trafic d'impression circule dans votre environnement, quels composants sont impliqués, afin de tester vos pilotes d'impression lorsque l'UPD ne vous suffit pas (même lorsqu'ils sont signés et approuvés par Citrix, par exemple), puis appliquez l'isolation logique.

Les chemins d'impression Citrix

Un chemin d'impression définit comment le trafic d'impression peut être ou sera acheminé dans votre environnement. Il nous indique également où un travail est traité, spoulé, etc. En fonction des types de terminaux que nous utilisons, de la manière dont nous configurons les imprimantes, y compris de la configuration physique de notre XenApp, des serveurs d'impression et des périphériques d'impression physiques, nous pouvons en partie influencer la manière dont le trafic d'impression sera routé et l'utiliser à notre avantage. . Avant de passer en revue les deux chemins, le client et le réseau, je voudrais commencer par une configuration appelée imprimantes locales du serveur.

Imprimantes locales du serveur

La configuration d’une imprimante serveur locale n’est rien de plus que de connecter une imprimante physique directement à un serveur XenApp. Probablement une configuration que vous ne rencontrerez pas souvent, mais qui pourrait néanmoins être utile. Du point de vue du client, lorsqu’un document est imprimé, la mise en file d'attente est effectuée localement sur le serveur XenApp, en exploitant les ressources locales avant l'envoi de la sortie au périphérique d'impression.

Le chemin d'impression du client

Bien que vous disposiez de quelques options concernant la configuration du chemin d'impression client (nous y reviendrons dans un instant), la meilleure façon d'expliquer et d'illustrer son fonctionnement est de supposer que, sur le périphérique client de l'utilisateur, une imprimante connectée localement. a été configuré. Par défaut, aucun serveur d'impression n'est impliqué. La partie client fait référence au trafic d'impression généré sur le serveur Citrix (XenApp) qui est redirigé vers le périphérique client à partir duquel il sera transféré à l'imprimante physique.

C'est ce qui se passe… Un utilisateur aura une session sur le serveur Citrix (XenApp). Dès qu’il cliquera sur «imprimer», la sortie d’impression de l’application sera spoulée / restituée sur le serveur Citrix (transformée en un travail d’impression réel) avant de la renvoyer (via ICA) à la machine cliente. Du point de vue du client / utilisateur, cela signifie que la mise en file d'attente est effectuée localement, en exploitant à nouveau les ressources locales sur le serveur XenApp.

Ici, il est important de noter que le protocole Citrix Receiver / ICA est installé sur le périphérique client ainsi que sur le serveur Citrix (XenApp). Lorsque le travail d'impression spoulé est renvoyé du serveur Citrix (XenApp) vers le périphérique client, cette opération est effectuée à l'aide du protocole ICA / des canaux virtuels ou par le biais de ceux-ci. Les données envoyées peuvent ainsi être contrôlées, ce qui signifie compressées, limitées, etc. N'oubliez pas le service de gestion d'impression Citrix mentionné précédemment, c'est là qu'il entre en jeu. Ceci est très utile, en particulier lorsque le périphérique client et le serveur XenApp sont physiquement séparés. Voir l'image ci-dessous.

Fait FMA, ils ne pourront pas gérer et traiter localement les travaux d’impression mentionnés précédemment. De ce fait, le chemin d'impression client ne fonctionnera qu'avec les périphériques clients Windows (gros). Pensez à utiliser / tester Universal Print Server dans ces types de scénarios.

Notez également que, lorsqu'une imprimante connectée localement est configurée et que cela ne fonctionne à nouveau que sur un périphérique client Windows (gros), le chemin d'impression client est appliqué – ce qui signifie que la sortie / le travail d'impression de l'application sera toujours renvoyé au serveur. périphérique client.

Restez à l’écoute car nous avons quelques «cas d’utilisation» supplémentaires à discuter en ce qui concerne le chemin d’impression client.

La voie d'impression réseau

Lors de l'utilisation de périphériques d'impression fournis par le réseau (serveur d'impression) par défaut, Citrix essayera d'utiliser le chemin d'impression réseau chaque fois que cela sera possible. En tant qu'utilisateur, vous aurez une session active sur l'un des serveurs Citrix (XenApp). Cette fois, après avoir appuyé sur print, la sortie d'impression est envoyée au serveur d'impression (service spouleur) où elle sera spoulée / rendue dans un travail d'impression avant d'être envoyée au périphérique d'impression physique. Bien sûr, et cela s’applique également au chemin d’impression client, toutes les données seront acheminées en conséquence, selon qu’il s’agisse de solutions GDI / EMF ou XPS, comme indiqué précédemment.

Du point de vue du client, la mise en file d'attente aura lieu à distance, en exploitant les ressources distantes. Contrairement au chemin d'impression client, seul le serveur Citrix (XenApp) aura le protocole Receiver / ICA installé: le serveur d'impression ne sait pas comment et ne peut pas communiquer à l'aide du protocole ICA / des canaux virtuels. Par conséquent, tout le trafic envoyé entre le serveur XenApp et le serveur d'impression sera ingérable et donc non compressé. Lorsque le serveur XenApp et le serveur d'impression sont proches l'un de l'autre, le problème ne sera pas trop grave. Mais lorsque le serveur XenApp est dans le centre de données et que le serveur d'impression est proche des utilisateurs

Une autre chose à considérer est que le travail d'impression envoyé du serveur d'impression au périphérique d'impression physique sera également envoyé dans un état non compressé. Encore une fois, lorsque le serveur d’impression est situé près de vos utilisateurs, dans la succursale mentionnée ci-dessus, cela ne pose aucun problème. Toutefois, si le serveur d'impression est situé dans le centre de données, près du serveur XenApp, vous devez également surveiller de près.

Fait FMA: Vous voyez que ce n’est pas une chose, mais tout ce qui est combiné qui fait ou défait votre architecture d’impression: les types de points de terminaison que vous utilisez, les stratégies configurées, y compris l’emplacement physique de vos machines et de vos imprimantes.

C’est la même chose qu’avant, mais ici, j’ai dit «essayer». En effet, avec le chemin d’impression réseau, il existe plusieurs dépendances avant que le chemin d’impression réseau proprement dit puisse être utilisé. Par exemple, si le serveur Citrix (XenApp) et le serveur d'impression ne font pas partie du même domaine ou sont incapables de communiquer, le chemin d'impression client sera utilisé à la place du chemin d'impression réseau. N'oubliez pas que si cela se produit et que vous utilisez des clients légers, il est fort probable que l'impression ne sera pas possible.

Fait FMASi, pour une raison quelconque, le serveur Citrix (XenApp) et le serveur d'impression sont incapables de communiquer, le chemin d'impression client sera utilisé (forcé) à la place.

Maintenant, vous pensez peut-être que ce n’est pas si grave, car lorsque le chemin d’impression client est utilisé, mon trafic d’impression sera compressé car il utilisera le protocole ICA. Et, bien que cela puisse être vrai, cette approche peut également jouer contre vous, comme vous le découvrirez bientôt.

Forcer le chemin d'impression du client

Comme nous l'avons vu, lorsque Citrix est impliqué et que vous utilisez des imprimantes fournies par le réseau, il essaiera toujours d'utiliser d'abord le chemin d'impression réseau. Cependant, il peut arriver que, même si un serveur d'impression est impliqué, vous préférez utiliser le chemin d'impression client à la place.

Supposons que votre serveur Citrix (XenApp) se trouve dans le centre de données et que le serveur d’impression se trouve à proximité de vos utilisateurs, comme je l’ai déjà mentionné à plusieurs reprises. Etant donné que le trafic envoyé entre les deux sera non géré / non compressé, vous devez faire attention à ce type de configuration, en particulier lorsque la succursale et le centre de données sont séparés géographiquement.

Ce que nous pouvons faire ici, c’est forcer le système à utiliser le chemin d’impression client au lieu du chemin d’impression réseau en désactivant la stratégie ‘Connexion directe au serveur d’impression '. En désactivant cette stratégie, tout le trafic sera acheminé par défaut via le chemin d'impression du client. Intéressant, non?

Désormais, au lieu d’envoyer la sortie d’impression de l’application au serveur d’impression, elle sera tout d’abord renvoyée au périphérique client par le canal ICA, ce qui la rendra gérable (compressée) à partir de laquelle elle sera transférée au serveur d’impression, lequel prendra le relais à partir de là. Et puisque ces trois clients, le client, le serveur d'impression et le périphérique d'impression physique sont tous proches, cette approche sera beaucoup plus efficace, comme vous pouvez le constater dans l'aperçu ci-dessous.

L'exception à la règle…

Et il y en a toujours. Lorsque le serveur d'impression est de retour dans le centre de données, comme indiqué et illustré dans l'un de mes exemples précédents, cette configuration, qui utilise le chemin d'impression client, ne fera qu'aggraver les choses. Regardez l'image ci-dessous.

Imaginez que vous ayez une session sur le serveur Citrix (XenApp). Vous cliquez sur ‘Imprimer’. Tout d’abord, la sortie imprimée sera renvoyée vers le périphérique client, via ICA, compressée, etc. À partir de là, il doit se rendre sur le serveur d'impression et, puisqu'il se trouve dans le centre de données, il devra à nouveau traverser le réseau étendu. Plus important encore, il le fera dans un état non compressé. Enfin, une fois rendu, le travail d'impression doit être envoyé au périphérique d'impression physique dans la succursale. Encore une fois, générer du trafic non compressé sur la ligne. Vous pouvez voir l'inefficacité, non? Essayez d'éviter cette configuration / configuration.

Transport adaptatif

A partir de la version 7.13 de XenDesktop, Adaptive Transport, également appelé transport de données Enlightened, ou EDT, est disponible à des fins de production. EDT fait référence à la stratégie qui doit être configurée pour activer le transport adaptatif. Cette nouvelle couche de transport au-dessus du protocole UDP améliore le débit de données pour tous les canaux virtuels ICA, y compris l'impression. Il optimise le trafic de données en appliquant un nouveau protocole Citrix appelé EDT (Enlightened Data Transport) de préférence à TCP, mais avec un retour en arrière à TCP lorsque UPD n'est pas disponible, quelle qu'en soit la raison.

Le portefeuille universel

Le «portefeuille universel» comprend le serveur d’impression universel, le pilote d’impression universel et l’imprimante peut-être moins connue. Commençons par Universal Print Server. Si vous repensez à mon exemple de chemin d'impression réseau où le serveur d'impression était situé dans la succursale et le serveur Citrix (XenApp) dans le centre de données, vous vous souviendrez probablement que le trafic envoyé du serveur XenApp au serveur d'impression était non compressé. Etat. Universal Print Server peut nous aider à compresser ces données.

Le serveur d'impression universel

Outre la compression, il est optimisé pour les scénarios d'impression en réseau et fonctionne également avec les clients légers et les tablettes (basés sur Linux). Il prend en charge les formats de fichier d'impression EMF ainsi que XPF et utilise le pilote d'impression universel (UPD), qui peut être couplé / combiné avec un nombre quelconque de pilotes d'impression natifs – lorsque cela est nécessaire pour des fonctionnalités d'impression plus avancées, par exemple – voir la section sur l'UPD aussi.

L'Universal Print Server (UPS) est constitué d'un serveur et d'un composant client. le composant serveur est installé sur le serveur d'impression. Insérez le DVD dans le lecteur ou montez le fichier ISO. Une fois le programme d'installation lancé et après avoir sélectionné XenApp ou XenDesktop sur la première page, vous pouvez sélectionner Universal Printer Server pour l'installation (UpsServer). L'onduleur composante client est installé sur le serveur XenApp / XenDesktop / la machine virtuelle VDI et peut être trouvé dans le cadre du package d'installation VDA autonome (extractable).

le composant serveur Citrix Universal Print Driver est installé avec VDA XenApp ou XenDesktop et inclut (également) les pilotes suivants: Citrix Universal Printer (pilote EMF) et Citrix XPS Universal Printer (pilote XPS) pour une utilisation avec Universal Printer – discuté plus en détail quelques paragraphes plus bas.

le composante client Citrix UPD est installé avec Citrix Receiver. Il récupère le flux d'impression entrant pour la session XenApp ou XenDesktop et le transmet au sous-système d'impression local d'Universal Print Server (l'onduleur ne prend pas en charge le rendu côté client) où le travail d'impression est rendu à l'aide des pilotes d'imprimante spécifiques au périphérique. Universal Print Server est pris en charge sur Windows Server 2016, 2012 R2 ainsi que Windows Server 2008 R2 et requiert Microsoft Visual C ++ 2013 Runtime, 32 et 64 bits.

En termes simples, c'est ce qui se passe. Après avoir cliqué sur «Imprimer», l’application génère une forme de sortie d’impression (EMF / XPS) qui sera transmise au sous-système d’impression (Windows) local (Windows) sur le serveur XenApp. Notez que s’il s’agit de données EMF, le GDI restera entre les deux pour faire sa magie – voir aussi l’image ci-dessus.

Universal Print Server ne prenant en charge aucune forme de rendu côté client, la sortie d’impression est directement envoyée au composant Citrix UPClient comme indiqué précédemment dans le composant UPServer (au lieu de l’envoyer directement au service de spouleur du serveur d’impression). partie où les données d'impression peuvent être compressées. Enfin, le sous-système d’impression Windows sur le serveur d’impression (universel) le gérera (restituera, spoulera) à partir de là.

Notez que le serveur d’impression universel sera désactivé par défaut. Il doit être activé via une stratégie – configurez la stratégie «Activer le serveur d’impression universel». Bien qu'il fonctionne avec l'UPD par défaut, s'il est associé à un ou plusieurs pilotes d'imprimante natifs, il essaiera d'utiliser le pilote d'imprimante natif Windows en premier. Si un fichier correct n'est pas disponible, il utilisera l'UPD à la place, bien sûr, vous pouvez le configurer pour qu'il l'utilise également tout de suite. Toutes les imprimantes réseau configurées exploiteront automatiquement l’onduleur au moyen d’une méthode appelée détection automatique.

Prêt pour la grande ligue

Historiquement, le serveur d’impression universel (UPS) Citrix associé au pilote d’impression universel Citrix (UPD – reportez-vous à la section ci-dessous) a longtemps été considéré (de préférence) comme adapté aux petites et moyennes entreprises, où l’impression était importante, mais non critique pour l'entreprise. voir. One of the (main) reasons for this was that before version 7.9 the UPS was a single point of failure. There was no way to setup and configure multiple print servers and apply HA and/or Load balancing.

Luckily that all changed with the introduction of XenDesktop and XenApp 7.9. Today we do have the option to configure multiple Universal Print Servers in an LB and/or HA set up, sweet, right? Note that you will have to be on a Current Release (no LTSR – 7.6 at the time of writing) version to be able to make use of this functionality, since updating your base XenDesktop/XenApp opponents will be necessary, VDA’s included.

UPS load balancing in more detail

This is (roughly) how it works. At login time, session (network) printers are mapped to different print servers. Each VDA has a separate (built-in) load balancer service responsible for distributing the print load to all configured print servers as part of the HA/LB setup, and policy. If one of the print servers should fail or become unresponsive for whatever reason (checks are performed periodically) and it does not respond within a certain (configurable) time frame, set to 180 seconds by default, it will be removed from the VDA load balancing scheme.

The load balancer service also has a fail-over mechanism built-in, which will make sure that any failed print connections will automatically be redistributed to the still healthy and active print servers. It is not HA as in active/passive, but as part of the load balancing policy.

For the above-mentioned functionality, you need to configure the following policies: ‘Universal Print Server for load balancing’ and ‘Universal Print Server out-of-service threshold.’ The latter (see above as well) is to configure a default time-out value after which a failed, or unresponsive print server is permanently offline and thus cannot be recovered within the specified amount of time; the earlier mentioned 180 seconds by default.

Checks and validation

As mentioned, checks between the VDAs and the print servers are performed periodically to see if they, the print servers, are online and active. When a VDA is unable to establish a network connection to one of the print servers, or if a print server fails to respond to PING messages it is considered down and/or unresponsive.

This is also where the above mentioned ‘Out-of-service threshold’ policy comes in. If the print server does not respond within the time-out window configured as part of this policy, it will be considered permanently offline, and it will be removed from the load-balancing scheme part of the VDA, as highlighted earlier. The PING interval is configurable through a registry key (not sure which one), no policy just yet.

When configuring a UPS load balance policy, as shown above, you also have the option to validate all print servers involved manually. After clicking the ‘Validate servers’ button the configured print servers are first queried for their printing queue names, which will be verified on the Delivery Controller as part of the Load Balance policy or on the VDA when the Citrix Management Service starts.

It will check to see if all servers are indeed print servers and if they are configured identically. Citrix recommends configuring each print server identically to optimize the printer creation time as part the XA and/or XD session. Again, this is just a validation, nothing more. Besides an event log entry, no other action is taken.

Proximity printing

Additionally, when the Universal Print Server is used, you can configure a feature named ‘proximity printing,’ which is based on session (network) printers. With proximity printing, session printer policies are filtered on IP address or subnet: based on your IP address or the subnet that you are in, specific printers, within the same range can/will be assigned. This way, your users will always have the printer that is closest – when configured correctly, of course.

Proximity printing cannot be used without the Universal Print Server. As stated, proximity printing works with session printers. Session printers are network printers that can be assigned and mapped to a specific user or user groups. Since these types of printers will generate a certain amount of network traffic, you’d do good to only use and configure them on fast (er) networks.

Printing and the CEIP

When you install and configure the Universal Print Server, or multiple as part of an LB/HA setup, you will automatically be enrolled in the Citrix Experience Improvement Program (CEIP). While this is nothing to worry about, it’s still worth a mention so you, as a customer know what is going on. In fact, I would encourage all customers to participate in the CEIP since all data send is unanimous, encrypted and only used by Citrix for analyses purposes – to improve their products. By the way, the first upload of data occurs after seven days from the date and time of installation, assuming you stay opt-in.

Since the customer is king, you always have a choice. While you are automatically opt-in, you can opt-out just as easy. To opt out of the CEIP (UPS specific) edit the registry key HKLMSoftwareCitrixUniversal Print ServerCEIPEnabled and set the DWORD value to 0. Change it back to 1 to opt-in again.

Always-On logging

If you would like to enable Always-On logging for the print server and printing subsystem on the VDA, you can do so by applying the following: to collate the logs as a ZIP for emailing, or to automatically upload logs to Citrix Insight Services, use the Start-TelemetryUpload PowerShell cmdlet.

FMA fact: Throughout the last couple of years’ multiple scalability and stability enhancement to the XenApp and XenDesktop printing subsystem have been made. As a result, the caching of printer data on the VDA for both network and directly attached client printers has improved and helps in optimizing the overall user experience and to reduce network traffic. Resource consumption on the UPS, and by the VDA have been reduced as well, think: the number and amount of threads, memory, and handles. Enhancements to multithreading algorithms make that the UPS is now capable of processing up 80+ print jobs per minute.

Stability enhancements

The health of the printing subsystem can be evaluated for the UPS and/or XenApp/XenDesktop VDA by leveraging performance counters exposed in PerfMon for both Client and network print devices.

The following got introduced as of XenApp and XenDesktop version 7.11: The Crash detection feature for all Citrix printing modules fully automates the detection of crashes, the generation of an associated crash dump file, and the safe and automatic upload of the crash dump files to the customer’s Citrix Insight Services (CIS) account. This results in higher product quality and faster fixes for customer-reported issues. I’m sure we’ll see similar functionality in Citrix Smart Check going forward since CIS will be slowly phased-out in the future, though I have no idea on how, when, etc. just an educated guess.

The Universal Print Driver

This one is well known and has been around for a while now. It’s primarily meant as a one driver to rule them all kind of scenario, but we all know that is near to impossible. It does do a good enough job in most cases, though. One of the biggest things missing, and the main reason why we use it combined with other native drivers is the lack of enhanced printing capabilities, which also differ per printer type, like ink-jet, laser, multi-functional’s, label printers and so on.

As mentioned throughout the Universal Print Server section as well, The UPD is build up out of two components, a client, and server component. The client component holds the print drivers and is installed as part of Citrix Receiver. The server component is installed as part of the XenApp/XenDesktop VDA and (also) includes the following drivers: Citrix Universal Printer (EMF driver) and the Citrix XPS Universal Printer (XPS driver) for use with the Universal Printer.

Both the XPS and EMF based Universal Print Driver (EMF is used by default, though this can be changed through policy) have been enhanced with a couple of more advanced printing features like stapling and print draw selection (next to sorting, which it already offered), including the ability to use secure PIN printing when available.

If the physical print device and the accompanying native print driver both support it, users can now select their paper draw of choice, next to that, the stapling of documents is also supported. The above functionalities, for both UPD’s, are available as XenDesktop version 7.12. You do need to enable the UPD since it will be disabled by default.

FMA fact: Enhanced print features can be used if the native driver makes them available using the Microsoft Print Capability technology. The native driver should use the standardized Print Schema Keywords in the Print Capabilities XML. If non-standard keywords are used, the advanced printing features will not be available using Citrix Universal print driver.

While the UPD can be used exclusively (give this a try if you can, it will save you a lot driver update and potential conflict issues) it can also be paired with Windows native print drivers, which might be needed because of more advanced features supported by the print device. With this type of set up, as an example, you can configure the system to first look for any native drivers that might be installed, before falling back to the UPD, or vice versa – By default, if a Windows-native driver is not available, the system falls back to the Universal print driver. The following print formats are supported by the UPD:

  • Enhanced Metafile Format (EMF), which is the default.
  • XML Paper Specification (XPS). The XPS driver uses XML, as discussed earlier.
  • Printer Command Language (PCL5cand PCL4).  PCL is a printing protocol developed originally by Hewlett-Packard for inkjet printers. It is used for printing basic text and graphics and is supported on most HP LaserJet and multifunctionals.
  • The Citrix PDF Universal Printer Driver generates PDF format files and enables printing to Citrix Receiver for HTML5 and Receiver for Chrome.
  • PostScript (PS). PostScript is a computer language that can be used for printing text and vector graphics. The driver is widely used in low-cost printers and multifunction peripherals.

The print driver on the Server OS or VDI VM and client device must match for printing to succeed. Here it is important to note that, while the print driver names might be the same, if the version numbers are different the print drivers will not be seen and thus treated as equal. Nice to know when troubleshooting these types of issues. You’ll read a bit more on this in the ‘How to speed things up, keep it clean and healthy’ section coming up shortly.

The Universal Printer

Typically, when a user logs in and successfully establishes a session on a Citrix (XenApp) server, no default printers, or all printers known to the client, will be mapped into the session (default behavior).

When you enable and configure the use of a Universal Printer, instead it will create a generic, or logical, print object at the beginning of the session. This means that no printer enumeration will take place at all, which will speed up the user login process. Potentially useful when the ‘Wait for printer to be created’ policy is used or when you need access to multiple printers, local & network.

This logical object is virtually mapped to the client’s default configured printer, although this can be set to any printer known to the client device. In the above example/image, the ‘Local 2’ printer is set as the default printer for the user (green), though in this case the ‘Network 1’ printer has been configured for use with the Universal Printer.

The Citrix Universal Printer is part the Universal Print Driver (UPD), which is installed as part of the XenApp and/or XenDesktop VDA and will only work with Windows based clients. As highlighted, the VDA installs the following drivers with Citrix UPD: Citrix Universal Printer (EMF driver) and the Citrix XPS Universal Printer (XPS driver). As a result, the Universal Printer will use the UPD as its default print driver.

How to speed things up, keep it clean and healthy

There are a couple of ways to speed up or improve Citrix printing, and additional (configurations) steps you can take to keep you printing architecture up to date, clean and healthy. Some steps are reasonably straightforward and obvious, while others might need some additional consideration and planning – like when editing the registry, for example.

  1. Configure and apply true QoS through Multi Stream ICA.
  2. Give the ICA virtual print channel a higher priority (be careful with this).
  3. Use the Universal Print Driver and configure:
    • Universal printing image compression limit. Defines maximum quality and minimum compression lever available for images printed with the UPD.
  4. Use the Universal Print Server for additional compression and QoS options.
    • Universal printing print quality limit.Specifies the maximum dots per inch (dpi) available for generating printed output in the session.
  5. We can allocate, limit and control print bandwidth/traffic through policies, which can then be applied per user or for the whole Site.
    • To prevent degradation/interference of other virtual channels, you can limit the bandwidth used by printing. By limiting the data transmission rate for printing, you make more bandwidth available in the HDX data stream for transmission of video, keystrokes, and mouse data.
    • ThePrinter redirection bandwidth limit percent setting limits the bandwidth available for printing to a percentage of the overall bandwidth available.
    • ThePrinter redirection bandwidth limit setting specifies the bandwidth available for printing in kilobits per second (kbps).
  6. We can configure session (network) printers. Here you specify a bunch of specific network printers (could be only one just as easily) to be mapped within a session and assign them to users. Use on fast (er) networks only.
  7. The XenApp server (as an example) will try to match the print driver (s) found on the client device. If the print driver cannot be found (remember that they must be named the same, version numbers included) the system will attempt to install a corresponding native driver from the Windows operating system. If the driver is not available in Windows, it will (try and) use the Citrix Universal Print Driver (it will need to be enabled for this to work). Configure the ‘Automatic installation of inbox printer drivers’ to change this behavior – keep things clean and manageable.
  8. In addition, think about implementing ‘printer driver mapping compatibility.’ Print driver mapping is useful in situations where the print driver on the client is named differently than the print driver on the server but offers the same functionality.
    • You can use wildcards. For example, to force all HP printers to use a particular driver, specifyHP* in the policy setting.
    • It can also be used/configured to create a whitelist: this way you can tell the XenApp server that it is ok to auto-install print drivers when not found on the system, but only if those drivers that are on the (white) list.
    • To ban a printer driver, select the driver name and choose the‘Do not create setting’.
    • Print driver mapping can also help to reduce the number of printer drivers needed/installed, minimizing the administrative overhead and potential print issues that come with it.
    • This way you can also instruct certain printers to make use of the Universal Print Driver, while others do not.
    • You can allow or restrict certain printers to be created with a specific driver.
  9. The Universal Printer helps eliminate printer enumeration while users log in. Other things you can configure include:
    • Configure desired image quality.
    • On top of the desired image quality, you can set bandwidth reduction by enabling heavyweight compression – without losing image quality.
    • Image and font caching.
  10. Make use of the client printing pathway where it makes sense. Sometimes, depending on the physical set up of your environment, and even when network printers are used on a fast-internal network, sending the print output back through the client device (making use of the ICA protocol) can help a great deal, performance wise.
  11. Printing preferences (user) and properties will be stored on the client device by default. If this is not supported, they will be kept in the user profile within the server Operating System. Configure the ‘Printer properties retention’ policy to change this. Again, you have multiple options. Citrix advises maintain the default settings.
  12. Map the default client printer only. By default, all printers known to the user’s device will be mapped as part of the session, this can take forever.
  13. Avoid upgrading print drivers. Always uninstall the old driver and install the new one. Keep your machines as ‘clean’ as possible.
  14. Limit the number of print drivers installed – less is more!
  15. Use ‘signed’ drivers exclusively and always thoroughly test your print architecture set-up, no matter how convinced you may be that it will work.
  16. The ‘simpler’ the print driver, the less traffic will be generated. Use vendor print drivers only when specific functionality is needed.
  17. Apply print driver isolation where it makes sense. Isolating multiple print drivers will demand more of the available local resources (CPU and memory).
  18. Only make use of version 3 and 4 printer drivers.
  19. To determine if a printer model is supported, contact the manufacturer or see the Citrix Ready product guide atcitrix.com/ready.
  20. Match the print server OS to that of the XenApp server OS.
  21. To obtain real-time information about printing bandwidth, use Citrix Director.
  22. All this, and this applies to all the other chapters in this document as well applies to XenApp as well as XenDesktop, and most isn’t IMA- or FMA-specific.

FMA fact: Remember that it isn’t just about the bandwidth exclusively. Make sure to check for congestion and latency.

Printing related troubleshooting and verification

Troubleshooting tools

Throughout the years, Citrix has released various troubleshooting tools specifically aimed at Citrix printing as well as print driver certification/verification and so on. In the below list, you’ll find that some are, as mentioned specifically meant to troubleshoot specific print issues while others provide general information on your XenApp and/or XenDesktop Site, which could assist in finding particular print issues as well.

  • Citrix Director: can be used to view real-time information on the bandwidth used by printing operations.
  • Print Detective: Print Detective is an information gathering utility that can be used for troubleshooting problems related to print drivers – CTX116474.
  • All-purpose troubleshooting tool: Run Citrix Scout from a single XenDesktop controller (DDC) or XenApp server to capture key data points and CDF traces for selected computers followed by a secure and reliable upload of the data package to Citrix Technical Support – CTX130147.
  • Citrix Printing Tool: Citrix Printing Tool 3.1 helps configuring and troubleshooting the Citrix Printing subsystem on XenApp and XenDesktop – CTX122962.
  • StressPrinters 1.3.2 for 32 bit and 64-bit platforms: This tool can be used to simulate multiple sessions auto-creating printers using the same printer driver – CTX109374.
  • UPD Finder: This program is a troubleshooting aid, and it does not modify the system. It calls standard Windows print spooler APIs to find the directories where the Citrix Universal Printer Driver is installed – CTX141351.
  • UPS Print Driver Certification Tool: The Citrix UPS Print Driver Certification Tool can be used to test the compatibility of a print driver with the Citrix Universal Print Server – CTX142119.
  • All-purpose troubleshooting tool: proactively run Citrix Smart Check to verify the general health of your environment and any patches, and so on that might be missing.
  • Crash Detection Feature: the generation of an associated crash dump file, and the safe and automatic upload of the crash dump files to the customer’s Citrix Insight Services (CIS) account. This results in higher product quality and faster fixes for customer-reported issues
  • PerfMon: The health of the printing subsystem can be evaluated for the UPS and/or XenApp/XenDesktop VDA by leveraging performance counters exposed in PerfMon for both Client and network print devices.
  • Event Viewer: Do NOT forget about this one. In fact, this is probably the best place to start your troubleshooting quest.
  • Citrix Health Assistant: Focuses on VDA registration issues for both XenDesktop and XenApp. A series of health checks will be run in an automated fashion to identify any potential root causes for common VDA registration issues. It is a GUI based tool but also supports the use of command line commands – CTX207624.

General troubleshooting tips and tricks

When it comes to troubleshooting our XenDesktop and/or XenApp environments, printing architectures included there are a lot of (free) tools that can be of assistance. Some are aimed at solving specific issues, while other tools are more generic and can be helpful in multiple ways – as we’ve seen in the above-mentioned list as well. However, while this is all great, I do think that a lot of IT administrators forget about the basics: you need to know and understand the products that you are working with before anything else, here’s my list of things to think about when it comes to troubleshooting, and note that these bullets apply to all sorts of technologies/products, not just Citrix:

  • You need to understand the architecture you are dealing with: the FMA, its main components and services, communication paths, and so on. Including the printing pathways, the UPS/UPD set up, architecture and traffic flow.
  • Expected behavior and interaction: how does it all work under ‘normal’ circumstances? One of the main reasons why I came up with this paper as well.
  • Assemble a personal tool kit. As mentioned, we have a lot of instruments at our disposal, see the above list as well: sometimes it can be hard to find out what the exact purpose of a tool is or how it should be operated. By doing some research beforehand, this will potentially save you valuable time when things do go wrong. And we all know this is going to happen sooner or later, right? In other words: prepare at times of ‘peace.’
  • Know where to find information. This may sound a bit silly, but it doesn’t hurt to go over some of the options you have when it comes to finding useful information. Which forums do you visit? Think about (ex-)colleagues or community folks you can contact. Perhaps make yourself a top 10 of blog authors and so on. Give this some thought. And don’t forget about social media.

Conclusion

While from a print architectural point of view not that much has changed throughout the years, like the printing pathways, for example, it still does tend to confuse a lot of people. Hopefully, this guide/cheat sheet has helped in clearing up one or two questions you might have had regarding the Citrix print portfolio. I really enjoyed putting in the research needed to come up with this. It doesn’t make me an expert, but I do like to think that this paper holds some valuable information, which goes beyond the basics – hopefully, you agree. If you feel I left anything out or perhaps explained incorrectly, please do let me know. I’m here to learn as well. As always, thank you for reading.

Bas van Kaam

Bas van Kaam
IT pro by day, analyst by night @ Salomon

Father of Julia, Sophie, and Mex. IT professional, freelance/independent blogger/analyst, author of the book: Inside Citrix – The FlexCast Management Architecture, over 300 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant, in constant doubt between Windows and Mac.

<! –

->

Commentaires

Laisser un commentaire

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