VMware Horizon Community
SummaCollege
Hot Shot
Hot Shot

Edit: Slow login after adding App Volumes agent

At this moment we are using floating desktops by means of Horizon 7.3.1, UEM 9.3 and App Volumes 2.13.2. App Volumes is running in a separate testing phase and we are having major issues when using Writable Volumes.

When a user has "filled" there Writable Volume by installing some applications, all seems fine. Logon times are a bit longer compared to a desktop without Writable Volumes (approx 45 vs 35 sec) but acceptable. The issues start when we update our golden image. Updating the golden image is mainly Microsoft updates + some small applications like Java, Chrome etc. After updating the golden image and recomposing, the logon times are increased up to approx 180 sec. As you might understand, that's not acceptable.

Emptying/recreating a Writable Volume, thus starting over again results in normal logon times. The downside of course is that a user has to reinstall there applications, not what we want. And updating the golden image results in the same procedure over and over again... This issue is withholding us from adding this feature into our production environment, and holding us back in regards to planning.

Does anyone have any idea to what might cause this issue?

Reply
0 Kudos
4 Replies
Ray_handels
Virtuoso
Virtuoso

Normally this should not happen at all. We have multiple users that install applications within the golden image but it never takes 180 seconds to login after we upgraded the golden image. No matter what we do to the golden image.

Could you check your svservice.log file on the machine? It is located in the C:\Program Files (x86)\Cloudvolumes\logs folder.

Could you please post snippets of what you think might be causing the issue?

Reply
0 Kudos
SummaCollege
Hot Shot
Hot Shot

I had a look at the svservice.log file and found nothing really that could indicate a problem. From start to finish it took 50 sec.

Only thing i see is a 32 sec gap between the following:

[2018-02-08 08:19:50.063 UTC] [svservice:P1732:T460] OnLogon : succeeded

[2018-02-08 08:20:22.939 UTC] [svservice:P1732:T460] OnStartShell called (Session ID 1, Handle 00000276BEC15FD0, Params 0000009CEF0FE678, Context 0000000000000000)

I have added the log to this post for anyone who want to take a look. The log is truncated to show only data from the point at where the user is logged in and data for that session is added to the log.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

Looking at the log files it seems as if Appvolumes is done merging the appstacks at 8:19:50 and the just waits for the shell to start.

After the shell is started (and the logon is succeeded looking at a users perspective) Appvolumes continues with actions that are stored in the shellstart.bat.

Long story short, slow logon is not due to Appvolumes.

Do you happen to have a large amount of policies or logonscripts that run? Do you attach printers using policies? Any powershell scripts during logon??

Reply
0 Kudos
SummaCollege
Hot Shot
Hot Shot

I have changed the title of this post to better represent the actual issue.

Trying to get to the bottom of this issue, but not without a fight...

Ray_handels

We do use policies (computer & user), don't run logonscripts, attach printers using UEM (drivers in golden image), no powershell scripts.

But even when using a copy of the exact same Golden image as our production VDI environment with only App Volumes agent added, and blocking all user GPO's ( thus also not using UEM), login is agonizingly slow. The Writable Volumes disk had 0 applications installed on it. We don't use AppStacks.

Btw we use Windows 10 v1703 and have run VMware OS Optimization Tool with the default Windows 10 template.

Measurements using vRealize:

pastedImage_0.png

Production VDI: 36.22 sec

App Vol VDI:     125.57 sec

We can't figure out why this is so slow.... Anyone?

Reply
0 Kudos