VMware Horizon Community
jb3vi
Contributor
Contributor

AppVolumes 2.16 VolDelayLoadTime

Good Morning,

Our infrastructure consists of VMWare Horizon 7.6 with AppVolumes 2.14.2:

I'm trying on a test pool (Windows 10, 1803) the new 2.16 Agent (The manager is still 2.14 because I'm reading there are some DB issues with pre-existing AppStacks) because this is needed after a Windows Security Update, however i'm noticing that the registry key "VolDelayLoadTime" on the new agent is ignored at login and unfortunately I really need it because if I don't set a Delay of atleast '5' seconds the printers mapped by GPO create issues (By design AppVolumes restarts the spooler AFTER the AppStacks are mounted):

Either the user get an endless login screen stuck on "Applying Policy: Printers Mapping", or they get duplicate printers or they get no printers at all.

The Registry Key completely mitigate these issues...

Do you know if in the last version this Key is deprecated or changed?

Thank you!

Reply
0 Kudos
7 Replies
Ray_handels
Virtuoso
Virtuoso

It could be that it is deprecated. I would suggest and ask VMware support for that.

What I do know is within version 2.16 they changed the way appstacks are being merged during logon. I believe reverse replicate has been set as the default. This means that during logon registry keys are not fully merged but these are merged after logon.

