VMware Horizon Community
Mneighthyn
Contributor
Contributor

Insane login times - Win10 LTSB

We have Horizon 7.2 using ESXi 6.0.0 and vCenter 6.0.0

I have multiple pools that are now experiencing 5+ minute login times and after calling VMware the initial fix was to uninstall the view agent and VMware Tools then reinstall those.  That successfully increased the login times to 7+ minutes.  I tried this on another pool and the login time jumped to 20+ minutes followed by an error which logged me out.

This is a production environment so, shockingly, I'm getting pressure to fix this.  Any suggestions on how to drastically lower the login times?

Reply
0 Kudos
17 Replies
pchapman
Hot Shot
Hot Shot

Please check the VMware Logon monitor log files on one of the suspect VM's, and at the bottom it will give you a summary of what was taking a long time during logon. 

C:\ProgramData\VMware\VMware Logon Monitor\Logs

I just built a Win 10 LTSB environment for a customer a few months back and they have excellent logon times, at about 10-15 seconds.

Reply
0 Kudos
sjesse
Leadership
Leadership

Read this, my logon times are much below that, and I followed this to create our windows 10 image

Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware

Reply
0 Kudos
pchapman
Hot Shot
Hot Shot

I agree that those steps will help get a great golden image, however 5-7 minute+ logon times would indicate some other issues going on in the environment for sure.  even a completely unoptimized image with vmware tools + view agent installed on it won't take anywhere near that amount of time to login.

Reply
0 Kudos
sjesse
Leadership
Leadership

I can't remember if its in the article or not, but I've seen group policy add large amount of time to login times. I made sure the loopback back policy gpo setting is set to replace which effectively removes any user based group policies applied to the users.

Reply
0 Kudos
suri123
Enthusiast
Enthusiast

Are yo running persistence or non VM's?

Secondly check all your services to see what is causing the delay during login, use process monitor to capture or lizard system remote process monitor to see which process is using your CPU or memory

Are you seeing the same time to login using the Vcenter console?

Run the VMware OS optimization tool, if needed

Is any updates running in the backend or scripts?

Do you have enough IO

Hope this helps.

Cheers!

Reply
0 Kudos
Mneighthyn
Contributor
Contributor

A few things.

1) The pools with extended login times are floating linked clone pools.

2) I checked the VMware Logon Monitor logs and group policy was definitely making a major impact on the login time.  I've looked into it and a policy for adding printers is most likely the culprit.  Still need more testing.

3) The extended login times was/is high on thin clients, web console login, and local horizon view client login.  Any way to access the pool experienced high login times.

Previously I ran the Optimization tool on one of the other pools and that did not boost login time (Not using a template, just remove everything possible.)  I suspect the other pools may be GPO related as well but once again, more testing to confirm.  I'll update more as I confirm what the root cause is.

Reply
0 Kudos
sjesse
Leadership
Leadership

What may work is taking those group policy settings and adding them directly to the parent image. I have a policy our security team updates that I keep an eye on, if there are updates to it I put the changes in directly to the parent image. If you have UEM some of these can be applied using that tool, you can get the admx templetes used by the gpo and apply them there, they still will add a little time I think though. Usually I only do the UEM part if they should only apply to a specific user group

Reply
0 Kudos
sjesse
Leadership
Leadership

If it was printers, and you have UEM, you can let the printers be installed asynchronously to speed up the installation. A side effect is they may not show up immediately but from my experience no user has noticed.

Reply
0 Kudos
Mneighthyn
Contributor
Contributor

The group policy for printers was set to create four domain printers.  I've since switched it to update the four print queues rather than create.  The thin client I tested had the following results after that change:

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Logon Time: 147.69 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Logon Start To Hive Loaded Time: 44.15 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Logon Start To Classes Hive Loaded Time: 45.17 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Profile Sync Time: 0.00 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Windows Folder Redirection Apply Time: 0.00 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Shell Load Time: 53.71 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Total Logon Script Time: 0.00 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] User Policy Apply Time: 46 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Machine Policy Apply Time: 0 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Group Policy Software Install Time: 42.38 seconds

2018-10-05T10:29:51.378 INFO (0850-056c) [LogonMonitor::LogSummary] Free Disk Space Available To User: 46 GB

Much better than the results of yesterday:

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Logon Time: 331.34 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Logon Start To Hive Loaded Time: 0.45 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Logon Start To Classes Hive Loaded Time: 0.49 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Profile Sync Time: 0.00 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Windows Folder Redirection Apply Time: 0.00 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Shell Load Time: 49.07 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Total Logon Script Time: 0.00 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] User Policy Apply Time: 280 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Machine Policy Apply Time: 0 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Group Policy Software Install Time: 277.67 seconds

2018-10-04T16:01:47.782 INFO (0c44-14bc) [LogonMonitor::LogSummary] Free Disk Space Available To User: 53 GB

Reply
0 Kudos
MikleF
Enthusiast
Enthusiast

Are you also using the UEM agent ?

UEM and Group Policy Preferences when working together produce some quirky results in applying them.

GPP in itself combined with item-level targeting also can increase logon times substantially.

Reply
0 Kudos
Mneighthyn
Contributor
Contributor

We are not using UEM so that won't be a factor in the extended login times.

Reply
0 Kudos
Mneighthyn
Contributor
Contributor

Found another possible reason.  Unbeknownst to me Windows Updates was still enabled on the Parent Machine and had applied an update when I took the snapshot.  Correcting that issue now... :smileyplain:

Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

Try to follow my guide for creating Win10 golden images on https://www.ituda.com/vmware-horizon-view-windows-10-golden-image-creation/

The logon times I reach are varying between 20 and 75 seconds depending on the customer. HIgher logion times are very often related to GPOs

Reply
0 Kudos
MikleF
Enthusiast
Enthusiast

Also an interesting one to do is to disable Windows Modules Installer after the customization process using a GPO or post synchronization script.

This module can kick in when it detects an idle pc aan hog a lot of resources which you need during the logon process.

Reply
0 Kudos
Mneighthyn
Contributor
Contributor

Well, the update to VMware Tools ended up doing more harm than good.  USB drives stopped working on thin clients and the login time increased.  I've since reverted back to an earlier snapshot and installed the required software (VLC) and blocked windows updates.  The login times vary but seem to max at 2-ish minutes or as low as 30 seconds. 

Root cause was more Windows Updates than anything else but updating VMware Tools was a major detriment. 

The Optimization Tool didn't seem to affect the login time unfortunately (neither good nor bad.)

If I need to make a new pool I'll follow the guides posted in this thread.  Thank you to everyone who made suggestions.  A combination of all helped resolve our current issues.

Thanks,

Reply
0 Kudos
BenFB
Virtuoso
Virtuoso

Are you using UEM? There is a workaround to fix the USB redirection issue.

Re: USB Drives and Mobile phones not showing up in VM

Reply
0 Kudos
Mneighthyn
Contributor
Contributor

We are not using UEM but it appears the version of VMtools is what broke USB with the thin clients.  The snapshot I'm using has a slightly older version of VMtools and that works well with the thin clients and the firmware they're at.

Reply
0 Kudos