On a number of occurrences, when an AppStack is mounted, a corresponding "CVApps" drive is mounted in My Computer. This condition happens mostly when an AppStack is mounted immediately, but I've also had it occur "at next login" or after a refresh/recompose. Also happens with both dedicated and floating desktops.\
I've seen an article online about verifying the value of a registry key. That key did not appear to be the issue in my case.
AppVolumes 2.7
any help would be appreciated.
Do you see this behaviour with any specific AppStack or all AppStacks?
Can you try restarting the App Volume service and check if it works?
With registry key do you mean the DriveLetterSettings?
The key you need to have is the following HKLM\SYSTEM\CurrentControlSet\services\svdriver\Parameters\DriveLetterSettings=6 (DWORD value).
This setting means give the writable volume a drive letter but hide it (used for installing add-ons in Google Chrome) and don't give the appstack a drive letter at all.
Did you accidentally attached an appstack to the golden image?? It could be that there is still a reference in the registry that holds the information for this disk. You could try and check the registry settings in the key HKLM\System\MountedDevices and do a cross reference with a machine that's cleanly installed.
Hi PirateFan
We have the same issue. It only occurs with agent version 2.7, we haven't tested 2.9 yet. To work around we rolled back to the 2.6 agent. We have a job open with VMware with the issue being reproduced in their labs. We noticed it first when mapped drives were bing replaced with the CVApps folders. We tried, in vain, to resolve the issue on our own, but in the end had to log a job with VMware. I could list the steps we tried if you'd like, to see if there was something else you would like to attempt.
Cheers,
Nick
We are running App Volumes 2.9.0 and we are experiencing the same problem. We have a workstation with 6 App Stacks assigned and all 6 show up as CVApps in Computer each with their own drive letter. With enough attachments we will run out of drive letters or start conflicting with mapped drives. We downgraded to 2.7 and the problem persists.
HKLM\System\CurrentControlSet\services\svdriver\Parameters - DriveLetterSettings does not seem to do anything at all. Tried 0x00000002 and 0x00000006 with no change.
We are trying to get our hands on App Volumes 2.6 to see if the problem goes away.
Alright, we have App Volumes Manager 2.9 with App Volumes Agent 2.6 deployed and the App Stacks are not mounting drive letters any more. The applications are still working, too. As far as we can tell there is no problem running our setup with the 2.6 agent and the 2.9 manager. We will probably continue on this way until VMware posts a fix for the unwanted drive mappings with App Stacks.
Good luck.
Hey Tim,
We are using Agent 2.9 and manager 2.9 and i don't see the issue to be honest. Could you check and see what kind of parameters you have in the HKLM\System\CurrentControlSet\services\svservice and svdriver? In the old versions there was another Driveletter setting that is still in documentation (i believe it is DLWritebleVolume). If you still have this setting, please remove it.
Also. Did you check the HKLM\Syetem\MountedDevices in the golden image? It should only hold the C drive and maybe A for disk and D for CD drive. All other references should be gone. If you accidentaly added appstacks to the golden image it could cause these errors.
Our Gold image was built fresh with App Volumes 2.9. No upgrades from older versions. Checked registry for other parameters and there are none. App Stacks were never attached to the Gold at any time. The MountedDevices registry key is clean. We use user assigned app stacks only in our environment. Machine assigned messes with our linked-clones and they break in View. VMware App Volumes support confirms that machine assigned with linked-clones is a bad idea. We also do not use writeable volumes as VMware is depreciating WVs to make way for the better solution User Experience Manager (formally Immidio). Even with one App Stack assigned we get the CVApps drive mount in version 2.9. We also saw it in agent version 2.7. In agent version 2.6 it goes away.
As far as we can tell in our testing, either the HKLM\SYSTEM\CurrentControlSet\services\svdriver\Parameters\DriveLetterSettings is ignored or the 2.7 and 2.9 agents are broken in that regard. Now you could say I'm doing something to cause this. Maybe I am. However, I had a Parent image snapshot with app volumes agent 2.9 composed to a linked-clone pool where the attached app stacks had mounted CVApps drives. I then took the same parent image, uninstalled 2.9, installed 2.7, took a new snapshot, and recomposed the pool with the new snapshot and the problem persisted. I proceeded to take the same steps except uninstalled 2.7 and installed 2.6 and the problem went away. Given that my testing has only changed 1 variable: the agent version, my conclusion is that there is a problem with the agent.
We see no performance hindrance using the 2.9 manager and a 2.6 agent; in fact by the time a view client connects to the desktop and the user can see the windows login process, the app volumes step has already finished: even with 8 app stack user assignments. So for the time being we will stick with what is working in production and test anything that VMware puts out that could potential fix this CVApps mount thing.
Same Problem here - is there a solution available ?
Jens
We were also experiencing the same issue after upgrading to App Volumes 2.9.0, the registry key below seems to have [inexplicably] resolved it:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\Parameters]
"VolDelayLoadTime"=dword:00000000
I say inexplicably because according to the documentation the key above should be the default if left undefined: "Defined in seconds, how long after logon process to delay volume attachments. This value is ignored if a writable volume is used. Writable volumes must be attached prior to any AppStacks. If the value is greater than VolWaitTimeout, it will be reduced to the value of VolWaitTimeout. This may speed up login time by delaying the virtualizing of applications until after logon is complete. If undefined, default is 0 (do not delay load time)".
There is a bug in 2.7 and 2.9 related to this and you found it. This is why that reg key resolved it. This is being fixed in 2.10.
Yeah, VMware Technical support told me this registry key execplicibly fixes a lot of problems!
Was this actually fixed in 2.10?
Please let us know, if this has been fixed in 2.10.
I would say yes, I have deployed AV 2.10 to multiple clients and have not seen that problem.
The registry fix worked in 2.9 for me, but I only had that problem once.
2.7 - 2.9 needed VolDelayLoadTime = 0 to be set explicitly, if not entered in registry it did not apply and drive letters still appeared.
I have only very rarely seen drive letters being consumed (1 or 2 slow appstacks) with this config, the issue has been resolved for us.
2.10 should also have this fix carried through (I haven't tested it)
