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.
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??
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.
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
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.