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?

[SummaCollege]

Although i can't really help you out regarding the Interactive Session Logon time, i do want to ask you a question if you don't mind?

You mention that you tweaked some of the UEM configs to get faster logon times. As we are also in the tweaking phase of our VDI project, is it possible for you to share some of the tweakes you did? Thanks in advance!

[alsmk2]

Sure - they were pretty basic tweaks based on the largest config files we were seeing, so may not apply to your environment:

1. Chrome - implemented the config file I've mentioned in the comments here (Not the Chrome.zip available for d/l), and configured it for Direct Flex (Export at logoff):

https://communities.vmware.com/docs/DOC-31428?et=watches.email.document_comment#comment-40480

Anywhere from 30 seconds + off the logon times.

2. Excel - exclude *.xlsb from the config (but specifically include PERSONAL.XLSB) - this may be specific to our builds, but for a long time we've noticed UEM hanging on to a lot of spurious autosave files.

10 - 15 seconds

3. Used UEM to add the following registry key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

DWORD: DelayedDesktopSwitchTimeout

Value=2

I have also seen reference to adding this to HKLM, so you could try it in your gold image; however, under HKCU it still knocked off an average of 5-10 seconds per logon.

With the above, I'm now at a point where logons are fairly quick, and we're stuck waiting for app volumes to catch up instead.

[Ray_handels]

Try going for Appvolumes 2.13, not quite sure if you already have that.

There was a major fix in the way Appvolumes handles very large registry hyves using the reverse recplicate setting. We now see 30 second logon times with 5 to 6 appstacks attached an 1 writable. Of these 30 seconds appvolumes only runs for about 20 to 25 seconds. With 2.12 this used to be a lot longer and we even had to set the VolWaitTimeOut=10 setting.

[alsmk2]

2.13 is in the pipeline - unfortunately, it still needs to go through thorough testing, as we find even incremental updates to App Volumes seem to introduce new bugs as quickly as old ones are fixed.

[Ray_handels]

2.13 is in the pipeline - unfortunately, it still needs to go through thorough testing, as we find even incremental updates to App Volumes seem to introduce new bugs as quickly as old ones are fixed.

Euhm well yeah I do feel your pain there.

We have seen quite the versions and quite the bugs as well. But I must say that version 2.13.1 is very stable and does what it needs to do. I am pretty happy with it.

[alsmk2]

Finally moved to 2.13 and haven't noticed any difference when using user assignments. It has improved logon times, but that is because some of the app stacks are now done via computer assignment instead,

In terms of interactive logon times, we are still seeing issues with this. Both vRealize and the view helpdesk show that these can be anywhere between 70 and 200 seconds in length. Still struggling to figure out what it is doing during this phase.

We have also noticed an overall increase in logon times to just over a minute now - it appears that the new horizon helpdesk functionality launches a script at logon which accounts for about 10 - 15 seconds extra per logon. Not best please with that as it looks like there is no way to disable it. 😕

[Sravan_k]

Hi,

if you are on Horizon View 7.1 and up, you can get logon log's from logon monitor tool which is sub component of view agent, you can find that information under view agent logs, let me know if you are not able to find it.

one more thing, is long log-on time is facing by everyone or few users or particular use case users?

Thank you,

Vkmr.  

[SchwarzC · Accepted solution]

Just my 2 cents on this topic - do not fortget about your AntiVirus Solution.

We where trying to push the login times to ~30 seconds and for us the biggest part was exclusions and setting in the AV rather than in the Windows part.

BR

[alsmk2]

The average logon time is 73 seconds at the moment, though quite a few users go up to 100+.

Pretty much everything in UEM that can use DF is now using it, which did help. For the users with higher logon times, we can see that they usually have more than one appstack applied as a user entitlement; however, vrealize is reporting an average appstack connection time of 6 - 10 seconds, which doesn't really tally up with what we've noticed.

The helpdesk tool / agent logon logs do display similar stats to vrealize, though there is a variance of a few seconds. Neither tool really helps me clarify what is happening during the interactive logon phase.

In regard to Anti-Virus, this has been checked in the past, but I've resent a list of necessary exclusions just to triple check that they are actually in place.

[DEMdev]

Hi alsmk2,

Out of interest, how much of those 73-100+ seconds is consumed by UEM at logon, i.e. how long do the path-based imports take?

[alsmk2]

Where about would I see that statistic out of interest? Would that be mentioned in the UEM logs or somewhere else?

