Product Documentation

Understanding XenApp Printing

Apr 27, 2015

Managing printers in a XenApp environment is a multistage process. The cycle for managing printers on a farm requires that you:

  1. Design your printing configuration. This includes analyzing your business needs, your existing printing infrastructure, how your users and applications interact with printing today, and what a realistic printing management model would look like for your organization (that is, assessing that the administrative overhead of printing pathway you choose is realistic in your environment).
  2. Configure your printing environment, including creating the policies necessary to deploy your printing design.
  3. Test a pilot printing deployment before rolling it out to users.
  4. Maintain your Citrix printing environment, including updating policies when new employees or servers are added and maintaining drivers on your farm servers.
  5. Troubleshoot issues that may arise in your printing environment.
Before you begin planning your deployment, make sure that you understand these major concepts for printing in XenApp:
  • The concept of printer provisioning in a session and the two major types of provisioning (auto-created and self-provisioned). To understand these concepts, you need to understand, among other things, the difference between a printer, a printing device, and a printer driver.
  • How print jobs can be routed in XenApp.
  • The policies that you can create to manage drivers.

XenApp printing concepts build on Windows printing concepts. To configure and successfully manage printing in a Citrix environment, you must understand how Windows network and client printing works and how this translates into printing behavior in a Citrix environment.

Introduction to Windows Printing Concepts

Updated: 2015-05-08

This section provides a limited overview of basic printing concepts in a standard (non-Remote Desktop Services) Windows environment. However, Citrix recommends reviewing the Windows documentation about network printing, print servers, and Remote Desktop Services printing before learning about Citrix printing concepts.

In a Windows environment, you can either print from your computer to a locally attached desktop printer (for example, a printer on LPT1 or COM1) or you can print to a network printer that is managed by a print server.

This diagram shows how print jobs are spooled from the client device to a print server and then sent to the printing device in a Windows network.


Here are a few basic definitions:
Printing Device
In the context of this topic, the term printing device refers to the physical printer (that is, the hardware device to which you send print jobs).
Printers
The term printer refers to the software representation of a printing device. Computers must store information about printers so they can find and interact with printing devices. When you see printer icons in the Printers panel in the Control Panel, you are seeing the software representation of the printers. (You are not seeing the printer drivers.)

For clarity, the term printer object is sometimes used to denote the software representation of a printing device.

Printer driver
The printer driver is the software program that lets the computer communicate with this hardware device. This program converts the information to be printed to a language that the printing device can process. It also understands the device and job settings of the printing device and presents a user interface for users to configure these. In Windows systems, printer drivers are distinct from the software representation of printers.
Print job
When a user prints a document, the data sent to the printer is known as a print job. Jobs are queued to the printer in a specific sequence, which the print spooler controls. When this sequence appears, it is known as the print queue.
Print spooler
The spooler is the Windows service that manages printer objects, coordinates drivers, lets you create new printers, determines where print jobs are processed, and manages the scheduling of print jobs. The print spooler also determines if the printer prints each page as it receives it or if the printer waits until it receives all pages to print the job.

Typically, when a print job is spooled to a printer, the spooler loads documents into a buffer. The printing device then retrieves the print jobs from the buffer when it is ready to print the job. By storing the job, the computer can perform other operations while the printing occurs in the background.

Print queue
A sequential, prioritized list of the print jobs waiting to be printed. The spooler maintains this list for each printer object in the computer.
Print server
A computer that manages the communications between client devices and printers. In this context, the term print server refers to dedicated computers that are running a Windows server operating system and hosting x number of shared printers. Print servers provide client workstations with drivers they need to print and store files, or print jobs, in a print queue until the printer can print them. A print server is a remote print spooler.
Network printer
A shared printer object accessed through a network print server.

Local and Remote Print Job Spooling

Print job spooling is important because where print jobs are spooled to is where print jobs are processed. Processing location affects network traffic, resource utilization, and has additional implications in a XenApp context.

Print jobs can be spooled either locally or remotely. Typically, print jobs sent to locally attached printers are spooled locally, and jobs sent to network printers are spooled remotely.

Locally Spooled Print Jobs

When print jobs are spooled locally, the local Windows computer processes the job. The application creates a spooled print job; the local print spooler, aided by the printer driver, processes the print job, and sends the rendered output to the printing device.