In very old version these action were executed during startup of the applications what could cause slow startup of applications. They changed it to do this during logon (Reverse replicate) but then logon could take quiet a while.because all registry keys were being merged (what could take up a few minutes thus not merging all appstacks during logon. They then changed that to do the reverse replicate 60 seconds after logon. It could well be that because of reverse_replicate the voldelayloadtime settings gets passed.

That being said, I would never suggest installing printers using a GPO. We did this in the very beginning but you can't really be sure when the last appstack is being attached or when GPO's are being executed during the logon process. There will always be situations in which it won't work and logon will stall or printers are not being attached.

I think that there are 3 options (going from best option to worst option Smiley Happy).

1. Use UEM to connect printers during logon. We do this now and never have issues with creating mapped printers. They are aware of each other and that's why it works.

2. Use a batch or PS script to create the printers. Just let it run after logon async and set a pause at the beginning of the script that either waits for 1 or 2 minutes, checks to see if the spooler is running or checks if all appstacks are attached.

3. Create a batch file that attaches the appstacks after logon. I would not suggest doing this because users will get their applications attached after logon which means the first minute or so a user can not use his VDI machine properly.

Reply
0 Kudos
jb3vi
Contributor
Contributor

Thank you for the answer Ray!
I also opened a support ticket directly with VMWare to actually understand if the behavior is expected or not... The documentation related to 2.16 still reports the RegKey as valid ( https://docs.vmware.com/en/VMware-App-Volumes/2.16/com.vmware.appvolumes.admin.doc/GUID-21E6F5D2-883... ) so hopefully it's just a bug...

I heard about UEM, but since we're already evaluating AppVolumes I'd avoid to throw other things in the mix that would add complexity if it's not absolutely required...

Our AppStacks are not that complex anyway since we use it just to handle "Per Office Exceptions" (Just 1-2 Appstacks per user that contain one application each, so the mounting process should be fast too).

An option/parameter/regkey to delay just the Printer Spooler restart that AppVolumes forces would be really handy...

I'm waiting to listen back from VMWare, and if we cannot pinpoint a solution i'll try to use UEM. (UEM and AppVolumes, should come together even when bought as an addon anyway, right?).

Thank you again for now!

I will keep the post updated as soon as I heard back from them.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

(UEM and AppVolumes, should come together even when bought as an addon anyway, right?).

I'm lucky enough to have full enterprise (or education) version of View so we don't need to bother with that, we can simply use anything.

When using VDI we found out that GPO's is not really the way to go. You will always have some settings but you'd rather do that with another tool be it UEM or Scense or Appsense (Or ivanti or whatever it is called now Smiley Happy)...

Apart from that I totally agree with you. Even better, if you buy View, you should get UEM and Appvolumes in the mix (maybe this is already the case, I really don't know). Maybe not all features but for me the product consist of the entire suite, that's what makes it work in the first place.. But hey who am I Smiley Happy. Besides, my salary isn't dependent from sales revenue Smiley Happy Smiley Happy

Reply
0 Kudos
jb3vi
Contributor
Contributor

Ok, I heard back from the support!

Apparently good news: The RegKey is not deprecated however they told me that using the 2.16 agent in conjunction with the 2.14 manager is not a supported configuration ( By reading your post here where you advise to not update the manager I thought that I could do that, but apparently not... Appvolumes 2.16 has been released​ ).
They say that probably the reason that is causing some settings to not be applyied (including the RegKey "VolDelayLoadTime) is caused by this version mismatch...
So, before further troubleshooting I've to schedule a maintenance window...
Fair enough!
I'll ask them if there's a planned minor release coming that fixes the current DB problems or if I'm supposed to fix that with the workaround that you found.
Anyway, before proceeding with the update, can I just let the user known about the maintenance, unassign the currently attached AppStack and then update the manager?
Because I noticed that if the OS boots and it cannot reach the AppVolumes server it stucks for 10 mins at user login before throwing "Cannot reach AppVolumes manager: Virtualization is disabled" so I'm asking if there's a way to avoid that...
Because if not, I'll probably have to schedule the mainteinance window during a Saturday.
Thank you!
Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

I'll ask them if there's a planned minor release coming that fixes the current DB problems or if I'm supposed to fix that with the workaround that you found.

I would not suggest doing that. I did find that by trial and error and just eager enough to not take no for an answer Smiley Happy. I don't think this will be supported nor will GSS ever give you a solution like that Smiley Happy.

Anyway, before proceeding with the update, can I just let the user known about the maintenance, unassign the currently attached AppStack and then update the manager?

Because I noticed that if the OS boots and it cannot reach the AppVolumes server it stucks for 10 mins at user login before throwing "Cannot reach AppVolumes manager: Virtualization is disabled" so I'm asking if there's a way to avoid that...

It depends. How many Appvolumes managers do you have? If you only have one manager then yes, I would suggest asking all of your users to log off and do the in place upgrade. I would then suggest going to version 2.15 if that is supported. If you have multiple managers (we have 2 per database) you could get 1 out of the LB, upgrade that one, than put it back into the LB and rinse and repeat with the other manager.

Last but not least to be honest I don't think that the manager is a reason that the VolDelayLoadTime setting does not work.Thing is that appstacks are always attached just after View assigned a machine to your account (you can see this in the Appvolumes log). After that the manager does not have any play anymore on what happens on the agent. I think that this is just a smart way of throwing you off. I think that after upgrading to Appvolumes manager 2.15 or 2.16 your issue with the key will still be there but hey, I might be missing something here.

Reply
0 Kudos
jb3vi
Contributor
Contributor

It depends. How many Appvolumes managers do you have? If you only have one manager then yes, I would suggest asking all of your users to log off and do the in place upgrade. I would then suggest going to version 2.15 if that is supported. If you have multiple managers (we have 2 per database) you could get 1 out of the LB, upgrade that one, than put it back into the LB and rinse and repeat with the other manager.

Unfortunately, since we're in the evaluation process it isn't load balanced yet (And it is also using and Internal DB)...

I'll try to ask them if bumping to 2.15 is supported or not.

Anyway, is the Manager retrocompatible? If I update it to 2.15 can I leave the remaining agents to 2.14 till the next recompose or I would face issues?

Last but not least to be honest I don't think that the manager is a reason that the VolDelayLoadTime setting does not work.Thing is that appstacks are always attached just after View assigned a machine to your account (you can see this in the Appvolumes log). After that the manager does not have any play anymore on what happens on the agent. I think that this is just a smart way of throwing you off. I think that after upgrading to Appvolumes manager 2.15 or 2.16 your issue with the key will still be there but hey, I might be missing something here.

That's what I thought too, but honestly I don't know where the problem lies: with both 2.14 and 2.16 agents I notice through vCenter that when the user tryies to login on his VDI, the Virtual Machine is reconfigured because the AppStack/Disk is getting mounted, however with the 2.14 version the Application icon appears after the specified delay as expected, while with the 2.16 versions the icon is there from the start which shouldn't happen.

For now I'll just play along following their instruction to troubleshoot more.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

AFAIK you can mix and mingle versions and it will work. I thought that having different agent and manager version is not supported but as long as it works, it works.

We also first upgrade the managers (due to new features there and agents might have an issue when they are newer than the manager) and than after a few weeks we start upgrading the agent. I would not suggest being out of sync for too long so try to keep version in sync as much as possible.

Reply
0 Kudos