Virtual desktops disable load of appx packages at logon

[Björn Schläfli]

We use FSLogix as profile solution. Control Ups logon duration analyzer shows 15 - 25 seconds at logon at the phase 'load appx packages'. It happens at every logon, not just the first one.

 

DelayedDesktopSwitchTimeout  is set to 0 (also tested 1)

We use Citrix Optimizer 

We removed all possible appx packages while staging windows 10 22h2

 

The cause is probably that the appx packages are stored in the regkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\UserSID for each user. Of course, this SID key is missing on non-persistent virtual desktops. Therefore, the AppReadiness service thinks it's the first login by that user and installs the AppX packages each time. But how should it be possible to create this UserSID entry beforehand, since you don't know with which desktop gets assigned to which user with pooled desktops. HKLM for user keys...bad idea.

 

Does anybody have any helpful tips how I'm able to reduce this time? Is it possible to bypass this appx load package phase?

 

Disabling the service appreadiness kills the load of appx but that's no solution as you can't open start menu afterwards and a lot more issues.

 

[James Kindon]

Yeah this process is horrible and has been for a long time… amazingly it’s been somewhat optimised in multi session windows 10 but not enterprise… ridiculous really 

 

There is a new feature in the latest release that I have haven’t tested which appears to be the start of trying to address this issue https://learn.microsoft.com/en-us/fslogix/whats-new

 

That’s about all you can play with in a safe fashion 

[Björn Schläfli]

Hi James, 

 

thank you.

 

I'm currently testing fslogix 2210, as I've seen the appx improvement in their release notes but it's not helping. I think as long as Microsoft will write user reg keys into hklm it will not be possible to optimize logon duration when using pooled desktops. 

[James Kindon]

They do note that it is a work in progress - they will be able to control this with regardless of where it sits in the registry, there are always ways ? 

[Luis Saldivar]

Did anyone ever see this get fixed? I'm still having this exact issue now with our Non-persistent VDI?