In a Windows environment, when you print to a printer connected to your local computer (when print jobs are spooled locally), the printer drivers and settings are stored on the computer itself. A typical printing process for locally spooled print jobs is:

  1. The application tells the local spooler to create a print job and an associated spool file on the local computer.
  2. On the local computer, Windows writes the application’s drawing commands to the local spool file. This process of writing commands occurs repeatedly until the job is completely spooled.
  3. The local spooler processes the job with the printer driver in a process known as rendering.
  4. The local spooler delivers the rendered data to the printing device (for example, a locally attached printer).

Remotely Spooled Print Jobs

When print jobs are spooled remotely, the Windows print server processes the print job.

A typical printing process for remotely spooled print jobs is

  1. The application tells the remote spooler to create a print job on the print server and an associated spool file.
  2. On the local computer, Windows writes the application’s drawing commands to the remote spool file. This process of writing commands across the network occurs repeatedly until the job is completely spooled.
  3. The remote spooler processes the job with the printer driver in a process known as rendering.
  4. The print server delivers the rendered data to the printing device (typically a network printer).

Key Differences Between Remote and Local Spooling

Unlike remote spooling, local spooling does not use any network resources. Remote spooling requires that the local computer and the remote printer exchange many messages across the network. Even in a non-Citrix environment, if a WAN has substantial latency, users will have a poor user experience if the print jobs are spooled remotely across the WAN.

However, in some situations, for example when the resources on the local computer are needed for other tasks, remote spooling is preferable. In remote spooling, the print job is processed on the print server, which off-loads processing from the local computer.

XenApp Printing Concepts

Updated: 2015-04-30

In a XenApp environment, all printing is initiated (by the user) on the server. However, print jobs are not always sent directly from the server to the printing device. Instead, the print jobs can be redirected through the client device.

Because there is no persistent workspace for users in XenApp (when a session ends, the user’s workspace is deleted), all settings need to be rebuilt at the beginning of each session. As a result, each time a user starts a new session, XenApp must reprovision (recreate or restore) the printers available in a session.

When a user clicks Print, XenApp:
  • Determines what printers (that is, printer objects) to provide to the user. This is known as printer provisioning.
  • Restores the user’s printing preferences.
  • Determines which printer is the default for the session.

However, you can customize how XenApp performs these tasks by configuring options for printer provisioning, print job routing, printer property retention, and driver management. Settings for these options can affect the performance of printing in your environment and the user experience. For example, you can reduce the amount of latency when users print by choosing a method of provisioning that is appropriate for your network configuration.

As a result, understanding key printing concepts is critical when planning your printing configuration:
  • The difference between the client and network printing pathway and how this is not the same as local printers and network printers
  • The term printer provisioning, the types of printer provisioning (static and dynamic), printer autocreation, and user self-provisioning
  • Print job routing and when changing it can improve utilization
  • The basics of printer driver management

Overview of Client and Network Printing Pathways

An important concept in XenApp is the printing pathway. The term printing pathway encompasses both the path by which print jobs are routed and the location where print jobs are spooled. Both aspects of this concept are important. Routing affects network traffic. Spooling affects utilization of local resources on the device that processes the job.

In XenApp, print jobs can take two different printing pathways:
  • Network printing pathway
  • Client printing pathway

Network Printing Pathway

The term network printing pathway refers to print jobs that are routed from the farm server hosting the user’s session to a print server and spooled remotely.

This diagram shows a XenApp network printing example: Printing begins on the farm server hosting the user’s session (where the application is published and executing). XenApp routes the print job over a network connection to the network print server. The network print server then routes the print job to an associated network printing device.


When a print job is spooled remotely in a Windows environment, it uses this process:

  1. The application tells the remote spooler to create a print job and an associated spool file.
  2. The Windows Print Provider sends the spool file to the print server.
  3. The print server processes the spool file.
  4. The print server then sends the print job to the appropriate network printer.

Server Local Printers

The term server local printers refers to a configuration that uses the network printing pathway where printing devices are attached locally to a XenApp farm server. Server local printers are shared printing devices that are physically attached to a farm server.

Note: To use a locally attached printer as a server local printer in a XenApp farm, the printer must be shared; otherwise XenApp does not recognize it.

