Interactive Session Logon time

[alsmk2]

This is not really a question relating to UEM, more vrealize / View in general; however, I thought this seems to be the most obvious place to post as folk in here are far more obsessed with logon times and probably better placed to help.

I've been tweaking some existing UEM & App Volume deployments to try and optimize logon times as best as possible with some good success. By tweaking some of the UEM configs, I'm able to get logon times from 90 seconds to around 30- 40 seconds. However, I'm struggling to reduce the interactive session logon time at all. Vrops is showing many users interactive times as being as high as an additional 150 seconds. What I can't figure out is what effects this part of the process.

There's very little detail on what VMware define the Interactive Session Logon time metric as (as in zero reference). I've found the definition Citrix use, which is that is the time between a user seeing the VDI desktop and being able to use the mouse/kb to interact with it. Is this true in the Horizon world?

More to the point, does anyone have any idea of what specifically happens during this period? Do App Stack attachments happen in this section, or anything else that I can start to look at?

[alsmk2]

It's a good call - that particular user's Windows Explorer config file is only 129kb compressed, and 1.69mb when extracted, so there is no reason for it to take more than a second to extract / import.

In terms of the infrastructure, the profile server and VDI desktops are both stored in the same geographic location with a full 10GB backbone. Neither the vsphere clusters, profile server, or vdi desktops show any stress or contention from a resource perspective.

For ref, the desktops are W7 linked-clones with 2 vCPU's / 6GB mem and are hosted on a all flash vSAN deployment.

[ijdemes]

I understand what you say.

What I am not really sure about is how/when decompression is done. Either directly from profile archive location (share) to temp user folder, or is the archive zip first copied over to the local system (user's profile), than decompressed to the temp user folder? Maybe UEMdev​ can elaborate on that?

Anti-virus can also have huge impact on profile archives. Do you have exclusions in place on both file server and/or VDI for UEM?

Extract from: https://techzone.vmware.com/sites/default/files/horizon-7-antivirus-view-app-volumes-thinapp-user-en...

User Environment Manager Scan Exclusions

VMware User Environment Manager delivers personalization and centrally managed policy

configurations across virtual, physical, and cloud-based Windows desktop environments. User

Environment Manager allows IT to control which settings users are allowed to personalize, and also maps

environmental settings such as networks and location-specific printers.

On servers, exclude the FlexEngine log path from real-time scans. For example:

\\server\FlexArchiveShare\%username%\Logs

On clients, as with other network paths, exclude the following paths from real-time scans:

• VMware User Environment Manager configuration share path

For example: \\server\FlexConfigShare\general

• Profile archive path

For example: \\server\FlexArchiveShare\%username%\Archives

• Profile archive backup path

For example: \\server\FlexArchiveShare\%username%\Backups

Additionally, in nonpersistent desktop pools that have a clean master image, you can exclude these User

Environment Manager executables from real-time scans because they are known to be virus free:

• FlexEngine.exe

• FlexSyncTool.exe

• Flex+ Helpdesk Support Tool.exe

• Flex+ Self-Support.exe

[alsmk2]

Unfortunately this particular site does use agent based AV in their gold image, rather than offloading it to the hypervisor, so it wouldn't be a stretch to say this could be the overarching reason for sub-par logons.

I've been assured in the past that the necessary exclusions are in place, but I've sent them over again including the ones above, and am just waiting on confirmation. Unfortunately, I don't have access to their AV solution to confirm one way or the other.

In terms of when a config file is decompressed, it was always my assumption that it would be done locally on the desktop - otherwise it would be copying the uncompressed data over the network, which I'd suspect could lead to some serious congestion during peak logon periods.

[DEMdev]

Hi alsmk2,

Again, I concur with Ivan (I usually do 🙂 – the imports are rather slow. Do you happen to have folder redirection configured?

How long does it take to "manually" unzip that Windows Explorer.zip profile archive that took more than 6 seconds?

Unrelated, but seeing that you're using UEM version 9.0: that will reach its end of general support on 3/17... Upgrading to a later version won't magically solve your perf issues, but just wanted to point this out.

[DEMdev]

Hi ,

What I am not really sure about is how/when decompression is done. Either directly from profile archive location (share) to temp user folder, or is the archive zip first copied over to the local system (user's profile), than decompressed to the temp user folder?

No, and no, respectively 🙂

Maybe UEMdev can elaborate on that?

Certainly! To minimize network traffic and local disk actions, the process is as follows:

• FlexEngine streams the remote profile archive, i.e. reading it in chunks from the first byte to the last and decompressing it on the fly, without any seeks or additional reads. (This is the reason why we have our own "special" ZIP file format: being able to read in such a fire-hose fashion).
• Every file we encounter in the ZIP is written into the actual destination folder, but with a temp name. Once the file has been extracted correctly, it's renamed to its actual file name.
• The only exception is the .REG file; this is written into the user's temp folder and fed to Reg(Edit).exe from there.

[alsmk2]

This is 99% certain down to anti-virus as already suggested.

I decided to fire up a fresh pool with no anti-virus installed and run a side by side comparison. With no AV it only takes UEM 5.5 seconds to process the entire config, and the desktop is fully usable after 40 seconds. With AV it takes 19seconds for UEM, and the desktop was usable after 70- 77 seconds... pretty massive difference.

As mentioned, I've been assured that the exclusions are in place, but the proof is in the pudding in my eyes. Have gone back with my findings, so it's now back with the site to check.

Thanks for all the help - grand input as usual.

[ijdemes]

Thanks for the feedback! Glad you narrowed it down to AV.

[ap_idb]

Has your team ever narrowed down the AV Exclusion issues? I have insane logon times, upwards of 5 minutes +, and it's a night and day difference without AV. Exclusions are in place, but we use Carbon Black Defense, which is a beast to get working right in any environment, so I suspect one of the flex executables' actions are just is not liked well in Carbon Black.