Apr 01 2020 03:29 AM
Apr 01 2020 03:29 AM
Currently we have a WVD environment with Windows 10 Multi Session combined with FSLogix.
We are running into issues when trying to use the apps from the Store.
This is what we are currently trying:
When we are trying this under the administrator, which is also excluded from using FSLogix profiling, it appears to keep the app installed, even after signing off and logging back in. This isn't a solution however, since the app is then only installed for the administrator.
It is still a bit unclear to us whether or not the Store apps are supported on WVD and if it is possible to distribute an app to all users (unlike what we are trying now under the specific user).
Is there any documentation on this subject perhaps?
May 14 2020 03:25 AM
@tomdw did you make any progress on this? We are experiencing exactly the same behaviour, very frustrating.
I am making the assumption that by having FSLogix enabled the filter driver is kicking in and 'potentially' invoking some future MSIX AppAttach functionality and making the C:\program files\windowsapps folder non-persistent.
Would be great to hear if you overcome the issue. We have tried all recent variants of the FSLogix agent.
Aug 21 2020 01:51 AM
@tomdw Hi, I opened a ticket with Microsoft and this is the below response:
As we spoke on the phone a few minutes ago, after my meeting on monday with WVD subject matter experts, I proceeded to raise this issue yesterday with a main FsLogix developer.
He acknowledged that this is an issue the FsLogix Team is aware of. Currently it is not possible to run Modern Apps along with FsLogix, and this is a by design behaviour as both technologies are working as expected, the problem is the compatibility between them.
This is caused by the way both technologies work. Basically Modern apps have part of the info in the base OS and part of the info in the user profile, and FsLogix seamlessly redirects user profiles. This causes problems with persistency.
When the Modern app version in the FsLogix user profile registry doesn’t match the version of Modern app running in the base OS, it doesn’t appear to be available for the user
As it seems this is the first time this issue was raised, this is not internally documented yet, there’s not a number or article confirming this I can share with you yet.
We should expect a compatibility fix from Microsoft in the form of a per-machine installation, just like with Teams and OneDrive, but there is not an estimated date for this.
So for now if you want to use UWP apps you cannot do this while using FSLogix profiles.
I do think this is crazy as UWP / Store apps are are massive part of the basic usage of the OS.
Due to this is have had to stop using FSLogix profiles in WVD and switch to traditional roaming profiles and folder re-direction.
Feb 10 2021 02:32 AM
Can confirm that I have discovered this too - I find it unbelievable that Windows Store apps don't work with WVD/FSLogix.
Any ideas where we can raise this issue so that it gets fixed?
Mar 29 2021 07:44 AM - edited Apr 05 2021 02:17 PM
+1 to the list of folks observing this problem.
This is really bad for anyone using Windows 10 Multi-Session Pooled deployments where the same profile container is used with updated host pools. The user expects to get an updated experience with the newly updated host pool an this is true for Win32 apps. But, the "Modern" store apps are whacked.
Doesn't seem so "modern".... A fix would have to entail updating the user profile hive with the new version info. That or perhaps breaking away from writing version specific info in the first place which seems like a better path.
@msft? Are you reading these posts?
Rough waters for the Flagship Azure WVD!!!
Apr 15 2021 07:09 AM
VMWare Horizon non-persistent same issues.
Apps work for new users. When apps update themselves or through updating the MASTER image the apps stop working. Also a topic on Microsoft Q&A.
May 24 2021 05:12 PM
Hi, I would suggest to refer to this article for more detail why UWP apps can't be installed in WVD environment: https://docs.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq#how-do-i-make-sur...
This happens because you're using Windows 10 Enterprise multi-session with a profile management solution like FSLogix. Your admin or profile solution configured your system to delete user profiles when users sign out. This configuration means that when your system deletes your user profile after you sign out, it also removes any apps you installed during your session. If you want to keep the apps you installed, you'll need to ask your admin to provision these apps for all users in your Windows Virtual Desktop environment.
Most virtualized environments are configured by default to prevent users from installing additional apps to their profiles. If you want to make sure an app doesn't disappear when your user signs out of Windows Virtual Desktop, you have to provision that app for all user profiles in your environment. For more information about provisioning apps, check out these resources:
May 24 2021 07:15 PM - edited May 24 2021 07:17 PM
I feel like Microsoft doesn't understand the problem statement. The use of FSLogix is very similar to a UPD scenario where the user profile is stored on a central storage location so that the profile remains available to sessions created on different hosts.
It's commonplace for the local profile to be deleted post logoff, in fact many other problems can manifest if this isnt done.
Also, it seems like Microsoft is completely ignoring the fact that these same apps work fine for new users. On that thought, you can delete an old profile container (FSLogix reference), have that user logon and these apps now work again as expected.
The problem is that the application references in the profile (stored on a network location in a .VHD(x) and mounted ad logon) are not getting updated with the new application version information, effectively creating broken app references.
This configuration is pretty much the standard configuration for organizations that deploy Azure WVD and a Pooled Session Host config.
These references to FSLogix profile containers being the problem are counter productive to one of the hottest Azure solutions these days. We're following Microsoft guidance on the deployment! Is Microsoft suggesting that we no longer use FSLogix? What would happen if this same problem could be reproduced with a UPD?
Why cant Microsoft not admit that there's a significant problem with the way that these applications (MS Store Apps) get updated in an existing profile? That is the root of this problem, not FSLogix!