Choose your language

Choose your login

Support

How can we help?

Lightbulb icon
Lightbulb icon

Here’s your answer

Sources:

Lightbulb icon

Oops!

We currently don’t have an answer for this and our teams are working on resolving the issue. If you still need help,
User reading a resource

Popular resources

Conversation bubbles

Contact us

Print Deploy VDI best practices

This page applies to:

While Virtual Desktop Infrastructures gain traction in all business sizes, PaperCut has recognized this trend by providing compatibility for print queue deployment and tracking via Print Deploy.

Managing print queues with VDI can be challenging, and over several years, PaperCut has worked with many companies utilizing various VDI platforms, particularly in print enablement. These companies range in verticals from Healthcare to Manufacturing to Finance. Therefore, we’ve learned quite a bit about the nuances of how these environments can be implemented, ultimately giving us some general “best practices” to share. We are certain there will be more learnings and will add them here as we discover them. Here are a few learnings we’d like to share in hopes it will help set you up for success.

Note: We will refer to 2 distinct versions of the Print Deploy Client:

  • Print Deploy Client for VDI - Print Deploy Client with VDI Support
  • Print Deploy “Classic” Client - Print Deploy Client without VDI Support

VDI session descriptions (Multi-Session, Single Session, and Persistence)

VDI Session deployments typically are delivered via a “Session Type”. There are two main session types and along with that, two main characteristics of what happens when a user logs off and, eventually, logs on again. Session types can be described as either “Multi-Session” or “Single-Session” You may hear other terms such as “Shared” or “Personal”, but for our descriptions here, we will use “Multi” or “Single” session types.

Another factor to consider is the idea of “Persistence”. Persistence can be a distinguishing characteristic with either type of session but can also affect driver deployment. Let’s examine the difference between Multi-Session and Single-Session and how “Persistence” affects print driver deployment:

Multi-Session vs. Single Session

The differences between these two types of sessions will dictate which Print Deploy Client will be necessary to support print queue deployment.

Multi-Session

This describes a VDI Session Type where a configured Desktop image can serve several users from the same instance at the same time. When each session is started with a logged-on user, variables are present, specific to each session. We use some of these session variables as “VDI Session Qualifiers” for the Print Deploy for VDI Client that is loaded on the Host Image(s). When the user logs on, the Print Deploy Client for VDI detects these ”Qualifiers” and if all the essential elements are present, will fetch and deploy print queues based on the Zone triggers set by the Print Deploy Administrator.

Single Session

This VDI session deployment is dedicated to a single user session at a time. It ultimately acts like a laptop or PC provisioned for a user. Although the Desktop can accommodate many user accounts assigned to it, only one user can log in to the Desktop at a time.

Persistent vs. Non-Persistent

Persistence relative to VDI describes the end user’s Desktop experience when a session is ended. This can affect Print Deploy’s need to redeploy print drivers for each new session.

Persistent Desktop

Persistent Desktop describes the behavior of the VDI Session after a User has signed off. With a “Persistent Desktop” experience, changes made to the Desktop Experience such as personalizations, saved files (vdisk), installed applications, and other items such as print drivers are kept intact when the user logs off.

Non-Persistent Desktop

Non-Persistent Desktop describes the behavior of the VDI Session where the Desktop is set back to a “baseline” configuration after the user logs off. In many cases, personalization is not allowed. Any applications installed, files saved, or print drivers loaded during that session would be lost when the user logs off.

VDI Multi-Session ‘Qualifiers’

Within Multi-Session VDI, Print Deploy Client for VDI looks for several main environmental “qualifiers” and records these in the Print Deploy Client for VDI log. When these “qualifiers” are present, the Print Deploy Client for VDI sees the session as legitimate and will deploy printers. If any of these qualifiers are missing or not what we expect, we will skip the session and therefore skip the fetch to install printers.

Note: Multi-Session VDI will have the qualifiers needed for the Print Deploy Client for VDI. Single-Session does not provide these qualifiers.

