Good day -

Many employees are now working from home using RDP connections to a windows server, then hopping to our Linux based cloud servers.

I was told by our IT that they could not get PDFX to work using this topography. I don't know why offhand, however before putting a great amount of research into it i thought it would be good to at least inquire if this is indeed a possibility... keeping in mind that we are also using PDFX to invoke email options.

I am happy to investigate/test further when i find out that this is an OK setup... and hopefully it is, as like i said this is now a very popular setup. Also welcome advice on how to install to get working.

TIA

Hi Frank,

All my customers are RDP users and PDFX is in place, for printing and email tasks.
But, all of them use A-Shell Windows so, I don't know what are the limitations in your scenario where the windows server is only the path to the Linux server.
Anyway, I was wondering here about what's different from what you have now and previously, where the users were still accessing the Linux from an Windows station?
PDFX works fine in RDP sessions, I'm curious to know what is the problem.

Hi Jorge,

Thanks for the quick reply. Hoping your hunkering down there safely.

In answer to your question, we usually just do a direct connections from the PC/ATE to the Linux server. Installing PDFX on the workstation works fine. I don't honestly know the issue, whether it didn't show up as an option, or had an error.. i apologize i didn't dive into it too deeply yet.

I'm glad you are having success with it, i would expect this to be the case, not sure why not working on this server. Is there any special instructions to install the PDFX driver on RDP in order to have all users access? Does it need to be installed on every "virtual" connection?

Thanks.

I just set up a test of this locally, and it seems to work fine, provided that the PDF-X driver is installed on the RDP server and visible to the user.

I ran the PDFX5 installer while logged in on the server console, creating a printer named PDF-XChange Printer 2012. Then I connected via RDP from two different client machines using different logins. From each I then used ATE to connect to a Linux server where I printed a test file using a printer init file that looks like this:



Both successfully created a PDF file on the RDP server. I was also able to save the PDF file on my local PC (since I had added my local C drive as a resource to the RDP connection.) The only problem I ran into was that Acrobat from within RDP session refused to open the PDF file from my local C drive, complaining about some kind of privilege issue.

What I'm pretty sure you will not be able to do is use an instance of the PDF-X driver installed on the client. Since PDF-X is licensed per workstation, it's not surprising that it doesn't allow access to instances shared across a network. It's surprising enough that it works within RDP, since that would also allow many users to share one copy. (Note that this isn't an issue for the A-Shell license for PDF-X, but it would be if you were buying the retail license which is sold on a one-user one-pc basis.)

I didn't try it with PDFX3, but I can't see why you would want to use the old version in this case.

If you're still having troubles, the intermediate test I would suggest is to just bring up Notepad within your RDP session and see if you can print a file to the PDF-X driver there. You'll get the not-licensed stamps, but that will at least verify that you can access the driver from the RDP session. And if so, there's no reason why ATE couldn't also do the same.

Thanks very much for the reply... that's exactly what i was hoping for. Given this new info, i will dive into the scenario and triage it myself.

I have researched the issue, for some reason there were multiple instances of PDFX on the server... not sure why. Either way, tested it and seems to be operating as designed including sending emails.

Thanks again.

The multiple instances of the printer driver are created when an A-Shell job instantiates the driver. Once instantiated, they could be used for additional printouts but it doesn't really matter. They should disappear as the A-Shell sessions that created them are closed.

Ahh good to know. Thanks Cap.