VMware Horizon Community
pbastiaans
Enthusiast
Enthusiast

Slow Login - Windows 10 UWP

We are seeing very login times (1.5 mins to 3 mins), ControlUp logon analyzer seems to be pointing at Windows 10 UWP processing at 'first' login.

Anyone else experienced this? And resolved hopefully. 🙂

The environment:

  • Windows 10 1809
  • DEM 2006
  • Horizon 7.12
  • AppVolumes 2.13

ControlUp Logon Analyzer output (bottlenecks highlighted in blue text):

Auditing of "Process Creation" is not set to at least "Success" as required, it is set to "None"
Auditing of "Process Termination" is not set to at least "Success" as required, it is set to "None"

Display Protocol : BLAST

Logon start : 12/14/2020 08:34:01
Logon end : 12/14/2020 08:37:09
Duration : 187.6 seconds

Source Phase Duration (s) Start Time End Time
------ ----- ------------ ---------- --------
Horizon Authentication 0.0 08:34:01.5 08:34:01.6
Horizon Broker 0.6 08:34:01.5 08:34:02.2
Horizon Protocol Connection 0.3 08:34:06.0 08:34:06.3
Pre-Windows Duration 4.8

Source Phase Duration (s) Start Time End Time Gap (s)
------ ----- ------------ ---------- -------- -------
Windows Windows Logon Time 0.0 08:34:08.7 08:34:08.7
FSLogix LoadProfile 0.0 08:34:11.6 08:34:11.6 2.9
Windows User Profile 8.8 08:34:11.6 08:34:20.5 0.0
Windows Group Policy 3.0 08:34:20.6 08:34:23.6 0.1
App Volumes ShellStart 10.1 08:35:15.8 08:35:25.8 52.2
FSLogix ShellStart 5.5 08:35:26.4 08:35:31.8 0.5
Shell AppX File Associations 16.2 08:35:35.2 08:35:51.4 3.4
Shell AppX - Load Packages 73.2 08:35:55.9 08:37:09.2 4.5
Shell ActiveSetup 18.5 08:35:58.8 08:36:17.3
Windows Duration 177.5

Non blocking logon tasks
------------------------

Group Policy asynchronous scripts were processed for 4.5 seconds

Logon Scheduled Task Duration (s) Action Name
-------------------- ------------ -----------
\RestoreTiles 53.21 %SVAgent%RestoreTiles.exe
\Microsoft\Windows\Workplace Join\Automatic-Device-Join 4.81 %SystemRoot%\System32\dsregcmd.exe
\Microsoft\Windows\CertificateServicesClient\UserTask 19.37 Certificate Services Client Task Handler
\Microsoft\Windows\Plug and Play\Device Install Reboot Required 2.85 Device Installation Reboot Dialog Task
\Microsoft\Windows\WindowsColorSystem\Calibration Loader 2.64 Color Calibration Loader
\Microsoft\Windows\EnterpriseMgmt\MDMMaintenenceTask 48.87 %windir%\system32\MDMAgent.exe
\Microsoft\Windows\TextServicesFramework\MsCtfMonitor 2.70 MsCtfMonitor task handler
\Microsoft\Office\OfficeTelemetryAgentLogOn2016 15.22 C:\Program Files\Microsoft Office\Office16\msoia.exe
\Microsoft\Office\OfficeTelemetryAgentLogOn 38.45 C:\Program Files\Microsoft Office\Office15\msoia.exe

 

3 processed GPO CSEs sorted by the most time spent processing them (seconds)

GPO Time Spent (s)
--- --------------
DEVGPO 1.781
Local Group Policy 1.672
Default Domain Policy 1.672

 

 

5 Replies
SimonPetrikov
Enthusiast
Enthusiast

I am seeing the exact same thing in my environment as well, AppX - Load is taking a long time, but not for all users though...

When viewing the Windows event logs on their session, I actually see the packages getting installed twice.

Did you see something similar or have you had a chance to resolve this issue?

Reply
0 Kudos
SimonPetrikov
Enthusiast
Enthusiast

One suggestion I did receive from asking reddit was to delete active setup keys but I have not yet applied that.

https://kb.vmware.com/s/article/2100337

Reply
0 Kudos
pbastiaans
Enthusiast
Enthusiast

Thank you. We run the Virtual Opt Tool and I'm pretty sure that does it. I will verify these keys are in fact not part of the ref image and update this post.

pbastiaans
Enthusiast
Enthusiast

We found that a good chunk of our login time was due to the app vol agent, VMware tech had us upgrade just the agent from 2.18.0.25 to 2.18.4, reduced 20-30 seconds with each login.

The AppX thing still happens but the agent has bought me some breathing room.

SimonPetrikov
Enthusiast
Enthusiast

Well that is good news.

We aren't using appvolumes in our environment.

Tags (1)
Reply
0 Kudos