We are working on Horizon 7.8, Instant Clones. Appvolumes 2.16, UEM 9.7, vCenter 6.7 U2 and Windows 1809 LTSC. We have recently discovered that our current image has some problems with some various Windows components, for example bitlocker, recent items and jump lists etc so we decided to build brand new image however we skipped using VMware OSOT and just did basic optimization manually. It included disabling unnecessary services, cleaning up startup, task scheduler etc. We are attaching at most 5 appstacks ( 4 combined applications appstacks and 1 Profile only writable). I have published the pool and almost right away seeing that logon time jumped from 40-50 seconds to 80-90 seconds. We are not using Mandatory profiles, instead we are doing Profile only writable and folder redirection through UEM.
I would like to ask the community and see if you might have any instructions/guideline on optimizing the image without OSOT and any possible tips/tricks on how to get the logon times at least to the 40-50 level or less. We are using all flash based Pure storage, newest C-Series UCS servers with Nvidia grids and I feel like we are not even close to what it should be.
Any help would be very much appreciated
i'm currently building an optimized windows 10 1803 Master (with OSOT own Template). I recorded the login times with and without appstacks. I looked into some performance data during logon and with appstacks the linked clones use a lot more cpu ressources. You should at least give your "Golden Image" 4 vCores.
Login Times with AppStack 4 vCores (on Thin Client, ZeroClient and natice 5.0 Horizon Client):
Login Times with AppStack 2 vCores (on Thin Client, ZeroClient and natice 5.0 Horizon Client):
I hope the results can help you.
Thank you, I feel like giving it already 3 vcpu is already a lot but I agree it could help. Let me test it and see what difference I can get. One thing made me wonder is a log from Logon Monitor and especially the following line:
That seems like a lot. If I don't attach any appstack it appears to be along 8-9 seconds but not sure how would this be related. Also I'm trying to figure our how to define which policy is causing (if single is a problem) or if it's all policies together
I noticed the same behaviour with the GPO loading times. Normally (without AppStacks) there are between 7-9 seconds but with it's over 17 seconds so i think thats related to AppVolumes in some ways.
I have tested with direct attachments to my account through AppVolumes Manager instead of AD group and getting exactly the same result.
4 appstacks +Writable Profile only logon time is 48 seconds - User Policy Apply time: 19 seconds
No appstacks but with Writable Profile only the logon time is 24 seconds - User Policy Apply time: 8 seconds
What if you don't use a writeable, and only appstacks? I am looking to do what your doing with the writable profile only, but when I test writeables back in 2.10 they added way to much latency and they slowed everything down. Its mainly because we have a hybrid array and I'm hoping by HCI system we are getting with flash storage will make it better in my case, but I was wondering if you saw extra time there as well.
I agree that the VMware OSOT tool can cause issues...and it's normally with the way it handles the Modern App Cleanup. You can edit the template and remove these sections. I say edit and remove, because OSOT is notorious for applying sections even though you have it unchecked. I also had followed VMware's Guide on setting up a Windows 10 master image using SysPrep and Mandatory profiles...but that caused too many headaches. It was NOT worth it in the long run.
I've had good luck using the following tweaks on the Master Win10 image: 2 CPUs w/4 GB Memory Windows 10 1709 & Windows 10 1809
LoginMonitor without AppStacks: (Cause I don't use it in production yet)
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Logon Time: 18.88 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Logon Start To Hive Loaded Time: 1.55 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Logon Start To Classes Hive Loaded Time: 2.01 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Profile Sync Time: 0.00 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Windows Folder Redirection Apply Time: 0.00 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Shell Load Time: 8.64 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Total Logon Script Time: 0.00 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] User Policy Apply Time: 7 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Machine Policy Apply Time: 0 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Group Policy Software Install Time: 0.23 seconds
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] Free Disk Space Available To User: 39 GB
2019-03-11T15:30:12.805 INFO (0c10-1ab4) [LogonMonitor::LogSummary] *************************************************************************************
WIth no appstacks whatsoever and no writable I'm roughly 18-20 seconds and User Policy Time according to Logon Monitor is 7-8 seconds. I agree writable was horrible with previous versions and we have completely stopped using them in favor of UEM until version 2.15 with that option that takes a lot of work figuring out some applications with UEM configs. SO far the writable profile has been pretty good to be honest
That is exactly what I'm seeing with no appstacks attached and no writable, with writable it increases by +/- 3 seconds but then it really makes a difference once starting to attach appstacks
Also, we are a little bit more generous on resources as I'm giving it 3vCPU and 8GB of memory + NVidia grid
Hi. I have my login time down to about 50 seconds using the Optimize Windows 10 Techzone VMware guide and Login VSI Optimization.
Did you disable any services manually aside Windows Update?
I also noticed that sometimes even though I disable Windows Updates it Runs along with Windows Modular Service. I can disable both but after provision the TIWorker.exe process creeps and uses some CPU on instant clones. It then stops running for period.
Stomped on this, any input on any other customizations you did would be helpful.
I'd double check and make sure both are, because I know in my case the windows updates service has always reenabled, but the windows module service so far hasn't. If it is reenabling might try an SR if you haven't already for the App Volumes team to see if they've seen it reenable. So far I haven't seen any other reports on here about that.
I'm just curious oh on how you were able to keep those disabled through gpo?
I have BITS, WIndows Update, UWindows Update Medic and Modules installer stopped and disabled and occasionally I see them in manual state on instant clones
I've had similar issues with Windows Update showing as Manual (Triggered) despite having the same (BITS/Windows update/module installer/windows update medic) disabled on the template. I have WU disabled via computer policy on the OU where the VMs go as well and it appears to ignore it eventually also.
For when you want to update your template do you just disable that GPO, proceed, then re-apply the GPO after you're done prior to snapshotting?
Also, to give a +1 to the general consensus of this thread, adding a single appstack (granted, a dozen+ applications in that appstack) adds a solid 15-20 seconds minimum to login time. From around 15seconds to pushing 40 or more. We found that Chrome with UEM is a huge culprit with a choice to either add time at login (can be upwards of a minute to sign in depending on the size of the profile being captured) or instead having it run in DirectFlex but that means up to multiple hundreds of MB of files have to be downloaded/extracted/etc prior to Chrome opening thus leading to up to a minute to have the window open properly (thus confusing users).
This is the first time I have implemented the "Windows Modular Installer" and "Windows Update" Services to be Disabled through Group Policy (Applied to OU containing both the Parent VM and Instant Clones).
This month will be the first round where this is configured this way. Now that this is hard set through GPO, I will move the Parent Image away from the VDI OU where this policy is set (will be moved to a Non-GPO applied OU), and turn on these services in order to install updates.
Once the updates are installed, I will move the VM back to the VDI OU and confirm the Group Policy settings are reapplied before sealing the Image (Snapshot).