Citrix Printer Driver replication Issues on PS 4.5/XenApp 5

Citrix has a feature called Printer Driver Replication. This feature is accessible from the XenApp Advanced Configuration.

Printer driver replication is designed to replicate printer driver files and registry settings across the server farm. You can install all required printer drivers on one PS/XenApp server in the farm and then replicate the files and registry settings to all other servers in the farm.

Printer driver replication does not replicate printer properties such as paper size, print quality, and so on

Managing the Printer Driver Replication Queue

Each printer driver/server combination creates an item in the printer replication queue. A old Citrix article (circa 2004) specifies that this queue must not exceed 1,500 entries in length. To determine the queue size, use the following formula:
QueueSize = Drivers * Servers
Drivers = Number of printer drivers
Servers = Number of servers to which the printer drivers are being replicated
Using this formula, the queue can include 30 drivers for replication to 50 servers (30*50=1,500) or three drivers for replication to 500 servers (3*500=1,500) without exceeding the queue limit. As of 2012 these limits must be different, but I could not find any information from Citrix about the current limit of the Queue size.

You can monitor the replication queue items with the qprinter command.

The following command allows you to purge the Printer Driver Replication:

dscheck /full printers /purge_replications

The distribution jobs are deleted from the data store. The command searches for the DISTRIBUTION/DistributionJobs node and deletes all the subnodes under it.
• All the replication jobs are deleted from the database. The command searches for the following node: PrinterRoot/PrintrDrivers-Replication. Under this node, there is one separate subnode for each driver that is due to be replicated. Each one of these subnodes includes information about how many target servers should be considered for that driver replication and which ones they are. After you run the command, all these subnodes are deleted and no effective driver replication occurs.
The replication jobs are deleted at the farm level.

Note about the Distribution Subsystem: To monitor how busy the replicators are, IMA uses the distribution subsystem. The distribution subsystem monitors the load on the XenApp server that is replicating the print drivers while they are distributed across the server farm. If the subsystem detects that the server is becoming overloaded, it reduces the speed at which it sends the replication jobs. This can cause very large replication jobs to take several hours.

Citrix has a utility called DSDiag

DSDiag enumerates each context ID to determine if there is an excessive amount of records under a particular context ID. This is useful to identify if there are too many printers and printer drivers listed on your data store.

CTX articles used to create this post:

CTX103308 – DSView

CTX112510 – DSDiag

CTX071480 – Printer Management Concepts

CTX121060 – Best Practices for Replicating Printers in XenApp

CTX115933 – Failing Printer Driver Replication Process on Citrix Presentation Server 4.5 Servers

CTX107572 – Troubleshooting Tools for Citrix Environments

CTX774641 – Printer Driver Replication Fails for Certain Printer Drivers

CTX881017 – Troubleshooting Imported Network Print Servers with XenApp

Replicating Printer Drivers automatically


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: