VMware Horizon Community
hschimpf
Enthusiast
Enthusiast

Windows 10 1909 Optimization

We are currently building a new GM for Windows 10 1909. I have used the official VMware guide to set everything up with OSOT and have used a customized template derived from the 1909 template that OSOT provides. We are using Instant-Clones with floating assignment.

Now with all the optimization done using the newest versions for Horizon, DEM and AppVolumes, I have found that the Login times are double that of our current 1809 branch. Granted we are using mandatory profiles but as this is no longer best practice, I did not set one up this time. I have since gone back and used the default OSOT template to rule out the possibilities of having anything active that might prolong the Login process.

Using Splunk and the Uberagent I have found that the loading of DEM and policies takes the usual amount of time, but the initialization of the profile in Windows itself takes a very long time.

Has anyone encountered this issue? Unfortunately I cannot pinpoint what is taking so long during setup as all the environment logging seems to do nothing and the few things I have found don't explain why it is taking so long. Last tests without DEM and AppVolumes have shown that the shell load time can be anywhere between 30 to 70 seconds.

Appreciate any ideas or info you might have.

Best regards,

Raetke

18 Replies
zhornsby
Enthusiast
Enthusiast

i am seeing my login times increase when i have a second monitor connected. (I have an open ticket and a recent post in the communities about this)

Do you happen to have two monitors connected also?

Reply
0 Kudos
Moltron83
Enthusiast
Enthusiast

Well we had dual monitor slowness also, with instant clones, on 1809 and 1903.  Haven't tried 1909 but I was hoping that would somehow improve -- 'till I read this. 

Reply
0 Kudos
jonathanjabez
Hot Shot
Hot Shot

The best way to isolate the issue is to try the below options one by one

- Remove App Volumes Agent and test the logon time only with UEM/DEM Agent installed

- Remove UEM/DEM Agent and test the login time only with App Volumes Agent

- Check which of the above options cause more logon time.

- As you have performed OS optimization using the customized template, check if all the default Windows Apps and Features are disabled as these default apps get loaded during logon every time user logs in. (Best way is to perform a full optimization and test the logon time with both App Volumes and DEM installed).

Reply
0 Kudos
hschimpf
Enthusiast
Enthusiast

So far I couldn't make a connection between 2 monitors and login times. I do have 2 monitors set up on our Zero clients but the issue also arises when I use the Horizon client with only 1 monitor.

I've tried attacking this from every angle I can think of. I've disabled all VMware products other than Horizon agent and suddenly got better times, close to 16 seconds at one point. Currently my bet is on DEM again. This has been an issue in the past and seems to be again. It might be the way that 1909 sets up the user account but I have a feeling that DEM tries to write settings during this process and makes Windows "stutter" during initial setup. I'm currently not sure how this may be circumvented. Login times are wildly different ranging from 30 seconds to sometimes close to 200 seconds.

I've tried Windows environment debug logging but that doesn't seem to do anything. Event viewer is mostly useless as always.

Any ideas welcome because I'm stumped on this.

Best regards,

Raetke

Reply
0 Kudos
sjesse
Leadership
Leadership

Make sure to open a ticket if you haven't, this wouldn't be the wierdest thing I've heard, someone swears they have seen login time improvements with enabling 3d vs not.

Reply
0 Kudos
hschimpf
Enthusiast
Enthusiast

I did but the answer was "This doesn't seem to be a VMware issue so good luck"...

Ok so I just did another test and found this.

This is what it looked like when the login time was 37 seconds.

faster.jpg

And this is the same part when the login was 56 seconds.

slower.jpg

From what I found the "ie4uinit.exe -UserConfig" is IE for every User Initialization. So as I guessed it seems to be during new user initialization. Question is what is happening and why is it so wildly different. Anyone have an idea how to troubleshoot this? There has to be some log somewhere that has the answer.

Best regards,

Raetke

Reply
0 Kudos
zhornsby
Enthusiast
Enthusiast

i was able to shave about 30 seconds off my dual monitor login by enabling 3d rendering on my master image.

On your master image right click,

select the video card drop down

enable 3d rendering

change automatic to software and configure memory to 256 mb

snapshot republish.

also how many displays are configured on your master and how much video memory is configured?

Reply
0 Kudos
hschimpf
Enthusiast
Enthusiast

As per this guide Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware  I set up 2 displays and 26MB of Video memory which is the same as our 1809 Image which has no such inconsistency issues.

3D Support is disabled. Since we don't have GPUs in our hosts, this would possibly fry our CPUs as the emulation is done on the CPU if no GPU is available.

Best regards,

Raetke

Reply
0 Kudos
zhornsby
Enthusiast
Enthusiast

were not using gpus either but this is what i got from a close buddy i have at vmware. i haven't tested it yet on a grander scale to see how it impacts performance however so far i haven't seen any issues

Reply
0 Kudos
sjesse
Leadership
Leadership

3D Support is disabled. Since we don't have GPUs in our hosts, this would possibly fry our CPUs as the emulation is done on the CPU if no GPU is available.

I'm not saying to turn it on, but frying the cpu is highly doubtful. I have it on on some of my desktops and they don't use really a noticable amount more of cpu utilization.

Reply
0 Kudos
sjesse
Leadership
Leadership

I'd push to escalate that case especially if your following the techzone article specifically and you see a difference between 1809 and 1909, level 1 seems to get stuck on pushing off issues like this sometimes. If you have a local vmrep let them know too. I haven't tried 1909 yet, we like to stay back and 1809 has over 2 years left I beleive.

hschimpf
Enthusiast
Enthusiast

From early talks of adopting Windows 10 before I was working here it was actually recommended to buy GPUs for the servers as Windows 10 is quite heavy on the visuals. It was declined due to the prices. I meant that you're gonna have a lot of heat generated by this. We're deploying around 800 desktops so this could have potentially quite an impact. For testing I can try this but it's not a feasible solution I think. And I'm having trouble understanding why this would make a difference on login times. Can you give some more info on the background of this recommendation?

Don't get me wrong, 1809 is stable and OK for now, but sooner or later we will need to switch. 1809 is already showing a notice in the update screen that it will be discontinued "soon". I will continue trying to find info on this but I think we might leave out 1909 or wait for something more "stable". As of right now Microsoft seem to have made a lot of changes that interfere with this.

Best regards,

Raetke

Reply
0 Kudos
hschimpf
Enthusiast
Enthusiast

Ok, so just out of curiosity I removed IE11 from 1909 and lo and behold, I get consistent login times of around 35 seconds. The ie4uinit.exe is no longer being triggered and I don't see any other processes that skew the timing. Sure there's still minor time differences due to network latency and such but the underlying issue seems to be fixed by removing the IE, which we were planning on doing anyway.

I don't know if this is feasible for any of you guys but it might be worth checking out.

Best regards,

Raetke

jhol5
Enthusiast
Enthusiast

What tool/utility is that?

Reply
0 Kudos
hschimpf
Enthusiast
Enthusiast

Which one? Splunk?

Reply
0 Kudos
VDINinja311
Enthusiast
Enthusiast

hschimpf

I don't remember if the OSOT fling removes these but during our optimization we go into "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components" AND "HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components" and delete any of them that have a StubPath key. Only Delete the StubPath key. We have done this optimization ever since Windows 10 1511 as it was causing login time delays. We do this on every build.

There is usually a minimum of 4 or 5 of those under Installed Components that have StubPath keys that can be deleted.

Especially check this one.

pastedImage_0.png

Hopefully this helps.

Reply
0 Kudos
VDINinja311
Enthusiast
Enthusiast

hschimpf

In your screenshots I also see some Active Setup for Chrome. I don't know if you use AppVolumes for Chrome but I'd suggest deleting this StubPath key as well for Chrome. Every update to Chrome this gets put back in and is needing deleted as well. Delete only the StubPath key.

pastedImage_0.png

Reply
0 Kudos
NLAVOIE
Contributor
Contributor

I don't think it's a good idea. I did it for Chrome in the appstack and after that i receive a "side by syde" error when starting it. 

Reply
0 Kudos