No Pages Selected RDS Server 2012r2

Question

Hi All
We are currently having troubles which seem to be random in nature printing only from Adobe PDF across three clients running on the below configuration.
Server 2012 r2 RDS (terminal Services) Hyper v instance
Adobe Reader 11.0.5
each of our three clients have a dedicated print server and all printers are shared network devices deployed by group policy.
Each RDS server has 15 to 25 user sessions
All users have no problem printing from any other app but when printing from adobe reader some users depending on the user and the printer (randomly) the user will not be able to print with the "no pages selected" dialogue box coming up.
For instance one user will log into their rdp session and will not be able to print pdfs to one printer. But another user can print from adobe no problems to the same printer.
Trouble shooting so far:
Re install Adobe
Ensure all drivers are at latest version V4 drivers where available and V3 where not. (Printers are HP upd and Xerox Docucenters)
pdf/a view mode set to never
Disabled Enhanced security mode and protected mode at start up.
Tested using auto rotate selected and not
changed the fit to page/shrink to fit etc options
Turned off advanced printing features on the printers.
If anyone could help this would be greatly appreciated as I am at the point of pulling my hair out and so are our clients.
Cheers
Luke

Answer 1

I've had the least Adobe issues with setting up the following:
On the print server:
Have as few drivers on your print server as possible. Set them to a universal driver if possible (I am trying to get all my printers on HP Universal Printing PCL 6 driver)
Set print drivers to run in Isolated mode.
Uncheck "Render print jobs on client computers" in the printers on the printer properties' sharing tab.
Set Print Processor to Winprint with default data type of RAW in the printer properties' advanced tab.
(Here is a quick powershell way to do it, but I have not tested it:  Two Minute Drill: Change Print Monitors/Processors via PowerShell - Ask the Performance Team - Site Home - TechNet Blog…)
On session host (disable logins, make sure no other users are logged in):
Make a backup and then delete all registry keys under:
HKLK\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\
Also, to clear the x86 side of things, do this for:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\
These will be a list of SIDs along with a Servers Key that lists print server connections.  Delete all of it.  As people reconnect, the printers will be mapped, and these keys will be created again.
So now the issue happens much less often (2 times a day on an environment with 150 people connected across 4 Session Host servers)
My next step that I haven't done yet.
On Print Server:
Remove unused print processors now that everything is on winprint per instructions from: How to Remove Non-Default Print Processors from Print Servers | HP® Support
Note: I did this on the print server, but I only renamed the .dll file in the C:\Windows\System32\spool\prtprocs\x64 folder, and when a new printer was added to the print server, not only did it re-add the .dll file from another driver location, but it reset all my printers that were using that driver to use the HP print processor again.  So make sure that ALL instances of the .dll file are renamed to .dll.old so that it can not grab it.
One thing I noticed when I did this was that an additional change had to be set to the driver to make sure that the driver can install, otherwise the printer will give you an error when you try to install it with the driver as it won't be able to find the print processor associated with that driver.
In the registry, go to:
HLKM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\<Driver Name>\
Change the REG_SZ Print Processor to "winprint".  Also edit the REG_SZ key Monitor to be blank.  (Replace "Windows x64" with "Windows NT x86" if you are using 32-bit clients, or do it in both if you have a mix)
When I did this on the print server without renaming all instances of .dll on the server, I was able to install a new printer and it reverted all these settings back.  In theory, if I get all instances of the .dll files to be renamed, and it can't pull them from another location, they SHOULD just pull the winprint print processor when it installs the driver, but I have not yet confirmed this.
Please make sure to back up registry keys before making changes, and perhaps take a snapshot/backup of your Print Server before making these changes in case anything inexplicably breaks.