Could you open a case for this as this type of issue while somewhat common can be very difficult to diagnose. It will require the review of a few files that will be present on the provisioning V...
See more...
Could you open a case for this as this type of issue while somewhat common can be very difficult to diagnose. It will require the review of a few files that will be present on the provisioning VM during capture and also on a VM created from the base image with a volume attached. There will also be Agent log analysis required from the provisioning VM and the end user VM's
There can be issues with Autodesk and AutoCad as well as other similar applications because they are so large and require time to place their registry keys and settings as well as other services....
See more...
There can be issues with Autodesk and AutoCad as well as other similar applications because they are so large and require time to place their registry keys and settings as well as other services. For testing purposes, if the application is installed in an appstack you could try disabling the reverse_replicate registry setting in the HKLM\SYSTEM\CurrentControlSet\services\svdriver\Parameters registry location on the base image (Will increase logon time) Or Create a writable volume for a test user and see if that resolves it at there may be some module that needs to write to a location that may not be present or already populated. If the application is installed on the base image then without appstacks assigned at all does it work ok? I would also recommend while testing or before testing that you open a case to help you with this.
Do you see anything of interest in the App Volumes svservice.log, Horizon Agent debug log or Windows Events on the VM at the time of the message appearing?
If Rays option works please update us..if not we had a similar case last year where there was an appstack copy operation from vSan to NFS and then vSan. It turned out to be default behavior on th...
See more...
If Rays option works please update us..if not we had a similar case last year where there was an appstack copy operation from vSan to NFS and then vSan. It turned out to be default behavior on the copy to the NFS if im not mistaken but it came to be storage related after a test of a NON appstack .vmdk copy operation (Any .vmdk created in vCenter) produced the same issue. If the same is true for you then i recommend opening a case with vSan for further troubleshooting on this one.
Hi, If not done so already you can set debug logging on the App Volumes Managers by following KB 2101668. You can check in System Messages under the Activity tab Once you save the update...
See more...
Hi, If not done so already you can set debug logging on the App Volumes Managers by following KB 2101668. You can check in System Messages under the Activity tab Once you save the update writable in the Manager and login to a VM with a test user you can check https://<AVManagerFQDN>/log and see if there is any information on the update. Also what version of App Volumes is this? Can you open a case for this issue? https://kb.vmware.com/s/article/2101668
Sorry i was wrong there... They are used to login to the actual application Running the command you provided allows the smart card to work....so do you need to run the command everytime the use...
See more...
Sorry i was wrong there... They are used to login to the actual application Running the command you provided allows the smart card to work....so do you need to run the command everytime the user wishes to use the application?
It may be possible to put "certutil -scinfo" in a batch file....most likely a batch file thats run on logon such as logon.bat or logon_postsvc.bat Check out the documentation for which script w...
See more...
It may be possible to put "certutil -scinfo" in a batch file....most likely a batch file thats run on logon such as logon.bat or logon_postsvc.bat Check out the documentation for which script would best suit the driver and you can set these by attaching a volume to a VM without the Agent installed.
You can edit the existing template by attaching the template to a VM and modify it that way. I would recommend creating a new custom template rather than modifying the original. You can follow t...
See more...
You can edit the existing template by attaching the template to a VM and modify it that way. I would recommend creating a new custom template rather than modifying the original. You can follow this KB for that: VMware Knowledge Base
These exclusions from the snapvol.cfg do work: exclude_registry=\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\Contr...
See more...
These exclusions from the snapvol.cfg do work: exclude_registry=\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Print\Printers However it does matter whether your VM's are 32 bit or 64 bit so at the end of the snapvol.cfg you will find the x64 section whereas all above that is for x86. Place the above keys in the relevant section and save the file and try it again........