Windows 10 WVD pnplockdownfiles bloat




Windows 10 Multi-Session WVD machine and pnplockdownfiles bloating


Dealing with an issue where the pnplockdownfiles seems to be bloating really badly with repeated printer driver installations:




On the WVD session hosts I cannot even open the PnpLockdownFiles key as its that large.

and is taking up to 20/30 minutes for the machine to boot up


Printers are mapped using GPP under the user context.


There seems to be a fix for this for Server 2012 R2:


Just to add to this, as a test I have set this up on my lab environment.


Every login it creates driver entries in the pnplockdownfiles key.

So in this instance I have logged into the WVD machine 3 times, using a HP printer driver I got from Windows update as a test.  It looks like it installs the driver 3 times.  This will just continue on every logon. I've seen it with HP and Ricoh drivers.


What is strange is the location of the drivers doesn't even exist under system32\spool\Drivers\x64, the entries are not there.


This is just a lab with one user and one printer. In my scenario I have 12 printers and loads more people, you can imagine the size of this key. Is this a bug within Windows 10 Multi-Session. Does it need to go to Microsoft?





4 Replies

Not seeing this behavior in our lab env if redirection is forced to use the RDS EasyPrint drivers (which I'm currently able to get away with in our environment ... you may not have that luxury).


Does pre-installing the HP/Ricoh/other vendor universal print drivers on the WVD host (instead of something from Windows Update) and / or changing the "Specify RD Session Host Server fallback printer driver behavior" GPO to "do nothing" make a difference? (not sure if either is an option in your environment ... but could potentially help prevent terminal services print driver installation bloat)

Yes, the GPO printer map will re-install/verify the driver files each time a user try to login to a RDS server depending of the the GPO map settings, because it need to keep the settings in the user context. With a few printer and a few users it should not be an issue. But In the past I have seen large RDS envirenoment that were trying to load more than 200 printers on a 2008 R2 server and it did endup bloating the registery and it is very hard to cleanup. In these cases I would strongly suggest you to find another printing maping solution (Sometimes you need to tell the user that their printer/printdriver were not deisgned for multisession and they need to change the printer) or a third party printing solution for your environment.

Thanks for your reply. I'm just testing different drivers in the lab. The HP Universal Printer may be the answer as I've just tested using that with two printers and it doesn't add any entries to PnpLockdownFiles at all. I only have 40 users with 12 printers, the only difference is that all users have all 12 printers mapped as they move about.
I don't think I can recover the machines as its in Azure and won't be able to boot into PE to delete and compress the registry.
This issue has caught me by surprise.
Thanks for your answer, majority are HP and one Ricoh, will see if we can switch to Universal Drivers.