Server local printers are often a good choice for printing in small farm environments. However, server local printers are not used widely in enterprise environments because they require installing the printer drivers on each server in the farm and require additional resources on the XenApp server. Server local printers are managed and configured in the same ways as network printers.

This diagram shows a XenApp server local printing example: Printing begins on the farm server hosting the user’s session and is routed to a printing device attached locally to the server.


Client Printing Pathway

The term client printing pathway refers to print jobs that are routed over the ICA protocol through the client device to the printer (either a printer connected directly to the client device or connected through a print server) and spooled on the Citrix online plug-in.

When using the client printing pathway, a virtual printer is constructed in the session that redirects to the printer object on the client device. The client device, in turn, sends the print job to the printing device.

Importantly, because all processing occurs on the XenApp server, when users print a document from a published application, they are actually starting that print job on the XenApp server. These jobs are spooled locally on the XenApp server.

There are two different configurations of the client printing pathway: one for printers attached directly to the client device and another for network printers.

Locally Attached Client Printers

The simplest configuration is the one where the printer is attached directly to the client device. In this configuration, the application server sends the print job back to the client/client device. The client device then relays it to a locally attached printer.

This diagram shows a simplified XenApp client printing example: Printing begins on the server where the application is published. XenApp sends the print job over the connection to the client device. The client device then routes the print job to the printer connected locally to the client device.


When a print job is spooled to a client along the client printing pathway, it uses this process:

  1. The published application tells the local spooler on the server hosting the application (that is, the host server) to create a print job and an associated spool file on the host server.
  2. On the host server, Windows writes the application’s drawing commands to the local spool file. (This process of writing commands occurs repeatedly until the job is completely spooled.)
  3. The local spooler processes the job with the printer driver in a process known as rendering.
  4. The rendered data is delivered to the client device through the ICA protocol.
  5. The client device relays the print data to the client-side printing device (a locally attached printer in this example).

Client Printers on the Network

While client printers are often printers physically attached to client devices, they can also be printers on the network. In this case, print jobs are routed through the client device to the print server.

The process is the same as for printing to a local printing device through the client. However, instead of sending the job to the client device, the job is sent to the network print server.

This diagram shows client printing to a network printer: Printing begins on the server where the application is published. XenApp routes the print job over the connection to the client device. The client device then routes the print job over the network to the print server, which in turn routes the print job to the network printer.


When a print job is spooled to a network printer along the client printing pathway, it uses this process:

  1. The application server sends the print job to the client for processing.
  2. The client processes the spooled job and sends it to the Windows print server for processing.
  3. The Windows print server then sends the print job to the appropriate network printer.

Configuring XenApp to use the client printing pathway for network printing devices is useful when a print server is in a domain different from the farm servers (and the client devices have access to the print server’s domain). Using the client printing pathway lets application servers send print jobs over the ICA connection to access the printer through the client device.

Configuring the client printing pathway for network printing is useful for low bandwidth connections, such as WANs, that can benefit from the traffic compression that results from sending jobs over the ICA connection. The client printing pathway also lets you limit traffic or restrict bandwidth allocated for print jobs.

Provisioning Printers for Sessions

For a computer to process a print command, it needs both the required printer object and a printer driver. Because sessions are hosted in a virtual workspace instead of locally on a hard drive, printers and their drivers are not stored on the local computer. Instead, they are restored at logon or reconnect. The process by which XenApp makes printers available in a session is known as provisioning.

You can control printer provisioning and the way you configure it affects what printers users see in sessions and the speed of the printers.

There are two types of printer provisioning:
  • Static. Server local printers are provisioned only once, when you connect them to the farm server. After that, they are always created in sessions with the same properties and do not vary according to policies.
  • Dynamic. The printers that are available in a session are determined as the session is built. As a result, they can change according to changes to policies, changes in user location, and changes to the network (provided they are reflected in policies). When printers are provisioned dynamically, the printers that appear in a session are not predetermined and stored. Rather, the printers are assembled, based on policies, as the session is built.

Because provisioning static printers is relatively simple, this topic focuses on provisioning printers dynamically.

The two most common methods of dynamic printer provisioning are:

  • User provisioning
  • Autocreation

To control what printers users have in their sessions and ensure printers are available when users start their sessions, provision their printers through autocreation. If you do not want to specify (and administer) user printers, you can let users self-provision their printers.

