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.
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
Does anyone know why UAG versions 2.9 and 3.0 are not listed on the compatibility Matrix? https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&326=&23=&hideEmpty=false&hideUnsupported=false
Sadly the fault is still occurring with varying regularity.
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.
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.
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!
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.
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
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.
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
This seems to be an oversight that the VMware team needs to correct. I would recommend filing an SR. Is there a specific reason you are looking at 2.9 or 3.0 as opposed to a newer version?
Do you possibly have another product installed on the VM with a filter driver? If not I would work with your A/V vendor to get it resolved.
I'm upgrading an existing Horizon 7.1 environment to 7.6 including a pair of UAG's one being 2.9 and the other 3.0. I do not want to be in a position where the connections servers are upgraded first which then causes the UAG to stop working. UAG version 3.2.1 looks to be compatible with both 7.1 and 7.6 so I'm planning to deploy a new pair before the Horizon upgrade.
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.
3.2.1 is a stable release that I used with our Horizon 7.4.0 environment but you may leverage different pieces than I did. Just make sure to read the release notes as we've been burned by some issue in prior versions (RADIUS was broken in a two nic deployment with UAG 3.1, 3.2 and was fixed in 3.2.1). I just upgraded to UAG 3.3.1 in anticipation of moving to Horizon 7.6.0 and so far it's the best release to date.
We are not using UEM so that won't be a factor in the extended login times.
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...
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
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.
