what is the best way to map network printer on persistent desktop without writable volume?
Are you using UEM? It is easy to map printers in UEM based on Organization unit, Pool Name, IP address, Client location etc. Please have a look here:
Choosing Printing Options for VMware Horizon 7
If no UEM, you may consider using logon scripts:
hmm, I have a error by map the network printer manually, with script or uem. On my persistent desktop without writables volume (desktop not refresh by restart) I can map my network printers by first logon on the desktop. By second logon I cannot map the network printers.
After refresh/reset the desktop I have the same effect, by second logon I cannot map my printers, network connection error.
I use appvolumes 2.13.
This is out of my production UEM. I track all user added network printers from my print server. All are persisted through logoff on instant clone desktop pools.
the problem is, after second login I cannot map my network printers from my print server.
Whether manual, script or uem I cannot map my printes, i have the error: network connection.
On the second login I can map new printers (another driver, another printer type) without problem, but after the next reboot I have the same error: network connection.
We have seen this issue with appstacks that have printer drivers installed. These appstacks were created with a 2.12. template.
Please try to NOT add the appstacks with a printer driver (appstacks with applications like Adobe Professional and such).
It seems as if the appstack registered the creation and deletion of the drivers for the printer which causes Appvolumes to no be able to install a new printer. Could you please post a screenshot of the exact error?
in my Appstacks I have no installed printer, I test only with Notepad++ Appstack.
By first login works my printer with appstack, only from the second login i have the error.
I've had some errors with users getting the printer not available from the print server. One log off solves it for my instant clones. One option I did do was install all the print drivers I have on my print server to my base image.
Are the printers showing in the registry?
With the Appvolumes agent 2.12 works this fine. I think since the Version 2.13 exists this problem.
Could you check with the latest 2.13.1 version please.
with the version 2.13.1 the same effect.
I see in the version 2.13/2.13.1 in process explorer the call to printer function ->(0043E818 FF1598554B00 call [USER32.dll!wsprintfW]), in the version 2.12 i cannot find this.
the appvolumes agent 2.13 has this problem with printer, can I use the 2.12 agent with 2.13 appvolumes manager?
This works fine for me.
with the latest version 2.13.2 we have the same error, with the version 2.12 works fine.
I am having the same issues since upgrading to 2.13.2 from 2.12.1. Printer worked fine before. I did the upgrade on the appvolumes manager to 2.13.2 and that work fine. But after i upgraded the agents on the linked clones to 2.13.2 . I am unable to add any network printers at all and the windows error.
Does anyone have a fix for this?
yes and no, with 2.13 agent and writable volume work printer mapping fine.
I think, it should work without writable volume.
Experts, what is the recommendation?
network printer on persistent desktop with or without writable volume?
A writable volumes isn't really a solution. I can't have 2000 users with writable volumes when we already have UEM setup for Profiles.
From what i've heard from VMWare they are trying to go away from writable volumes with profile data.
Right now i'm using 2.12.1 agent and it working fine at the moment. We do have have quite a few Appstacks that have virtual printers installed in there.
I'm going to try updating the appstack with a provisioning machine with the latest 2.13.2 agent and see if it fixes the issue.
the agent 2.13.2 does not work with printer map
I have a SR open 18706637202. They have sent my logs info to the Appvolume Developers. Sounds like it might not be fixed till the next release though.
So to give an update to this if anyone else has the problem. it looks like the issue was related to an older Appstack. We have been using app-volumes for 2 years now and had some Appstacks that were originally created with 2.10 or 2.11. I just recreated the appstack from scratch using the new templates for 2.13.2 and its working perfectly. It seems like the old appvolumes agent handles virtual printers differently than in the new version. I know this might be bad news for some of you has i have quite a few complicated appstack. On the bright side the updated appstacks seem to have improved my login time by at least 20 seconds.
do you use VDI Desktop with refresh/reset after logoff?