Virtualization is a key factor in efficiently deploying and managing an enterprise network today. Server-based computing via virtual desktops and applications that can be accessed from thin clients saves companies money and saves IT administrators time and frustration. The 2X suite of virtual computing software components, consisting of 2X VirtualDesktopServer, ApplicationServer and LoadBalancer – and with client software for Windows, Linux and Macintosh – provides a comprehensive solution that supports many popular VDI providers with increased security and performance. 

The 2X programs don’t have to replace the thin client and virtualization technologies with which you’re familiar, such as Windows Terminal Services/Remote Desktop Services, Citrix, VMware, Microsoft Virtual Server/Hyper-V, Sun VirtualBox, Virtual Iron, and so forth. 2X extends those technologies, making the virtualized environment more seamless and easier to manage.

Of course, thin client computing with virtualized desktops and applications is not a new concept, but 2X offers some unique features that simplify both the administrative and end-user experiences. One of those is the Universal Printing and Scanning feature, which we’ll be looking at in this article.

The Challenge

A big advantage of server-based computing is that users can connect to their corporate desktops and applications from almost anywhere. This means they can run their applications from a desktop or laptop computer, or even better, they can use a thin client operating system that will run on hardware that would not support the latest client operating systems. But this can present some challenges, and one such challenge involves the ability of users to print and scan documents. Much as we might wish it, most organizations are still far from “paperless” and users still need to generate paper documents from their electronic files and/or convert paper originals into an electronic format. 

The problem is with all the different printers and scanners and their corresponding drivers. In a terminal services environment, all of the application processing takes place on the server, so the print jobs are likewise created on the server – but the server is often located in a place that is physically distant from the user, and users want to print to printers that are attached to or close to their client machines. So the print job needs to be delivered to the printer that the user wants to use. Another problem is that the server must have a driver installed for the printer that is being used by the client. Since different clients will likely be using different printers, this could result in the need to install many different drivers on the server. All those drivers would also need to be updated from time to time. Performance can also be a problem.

The Process of Printing from Terminal Services

To understand the challenge, let’s look at the process that you normally have to go through to print from a Terminal Services session. Printing from Terminal Services works essentially the same way as printing directly to a local or network printer, involving a number of steps:

  1. The user tells the application to print the document.
  2. The application calls GDI functions in the Windows API, which pass the information to the GDI graphics engine.
  3. The GDI graphics engine either spools the drawing instructions as an EMF file or (in conjunction with the printer driver) renders a printable image to be sent to the spooler.
  4. The spooler components interpret EMP files and insert page layout information and job control instructions.
  5. The spooler sends the data stream to the port driver that’s associated with the printer’s I/O port.

If the wrong driver is used, the job will not print correctly; the formatting may be wrong or the printed page may be complete nonsense because the wrong characters print. 


If printing from an XPS application, the application calls XPS functions in the XPS Print API. The spooler passes the XPS spool file straight to the device for rendering and output when printing to queues with XPS Drv printer drivers. If the XPS file is being printed to a GDI device, it’s converted to EMF via the XPS to GDI Conversion Module and sent through the GDI print path. For more detailed information about the Windows printing process, see:

Windows Printing Process Description

Printing from a Terminal Services session further complicates this already-complex process. The RDP client makes locally installed printers (including network printers) available from within the server session. The GDI creates the EMF file on the Terminal Server and sends it to the print spooler on the Terminal Server. If the drivers for the client printer are installed on the Terminal Server, the print job can be rendered correctly; if not, it can’t. 

Performance issues are due to the relatively large size of a raw print job, which can take a while to transfer from the server to the client printer, especially over a low bandwidth connection. This could also reduce the performance of the RDP session itself during the time the print job is being transmitted. 

Printing with Windows Terminal Services has historically been a bit tricky because if the name of the client printer driver didn’t exactly match that of a driver installed on the terminal server or in the list of drivers included in the Windows Server installation, printer creation failed. So even if the correct driver was installed on the server, if the name was not exactly the same, it was not recognized as such. So if one driver is named “Hewlett Packard OfficeJet XXX” and the other is named “HP OfficeJet XXX,” the server saw them as two completely different drivers. 

With older versions of Windows, you had to map the names of the printer drivers on the server with those on the clients, by creating a file in the system32 folder. To enable mapping in Windows 2003, you had to add registry values. This situation was improved in later versions of Windows, and the Terminal Services Easy Print driver in Windows Server 2008 made everything easier, but clients had to meet certain requirements. Meanwhile, many organizations are still using older versions of Windows Server, because of the cost of upgrading hardware to support the new server operating system and the need for updated clients (Vista or Windows 7) to take advantage of its advanced features.