[alsmk2]

The other thing I failed to mention is that since going to View 7.3, we've noticed that a script runs for V4V Helper (the helpdesk tool) at logon - this seems to take around 10 - 15 seconds to run, and appears to hold up the logon process.

I'm pretty sure if we hadn't upgraded View and had just done AV to 2.13.1, that logon times would have seen a bigger decrease because of the lack of the v4v script running. It appears there is no way to stop it running, and in all honesty, the helpdesk tool is too useful to try and stop it anyhow. Has anyone else noticed the same thing?

[ijdemes]

You can find this in the FlexEngine.log file.

Just check for "Done" and it mentions the amount om miliseconds it took for import.

[DEMdev]

Hi alsmk2,

Where about would I see that statistic out of interest? Would that be mentioned in the UEM logs or somewhere else?

Indeed, that's logged in the FlexEngine log file, like 2018-01-03 18:40:59.879 [INFO ] Done (119 ms) [<<IFP#f80a71f8-2a01a]

As for your question about Horizon's V4V Helper process: that's probably a question for the Horizon forum.

[alsmk2]

Here's an example from a user with the highest logon time this morning from vrealize:

2018-01-16 08:27:13.940 [DEBUG] Processed 74 Flex config files (18 successful, 13 skipped, 38 added to DirectFlex cache, 1 disabled, 4 retired)

2018-01-16 08:27:13.940 [DEBUG] Processed 8 UEM import tasks (7 successful, 1 skipped)

2018-01-16 08:27:13.940 [DEBUG] Processed 89 UEM drive mappings (6 scheduled, 82 skipped, 1 disabled)

2018-01-16 08:27:13.940 [DEBUG] Processed 5 UEM printer mappings (1 scheduled, 4 skipped)

2018-01-16 08:27:13.940 [DEBUG] Processed 15 UEM settings imports (13 successful, 1 skipped, 1 disabled)

2018-01-16 08:27:13.940 [DEBUG] Processed 1 UEM drive hiding setting (1 successful)

2018-01-16 08:27:13.940 [DEBUG] Processed 2 UEM ADMX-based settings (2 successful)

2018-01-16 08:27:13.940 [DEBUG] Processed 131 UEM shortcuts (3 successful, 25 scheduled, 100 skipped, 3 disabled)

2018-01-16 08:27:13.940 [DEBUG] Processed 4 UEM folder redirection settings (2 successful, 2 skipped)

2018-01-16 08:27:13.940 [DEBUG] Processed 1 UEM application blocking setting (1 disabled)

2018-01-16 08:27:14.581 [DEBUG] Started DirectFlex injection

2018-01-16 08:27:14.627 [DEBUG] Launched FlexEngine in DirectFlex mode

2018-01-16 08:27:14.627 [INFO ] Done (35113 ms) [<<IFP#00e843da-3e7]

What are people's thoughts on Direct Flex for the office applications? At the moment I tend to leave this as default, but is there any reason not to enable it on these as well?

[ijdemes]

Can you post the full FlexEngine.log for this user/session?

Regarding DirectFlex and Office, I think it depends. It is always finding the balance between swift logon and swift application launches. For those applications that are started/closed a lot of times in a session, like Office apps, I import those settings during logon/logoff, rather than importing them at launch/closure of the application (DirectFlex). This means taking the "pain" once during logon and having the benefit of not needing to import/export at application launch/closure for those applications.

[DEMdev]

+1 on Ivan's request for a full log file. 35 seconds is quite slow, so we should definitely take a look at what's going on.

(And now I'm wondering whether I should try and add timing information to the "Processed N settings" stats dump 🙂

[alsmk2]

Sure thing - thanks for taking a look.

[ijdemes]

One thing that stands out is Windows Explorer.zip

2018-01-16 08:26:55.643 [INFO ] Importing profile archive 'Windows Explorer.zip' (\\domain.com\UEM\UEMProfiles\user.name\Archive\Windows Settings\Windows Explorer.zip)
2018-01-16 08:26:55.830 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\REGEDIT.EXE" /S "C:\Users\user.name\AppData\Local\Temp\FLXD0E8.tmp"' (RPAL: l=0 (D/E), r=0)
2018-01-16 08:27:02.190 [DEBUG] Read 6 entries from profile archive (size: 1563998; compressed: 130956)

This one alone already takes about 6-7 seconds.

I my current customer's environment, it takes less than a second.