Windows 10 version 1703 - Logontime getting slow using Appvolumes.

[lansti]

Hi folks.

I'm working on a windows 10 image, and i'm running version 1703 as we speak.

I'm running mandatory profile. 

My system:

Horizon agent 7.3.1

UEM 9.2.1.794

Appvolume 2.12.1.103

When i log on, i have a great exprience with the logontime. We are talking about 20-25 seconds. And about 12 seconds from FlexEngine starts to its finished.

Right now, i do not run to much of policies, and i asusme that it will slow down my logontime a bit.

But, when i attach an AppVolume(with office 265) to my windows, the logon time increase with almost a minute... It takes a long time from my flexengine ends, to a UEM refresh is triggered.

2018-01-09 08:10:43.338 [INFO ] Starting FlexEngine v9.2.1.794 [IFP#132f8f34-T5>>]

2018-01-09 08:10:43.338 [INFO ] Running as Group Policy client-side extension

2018-01-09 08:10:43.338 [DEBUG] Performing path-based import

...

2018-01-09 08:10:55.869 [DEBUG] Launched FlexEngine in DirectFlex mode

2018-01-09 08:10:55.869 [INFO ] Done (12529 ms) [<<IFP#132f8f34-T5]

2018-01-09 08:11:37.822 [INFO ] Performing UEM refresh [IFP#7b44e287-6f35de>>]

2018-01-09 08:11:37.822 [DEBUG] Running as child process of 'cmd.exe' (7428)

2018-01-09 08:11:37.822 [DEBUG]    User: DOMAIN\vdi.bruker, Computer: Desktop-001, OS: x64-win10 (Version 1703, BuildNumber 15063.483, SuiteMask 100, ProductType 1/4, Lang 0414, IE 11.483.15063.0, App-V 5.2.0.0, VMware VDM 7.3.1, UEM 9.2.1.794, ProcInfo 1/1/3/3, UTC+01:00S), PTS: 7576/7596/1C

2018-01-09 08:11:37.822 [DEBUG]    Recursively processing config files from path '\\HorizonServer\uem-config\general'

2018-01-09 08:11:37.822 [DEBUG]    Logging to file '\\HorizonServer\uem-profiles\test-User\logs\UEMlog'

2018-01-09 08:11:37.822 [DEBUG]    Log file will be overwritten when larger than 512 kilobytes

2018-01-09 08:11:37.822 [ERROR] Async UEM actions or UEM Refresh in progress

2018-01-09 08:11:37.822 [INFO ] Done (6 ms) [<<IFP#7b44e287-6f35de]

Any ideas why it waits almost a minute?

[ijdemes]

I know there are cases with Office in AppStacks that may result in 100% CPU usage. This was fixed in version 2.13 and up.

Do you see any high CPU usage, during logon?

[ijdemes]

It's also mentioned in the release notes:

VMware App Volumes 2.13 Release Notes | 19 OCT 2017

[lansti]

Thank you for your reply.

I can see that Office is an issue here, and i'll fix that with an upgrade.

but still, i see that logontime increases with 8-9 secons when i mount an appvolume with only notepad++ installed.

2018-01-09 10:47:50.724 [INFO ] Done (8151 ms) [<<IFP#da6f0895-T5]

2018-01-09 10:47:58.599 [INFO ] Performing UEM refresh [IFP#adbf1768-1e711f>>]

2018-01-09 10:47:58.599 [DEBUG] Running as child process of 'cmd.exe' (6168)

I assume that it should be a bit faster

[Ray_handels]

Hey lansti (and Ivan),

I guess that you are better off posting this on the Appvolumes forum, it isn;t really a UEM issue .

What happens when you use Appvolumes is that, when logging in, the APPV agent asks the manager which appstacks to attach. Then the manager checks this and asks the VCenter te recompose the VDI machine you are logging into. Normally this process takes up about 3 to 4 seconds so these will always be added to the login time. If you have esx 6.0 without any update it takes up to 3 seconds alone per appstack to reconfigure the machine, so in a case where you would have 5 appstacks it could take up to 20 seconds to complete this process.

Besides the 4 to 5 seconds that i explained above the reason why office takes much longer to login in comparison to Notepad is because Appvolumes (from 2.12 and upwards) uses something called reverse_replicate. What it does is it writes the registries for the application in the local registry. This way when you try to start up an application all registry settings are already there and don't need to merged the moment you start up the application. If you look at applications like Exact or ArcGis there are thousands of registry keys meaning that it could take up to more than a minute to start the application.

What they changed in 2.13 is that they postponed this reverse_replicate process until after logon (default 60 seconds after logon). This means the merge is being done instantly (it takes about 6 seconds to merge about 5 appstacks not taking to 5 seconds of part 1 into account) wheras with 2.12 we saw times of over 2 minutes. 60 seconds after logon though you will see the system process spiking up to 1 full cps usage (if you have 2 CPU's it will be 50%) which is the reverse_replicate taking place.

So I would definitely suggest upgrading to 2.13 if you need faster logon times.

And yes, please place Office within the golden image. It will safe you a crap load of issues .

[alsmk2]

Just to echo what Ray has already said. If you go to 2.13.1 you also get the benefit of being able to mix user & computer assignments. If you have any appstacks that everyone in the business needs access to, you can assign them to the computer objects instead. That means the appstacks are already attached before the user even logs on, and it will only be their specific user assigned stacks that will need processing during logon.

It's knocked a decent chunk of time off logons where implemented, and has improved overall user experience as most apps are ready to go as soon as they hit the desktop, rather than waiting for a random amount of time after the desktop is already visible whilst the various apps trickle in.

[Ray_handels]

I totally agree with your there alsmk2 but this only works if you don't have a writable volume, the writable always needs to be attached first.

They must come up with something don't you think?? Oh one can only dream