Thin clients with roaming profiles missing GPO applied printers when connecting to RDS farm

Hi, I posted a question a month ago and while I received a response, things have improved and I want to provide a fresh synopsis in the hopes we've overlooked something simple.

Our environment: 8 RDS VMs running Microsoft Server 2012. They run in a farm that assigns a new server to HP thin clients when they disconnect and log in again (roaming profiles).
The RDS servers were cloned from a template server.  About a month ago, a 2008 print server was retired and printers were exported off it using Print Management and imported into the new Windows Server 2012 R2 VM.

The 80 or so printers, mostly HP using the Universal printer driver, are deployed via Group Policy.
The policies are set up with Security filtering applying to the AD group, and both that group and Authenticated Users are listed under the Delegation tab.
The printers are added under User Configuration - Policies - Windows Settings - Printer Connections.

Additional information:
We have loopback enabled, but printer redirection disabled.

Behavior:
1. We were getting duplicates of the printers stacking on top of one another, where you right click on them. This has since stopped by putting in the value of “RemovePrintersAtLogoff” to 0 under the key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider.
2. Now, every morning, people log into the farm and some people don't see their printers. It doesn't happen every day but it does happen.  When gpresult /r is run, the group policies ARE showing up as applied.
We can go to these clients and manually add the printer with no issues, i.e. \\newprintserver\printername.

The method I have read that seems to clean things up a little is to run a Powershell script that cleans the registry on the RDS servers of all instances of the printer connections so they rebuild from scratch.
HKLM\SYSTEM\CurrentControlSet\Control\Class\{1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc} <- All numbered keys
HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses\{0ecef634-6ef0-472a-8085-5ad023ecbccd} <- All ##?#SWD#PRINTENUM# keys
HKLM\SYSTEM\CurrentControlSet\Control\DeviceContainers\ <- All keys containing SWD\PRINTENUM values under GUID\BaseContainers\GUID
HKLM\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM\ <- All subkeys
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\ <- Everything
This was taken from this article: https://community.spiceworks.com/topic/1601648-terminal-server-printing-pdf-s-server-2012-r2-adobe-reader-dc-group-policy

We've tested it on a server pulled out of rotation and it seems to be working, but as the article suggests running this once a week, it looks like we may be running this on all the RDS servers once a night if it works. The registries fill up very quickly with so many people using so many different printers. Testing this evening at 1:00am, and we would even be open to making the same changes to the cloning template and re-cloning the whole farm, as that would ensure all of the printer drivers on the template would be the exact same on each member of the farm.

So Experts, the questions are:
1. Are we missing or adding anything to this setup that would be interfering with the Group Policies being run correctly every morning? Does anyone else run an RDS environment in this manner and perform a certain best practice on their roaming profiles, the GPOs, etc?
2. What would cause the Group policies to be applied but not install the printer, when we can manually add them with no driver issues?

Thanks for any assistance you can provide.