Server 2012 RDS Printers in a pool


  • 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?!?

    Monday, December 16, 2013 8:54 PM

All replies

  • 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 :/ 

    Tuesday, December 17, 2013 2:01 PM
  • 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!
    Thursday, December 19, 2013 2:33 AM
  • 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.

    Friday, December 20, 2013 2:11 PM
  • 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.
    Friday, January 17, 2014 9:14 PM
  • 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.


    Friday, January 17, 2014 10:39 PM
  • Hi JustusIV,

    Even though you say "there has to be a better way" I don't think there is.

    I think you need to reconsider the way you design your "Master VM". Instead of building it manually, which is the case if I understand your posts correctly, you might want to consider automating the process to build your Master VM.

    We use MDT to create our Master VM and indeed add all necessary drivers to that image before deploying it in a Pooled Desktop collection..

    MDT has a Sequence which builds the Master VM based on a Golden Image, and in this tasks we have several steps to add printer drivers, brand the image using our logo's and images, and fine tune a lot of other stuff.



    There's a new blog in town:

    Saturday, January 18, 2014 12:40 PM
  • Ok so i tracked this down.

    All the printers we are having trouble with are the Type 4 printers. Are others seeing this issue mapping a type 4 printer in a Pooled RDS from a UNC it works the first time but disconnect and reconnect and it throws the error. 

    Wednesday, January 22, 2014 6:13 AM
  • Can anyone else try to reproduce this?

    In a pooled machine. With the users running without admin rights. Map from UNC a type 4 printer from a printer server.

    Printing works. Logout then log back in.... printing fails.

    Monday, February 03, 2014 8:51 PM
  • JustusIV, did you find a resolution to this? I have a similar environment (pooled RDS) running 2012 R2 and users' default printers change frequently and seemingly arbitrarily.
    Friday, November 20, 2015 3:38 PM
  • We had enough issues that we took the "pooled" down. We still run about 150 "personal" VDI however.

    From what i remember all the printer woes were caused by the type 4 printers. We stopped using "type 4 "and all the problems went away.

    This really didn't have to do with the default printers however.

    • Edited by JustusIV Friday, November 20, 2015 3:55 PM
    Friday, November 20, 2015 3:42 PM