Client Side Rendering on Terminal Servers

Question

I’m having horrible printer issues on my Terminal Servers such as slow printing, slow to add printers, some applications load slowly because they are enumerating the list of printer (thanks Procmon), slow logons, etc. I'm trying to get Client Side Rendering
(CSR) disabled. From what I can tell it still appears to be on. Terminal Server are Windows Server 2008 SP2 x86.
On my print servers I have verified that all printers have Render print jobs on client computer unchecked. I have a Group Policy linked to the OU that the Terminal Servers are in that has
Always render print jobs on the server set to enabled. Per
http://blogs.technet.com/b/askperf/archive/2008/02/10/ws2008-client-side-rendering.aspx I have verified that on each Terminal Server in
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers the
ForceCSREMFDespooling value is present & set to 1 so the GP is being applied.
However I still have tons of entries in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\<SERVERNAME>\Printers.
I have found KB958656 which seems to describe my problem that CSR is not being disabled. However one of the files it updates is older than a file that I have (win32spl.dll) & one is newer (printcom.dll).
Printcom.dll in hotfix is 6.0.6001.22288 mine is 6.0.6001.18000
Win32spl.dll in hotfix is 6.0.6001.22288 mine is 6.0.6002.18005
Has anyone else seen this behavior & been able to get CSR disabled?
Has anyone else had success with the KB hotfix mentioned or know whether or not installing it would causing any issues (since it has that older file)?
Thanks in an advance to any input.
Patrick Hoban
http://patrickhoban.wordpress.com

Answer 1

Alan/Patrick,
Hi, sorry, went away on leave for a while so didn’t respond.
Alan – our case was REG:112081612189183.
For someone who has been dealing with MS support for about 20 years, this was the most disappointing of any support call I’ve ever had raised – to have the call shut
down, without a perfmon trace, process explorer analysis, or hang dump analysis (of spooler) – and simply blame “3^rd party drivers” without any proof – is utterly deplorable.
Anyway, for anyone’s benefit who has similar problems – trying to do direct printing from RDS – I’ve managed to get a solution working. 
Here are the details;
A nightly print spooler clean-up script that;
Stops the spooler
Deletes the entire key under “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider”
Re-creates the key (empty) and sets the value "RemovePrintersAtLogoff"=dword:00000000
Note, this was vital. 
MS support had recommended we set this to 1, along with some other keys (InactiveGuidPrinterAge, 
InactiveGuidPrinterTrim) with specific values.  If we used these MS support recommended values, our RDS serer would not enumerate printers for more than 3-4 hours before requiring a restart of the spooler.
Restart the spooler
Map a printer (just to make sure it works)
Clean up the USERS\.DEFAULT\Printers key on all existing servers
There was heaps of crap here, the default user NTUSER.DAT was over 800MB in size
Modify the security on the registry, using GPO to deny SYSTEM write access as below, to stop the crap writing here again;
USERS\.DEFAULT\Printers
Deny Set value
Deny Create Subkey
Run NGREGOPT on all servers to compress the DEFAULT and SOFTWARE hives back down.
Even though we had deleted the crap from “Client Side Rendering Print Provider” and the DEFAULT user hive, the registry files were still large of course, and needed to be compressed to reduce
paged pool usage.
Note, make sure no users are on the server when this is run !
With the nightly spooler ‘refresh’ and the registry security changes, we are no longer seeing any problems. 
In addition the paged pool has gone down from 5GB to 1GB – which I believe was related to the registry bloat that had occurred previously. 
Cleaning up the keys and using NGREGOPT has fixed this.
In addition, I am running a spooler check script every 30 minutes on each of the 13 servers. 
This script checks how long it takes to enumerate the printers for the specific test user. 
If it takes more than 20 seconds, we get an alert.
Since I have made the changes above, we no longer have any printing problems… touch wood.. even using HPD 5.4 for most printers, and other (RICHO) 3^rd party
drivers.
If anyone wants the scripts (the spooler refresh or the check script) let me know on david.frith<at>glfconsulting.com.au
ta