I have an environment with VMware View 6.1.1 linked clones and appvolumes 2.9.
Applications are delivered through Appvolumes appstacks
Users can install applications through Appvolumes writable volumes ((UIA_ONLY)
User profiles are being handled by Persona Management.
When I assign a writable volume to a user and the user logs in to Horizon View, the user gets assigned a VDI from the pool, the writable volume and other appstacks are being attached to the assigned VD, the logon occurs and the user can install applications. So no problem there.
When the user logs out of the VDI, the writable volume and appstack volumes are not being detached automatically. I then detach the appstacks and writable volume manually (via the vSphere client) and delete the desktop.
When the same user logs again in to Horizon View, he gets assigned a VDI from the linked clone pool, writable volume (UIA_ONLY) and other appstacks are being attached to the assigned VDI, but the VDI itself displays the message "Please wait for the App Volumes Service" and the logon process does not finish.
This situation only occurs when users are assigned a writable volume and does not occur when users are assigned only appstacks.
Enabling or disabling the option "Prevent user login if writable is in use on another computer" does not have any effect on resolving the problem.
Have you ever received an answer from support?
We do not have that issue now but I'm not quite sure if you have the exact same setup as we have.
No answer from support yet? They are "working on it". It's very frustrating.
I'll try to discuss at VMworld Barcelona next month with the product Manager. Are you going to VMworld?
Support asked us now to change the registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\Parameters\RebootAfterDetach from 0 to 1
We tested this out but it did not work 😞
Now we're waiting again for support to call us and help us out. I have however the impression that they are doing trial and error with different settings.
As far as my knowledge goes, rebootafterdetach is useless if you have refres immediatly configured, it does exactly the same thing.
The only reason you would like to this is for as far as i'm aware is due to a timing issue.
I'm very surprised though that you have this issue. You only have the writable volumes at 1 datastore??
yes, we have a single dedicated datastore for writable volumes (and the template)
There's now a new Support Engineer working on the Support Case at VMware (SR# 15722287707). He is in contact with engineering and is waiting for a response from them.
Currently tracking this issue with a few customers and a possible hotfix will be coming in the next few weeks. Will post here when we have a release candidate to share.
Hi. Is there any resolution to this annoying issue? I'm seeing exactly the same things.
Any updates from Vmware or anyone find a workaround. Same exact issue using AppVol 2.10
We did not get any resolution from VMware on our case regarding this problem (Case # 15722287707) and the case was closed.
Because of the many bugs in version 2.x of AppVolumes we discovered and the lack of good support from VMware for this product, the end-customer decided to stop all together with AppVolumes 2.x. They are now running full clone machines. Not the ideal solution, not the cheapest solution, but at least it works.
I am now testing version 3.0 in my lab. Hopefully there will be less bugs in this version. Unfortunately there is no upgrade possibility from 2.x to 3.0. It's rip and replace + recreate all the appstacks.
Why is everyone wanting to use WV's when they are not the best solution and bugging?
I use UEM or Persona Management.to handle the Users Profile & Configurations.
I have a brand new install and have the ability to rip and go right to 3.0 have you seen many issues with 3.0?
Hot off the presses: We are using 2.10 and experienced the same issue identified in this thread. Opened a ticket and Shaun from VMWare was great! We performed some cleanup and applied a couple Microsoft Hotfixes
1. Remove any hidden network cards from your Golden image (we had 1 from the way we spun the VM up originally) devmgr_show_nonpresent_devices=1 Shaun mentioned uneeded or hidden network cards on your Golden image can cause delays during login on the VDI
2. Install MS Hotfix KB2550978 https://support.microsoft.com/en-us/kb/2550978 (Best practices if using VMXNET3 adapters for your VDI's)
3. Install MS Hotfix 2614892 https://support.microsoft.com/en-us/kb/2614892 this the fix Shaun said fixed the issue we were experiencing in 2.10
NOTE: If you are using 2.9, Shaun did mention there is a know issue with AppVol not dismouting the writable during loggoff and there is a different fix/update for that condition (although identical locking during logon seen as my issue)
Hope this helps!
Thank you very much for the information. We have had this issue affecting our Horizon 6.22 solution for almost 3 weeks now. We have rebuilt pretty much every component of the solution, including the vSAN, Connection Servers, UEM solution and AppVolumes 2.9 and 2.10 servers multiple times.
We have also rebuilt out Windows 7 images multiple times, installing agents in varying different methods and orders. TBH it been an absolute nighmare, and VMware Technical Support have struggled to find a solution despite taking lots of logs and quite a few remote sesisons to our systems.
Finally, last night, I added the 2 x Windows hot-fixes to our build script and added 2 x registry keys suggested by VMware for AppVolumes, then recomposed our Linked Clone Pools. Today we have not had a single session hang at logon - the first clear day for two weeks.
So what were the changes exactly that worked for you?
I already have the two MS hot fixes on my VDIs + Gold image.
AV 2.10 on Win2012R2
Win7 - VDI
Same issue for us. Everything was working great (we are doing a test pilot) until today. WV's are not being detached (or App stacks for that matter) upon logoff. I have to reboot the VDI to get the disks to detach. This all started after I applied June MS updates to the gold VDI image and recomposed.
Can't go to AV 3.0 because our vSphere environment is still 5.5
Don't go to AppVolumes 3.0. App volumes 3.0 is not foreseen for on-premises installations.
See http://ituda.com/vmware-appvolumes-vmwares-strategy-for-version-2-x-and-3-x/ for more explanation
Well today all 5 of our test users had issues with their WV's and things not detaching and working correctly.
We ended up scrapping 2.10 and started fresh with 2.11. I'll let you know in a few days how its holding up.
I would recommend checking to see if the user is actually logged off by checking Windows Events. You maybe having a hung session issue.