If you have a loginscript that simply installs printers and installation is done during logon it may fails due to the print spooler service being restarted. I do know why they do the spooler restart but we are in the midst of trying to find a way to work around that. Why the printers are deleted then I have no idea. So it doesn't seem to be related with the quick login but more with the restarting of the print spooler.
The moment the spooler is restarted I lose my printers. As always, at the end of the attachment and merging of appstacks svservice restarts the spooler. The logon time is still very fast if you don't have a writable (about 18 seconds in our case with 8 appstacks) but they still need to be processed after logon off course.Īfter i'm logged in I am able to see the locally installed printers. I did some more research on it and indeed am seeing the exact same issue but with some more info. At least this is manageable, but I guess those "30-50%" decreased login times are a result of not actually attaching everything in the stacks. Here's how it breaks down:Ģ.11 Agent + 2.11 stack w/virtual printer = all printers present (incl XPS from parent image)Ģ.11 Agent + 2.12 stack w/virtual printer = only 2.12 stack printer present (none from parent image)Ģ.12 Agent + 2.11 stack w/virtual printer = no printers presentĢ.12 Agent + 2.12 stack w/virtual printer = no printers presentīetween this and the requirement for capture VMs to be domain joined this is another great example of 2 steps forward, 1 back from the App Volumes dev team. Most of my stacks were built with the 2.11 agent/template, but even after updating a stack to 2.12 it persists.ĭowngrading the AppVol agent to 2.11 resolves the issue. We have a few stacks with virtual printers (Adobe Acrobat X, Bullzip PDF, CutePDF) and all (including the XPS printer on the image itself) are missing with stacks successfully attached (any stack). I'm seeing this issue in my env as well under 2.12. The version of AppVolumes we are testing with was downloaded on 12/9/16 - and the filename is 'Vmware_App_Volumes_v121.iso' Strangely enough, the baseline AppStack that was updated to 2.12 mounted on a VM running the Agent 2.11, the default printers (XPS,Fax OneNote) persist after the appstack is attached All the default printers from the Golden Image and from the assigned baseline AppStack are not available.
To reiterate, the linked clone Pool was provisioned and when the appstack is attached to the user session ,only network printers saved to the UEM profile of the user are available.
#Cutepdf printer windows 8 pdf
The Adobe PDF Printer is created on the AppStack during the provisioning process but, when attached to a Linked Clone VM, all the printers (XPS, Fax, OneNote) are removed and Adobe PDF Printer doesn't show up on the Linked Clone VM.ĪppStack was updated with new version of the Agent 2.12 from Agent 2.11, the master image for the linked cloned VDI pool was updated to Agent 2.12 from Agent 2.11 and the App Volumes Manager Server was updated to 2.12 from 2.11.
#Cutepdf printer windows 8 pro
We are experiencing the same problem, our original baseline AppStack includes, Java 8 U21, Shockwave, Adobe Reader DC and Acrobat Pro 11. Hope this helps until VMware can address. After applying the above the local printers showed and after doing a repair on the app that installed an additional local printer they all appeared. This worked in my environment and I had two local printers on the golden image and one in the AppStack. Otherwise you may get local printers, but the CutePDF printer will still not appear.
#Cutepdf printer windows 8 install
If you have applications like CutePDF that install local printers as part of your AppStack capture you may have to repair/reinstall that app after performing the above steps or recreate the install from scratch after apply the above settings first. Drill down to the mountpoint and unique ID folders and edit the file snapvol.cfg and add the following lines in the exclude_registry area (or anywhere if you're messy).Įxclude_registry=\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\Print\PrintersĮxclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Print\Printers Once provisioning has started on the capture machine browse to C:\snapshotvolumetemp\ and press enter (hidden volume when provisioning is being performed)ģ. Stage your appstack to be updated and set it up on your provisioning (capture) machine.Ģ. This will need to be performed on all existing and new appstacks ġ. They are working on a permanent resolution, but this workaround did the trick in my environment Apparently VMware made some changes in 2.12 that took away some exclusions for printer settings in the registry.
0 kommentar(er)
