App Volumes Agent causes Network Printers to fail to install

[taopiglet]

We have recently setup an App Volumes 2.7 Server/environment utilizing AppStacks ONLY (NO Writable Volumes).  The AppStacks are working fine on Linked Clone Virtual Desktops.

We normally deploy our network printers via Group Policy using pushprinterconnections.exe (part of Windows 2008 R2).  This has worked fine for years until we installed the App Volumes Agent on the Virtual Desktops.  Now, the Network Printers will not install on the Virtual Desktops.  The only errors we see are in Event Viewer (Applications and Services Logs/Microsoft/Windows/Print Services/Admin).  The below are the errors we see:

Error 601:  Client Side Rendering

The print spooler failed to download and import the printer driver from \\SERVERNAME into the driver store for driver HP Laserjet xxxx

Error 215:  Installing a Print Driver

Installing printer driver HP Laserjet xxxx failed, error code 0x3, HRESULT 0x80070057

We also cannot manually install printers with the App Volumes Agent installed once we have received the above errors...we get the message "Printer cannot be found". 

NOTE:  We are using the same exact Master Image to create Windows 7 (SP1) Linked Clone Virtual Desktops.  This image has 2 Snapshots...one without App Volumes Agent and one with App Volumes Agent.  This is the only difference between the two snapshots.  Linked clones created without the App Volumes Agent can install/receive Group Policy Network Printers without any issues.  Linked clones created with the App Volumes Agent installed fail to install the Network Printers.

[jrp1]

Wow.  It looks like I have the same issue in my environment.  I tried mapping printers with UEM and via GPO and it's sporadic at best with App Stacks attached.  Often no printers appear and error event 601 always appears when there's an issue.  I detach all assigned App Stacks and printers appear each time.  Unreal.  I'm opening a ticket.  Let me know if you found a resolution.

[HenryLe0311]

Does this happen when appstacks are attached or just when the app volumes software is in the image? From a troublshooting stand point I would start there.

Login to a desktop that is managed by Appvolumes but has no appstacks assigned to the machine or the user (App or writable).

Try mapping printers. If it still works move on.

Now try an app stack. a simple one like firefox or something. then try other app stacks. Maybe even one at a time.

What this will tell you is if there is a conflict somewhere with just the appvolumes agent or is it something conflicting in a layer. Like does one of the appstacks have a print driver or something in that is touching the windows driver store and therefore causing a problem with the new mapped printer objects.

[jrp1]

The agent doesn't seem to conflict, it's just when App Stacks are in the process of attaching.  I unassigned all App Stacks from a VM and both assigned printers install no problem.  If I reattach a single App Stack the 601 error reappears and a printer is missing.  Manually installing the printer post-login works fine but no one wants to manually add in printers.

[HenryLe0311]

whats in your app stacks that you are attaching? anything touching the driver store?

[jrp1]

No custom drivers are being used.  Just Adobe Reader, Flash, Java and a couple other standard applications.  I've got a case open and a VMware engineer was already able to replicate the issue in a lab environment.

[Jason_Marshall]

Do you have the SR# for this?

[jrp1]

15765041809

[Jason_Marshall]

Sorry for the delay. It does appear that there is some issue in specific circumstances that creates the printer to not refresh properly. If you manually refresh the UEM environment after all AppStacks have been attached does it work as expected?

[taopiglet]

We are not using UEM yet...we are only using App Volumes to assign applications.  Is it possible to refresh the environment when we are not using UEM specifically?

[Ray_handels]

Just to add a little info into the conversation.

We added printers using the GPO Preference policy with item level targeting. One of the hassles is that logging in is slowed down hugely because of the item level targeting. The other issue (which in my opinion is much more of an issue) is that AppVolumes does a spooler restart at the end of attaching all appstacks (what normally is being processed after login to speed up login process). Because attaching printers, if the drivers are not in the golden image, takes quite some time we saw that attaching printers and restarting the spooler happened at the exact same time.

We are using writable volumes and saw some really quircky things happening with printers. Drivers were being marked as #DELETED# in the writable volume causing the errors with adding printers you described.

We eventually created a powershell script that waits for 90 second and then starts to create the printers if not created already.

Until now we didn't have any issue with adding network printers anymore. If you are using some sort of script, just add a timeout inthere to create the printers at a later time after logon.

And for the record. My guess is that UEM will have the exact same issue because for as far as I know UEM does not know when AppVolumes is ready with processing appstacks (and stopiing and starting the spooler afterwards).

[MrSeagull]

We're having the exact same issue in our environment, we do not use UEM. Our printers are mapped via GPO, but when we apply app volumes, no network printers are present, and any attempt to add them manually gives the error 0x00000bc4 - No printers were found.

Has anyone tried this yet?"

http://kb.vmware.com/kb/2137401

We're going to try this fix today, I'll report back what I find here.



Apparently, this registry key has been set to that value the whole time, so this does not resolve the issue.

[jahos_]

This is indeed a very annoying issue.

I also tried the VolDelayLoadTime reg key, but it is not working.

Did you find a solution for this?

[jahos_]

Hi Jason,

This is indeed the case. Manually refreshing the uem environment adds the printers

[Ray_handels]

As said before. After all appstacks are attached AppVolumes triggers a spooler restart, you can check the svservice.log for it. After attaching all appstacks it says restarting spooler.

My guess is that UEM attaches the printer at the exact same time as Appvolumes triggers the spooler restart because they are still 2 different applications.

They either need to buil in an options that makes UEM wait for Appvolumes or at least waits for the spooler restart or not do a spooler restart at all. But then printers added into the Appstacks (looking at you Adobe Pro) won't work anymore, they need a spooler restart.

Manually refreshing it does make sense because then the spooler restart has happened and Windows can create the printers and install the drivers.

[jahos_]

Hi Ray,

The print spooler restart is indeed the problem.

Do you know where to remove the print spooler restart?

[Ray_handels]

Hey Jahos,

I don't believe you can actually remove it because it is being triggered by the client itself. But maybe someone from VMWare  can tell you that (or just create an SR).

What we eventually did (because we did need the restart of the spooler service) is create a script that installs the printer and set a wait command in it. This way the printers are being configured correctly.

[jahos_]

For now the only workaround provided by support is to add a scheduled task with delayed start and a repeat after 2 minutes (depending on your appstacks) which starts a uemrefresh.

I don't really like these kinds of workarounds, but for now it will do. (It is this or no appvolumes)

[ol1v13r]

i have the same issue with appstack and network printers installation. My workaround is to create an appstack with all printers drivers.

[SchwarzC]

Are there some updates on this AppVol - Printers - Spooler Issue? We have a simular issue and I am searching for input on this matter - thanks!