Ok here is my scenario. We just created a pooled collection. Our users are able to jump on to our print server via unc path and install a printer and print and everything is fine. They then log out and log back in. The machine is a fresh machine but their profile has a connected printer. If they try to use it they get a missing driver. Which asks them to re install which says it works but then it fails to print. 

How can i make it so users can manage their own printers in a pooled desktop?!?

I am still looking for an answer on this one.

What i did in the mean time was to "Recreate All Virtual Desktops" with my same machine except connected the the printer first. This essentially added the drivers before the sysprep instead of the users actually adding the driver when they do it. This is fine in this scenario but surely i cant be expected to add all printer drivers before i deploy the pool.

There has to be a better way :/ 

Hi,

Do you have RD Gateway server?  Have you enabled RemoteFX feature?

If you are using Remote desktop easy print driver first in your environment then you can enable the option under group policy. Here providing you article for RD Easy print (You can check for Server 2012).

Computer Configuration -> Administrative templates -Windows Components -> Remote Desktop Services > Remote Desktop Session Host -> Printer Redirection

Apart from that in a session collection properties under printers option, you can check the same option there and if want to use default printing device then you can check the option Use the client default printing device. Below is the snapshot for your guidance.

 

Hope it helps!
Thanks.

Ok so this is "Pooled virtual Desktop collection" not session. For the last several years we have been training our users to connect to our printer server and map there own printer via the \\printserver\printername 

What is happening now that they are pooled and not just a standard machine is they go there map a printer and it works great. They log out and the VM resets causing the driver to be removed from the machine. They connect back in and their profile thinks yeah i have this printer however since the machine reset it doesn't have the drivers. So the print fails. I would think reproducing this issue wouldn't be hard at all. Connect to any "pooled" map a printer from UNC that windows doesn't natively have its drivers. At this point the printer works..... Log out, let machine reset. log in. Experience a broken printer.

We are not interested in pushing out printers onto the thin client. We do no want to "manage" our thin clients at all.

I am still looking for an answer. This is causing major issues. Not every printer is a problem just a handful of them maybe 20% in our environment.

While i hunt for anything on this issue i have discovered there is one driver that is giving us issues. Interestingly enough it happens to be version number 6.2.9200.16430

We have 16 printers using it. Outside of our pooled VDI environment it works just fine.