If you choose, you can prevent printer autocreation and let users provision printers visible from their client device.

User Provisioning

You can allow users to add printers to their sessions on their own. Users can map client printers that are not autocreated by policy manually in a user session through the Windows Add Printer wizard on the server (in their sessions). If users have thin clients or cannot access their client devices, they can self-provision by running the ICA Client Printer Configuration tool (PrintCfg.exe). For users to self-provision with the utility, you must publish PrintCfg.exe on your farm.

Autocreation

The term autocreation refers to printers XenApp creates automatically, at the beginning of each session, based on what printers are configured on the client device and any policies that apply to the session.

By default, XenApp makes printers available in sessions by creating all printers configured on the client device automatically, including locally attached and network printers. After the user ends the session, the printers for that session are deleted. The next time a session starts, XenApp evaluates any policies for printer creation and enumerates the appropriate printers from the client device.

You can change the default autocreation policy settings to limit the number or type of printers that are auto-created. XenApp can auto-create:
  • Client redirected printers, including auto-created client printers and a Universal Printer
  • Network printers

There is maintenance associated with provisioning by printers by using client and network printer autocreation. When you add new printers, you need to update the autocreation list. Also, the drivers for these printers must be added to all servers on the farm; however, you can specify for XenApp to do this automatically.

This topic comprises:
  • Auto-creating client printing
  • Provisioning a Citrix Universal Printing solution
  • Auto-creating netwrok printing
  • Letting users provision their own printers

All of these provisioning methods use the client printing pathway except for auo-creating network printers, which uses the network printing pathway.

Auto-Creating Client Printers

Updated: 2013-12-11

The autocreation feature creates a list of printers that a user can use after logging on. When the user logs in, their print drivers will be installed and all printers returned in this list will be available for use.

XenApp can auto-create redirected client printers in two different ways:

  • By creating a one-to-one match with printers on the client device
  • By creating one generic printer, the Citrix Universal Printer, that represents all (or any) printers on the client device

In many environments, especially large ones, Citrix recommends that you auto-create only one default printer. Auto-creating a smaller number of printers creates less overhead on the server and is better for CPU utilization.

However, in environments where users with limited computer skills need to print to a wide variety of local printing devices, you may want to leave the default autocreation setting so that all printers are created on logon.

If you do not want large numbers of printers created at the beginning of each session, consider specifying for XenApp to use the Citrix Universal Printer.

Auto-Creating Printers from the Client Device

At the start of a session, XenApp auto-creates all printers on the client device by default. You can control what, if any, types of printers are provisioned to users and prevent autocreation entirely.

The Citrix policy setting Auto-create client printers lets you control autocreation and specify that:
  • All printers visible to the client device, including network and locally attached printers, are created automatically at the start of each session
  • All non-network printers physically attached to the client device are created automatically
  • Only the default printer for the client device is created automatically
  • No printers visible to the client device are created automatically
When configuring policies for printer autocreation, ensure:
  • User accounts are not shared
  • You add Microsoft native or fully tested drivers only
  • Users have write access on the server to %systemroot%\system32\spool

These points help ensure that printers auto-create successfully.

Provisioning a Citrix Universal Printing Solution

Citrix Universal printers and drivers are printing solutions that let users print regardless of whether or not they have the correct printers and drivers installed.

Universal printing solutions are printers and drivers not tied to any specific device. Consequently, they simplify administration by reducing the number of drivers required on farm servers or the number of printers created at the beginning of sessions. Because users need to access fewer printers and drivers, the speed of starting a session is increased and the complexity of printer administration is decreased.

XenApp includes two types of universal printing solutions:
  • Citrix Universal Printer. A generic printer object, replacing the printers that appear in the users Printers control panel during their session. This printer can be used with almost any printing device.
  • Citrix Universal Printer Drivers. Windows Native Printer drivers are generic drivers that work with almost any printer. These drivers also work with non-Windows clients. Citrix-created Universal printer drivers consist of the Citrix XPS Universal Printer driver and the EMF-based Citrix Universal Printer driver.
