- 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<sup>rd</sup> 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
- USERS\.DEFAULT\Printers
- 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<sup>rd</sup> party drivers.If anyone wants the scripts (the spooler refresh or the check script) let me know on david.frith<at>glfconsulting.com.auta - A nightly print spooler clean-up script that;
-
Has anyone tried this hotfix?
http://support.microsoft.com/kb/2778831 -
Dale - wow, that sounds like the hotfix we are after
about time Microsoft !
Gee, makes me even more angry that our support call was closed on us by Microsoft blaming 3rd party drivers ...
It will be on our farm within 2 weeks, and I'll try removing the nightly registry clean up - but looking at the article, it sounds 99% sure to solve the problem
source: http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/42f8e930-c50b-4166-88f4-4832ea9e2f13/