I have a VM running Windows Server 2008 and there is a web application deployed on a Tomcat instance that is installed on that machine. Tomcat is configured to run as a service on behalf the local administrator.

There is a feature in this application that offers the conversion of Microsoft Office files to a PDF format. Basically it uses the Tomcat user as the interactive user to open Office applications, such as Excel, and to use the opened Office application Save as PDF feature.

Issue Description

The dilemma is that when I use Remote Desktop Donnection to connect to that VM using a certain username and password, the conversion works successfully, but when QA connects to the VM, using the SAME username and password as I use, the conversion gets stuck.

I have to reconnect and kill the Excel process and use the conversion feature to get it to work successfully.

What could be the security difference between connecting from my PC and the QA PC, we are running the same OS (Windows 7), connected to the same network.


1 Answer 1


Quick Fix Detail

  • From the Local Resources tab and within Local devices and resources section of the RDP editable properties, ensure that the Printers option is not selected

    Note: This setting maps over defined printers and printer drivers to RDP when establishing sessions using printer redirection.

    Remote Desktop Connection

More Detailed Information

Okay, when QA connects to this server, ensure that the Local Resources tab within the Local devices and resources area of the RDP icon on saved shortcut DOES NOT have the Printers option selected (see below)—this may be the quickest and simplest solution—it tells the RDP session to NOT use Printer Redirection.

Since this software is converting documents to PDF, it's likely using a Windows defined virtual printer, and the printers 'defined \ mapped' on the two machines are different (yours and QA's).

The QA machine that causes the issue when it RDP's into the server, likely has some printer defined on it that your machine doesn't have, and this is causing the Tomcat PDF conversion process problems per the Printer Redirection—trying to redirect printer settings that causes the Windows Server 2008 OS to scream at, etc.

You'll likely see Event Viewer printer driver related error messages when this occurs on the server, but you could install those drivers on the server that this errors on for a solution potentially as well. So when that machine connects and the printer redirection occurs, the server OS has the print drivers to move forward without issue thus not causing problems with the PDF conversion process and its correlated virtual printer that's defined.

  • So weird that it worked, but it did, and for that sir. I say thank you!
    – QuakeCore
    Oct 18, 2015 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.