The 2X Universal Printer

If all of the above sounds like a lot of work, that’s because it is. Managing all those drivers, especially when you have multiple Terminal Servers, could be an administrative nightmare. A number of vendors have devised universal printer drivers to solve the problem of printing in a terminal services session. There are several different ways this can be done, including universal printer drivers based on an EMF driver. The disadvantage here is that it can only be used by Windows clients. Universal printer drivers can also be based on the Adobe PDF format, which turns the original EMF file that is created by the local printer spooler into a PDF file and sends it to the client. There it is turned back into EMF format so it can be printed. 

Universal print drivers render the print job in a universal format on the server and send it to the client’s local printing subsystem, and the local print spooler handles the printer specific rendering of the print job with its locally installed printer driver. This has many advantages, including:

  • No need to install the printer drivers on the server.
  • You can change the local printer without any effect on the server or printing capability.
  • Performance is generally improved because the files transferred over the network are smaller. 

When using the 2X VDS, the printing process is greatly simplified by the 2X Universal Printer, which is automatically installed when you install the Terminal Server Agent.

The Universal Printer then shows up in Windows Server 2008 R2’s Devices and Printers window, just like any other installed printer.

Click to enlarge the image

To configure the Universal Printer, open the 2X VirtualDesktopServer console on the server, select Universal Printing in the left pane and select the server. You can enable or disable Universal Printing here for each terminal server in your farm.

Click to enlarge the image

You can also set the EMF Properties, which gives you control over which fonts should be embedded in the print job. If a font is already installed on the client computer, you can exclude it from being embedded. The fonts that are included in the list by default are the ones that are installed on the typical Windows machine. Adding or deleting a font is as simple as clicking a button.

Using Universal Printing 

To use Universal Printing, it must be enabled on each of your terminal servers. In addition, each client must have the 2X client software installed and a PDF viewer installed, with its file associations set to open PDF files. From the client machine, a user can print to the local printer or display the document in PDF format. 

The 2X Universal Printer will show up in the list of printers in the application’s Print dialog box, as shown in the figure below:
Click to enlarge the image


Options for Universal Printing can be set in the Options dialog box on the 2X client software, as shown in the figure below.

Click to enlarge the image

You can set it up to always print to the printer that is set as the default on the client machine, to always use another selected printer, or to prompt you to select a printer each time you print. 

You can also select the data format: Portable Document Format (PDF), Enhanced Meta File (EMF), or Bitmap (BMP). EMF is the default. If your printer supports two-sided printing, you can configure whether to flip on the long edge or the short edge of the paper. There is also a checkbox to print in reverse order, and you can configure hardware margins to fit to the page, use preferred dimensions or fit with dimensions. 

Now you can print from a virtualized application, in exactly the same way that you would from an application installed on your local machine. Select the 2X Universal Printer in the Print dialog box, and printing will proceed seamlessly.

The 2X Universal Scanner

The Universal Scanner works just as seamlessly as the Universal Printer. It is automatically installed on each terminal server when you install the 2X Terminal Server Agent software. You set it up in the same way in the VDS console and enable or disable it for each terminal server in your farm. Then, on the Scanning Applications tab, you can add any TWAIN compliant published application, as shown in the figure below.

Click to enlarge the image

Note that to add an application, you will need to know its location in the file system. The Add dialog box filters for the .exe file type, as you can see in the figure below.

Click to enlarge the image

On the client, in the 2X Client’s Options dialog box, click the 2X Universal Scanning tab and select the scanner to use, as shown in the figure below.

Click to enlarge the image

Once you have Universal Scanning configured, on the client machine you open the published scanning application and select the 2X Universal Scanner from the scanner selection list, as shown in the figure below.

Click to enlarge the image

It shows up like any network scanner, and you can change the scanning settings within the application as if it were a local scanner.


An important goal of virtualized and thin client computing is to make the experience seamless for users, so that things work the same way they do with a local machine. In the past, printing and scanning have been two activities that sometimes presented problems in that respect. The 2X solution solves those problems with its Universal Printing and Universal Scanning functions, which allow a user to print and scan from the Terminal Services applications and frees administrators from the worry of installing multiple drivers on the server and keeping those drivers up to date.

About The Author

DEBRA LITTLEJOHN SHINDER, MCSE, MVP is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor and contributor to over 20 additional books, is lead author, blogger and newsletter editor for, and and edits the popular WXPnews and Win7News newsletters. She has authored training material, corporate whitepapers, marketing material, training courseware, and product documentation for Microsoft Corporation and other software and hardware companies. Deb currently specializes in security issues and Microsoft products and is a Microsoft MVP.

Leave a Reply

Your email address will not be published. All fields are required.