These printing solutions can be used in one of the following ways:
  • Auto-created device printer with Citrix Universal printer driver. A device-specific printer gets auto-created but uses a Citrix Universal printer driver. For example, configured policy rules specify that the printer LaserJet5L still gets auto-created at the beginning of each session; however, the session uses the Citrix Universal printer driver to communicate with the driver on the client device and the print job is processed on the client device.
  • Auto-created Citrix Universal Printer with a Citrix Universal printer driver. A Citrix Universal Printer gets auto-created and it uses a Citrix Universal printer driver. That is, at the beginning of each session, the only printer that is auto-created is the Citrix Universal Printer. Like the first example, the session uses the Citrix Universal printer driver to communicate with the driver on the client device and the print job is processed on the client device.
  • Auto-created device printers, auto-created Citrix Universal Printer with a Citrix Universal printer driver – At the beginning of the session, the Citrix Universal Printer and device-specific printers are auto-created. Both printers use the Citrix Universal printer driver.
Whether you use a Citrix Universal printing solution depends on various factors:
  • The Citrix Universal Printer and printer driver might not work for all client devices or plug-ins in your environment. The Citrix Universal Printer and printer driver solution requires the Citrix Online Plug-in or the Citrix Offline Plug-in.

    The Citrix Universal Printer does not work if plug-ins are not connecting through the ICA channel, such as when you are using the Citrix Offline Plug-in and streaming applications to the client.

    If you want to use a universal printing solution for non-Windows plug-ins, use one of the other universal printer drivers that are based on postscript/PCL and installed automatically with XenApp.

  • The Citrix Universal printer driver might also create smaller print jobs than older or less advanced printer drivers. However, sometimes it might be better to use a device-specific driver because the driver might be able to optimize print jobs for its associated printer.
Note: If you want the Citrix Universal Printer to appear in sessions, make sure that the Citrix policy setting Client printer names is not set to Legacy printer names in any policies affecting those sessions.

Universal printer drivers are installed by default on each farm server; the printer is not enabled, however. To get the best results when configuring your farm, use both the Citrix Universal Printer and a Citrix Universal printer driver.

Note: Citrix Universal Printing is available for Citrix Presentation Server Client, Version 9.x or Version 10.x, Citrix XenApp Plugin for Hosted Apps 11.0, the Citrix Online Plug-in, the Citrix XenApp Plug-in for Streamed Apps, and the Citrix Offline Plug-in. This feature is available in Presentation Server 4.0 to XenApp 6.
Citrix Universal Printer

The Citrix Universal Printer is a generic printer created at the beginning of sessions that can be used with almost any printing device. This printer can print to and communicate, through the client, with any client-side printer.

You may also want to use the Citrix Universal Printer because the printer name does not change when users reconnect. Changing printer names can cause problems for some applications.

The Citrix Universal Printer is created on a per-session basis. When used with a Citrix Universal Printer driver, it can greatly reduce the resource usage at the start of a session from printer autocreation. When you use the Universal Printer, you can specify that only the Universal Printer be auto-created for each printer on the client device.

When the Citrix Universal Printer is enabled, an extra printer is created in the session with the name Citrix UNIVERSAL Printer in session number of session. To use only the Citrix Universal Printer in sessions and not auto-create any printers on the client device, enable the Universal Printer through the registry and configure the Citrix policy setting Auto-create client printers to Do not auto-create client printers.

The user experience varies depending on the type of Citrix Universal Printer.

Because the Citrix Universal Printer is not tied to a specific printing device, both the EMF-based and XPS-based Citrix Universal Printers provide ways to preview and select settings:
  • EMF-based Citrix Universal Printer. The EMF-based Citrix Universal Printer can display a print preview before printing. If the Preview on client option is selected in the printer’s printing preferences, the user sees a preview of the print job and has the option of choosing a target printer and controlling print device setting. If the Preview on client option is not selected, no preview is displayed and print job is routed directly to the default printer on the user device.
  • XPS-based Citrix Universal Printer. Like Microsoft XPS Document Writer, the Citrix XPS Universal Printer sends documents to Internet Explorer if a user selects Print Preview or modifies the print settings, displaying them in Microsoft’s XPS “electronic paper” format.
Note: The Print Previewer cannot be controlled by the administrator unless users have the Citrix Presentation Server Client, Version 10.100 or later, the Citrix XenApp Plug-in for Hosted Apps, Version 11x, or the Citrix Online Plug-in.

Auto-Creating Network Printers

By default, any network printing devices on the client device are created automatically at the beginning of sessions. However, if possible, XenApp always tries to route jobs directly from XenApp to the print server and not through the client connection.