Qualifiers for VDI Based Sessions are as follows and can be found in the Print Deply Client for VDI logs:

  • “Client Name” - This is a VDI environmental variable used to identify the physical client. This could be a Thin OS Terminal, a PC or MAC, Chromebook or, Tablet. This is automatically used as the “Hostname” parameter for Print Deploy Zone Configuration.
  • “Domain Name” - Domain from which the user is logged on
  • “User Name” - Subject logged into the current Session. This subject must be present in the PaperCut Application Server
  • “SessionID” - should be a unique ID and normally counts up as new sessions are spawned from the HOST VDI Server(s). When a new session is started, the Print Deploy for VDI client will discover the new SessionID and log it.
  • “Client IP Address” - this is the actual endpoint IP Address of the client host serving the VDI Session. This could be a Thin Terminal, a PC/MAC, a Chromebook, or a Tablet. We utilize this address for Print Deploy Zone that triggers off of the Subnet element.
  • “isRemoteSession” - this element is important for Print Deploy to ascertain whether the session is run for a physical client and not directly on the VDI Server. For the session to be considered valid, we expect to see the value returned as “true”.

VDI Environments

Although we support a few different VDI Solutions with Print Deploy, we should take some time to present the learnings we’ve gathered over our course of testing and in the real world. Let’s examine some of the VDI Environments we’ve tested and have customers actively using:

Microsoft Azure Virtual Desktop (aka AVD)

Azure Virtual Desktops are a great option for many customers who are already Microsoft Azure/Entra ID customers. The offering includes various options from sizing to availability, but we are mainly concerned with the “Session Type”. We can say there are 2 main session types we can work in with either the “Classic” Print Deploy Client or, the Print Deploy Client for VDI. The Host Pool Type also defines session types:

  • Multi-Session AVD (Pooled) - this type of Azure Virtual Desktop allows for multiple sessions to be served from the same instance simultaneously. This corresponds almost directly with how Microsoft Session-Based Remote Desktop Services serves desktop environments. Since we are running multiple sessions from a single instance, we will have the “Qualifiers” described above associated with each logged-on user. Here are the steps to accommodate AVD Multi-Sessions
    • The administrator will load the Print Deploy Client for VDI on the AVD Pooled instance
    • The administrator will load the Print Deploy User Console Tool aka UCT (optional) on the AVD Instance
    • Users will log in as usual and each session contains all the unique “Qualifiers”. and deploy printers based on the Zones configured in the Print Deploy Admin.
    • We would see this session identified as “remote” in the Print Deploy Client for VDI logs.
  • Single-Session AVD (Personal) - this is a type of AVD instance that is completely dedicated to a single user or to multiple users who may only be logged in at a single time. This is the opposite of the “Multi-Session” concept.
    • The administrator will load manually or push via MDM, the “Classic” Print Deploy Client on each “Single Session” image. This is the same concept for loading the client on a Thick O/S” such as Windows Laptops or Desktops as we do not have “Qulaifiers” present.
Microsoft Azure RDS/On-Premise RDS

Microsoft Remote Desktop Service has been around for a couple of decades. Azure provides a “SaaS” instance of RDS for organizations who want more control over their virtual Desktop and Application sessions. Very similar in the “end user” experience compared to AVD, Azure RDS mirrors the same deployment strategy as On-Premise RDS when deploying Print Deploy:

  • RDS “Session” based VDI - This equates to Multi-Session VDI where multiple users are able run VDI Sessions from the same RDS Host simultaneously. Since we are running multiple sessions from a single instance, we will have the “Qualifiers” described above associated with each logged-on user.
    • The administrator will load the Print Deploy for VDI Client on the RDS Session hosts
    • The administrator will load the Print Deploy User Console Tool aka UCT (optional) on the RDS Host Instance or as a Published Application
    • Users will log in as usual and each session contains all the unique “Qualifiers”. and deploy printers based on the Zones configured in the Print Deploy Admin.
    • We would see this session identified as “remote” in the Print Deploy Client for VDI logs.
  • RDS w/ Hyper-V Image - this is a type of RDS instance that is completely dedicated to a single user or to multiple users who may only be logged in at a single time. This is the opposite of the “Multi-Session” concept as we do not have qualifiers” present.
    • The administrator will load manually or push via MDM, the**“Classic” Print Deploy Client** on each “Single Session” image. This is the same concept for loading the client on a Thick O/S” such as Windows Laptops or Desktops.
