App Volumes 2.12 User Logs in Before Appstacks finish Processing

[VDIMega]

sometimes when a user logs into his W10 1607 desktop, he sees a drive letter for each of the appstacks.  about 5 minuets later, the drive letters go away and the apps they are supposed to serve appear.  The problem is that the users can't find the apps for the first 5 minutes, and UEM directflex does not detect the apps during logon, so when the apps finally do appear, no settings are loaded for them.

all machines refresh on logoff.

Has anyone else seen this?

[Ray_handels]

That's the entire idea of how 2.12 works. Log in is much quicker but at the end it still needs to process the appstacks.

Only thing we see is that it takes about 8 seconds at max to attach an appstack, a little bit more for the writable. So 5 minutes is a very long time. Max we saw is about 1 minute after the user is logged in.

How many appstacks do these users have? And do you have some extra scripts or info in those appstacks that also need to run?

I would suggest looking into the svservice.log file to see where these time issues arise from.

[VDIMega]

I think the issue was that some appstacks had been attached to the parent VM at some point, which left some "debris" on the record of mounted devices.  We cleared a few registry values from [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] leaving only the two values that represent the default drives the master image always has (e.g., \DosDevices\C:)

I'll let a few weeks pass to see if it happens again before declaring victory.

[Ray_handels]

Or that ...

Had that issue waaay back in the days.. Learned the hard way .

Would you mind posting the information you left here?? Just for a reference??

[jmatz135]

I am having the same issue in two different environments I run.  The appstacks don't finish processing before login even if I set the WaitForFirstVolumeOnlyValue regvalue to 0 which is supposed to make the system wait for all volumes to load before logon continues.  This is not supposed to happen.  Having the applications popup after login isn't a solution either because that just breaks UEM policies as the application doesn't exist as far as UEM is concerned.  Also, it is worthless anyway because the user can't really use the desktop if their applications aren't there so what is the point of having the desktop logged in without the applications.

I am using Windows 7 by the way and these are completely fresh base master images so they have never had an application volume applied and thus there isn't any cruft in the HKLM\System\MountedDevices registry key so I'm pretty sure that isn't the solution.

[Ray_handels]

Hey jmatz,

What version of Appvolumes are you using??

For the driveletter not to appear please follow the following KB article https://kb.vmware.com/kb/2139351.

When you have appstacks created with a non 2.12 template the nodefaultdriveletter setting for the disk is not in place. I've tested it and I don't see the driveletters anymore.

Regarding the 2.12 version I do see something different. I am curious though if it is just my machine or maybe more people are seeing this.

When I log in (which still is quite quick) i can see a process running being drvinst.exe. Also, if I go to the c:\snapvolumestemp folder I can see the disk being added one by one but it can take up to 2 minutes for the disks to be there. Once the disks are there Appvolumes processes them within a few seconds, even apps like ArcGis. But because not all disks are there in the first place I'm missing out on a few applications that users need to wait for. This mostly happens if I start to pile up the appstacks. When using 8 appstacks (no writable) it can take up to 2,5 minute.

And just for the record. I don't mind applications not being there when the user logs in. Our office applications and browsers (which are mostly used) are in the golden image. If a user can login within 20 seconds and start using his default applications I don't mind waiting for a few seconds for all extra applications to be there.

[jmatz135]

I'm using App Volumes 2.12.  I'm not concerned about the drive letter being there since as soon as the appstack finishes processing it goes away.  Of course when I log on and the appstack is not finished processing the drive is visible until it finishes processing which could be confusing to the user, but if the WaitForFirstVolumeOnlyValue registry key actually worked as it is supposed to and the stacks waited to be processed before login then that wouldn't be an issue at all.  The problem is App Volumes apparently doesn't recognize this value anymore, in fact it doesn't even wait for the first volume which is what the default behavior is.  Basically it just lets the login proceed as normal as if there were no appstacks attached, which is not the stated behavior. 

You may not mind having the users login before the appstacks finish processing but I do.  It would confuse our users for one, two we put most of our applications in appstacks including necessary applications, three this screw up UEM as it doesn't recognize the application being there at login, so say you have Google Chrome in an appstack an you have the users settings copied in at login instead of using directflex to copy it in at launch.  If the Chrome appstack isn't processed before login finishes UEM doesn't think Chrome is there so it doesn't apply the settings for Chrome, a few seconds later Chrome shows up, the user launches Chrome and none of their bookmarks, settings, etc are there.  They call the helpdesk who says try logging off and back on which then causes UEM to capture the Chrome settings at logoff because Chrome IS now there.  Of course the settings it captures are blank because none of the settings were copied in at login.  This is bad.  Yes, you can get around it with using directflex to copy the settings in at application launch but for some applications that isn't the best method or even one that works.

[Ray_handels]

We are using writable volumes for personalisation but I do see where you are coming from.

But do you actually see the disks popping up one by one after you are logged in or are they all there? Are you also seeing the drvinst.exe process when logging in? And what you are explaining seems to be that the Async logon is actually enabled (which is something you are clearly not looking for).