To specify that specific printers are created in sessions rather than auto-create all the network printing devices available from the client device, configure the Citrix policy setting Session printers.

Network printers created with the Session printers setting can vary according to conditions where the session was initiated, such as location (by filtering on objects such as subnets).

Note: For printers in domains that do not have a trust relationship with the XenApp farm, disable the Citrix policy setting Direct connections to print servers. When this setting is disabled, print jobs are routed through the client using the client printing pathway.

Letting Users Provision Their Own Printers

If you do not want specific printers to be auto-created at the beginning of each session, allow users to add their own printers.

By default, provided they can access the network from their client devices, all users can add printing devices to be used in a session. The only time users cannot add printers to their sessions is when they cannot access their client device because they are using a thin client and there are no applications published that let them browse and add printers.

Printers that users create on their own during a session are known as retained printers because they are created again (or remembered) at the start of the next session. When XenApp recreates a retained printer at the start of a session, it considers all Citrix policy settings except Auto-create client printers.

Retained printers appear in sessions on that device until the client printer within the session is deleted manually, the remembered printer connection is removed from the client’s properties store, or the client-side printer is inaccessible.

Users might need to use the PrintCfg.exe tool to add printers if they cannot browse to the printer from within the session or cannot access their client desktop. If they use this tool, the printers are routed along the client printing pathway.

Device or Session-Based Print Settings

By default, all changes users make to the printer device settings and preferences, whether in a session or working on their local computer, are saved and used locally and in a session. This means that printer settings and preferences are always the same on the client device and in a session. Citrix policy settings let you change the way XenApp software saves and applies printer device settings and preferences.

You can configure sessions to obtain print settings, specifically user printing preferences, from either the printer object or the printing device.

XenApp can write printer settings to the printer object at the end of a session or to a client printing device, provided the user’s network account has sufficient permissions. By default, XenApp plug-ins use the settings stored in the printer object in the session, before looking in other locations for settings and preferences.

The main reason you want sessions to obtain their print settings from the printing device is if Windows users make changes to local printers outside of sessions (that is, on their local computer offline). Non-Windows plug-ins synchronize changes made out of sessions automatically.

Device-Based Print Settings

Caution: Using Registry Editor incorrectly can cause serious problems that may require you to install your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

If you have Windows users with locally attached printers who work on applications locally and on the server, you might want to retain changes to the printer settings the users make locally outside of a session. To do so, create and set the Win32FavorRetainedPrinterSettings registry key to False, as described in To synchronize properties from the printer.

When the registry key is modified, the plug-in gives priority to settings from the printer, rather than retained settings. Settings in the session stay synchronized with settings on the printing device. If a change was made to the printer out of a session, the change is picked up. If a change is made to the printer inside the session, the plug-in attempts to write the change back to the printer on the client device when logging off.

You must have the same driver on the client device and server. If you do not, only a subset of settings is exchanged between the real printer and the virtual printer in the session. Some device independent settings are inherited and others are not.

Controlling Printing Settings and User Preferences

To understand how printing preferences are retained and applied, you must understand:
  • The locations printing settings can be stored in a XenApp environment
  • The priority XenApp software uses to apply printing preferences from previous sessions to the printers in a newly created session
  • Where XenApp software stores printing preferences by default and if there are factors in your environment that will prevent the software from successfully storing them in this location (that is, when you need to change this setting)
General Locations of Printing Preferences

In Windows printing environments, changes made to printing preferences can be stored on the local computer or in a document. In a XenApp environment, when users modify printing settings, the settings are stored in these locations:

  • On the client device itself. The settings are set on the client device by right-clicking the printer in the Control Panel and selecting Printing Preferences. For example, if Landscape is selected as page orientation, landscape is saved as the default page orientation preference for that printer. This type of preference is known as Device Settings.
  • Inside of a document. In word-processing and desktop-publishing programs, settings, such as page orientation, are often stored inside documents. These settings are often referred to as Document Settings. For example, when you queue a document to print, Microsoft Word typically stores the printing preferences you specified, such as page orientation and the printer name, inside the document. These settings appear by default the next time you print that document.
  • From changes a user made during a session. XenApp keeps only changes to the printing settings of an auto-created printer if the change was made in the the Control Panel in the session; that is, on the server.
  • On the server. These are the default settings associated with a particular printer driver on the server.