Citrix

Citrix provides comprehensive methods to deliver Desktops and Apps to your End Users. There are many ways to configure Desktop and/or Application Sessions with Citrix, however, for our purposes, we will simplify it down to the following basic rules based on “Machine Type” configured by the Citrix Admin.

  • Multi-Session OS - This type of VDI deployment serves many users simultaneously from the same Machine Catalog. Similar to ” Pooled” AVD Sessions, we will have the “Qualifiers” present associated with each logged-on session.
    • The administrator will load the Print Deploy Client for VDI on the Machine Catalog Machines as needed
    • The administrator will load the Print Deploy User Console Tool aka UCT (optional) on the Machine Catalog Machine or as an Application
    • Users will log in as usual and each session contains all the unique “Qualifiers”. and deploy printers based on the Zones configured in the Print Deploy Admin.
    • We would see this session identified as “remote” in the Print Deploy Client for VDI logs.
  • Single-Session OS - Opposite to the Multi-Session OS deployment above, this type of Machine is a single-session instance where only one user can be logged in at a time. The VDI “Qualifiers” will not be present in these sessions.
    • We would want to use the “Classic” Print Deploy Client here either pushed via MDM or installed locally by an admin. This assumes that VDI environmental variables such as Session ID would not be present, similar to the RDS w/ Hyper-V Image provisioning
VMWare Horizons
  • Multi-Session Hosts - Uses RDS Server(s) to serve Multiple Sessions to serve multiple users simultaneously. Similar to ” Pooled” AVD Sessions, we will have the “Qualifiers” present associated with each logged-on session.
    • The administrator will load the Print Deploy Client for VDI on the VMWare Pooled Hosts (RDS) as needed
    • The administrator will load the Print Deploy User Console Tool aka UCT (optional) on the Pooled Hosts (RDS) or as a VMWare Horizon App
    • Users will log in as usual and each session contains all the unique “Qualifiers”. and deploy printers based on the Zones configured in the Print Deploy Admin.
    • We would see this session identified as “remote” in the Print Deploy Client for VDI logs.
  • Single Session Hosts - VMWare is similar to RDS and Citrix Desktop Provisioning uses ESXI Images for Persistent Desktops. This would require the “classic” Print Deploy Client
    • We would want to use the “Classic” Print Deploy Client here either pushed via MDM or installed locally by an admin. This assumes that VDI environmental variables such as Session ID would not be present, similar to the RDS w/ Hyper-V Image provisioning
Summary

To summarize the above descriptions here is a table that shows which Print Deploy Client will work for each supported VDI environment:

VDI Solution

Print Deploy Client for VDI

Print Deploy Client “Classic”

Azure Virtual Desktop (“Pooled” Multi-Session)

✅ Supported

❌ Not Supported

Azure Virtual Desktop (“Personal”-Single Session)

❌ Not Supported

✅ Supported

Microsoft RDS (Session Based)

✅ Supported

❌ Not Supported

Microsoft RDS (Image Based)

❌ Not Supported

✅ Supported

Citrix XenDesktop/XenApp

(Multi-Session OS)

✅ Supported

❌ Not Supported

Citrix XenDesktop/XenApp

(Single Session OS)

❌ Not Supported

✅ Supported

VMWare Horizons

(Multi-Session Desktop - RDS)

✅ Supported

❌ Not Supported

VMWare Horizons

(Single Session HyperVisor Based)

❌ Not Supported

✅ Supported


Troubleshooting Session issues

One of the best tools to figure out why you may not see the results with Print Deploy you were expecting can be found in the Print Deploy Client for VDI log file.

  • Windows file path: C:\Program Files\PaperCut Print Deploy Client for VDI\data\logs
  • We can quickly determine if the session environment is returning all the “qualifiers” required.
  • If one is missing, the session may be determined to be invalid, or the Print Deploy VDI Clientmay not fetch queues at all if, for example, the Client IP is incorrect or missing.
  • Given the complex nature of VDI environments, it is best practice to grab the logs and open a ticket with your ASC/Reseller.

Comments