question

Hello @MirtoMorinini-1087

I would recommend you first install all the available hotfixes on the Print Server.

Then try add the following registry value :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\RemovePrintersAtLogoff = 0 (DWORD)

Keep me posted how it goes. Thank you and have a great day!

---

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Best Regards
Karlie

Hi,

thank you for your answer. I've cloned / sysprepped today a RDSh and made a separate collection in the way I can try to implement various solutions and avoid mess up with the productive environment.

I've been reading a lot about such issue and how it works Printing for RDS on W2016/2019. I really don't get why Printers connected from Users are stored in HKLM..
I've been dealing with another issue for another customer today, but this environment is using XenApp and Printers are deployed through PS Script and assigned via item-targeting (Groups/Users), it seems that issue got fixed by disabling on all shared printers "Render Print Jobs on Client Computers" and by adding the registry value you also mentioned, after deleting all sub-keys of HKLM/Client Side Rendering Print Provider on XenApp Servers.

After some discussion with another engineering team, it looks like a similar issue of my OP was already "solved" but with a workaround that is not really a solution I would be happy to use. The issue has been identified with the fact the printers connected from users are appearing on control panel -> Printers and devices with such a great delay (minutes, not seconds, and everything is on-prem on a single hyper-v failover cluster - despite they can be seen immediately by printing from Notepad or other programs), causing the Standard Printer to be assigned to the first "physical" printer found (in this case a PDF Printer on RDSH).

Anyway, if I add the value you suggested, I don't risk that all the printers connected from Users will disappear? As I mentioned, we are not using any GPO or PS Script to deploy printers, Users are choosing the printers they need and they must not disappear. We are using FSLogix Profiles so everything except redirected folders is stored in FSLogix Profiles.

This is the workaround suggested from the Engineering team, maybe could inspire new suggestions..

• Logout all Users
  

• Open registry with psexec -i –s c:\windows\regedit.exe
  

• Delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider" and then Re-Create it (empty)
  

• Add under Client Side Rendering Print Provider "RemovePrintersAtLogoff" / 00000000
  

• Export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM\PrintQueues , delete PRINTENUM Key it, then re-create it, then Import again all the Exported Items of PrintQueues
  

• Do the same step for HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\SWD\PRINTENUM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\SWD\PRINTENU
  

• Restart the Server

Now, every Shared Printer on Print Server must be opened as security group (Ok, with AD Toolset / PS Scripts can do it relatively quickly, but..) and the description must match exactly the name of the shared printer.

Configure this Powershell Script on Logon:

 $adsearch = "OU=PrinterMapping,OU=Groups,OU=VA,DC=contoso,DC=local"
 $adsearchdef = "OU=PrinterDefault,OU=Groups,OU=VA,DC=contoso,DC=local"
 $psrv = "PRNT-SRV01"
    
 Foreach($NetworkPrinter in $NetworkPrinters)             { 
                 $NetworkPrinter.Delete()   
             } 
    
 $pgrp = (Get-ADGroup -filter * -Searchbase $adsearch).name
    
 foreach ($g in $pgrp) { 
     $groupmember = (Get-ADGroupMember $g -Recursive).samAccountName
     foreach ($i in $groupmember) { 
    
         if($i -eq $env:USERNAME){ 
             $gdesc = (get-adgroup $g -Properties Description).Description
          $printer = get-printer -ComputerName $psrv -Name $gdesc
    
          foreach ($p in $printer) { 
    
                 add-printer -connectionname "\\$($psrv)\$($p.name)"    
             }
         }
     }
 }
    
 $pgrp = (Get-ADGroup -filter * -Searchbase $adsearchdef).name
 foreach ($g in $pgrp) { 
     $groupmember = (Get-ADGroupMember $g -Recursive).samAccountName
     foreach ($i in $groupmember) { 
    
         if($i -eq $env:USERNAME){ 
             $gdesc = (get-adgroup $g -Properties Description).Description
             $defprinter = Get-WmiObject -Query "Select * from Win32_Printer Where ShareName = '$gdesc'"
             $defprinter.SetDefaultPrinter()
         }
     }
 }

And this one on Logoff

 Foreach($NetworkPrinter in $NetworkPrinters)             { 
                 $NetworkPrinter.Delete()   
             } 

Honestly I really hope there is another way. It can't be that Microsoft is just sitting and doing nothing, no wonder there are so many 3th party Print Server software. I don't think I'm asking so much, I just want that my users can connect their printer and the default printer doesn't get lost every time.

Even with this workaround I won't fix the issue permanently, as explained, the major issue is that the default printer get lost even if a user DISCONNECT the RD Session and then reconnect, the Default Print switches back to the PDF Printer, therefore there is something really wrong that is related to RDS Session - if the issue would happen only during Logout/Login I could understand and the workaround above would work, but the fact that the default printer is lost even with session disconnect/reconnect (happens with domain admin as well, global issue, so nothing about permissions) is really freaking me out.

I will try on the testing RDSh what you suggested, maybe this will fix the issue already..but I really think I need to clean up the register properly. I also don't understand why under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers I've 4 Print Servers listed with different Printers as well in the sub-keys. One was a test print server, but the other 3 are actually the same but with different printers.. (one is the printserver_hostname, one is printerserver_hostname.domain and the last one the IP Address of the printserver_hostname.)

What a mess just for keeping a STANDARD PRINTER for Users.

I was able to identify more pieces of the scrambled puzzle.
When the Standard Printer is lost due the RDS disconnect/reconnect issue, and the user set again manually the standard printer, it seems this printer is added to

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\SWD\PRINTENUM and Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM

