View Users default printer not always sticking

[Mercutio879b]

We are using VMWare Horizon View 5.2 and it seems that about 50% of the time, our users' default printer is not remember between sessions. I put a ticket in with VMWare, who referred me to the KB telling us to use their Location Based printing service, or uninstall ThinPrint. Location Based Printing is not really an option. I've disabled the ThinPrint services in our master image, then recomposed, but that didn't seem to help. Anybody out there figure out a fix?

[CameronUBC]

To fix this, I wrote a script that looks at the default printer and exports it to a registry file in the user's profile only if it's set to network printer on a specific set of print servers at my organization. At login time the default printer is restored. All network printers are exported and restored at logon/logoff too so they don't disappear by accident as we see sometimes too for printers not deployed through group policy.

This was especially important as we moved to using persona management, as this caused this problem to happen way more often on a floating pool.

[Mercutio879b · Accepted solution]

I may have found a solution. The VMWare rep assigned the case I filed said that ThinPrint can overwrite Personas. I tried just disabling the services, but that didn't work. I ended up completely uninstalling the 'Virtual Printing' section of the VMWare View Agent and it seems to have worked, although we are still doing some testing.

[iamxCPx]

Do you mind sharing your little script?

I have similar issues.

This printer thing has been a challenge since we have deployed the VMware View.

Thanks.

[CameronUBC]

VBScript logoff

Set oShell = CreateObject("WScript.Shell")
strValue = "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device"
strPrinter = oShell.RegRead(strValue)

If inStr(UCASE(strPrinter), "V-ITSV-PRINT02") Or inStr(UCASE(strPrinter), "PROD-PRINT02") Then
oShell.Run("reg export ""HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows"" ""%APPDATA%\printdefault.reg"" /y")
End If

oShell.Run("reg export ""HKCU\Printers\Connections"" ""%APPDATA%\print.reg"" /y")

Batch login script:

@echo off

timeout 120 > nul

reg import %APPDATA%\print.reg

reg import %APPDATA%\printdefault.reg

[Mercutio879b]

The ThinPrint was the culprit, by the way. After removing the Virtual Printing section of the install, all our issues disappeared. We may be in the minority, though, as we have purged all locally attached printers like the vermin they are.

[CameronUBC]

Yes, I wish I could turn off thinprint at my org but people rely on it

[iamxCPx]

Is your View deployment a floating or persistent desktop?

[Mercutio879b]

It's a floating pool, and it refreshes the image when the user logs out. I didn't realize I hadn't marked it as answered, but removing ThinPrint did resolve it for our deployment.

[iamxCPx]

I have floating desktop (5.2) and refresh when they log off too.

But I don't think refresh was the issue for me but recompose was.

We have 5 remote offices and each has their own default network printer. Not to mention in the main office we have 3 main network printers that the users could choose. Every time I recomposed a new image, their default printer will all reset to the one that the master image was defaulted to.

OR

When the users logged on from somewhere remote (home or hotel) using their home pc or tablet when there are no local or network printer is available, the default printer will get reset to something like "Microsoft XPS Document Writer" or "Adobe PDF" or "Send To OneNote 2010", etc. Therefore when they are back in the office and logged on to their pc or zero client, they will have to reset the default network printer back to the printer of their choosing manually.

Is your situation a bit similar to ours when you're doing your testing with ThinPrint uninstalled from the agent?

Thanks.

[Mercutio879b]

We have ~250 users (about 50 migrated to View). I haven't seen the same issue with the recompose causing printer resets. Just to be clear, according to VMWare, ThinPrint does it's thing after Personas sets the default printer, if it's deployed via group policy (as ours are, not a login script). This is what was biting us.  I didn't want to rebuild the rather complex group policy in VMWare's Location Based printing services, and as it was going to be of limited use to us, we uninstalled ThinPrint from the agent. It's working fine now.

Also, I removed the OneNote and Fax print objects. No need for those to exist. That seemed to help as well. We don't have any PDF printers installed yet.

Message was edited by: Mercutio879b

[iamxCPx]

Just want to confirm with you, so you used LBP through GPO and disabled the thinprint from the Agent or not using the LBP through GPO (just a regular GPO for printer assignment) and disabled thinprint from the agent to make the default printer to stick?

Thanks!

[Mercutio879b]

I uninstalled the View Agent, rebooted, then reinstalled, with the Virtual Printing option unchecked. That was the only thing that seemed to work. We are not using LBP, just regular GPO.