Currently we are in the latest appvolumes VERSION: 126.96.36.199 and after a user gets an appvolume , he looses the default printer.
All the printers are network mapped and when the user logon gets as default "send to onenote 2010"
I try to change the registry according to VMware Knowledge Base but no luck.
This issue is getting worst and worst as more users get appvolumes.
I dint find any article that resolves the issue.
If anyone has any kind of solution , please help.
do you use persistent or non-persistent desktops?
That happens to our floating pools.
We use floating (non-persistent) and we use persona for the profiles.
When looking at the appvolumes agent in combination with the writable we see the exact same issue.
It seems as if printer being attached is not being saved within the desktop thus after logoff printers are removed. When you then login the printers need to be recreated and Windows selects the first printer available as default. We use UEM for this setting and that seems to work quite well.
we deploy the printers through group policy, and it will be too difficult for the business to go via UEM.
I open a ticket with VMware to check the issue, lets see what they will suggest.
If you have UEM available to you I would suggest using it. I don't deploy mapped printers through GPO as you are doing. My users will add whatever printer they wish from my print server and UEM tracks their added printers and their selected default. UEM has a standard template for printers. Do you have the Thinprint service installed and running? That caused me a major headache with printers as it would overwrite UEM settings and select a random available printer as a default. I had to manually set the service through GPO to prevent it from happening.
I run non-persistent instant clones with AppVolumes and UEM.
# Expanded settings for Windows Common Setting 'Printers':
That's a very good idea for the Thinprint service. We have it installed and running, but we never had issue.
Of course with app volumes maybe somersetting change.
The problem is the "delay" that mapped network printers appear on the vdi.
I will give a try to the thinprint service.
The Thinprint service caused problems as soon as started it. I modified local security policies in GPO to set the service to manual so users can start/stop when they are working remotely and would like the functionality.
With UEM and adding all my print drivers to my base image. I don't have much of a delay anymore with printers showing under Devices and Printers. I know the Appvolumes service causes problems with some legacy apps for me, but I doubt it would have any effect on Windows printers.