Since there is already a printer existing in such keys, this will cause a duplicate that will cause then issues of loosing the Standard Printer even if he correctly logoff/login again and ghost printing issues.

The only workaround that is not really a customer would appreciate, is to set in gpo (not on the colllection) to terminate a disconnected session after 1 minute. In this way this issue won't occur, but it's certainly now a solution.

There must be another way to stop RDS to mess up printers when reconnecting.

FYI, I opened a Case with Microsoft business support. I'll let you know the outcome.

Hi @MirtoMorinini-1087

i'm suffering the same problem with our RDS 2019 farm (1x VM Broker; 1x VM Gateway; 1x VM UserProfile Disk Server; 5x VM Session Host; 2x VM Print Server)

The problem is exactly the same as you mentioned, but somehow I can't recreate it on every user.
I've already installed a new print server, because the old one was running Server 2012 R2 - but no fix.

Would be great if MS has some information here!

But I've noticed some strange behavior too, this didn't really fix the problem but was helpful anyway.
We have about 50 printers in our network, due to the add printer option Windows starts some kind of printer discovery and adds discovered printers automatically with an WSD Port to the whole Session Host.
The problem with this was, users started printing on other printers instead of their own because the default printer was silently changed to an automatically installed WSD Port printer.
This causes some major problems, especially for our HR Team and other Teams which print privacy documents.

The fix for this problem was to deactivate every WSD communication on every network printer.
Adding Printers is still easy possible for every user, but no more automatically installed WSD Port printers.

Hi @CiemalaMarkus-0741

Microsoft got in touch with me, but the solution proposed is actually exactly the same I've already suggested.
But, there is no need as I added to create PS Scripts for Logon/Logoff and open Printers as Security groups.

After I cleaned up the registry in the way I described above:

• Open registry with psexec -i –s c:\windows\regedit.exe

• Delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider" and then Re-Create it (empty)

• Add under Client Side Rendering Print Provider "RemovePrintersAtLogoff" / 00000000

• Export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM\PrintQueues , delete PRINTENUM Key it, then re-create it, then Import again all the Exported Items of PrintQueues

• Do the same step for HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\SWD\PRINTENUM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\SWD\PRINTENU

• Restart the Server

  
  

The Problem resolved on the RDS Prod Collection as well.

I think the root of the Problem you have could be related, and certainly do such operation won't damage for sure. Doing it will NOT cause any issue in terms that the User will need to re-connect the Printers, after the clean up all Printers that were previously connected to the server (so not the redirected printers, the one connected manually on RDSH from the Print Server) were still there.

I never had good experiences by using WSD Ports. Check if the printers are not appearing wild / register themselves to print server or appearing on Users Session / Clients, on the Printers Web Interface you should have the possibility to disable this feature.

Remove all WSD Ports you have on your Print Server, if you have already opened TCP IP Standards Ports, DELETE the Ports then Re-create them (trust me, I had odd experiences by "recycling" TCP IP Ports instead of deleting and re-creating them), and assign them to the proper printers.

For now the problem is solved for this customer, still, i'm not very happy with the whole. But this was a mistake in the design, because all Users got on their Desktop (very few Thin Clients, mostly Notebooks) the RDP Icon from RDweb. Since on the collection it was set "Connect Printers" and "Set Standard Printer the remote computer standard printer", they are actually working only with redirected Printers. A lot cleaner solution would have been to have a manual RDP Icon for all Users WITHOUT connecting printers, and let the Users connect/set standard printers on RDSH, and instruct the Users Out of Office to Login via RDweb, where the Standard Printer will be properly set the current Standard Printer (so basically their printer at home, since most people are working home office during covid times).

At the same time, I've been evaluating 3th party RDS Printing Software. ThinPrint is a monster, it has so many amazing features, definitely next-generation printing. But this should be sold as product with all the features and perks it brings, because just to fix issues, it's DEFINITELY too expensive (29 usd per user).
Another Software I've found EXCELLENT with his Concept, but I still need to check how it will behave with Thin Clients, is TSPrint. Price is very affordable in this case (500 USD per RDSH), check out the video on their site to see the concept.

I wish you best of luck in fixing your issue, and happy new year!

Hi @MirtoMorinini-1087

At first also a happy new year!

Thanks for the feedback.
I'll clean up the registry this week - hope this will fix the problem permanently.

I've taken a closer look to the Client Side Rendering Print Provider Reg Key - the DWORD "RemovePrintersAtLogoff" 0 is already there.
Maybe I've taken your approach a few weeks/months ago but not completely.

In terms of the printer connection I agree with you - luckily our users don't really print that often so the redirected printers from home office connections is not that much.

Also thanks for the WSD Port hint - I've disabled the WSD features on all printers, and it seems to be fixed.
The WSD Ports on either the Print Server or RDSH are also deleted completely and printers are only connected via TCP/IP.

Thanks @CiemalaMarkus-0741 , happy new year to you as well!
I'm very glad I could be of any help with the struggles with printers :)

Don't forget to re-add this registry value after you delete / recreate the key. And make sure you are using psexec -i –s c:\windows\regedit.exe or you won't be able to clear all entries.

I've discovered the problem of Standard Printers with the current scenario is caused from few clients, that they suffer of the exactly same issue - even if you manually delete from control panel / windows 10 menu the printers, they still hide in the registry, and all of sudden, a deleted printers appear again and set itself as default!

We finally started to configure things properly, editing the RDweb RDP Icon and disabling to connect printers, letting the users connect the printers and set default on RDSH Servers, in the way redirected printers are not an Issue anymore. And, for all people working Home-Office, they can simply use the other RDP Icon where printers get connected.

Best regards