LukaszDziwisz
Enthusiast
Enthusiast

Image Optimization for Instant Clones

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

0 Kudos
17 Replies
vdi2777
Enthusiast
Enthusiast

Hi LukaszDziwisz,

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):

  • Between 40 - 48 seconds

Without AppVolumes:

  • Between 25 - 32 seconds

Login Times with AppStack 2 vCores (on Thin Client, ZeroClient and natice 5.0 Horizon Client):

  • Between 70  - 85 seconds

Without AppVolumes:

  • Between 40 - 52 seconds

I hope the results can help you.

Kind regards,

Markus

0 Kudos
LukaszDziwisz
Enthusiast
Enthusiast

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:

User Policy Apply Time: 19 seconds

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

0 Kudos
vdi2777
Enthusiast
Enthusiast

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.

0 Kudos
LukaszDziwisz
Enthusiast
Enthusiast

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

0 Kudos
sjesse
Leadership
Leadership

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.

0 Kudos
JohnTwilley
Hot Shot
Hot Shot

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

  1. I run the OSOT using  a modified version of the LoginVSI template. (No Modern App Cleanup)
  2. George's Optimization Scripts: https://www.jgspiers.com/category/scripts/
  3. Windows 10 DeBloater script: GitHub - Sycnex/Windows10Debloater: Script to remove Windows 10 bloatware.  
  4. Various registry Tweaks I've collected.  I put as many in the Default NTUser.dat as I can, to lessen UEM processing.
  5. Minimize User Group Policies if possible. Since UEM mandates the "Always wait for the network at computer start and logon", GPO process synchronously...slowing things down.

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] *************************************************************************************

0 Kudos
LukaszDziwisz
Enthusiast
Enthusiast

@sjesse

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

0 Kudos
LukaszDziwisz
Enthusiast
Enthusiast

@JohnTwilley

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

0 Kudos
josejjcv
Contributor
Contributor

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.

0 Kudos
sjesse
Leadership
Leadership

disable the windows module service as well if in the parent, if you use appvolumes its actually recommended .

Reduce App Volumes Login Time on Windows 10

0 Kudos
josejjcv
Contributor
Contributor

I have done that on the parent and re provisioned and for some reason the Service still runs despite disabled. Weird.

0 Kudos
sjesse
Leadership
Leadership

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.

0 Kudos
josejjcv
Contributor
Contributor

It appears I have been able to keep these Windows Update and Windows Modules Installer Services through Group Policy. So far so good and I don't see spikes in CPU in vCenter.

0 Kudos
LukaszDziwisz
Enthusiast
Enthusiast

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

0 Kudos
josejjcv
Contributor
Contributor

Set the Services in Group Policy Object to 'Disabled'. I did this on the parent image before sealing (Snapshot) and then deploying instant clones.

GPO_Services.jpg

Anobix67
Enthusiast
Enthusiast

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).

0 Kudos
josejjcv
Contributor
Contributor

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).