Several decades ago, the idea of the paperless office was introduced to the business world. Since that time, we have made great strides toward digitizing documents, forms and other necessary papers. We’ve also seen the printer lose its spot in business as we’ve made this transition. Or have we?
You most likely still have at least one – if not multiple – printers to manage. And chances are you are using printers in a Citrix XenApp or XenDesktop environment to assign network-based printers to users via policies. You’re probably also running into scalability issues as more printing is being required by regulations, expansions and other reasons.
Traditionally, Citrix has supported individual instances of the Citrix Universal Print Server (UPS), leaving any HA configurations to be handled by Windows clustering, or NetScaler for more complicated mechanisms. You could have multiple Universal Print Servers in an environment; however, each printer policy assignment could only contain a single Universal Print Server for each printer queue.
UPS Load Balancing
With the recent release of Citrix XenApp and XenDesktop version 7.9 comes a brand-new feature to the existing Citrix UPS component: Print Server Load Balancing. In addition to Universal Print Server Load Balancing, improvements for increased print job scalability have been made to better serve large scale printing environments. This new feature along with the expanded scalability support provide enterprise with a more robust and effective printing solution.
To begin, let’s talk about UPS Load Balancing, what it offers and how to implement it. With this new feature, you can now have multiple standalone UPS instances acting in a “High Availability” manner, while providing a built-in method to allow printer connection distribution across available UPS instances. This allows multiple independent UPS instances to continuously provide printing capability while sharing the load and also handling cases of single or multiple failures of print servers. This now removes the single point of failure inherent in the previous versions of UPS.
Four new policies for load balancing
Implementation of the UPS Load Balancing feature is accomplished through four new Citrix Policies: two default registry entries and two included in the new 7.9 version of Citrix Studio. The two new Citrix Studio policies are: Universal Print Servers for load balancing and Universal Print Servers out-of-service threshold, while the registry entries modify PING interval behavior. These policies make changes to the HKLM sub tree of the registry of the XenApp and XenDesktop systems and are processed at system start. This prevents on-the-fly changes being made to the load balancing settings and all configurations need to be set prior to system startup.
UPS for load balancing policy
The UPS for load balancing policy is used to populate and verify the print servers to be used as part of load balancing. The print servers need to be consistently identified (either by hostname, FQDN, or IP address) across this and any other printer related policies (whether session or direct network printer mappings). An additional validation mechanism is available in this policy to verify that each server is available, and has an identical set of printers available. It should also be noted that any printer mappings need to be made using the same identification scheme for load balancing to work correctly for users.
UPS out-of-service threshold policy
Universal Print Servers out-of-service threshold policy specifies the timeout for an unresponsive actively used UPS to respond before being marked as offline in the load balancing list. This policy is set to 180s by default and can be adjusted higher or lower depending on your specific configuration and needs. This policy is used when a currently active UPS fails to fulfill a print request from the VDA. Upon this failure, a series of PINGs are made to the UPS in question for up to 180s before the UPS is marked as offline.
Two registry keys are prepopulated with default Maximum and Minimum values for the PING interval to be used as part of the out-of-service threshold. These registry keys are available to provide further granular control of the time-out behavior.
Value: DWORD : “UpsMinimumTimeIntervalBetweenPings”
Default: 30 seconds
Value: DWORD : ” UpsMaximumTimeIntervalBetweenPings”
Default: 180 seconds
How UPS load balancing works
Utilizing the above policies and registry keys, each VDA will be provided a list of available UPS instances that can be used for user printer connections. This also is what enables the load balancing and “HA” (failure detection) mechanisms to be utilized. In a default configuration, the actual time to mark an UPS as offline will be within the range of 180s minimum to 360s maximum. Depending on the type of VDA implementation, whether XenApp or XenDesktop, the load balancing mechanism will work in one of two ways:
- UPS load balancing with server-based VDAs
With multi-user server-based VDAs, the first user to create a session on a given machine will be assigned to a randomly selected UPS from the list of available print servers. Subsequent users will be assigned to an UPS from the list of available print servers based on the order they are provided in the policy setting and each server’s load relative to the other available servers. This is accomplished by a running set of counters that tracks the number of printer connections to each UPS (each UPS will have a counter for Active, Created, and Deleted connections). These counters help to more evenly distribute the printer connection load and are available for view through Windows built-in PerfMon interface. If a UPS fails, such that it is marked as offline, all current connections to that server are redistributed to the remaining actively available printers, and new connections are made based on the relative loading of the remaining active servers.
- UPS load balancing with desktop-based VDAs
In a desktop-based environment (VDI), each user session will be assigned to a randomly selected UPS from the list of available print servers. As there is only ever a single user per desktop VDA, there will only be a single connection at any time. The printer connection counters are also present in XenDesktop, but due to the single user nature they are utilized only for reference. If an UPS failure occurs, all current connections are redistributed to a random active server.
In both scenarios above, an UPS marked offline will not be available for use until it has recovered and responds to PING requests. If the server does come back online and is available, it will automatically be added back to the list of available printers and would receive preference for new connections. With VDI, the newly added server would be added back to the list to be randomly selected.
Double your scalability
Now that we know we can have multiple UPS instances setup (we’ve scaled to 16 UPS internally) and can fully utilize them all for connections, what else has improved and how can we use this new found feature? Previously, UPS could handle 50 concurrent active print jobs per minute. With XenApp and XenDesktop 7.9, UPS scalability has improved two-fold, to 100 concurrent active print jobs per minute.
So, let’s scale that up to 5 UPS instances and you can have a sustained concurrent active print rate of 500 print jobs per minute across all 5 servers. Need more? Try 1,000 concurrent active print jobs per minute across 10 UPS instances. Yes, UPS load balancing can and does scale linearly. This makes scaling and sizing for your environment a simple matter.
Ready to upgrade?
Have we enticed you to upgrade yet? Are you ready for this great new feature? If you’re still on the fence, stay tuned for Part 2 where we will show the results of actual tests with multiple UPS instances and thousands of users. You’ll see how well the load balancing works and what happens when server failure occurs.
Learn more about all of the new features in XenApp and XenDesktop 7.9!