If you want to control user printing preferences, it is important to understand that the settings preserved in any Windows-based environment vary according to where the user made the changes. This also means that the printing settings that appear in one place, such as in a spreadsheet program, can be different than those in others, such as documents. As result, printing settings applied to a specific printer can change throughout a session.

Hierarchy of Users’ Printing Preferences

Because printing preferences can be stored in multiple places, XenApp processes them according to a specific priority. Also, it is important to note that Device Settings are treated distinctly from, and usually take precedence over, Document Settings.

XenApp searches for settings in this order:

  1. XenApp checks for retained printer settings.

    If XenApp finds retained settings, it applies these settings when the user prints.

  2. If there are no retained printer settings, XenApp searches for any changes to the printer settings for the default printer for the client device.

    If XenApp finds any changes to printing preferences on the client device, it applies these settings when the user prints.

  3. If there are no retained or client printer settings, XenApp applies the default printer settings stored on the server when the user prints.

At this point, the printer settings are merged. Generally, XenApp merges any retained settings and the settings inherited from the client device with the settings for the default printer driver on the server.

By default, XenApp always applies any printing settings a user modified during a session; that is, the retained settings, before considering any other settings.

Saving Users’ Printing Preferences

By default, XenApp attempts to store printing properties, a combination of the user’s printing preferences and printing device-specific settings, on the client device. If the client does not support this operation, XenApp stores printing properties in its user profile for that user. Sessions from non-Windows XenApp plug-ins or even older Windows XenApp plug-ins use the user profiles on the server for properties retention. You can use the Printer Properties Retention policy rule to force properties to be saved on either the client or on the server.

If one of the following apply, you might need to reconfigure how XenApp stores user printing preferences:

  • Client version. Not all XenApp plug-ins allow users to store printer properties on a client device. Users must be running Citrix Presentation Server Client 9.x and higher to store user-modified printer properties on the client device.
  • Type of Windows user profile. That is, if you are using local, roaming, or mandatory profiles on your Windows network.

    If you are using a mandatory profile and you want to retain the user’s printer properties, you must store the properties on the client device.

  • Farm Size. If you have a large farm and you are load balancing applications, users will experience inconsistent printing behavior and properties if you use local profiles. The only way you can get consistent printing behavior is to save the printer properties on the client device.
  • Type of workers. If you have mobile or remote workers and you are using roaming profiles, you must save the printer properties to the user’s profile and not the client device.

If none of these factors apply to you, Citrix recommends you not change where the printer properties are stored. Leaving the default setting, which saves the printer properties on the client device, is the easiest way to ensure consistent printing properties.

You can specify whether you want these settings stored on the client device or with the user’s profile. You can also change this default behavior so settings are not stored. However, before you make these decisions, you must understand how XenApp determines what print settings it applies and also what the difference is between storing print settings on the client device or with a profile.

Setting Default Printers

The printer that XenApp selects for a session’s default printer can be based on:

  • A network printer you specify as the default
  • The default printer on the client device

If you want to base the default session printer on either of these, use the Citrix policy setting Default printer. See To specify a default printer for a session for details.

However, if you specified that XenApp auto-create the default client printer, then, if no other printers are provisioned in sessions, you might not need to specify a default session printer.

Printing and Mobile Workers

In situations where users move among different workstations or sites, you can make sure that the closest printers are presented to them wherever they try to print. Examples of such users include hospital workers who move among workstations in different wings of a hospital, reconnecting to the same session using a smart card, or employees who travel to remote business units.

If you have mobile workers and need this type of printing functionality, use one of these features:

  • SmoothRoaming
  • Proximity Printing

SmoothRoaming

Also known as Workspace control, this feature lets a user disconnect from one session, move to another device, and reconnect to continue that same session. The printers assigned on the first client device are replaced on reconnection with the printers designated on the second client device. As a result, users are always presented with applicable printer options from wherever they connect.

Proximity Printing

This feature lets you control the assignment of network printers so that the most appropriate printer is presented, based on the location of the client device.

The Proximity Printing solution is enabled through the Citrix policy setting Default printer.

Proximity Printing can make administration easier even if you do not have mobile workers. For example, if a user moves from one department or floor to another, you do not need to assign additional printers to that user if Proximity Printing is implemented. When the workstation is recognized within the new location’s IP address range, it has access to all network printers within that range.

However, if you configure Proximity Printing, you must maintain the Session printer policy. For example, as network printers are added or removed, you must update this policy to reflect the current set of network printers. Likewise, if you modify the DHCP IP address ranges for floors or departments, you must update this policy.

Proximity Printing requires that you can filter the policy on some type of geographic indicator, such as:
  • The name of the workstation, if the name relates to the workstation’s location
  • Your network’s IP addresses, if they correlate with user locations

Optimizing Printing Performance by Routing

In a XenApp environment, you can control how print jobs destined for network printers are routed. Jobs can take two paths to a network printing device: along the client or network printing pathway.

By default, XenApp routes print jobs along the client printing pathway as follows:

  • Auto-created client printers. XenApp routes jobs to locally attached printers from the server, through the client, and then to the print device. The ICA protocol compresses the print job traffic. When a printing device is attached locally to the client device, the jobs must be routed through the plug-in.
  • Auto-created network printers. By default, all print jobs destined for network printers route from the server, across the network, and directly to the print server. However, if the application server and the print server are on different domains, XenApp automatically routes the print job through the plug-in.

When network printers are visible from the server, you can use policies to control how print jobs are routed to network printers. You can configure that jobs be routed to network printers:

  • Through the plug-in. This is accomplished by auto-creating the network printer but specifying its jobs to route through the plug-in.
  • Over the network. This is accomplished either by leaving the default settings so that the network printer is auto-created (or configuring a policy to do this) or by provisioning the network printer through the Session printers policy rule.

Routing jobs along the network printing pathway is ideal for fast local networks and when you want users to have the same user experience that they have on their local client device (that is, when you want the printer names to appear the same in every session).

However, print jobs relayed using the network printing pathway are not suited to WANs. The spooling of print jobs using the network printing pathway method uses more bandwidth than using the client pathway; many packets are exchanged between the host server and the print server. Consequently, users might experience latency while the print jobs are spooling over the WAN. Also, the print job traffic from the server to the print server is not compressed and is treated as regular network traffic.

When printing jobs across a network with limited bandwidth, Citrix recommends routing jobs through the client device so that the ICA protocol compresses the jobs. To do so, disable the Citrix policy setting Direct connections to print servers.

Managing Printer Drivers

During printer auto-creation, if XenApp detects a new local printer connected to a client device, it checks the server hosting the published application (from which the user is trying to print) for the required printer driver. By default, XenApp automatically installs a native driver if one is not found on the server hosting the published application.

Because users in a XenApp environment do not have a persistent workspace, drivers cannot be stored on the client. To print to a local device, XenApp must find the correct driver on: (a) its server or in the server’s Windows operating system, and (b) the client device. The diagram that follows shows how the printer driver is used in two places for client printing.

This diagram shows client printing to a local printer: The printer driver on the server routes the job over the ICA channel to the client device. The client device then routes the print job through the same printer driver, which is accessible on the client device. The printer driver on the client device relays the print job to the print spooler on the client device, which in turn routes the print job to the local printer.


The printer driver on the server and the driver used by the client device must match exactly. If not, printing fails. As a result, XenApp provides features to manage drivers, install them automatically, and replicate them across your farm.

The following problems can arise from not managing client printer drivers correctly:

  • Any missing drivers can prevent users from printing successfully. If a third-party printer driver has multiple or inconsistent names across your farm, a session might not be able to find it and a user’s job may fail to print.
  • Printing to a client printer with a defective driver can cause a fatal system error on a server.
  • XenApp does not download drivers, including printer drivers, from the print server. For XenApp servers to print across the network printing pathway, the correct device-specific printer driver for the XenApp server's operating system (version and bit depth) must be installed on the XenApp server. Two print servers are not required.
  • If a defective driver is replicated throughout a server farm, it is difficult and time consuming to remove it from every server to prevent its use with client printers.

When planning your driver management strategy, determine if you will support device-specific or the Universal Printing driver, or both.

If you support standard drivers, you also need to determine:
  • What types of drivers you want to support
  • If you want printer drivers automatically installed when they are missing on farm servers
  • If you want to create driver compatibility lists
  • If you want to replicate drivers across your farm servers automatically