[jmatz135]

When you login if the appstacks haven't finished processing (the login process is held about 30% of the time, confusing the situation even more) you can then actually see all of the disks under computer, so you will see CVApps F: and CVApps G: for instance until the appstacks finish processing and then the drives disappear and your applications show up for use.  It isn't 1 at a time though, everything finishes at once.  So you can have 5 appstacks and all of the drives will be visible and then all 5 drives will go away at once and the applications will all appear at once. I did not see the drvinst.exe process but I may not have been quick enough.  The appstacks in my environment attach within about 10 seconds of the login finishing so it is kind of hard to catch it.  Async logon should not be on, I have not set that registry key.

[VDIMega · Accepted solution]

I have not had this problem even once since I remove those registry values!  Below are the values that I left in there:

[HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]

\\DosDevices\\C:

\\DosDevices\\D:

My master image has a C:\ drive and D:\ optical drive.  The reg values may vary depending on the drive letter configuration of other admins' master images.

[jmatz135]

I have built the base image from scratch multiple times in the last few weeks.  There is definitely nothing in the HKLM\SYSTEM\MountedDevices registry key.  To make sure though I went in and check on my base image when you said it worked for you and there was nothing in there but the C: and 😧 drive.

This is not the fix for me apparently.

[Ray_handels]

jmatz, did you create the appstack with an older template? That could explain the letters but it still should not log you on before appstacks are assigned.

Did you see the exact same behaviour vdimega when you didn;t have those mounteddevices inthere? That it created the disks one by one adding them one by one??

The driveletters I can live with (although it is fixed now) but it can take up to 3 minutes for all disks to be processed. For testing purposes i've added 8 disks.

And to make things even more complicated in Windows 10 it works..

@Jmatz135. Did you set the VolWaitTimeout value? You could try and set it to about 20. It will then wait for 20 seconds to process all appstacks and login after that time if it can't process um before that time. If you have a writable volume it might now work though as it will push your login after the writable is attached (at least that's my knowledge of it)

[jmatz135]

The appstacks are created with template 2.12.0.32, which is the template that is supplied with AppVolumes 2.12.0.70 when you use the upload prepacked volumes button.  I haven't even really tried to get rid of the drive letters prior to the appstacks processing as that is not really my issue. 

The VolWaitTimeout value is set to 120, which I have explicitly set because someone said that the default value is sometimes ignored.  I do not use writable volumes so I'm not sure if that does/would work. 

[LFC]

Hi JMatz135

Do you have a solution to stopping the desktop session from starting until all the AppStacks are fully initialised?

In previous releases of APV, we had lots of issues with extended logon times. APV v2.12 was supposed to allow you to toggle the Async load On and off with reg keys / variables, however it now seems to be the default behaviour! (Async mounting is supposed to be tech preview?)

Now we have upgraded, the users are complaining in a huge way. The desktop cannot really be used until the app stacks are ready (it hangs even if you try to use locally installed apps not on AppStacks), so it really seems pointless.

I'm going to have a play with the VolWait reg keys, but you say this is being ignored?

Regards

Sean

[jmatz135]

I have not figured out a solution to this problem and from my testing the VolWait regkeys seem to be ignored as well.  If you find something different or find a solution let me know.  Sorry I can't be of help at this moment.

[Ray_handels]

Hey LFC,

Async mounting is not enabled by default, you can check the svservice.log file when you log in. After a few lines it should say Async mounting disabled.

Just for my idea. When you log in and users need to wait, do you actually see the drvinst.exe process running and disks being added one by one when you look at c:\snapvolumestemp\mountpoint??

What i see happening is that in Windows 7 (Windows 10 doesn't have this issue) it takes quite some time to add the disks as they are added one by one which could take up to 3 minutes.

[jmatz135]

According to the logs Async mounting is disabled.   I do not see the drvinst.exe process although I may not be catching it as the appstacks we have finishing mounting within about 10 seconds of login finishing and the computer is almost useless until they finish mounting.  I do not see the C:\snapvolumestemp\mountpoint, but I do see C:\SVROOT and I also see the CVAPPS drives until the appstacks finish processing and then they go away.

[Bleeder]

For Windows 7, have you seen this?  I'm not sure if the VMware OS Optimization Tool checks for the hotfix mentioned (if not, that would be a good thing for them to add).

Logon hangs when writable volumes are attached

https://kb.vmware.com/kb/2145119

[jmatz135]

I use the Windows 7 SP1 rollup that includes all of the hotfixes that are known to help this issue, including the one from the kb: https://kb.vmware.com/kb/2145119

[Ray_handels]

@jmatz, The snapvolumestemp is a system folder that you can only reach by typing in the name. Otherwise you cannot reach it. At least that's my knowledge of it. I don't see an svroot folder though. And the drivesletters being created can be fixed if you would like to.

What i see happening is after logon (which is about 30 to 40 seconds when using a writable) the disks are being added one by one and are being "installed" by using the drvinst.exe process.