Windows 10 (1903) - UWP Apps - Roaming/U-EV profiles

[Benzini00]

Hi all,

 

I'm currently putting together our Windows 10 Enterprise 1903 build and seem to have hit an issue with UWP apps, having spent almost a week working on this issue I thought I'd ask here to see if anyone else has encountered the same issue or has any tried and tested work-arounds from previous builds?

 

Having used the excellent 'OneDriveMapper' powershell script for a number of years I decided to test the latest OneDrive client with 'Files on Demand' enabled, I want OneDrive to sign-in automatically for our users so I've followed documentation to allow our on-premises AD joined devices to perform a Hybrid Azure AD Join, which is a requirement for OneDrive client SSO.

 

The majority of our users hotdesk or use computer labs so we still utilise Ye-Olde Roaming Profiles, we've been evaluating U-EV but there's a number of 'features' that have prevented us from rolling U-EV out, mainly surrounding Outlook client but also the amount of on-going work required managing & maintaining XML templates for U-EV.

 

Anyhow, we're currently observing the following:

 

Log on to a Windows 10 device with a new account that uses a roaming profile

OneDrive signs-in automatically (SSO) as expected

All UWP apps open and function correctly - eg. Calculator / Maps / Edge / Photos / Skype / Snip & Sketch / Sticky Notes / Voice Recorder / Weather etc ...

Office 365 Applications (Word / Excel etc) are signed in (SSO) and function correctly

 

 

Providing a locally cached copy of the roaming profile remains on the device you can login multiple times to the same device and everything works perfectly, however, if the locally cached profile is removed via GPO or if the user moves to another lab device, things start to fail ...

 

 

If the locally cached profile has been removed or the user moves to another Windows 10 device

OneDrive fails to sign-in - "We can't sync your OneDrive folder"

UWP apps mostly fail to open or briefly flash up (attempt to open) and immediately close with the exception of: Maps / Edge / Skype / Sticky Notes

Office 365 Applications show an exclamation mark against the account name - "Sorry, we can't get to your account right now. To fix this, please sign in again."

 

 

I've also tried the above with an account that uses U-EV and get the exact same behaviour, all works fine initially with a fresh account and whilst there's a locally cached profile but if the locally cached profile is removed or the user moves to another device, things start falling apart.

 

 

I assume this behaviour is due to the fact that UWP apps store information in the 'Local' part of a user profile ... but surely there's a way to make UWP apps work in a domain/hotdesk/lab environment?

 

Any advice, assistance, thoughts gratefully received!

[Arthur]

Have you set the 'SpecialRoamingOverrideAllowed' registry value to 1?

 

https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles#step-7-optionally-specify-a-start-layout-for-windows-10-pcs

(www.edugeek.net/forums/windows-10/197483-windows-10-search-issues.html#post1688935)

[Arthur]

Do you know if that reg setting changes the way the UWP apps themselves roam/work or is it just to make sure the customised start menu app tiles roam and don't disappear? Just to be clear our app tiles are consistent, but when clicked the UWP apps attempt a launch and then immediately close.

Actually I think it's the following GPO you need to enable so apps install and open properly with roaming profiles. I would try this first.

 

https://happysccm.com/calc-wont-open-roaming-profile

 

If you enable the group policy 'Delete cached copies of roaming profiles' apps like calc, calendar, weather stop working. If you try to launch them from the start menu they just don't open, if you try from command the message is 'You'll need a new app to open this calculator'

 

This will also happen with mandatory profiles and temporary profiles.

 

To fix this you need to enable another group policy object

 

Computer Configuration > Administrative Templates > Windows Components > App Package Deployment > Allow deployment operations in special profiles: Enabled

 

https://gpsearch.azurewebsites.net/#7390

 

This policy setting allows you to manage the deployment of Windows Store apps when the user is signed in using a special profile. Special profiles are the following user profiles, where changes are discarded after the user signs off:

 

Roaming user profiles to which the "Delete cached copies of roaming profiles" Group Policy setting applies

 

Mandatory user profiles and super-mandatory profiles, which are created by an administrator

 

Temporary user profiles, which are created when an error prevents the correct profile from loading

 

User profiles for the Guest account and members of the Guests group

 

If you enable this policy setting, Group Policy allows deployment operations (adding, registering, staging, updating, or removing an app package) of Windows Store apps when using a special profile.

 

If you disable or do not configure this policy setting, Group Policy blocks deployment operations of Windows Store apps when using a special profile.

Edited June 3, 2019 by Arthur

[Benzini00]

Hi Arthur,

 

Thanks for this, I found others discussing the 'Allow deployment operations in special profiles' GPO during my research last week, I set it to enabled and tried again with a fresh account but it didn't make any discernible difference unfortunately.

 

Cheers,

 

Benzini

[Benzini00]

I spent yesterday creating test users & environments to try and get to the bottom of this issue, as a result of these findings I'm going to log a call with Microsoft as I believe there has been a change/bug introduced to 1903 that wasn't present in 1803. I'll post here with any updates for completeness.

 

Testing process:

 

I have two identical devices, W10-1803 has a fresh install of Windows 10 1803 (the build we've been using for the last 12 months) and W10-1903 has a fresh install of our Windows 10 1903 build

 

Both devices are in the same computer OU within our on-premises AD, thus receiving the same computer GPO's

 

I also created two test accounts, both using roaming profiles, test.1803 & test.1903 both accounts are in the same user OU within our on-premises AD, thus receiving the same user GPO's

 

 

I logon to W10-1803 with test.1803 and W10-1903 with test.1903

 

Upon first logon both devices/users behave as expected, all UWP apps launch successfully, Office 365 applications are signed in correctly.

 

I then reboot both devices, this clears the locally cached copy of the user profile due to having the "Delete cached copies of roaming profiles" GPO set.

 

I then log on to the devices ensuring the same user accounts are used with the same devices.

 

On the W10-1803 device all UWP apps open successfully with the exception of the 'Weather' app, which opens and then immediately closes. Office 365 Applications show an exclamation mark against the account name - "Sorry, we can't get to your account right now. To fix this, please sign in again."

 

On the W10-1903 device the majority of UWP apps attempt to open but then immediately close. Office 365 Applications show an exclamation mark against the account name - "Sorry, we can't get to your account right now. To fix this, please sign in again."

 

 

On the W10-1903 device the following is observed in Event Viewer for the majority of UWP apps, I'll list two examples as it's essentially the same error for each UWP app:

 

Event Viewer – Application

 

Event ID 1000

 

Faulting application name: Calculator.exe, version: 10.1812.1901.4008, time stamp: 0x5c304989

Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.1, time stamp: 0x59570cf9

Exception code: 0xc000027b

Fault offset: 0x0000000000712720

Faulting process ID: 0x298c

Faulting application start time: 0x01d51b8175c6ce91

Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1812.10048.0_x64__8wekyb3d8bbwe\Calculator.exe

Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll

Report ID: 3b2be1d5-7d48-454c-a2f5-3b12bcdc0744

Faulting package full name: Microsoft.WindowsCalculator_10.1812.10048.0_x64__8wekyb3d8bbwe

Faulting package-relative application ID: App

 

Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational

 

Event ID 5961

 

Activation for Microsoft.WindowsCalculator_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation

 

 

Event Viewer – Application

 

Event ID 1000

 

Faulting application name: Microsoft.Photos.exe, version: 2019.18114.19410.0, time stamp: 0x5c5610e0

Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.1, time stamp: 0x59570cf9

Exception code: 0xc000027b

Fault offset: 0x0000000000712720

Faulting process ID: 0x2288

Faulting application start time: 0x01d51b819a2b9297

Faulting application path: C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2019.18114.19418.0_x64__8wekyb3d8bbwe\Microsoft.Photos.exe

Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll

Report ID: 4027c070-d25c-459e-a2d4-2536e12617dc

Faulting package full name: Microsoft.Windows.Photos_2019.18114.19418.0_x64__8wekyb3d8bbwe

Faulting package-relative application ID: App

 

Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational

 

Event ID 5961

 

Activation for Microsoft.Windows.Photos_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation

 

 

The Weather App:

 

 

The Weather UWP App fails on both 1803 and 1903 the following is observed in Event Viewer, it essentially appears to be the same error:

 

 

1803

 

Event Viewer – Application

 

Event ID 1000

 

Faulting application name: Microsoft.Msn.Weather.exe, version: 4.22.1711.21004, time stamp: 0x5a14b3fc

Faulting module name: Windows.UI.Xaml.dll, version: 10.0.17134.556, time stamp: 0xd94c4e1e

Exception code: 0xc000027b

Fault offset: 0x00000000006a6082

Faulting process ID: 0x2bf4

Faulting application start time: 0x01d51b81b6e0246f

Faulting application path: C:\Program Files\WindowsApps\Microsoft.BingWeather_4.22.3254.0_x64__8wekyb3d8bbwe\Microsoft.Msn.Weather.exe

Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll

Report ID: b5d25ea5-5fc0-4c4e-bbbc-f9e8cd3a00b1

Faulting package full name: Microsoft.BingWeather_4.22.3254.0_x64__8wekyb3d8bbwe

Faulting package-relative application ID: App

 

Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational

 

Event ID 5961

 

Activation for Microsoft.BingWeather_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation

 

 

1903

 

Event Viewer – Application

 

Event ID 1000

 

Faulting application name: Microsoft.Msn.Weather.exe, version: 4.25.1901.21001, time stamp: 0x5c462b27

Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.1, time stamp: 0x59570cf9

Exception code: 0xc000027b

Fault offset: 0x0000000000712720

Faulting process ID: 0x2638

Faulting application start time: 0x01d51b81b4604752

Faulting application path: C:\Program Files\WindowsApps\Microsoft.BingWeather_4.25.20211.0_x64__8wekyb3d8bbwe\Microsoft.Msn.Weather.exe

Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll

Report ID: 2327e788-0039-4a6b-8488-6e9ef83018e3

Faulting package full name: Microsoft.BingWeather_4.25.20211.0_x64__8wekyb3d8bbwe

Faulting package-relative application ID: App

 

Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational

 

Event ID 5961

 

Activation for Microsoft.BingWeather_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation

 

 

As I mentioned at the start of this post, I'll update the thread as and when I hear back from Microsoft.

Edited June 5, 2019 by Benzini00

[BOOT]

I had the same issue with any apps, even the start menu. Registering the Microsoft.UI.Xaml app on logon helped most of the time.

Currently using a tool that registers all provisioned apps at logon.

[Benzini00]

Hi @BOOT3988

 

Are you able to share any information about the tool/script you're using during logon?

 

Many thanks,

 

Benzini00

Edited June 5, 2019 by Benzini00

[JasonNVSD]

UWP apps mostly fail to open or briefly flash up (attempt to open) and immediately close with the exception of: Maps / Edge / Skype / Sticky Notes

Yep, same here. We're not using Roaming profiles or U-EV. I posted here asking about it a couple weeks ago but got no replies.

 

Something I noticed... Even though Edge is an app, it's not a "provisioned" app, and it's not in the Store. The apps that break like Photos or Calculator are provisioned and part of the Store.

[BOOT]

Hi @BOOT3988

 

Are you able to share any information about the tool/script you're using during logon?

 

Many thanks,

 

Benzini00

This is what I'm using:

https://github.com/SN29856L/RegAllAppX

[Chuckster]

This is what I'm using:

https://github.com/SN29856L/RegAllAppX

 

How are you running this at logon?

[BOOT]

Via a GPO that adds an entry in:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components]

and removes the entry in:

[HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Installed Components]

[Benzini00]

Hi BOOT3988,

 

Thanks for the link, it's a brutal fix but I can confirm this resolves the issue of UWP apps not opening in 1903.

 

Unfortunately the way the script works is to reset UWP apps on every logon, thus the user will see a black screen for around 10-15 seconds after 'Preparing Desktop' completes whilst it resets the apps, and due to the UWP apps being reset any changes the user makes to those apps during their session will be lost when they next log in.

 

I'm starting to see other reports of issues with the Start Menu/UWP apps so it appears something has definitely changed or is broken in 1903.

 

Still waiting to hear back from Microsoft regarding the ticket I've raised, I'll post here when I've got more information.

[ful56_uk]

Hi

 

I am seeing this issue as well have Microsoft got back to you yet?

[jpbp200]

So here are my experiences.....

I have UE-V enabled and when I first sign on to a machine UWP app works OK. I have delprof.exe running as a script at logoff and when this happens the profile appears to be deleted OK but when a new profile is created I start to see the app failures described by the OP. If I delete the profile using System/system Info/ advanced system settings/user profiles etc etc this deletes the newly created (but now corrupted) profile OK and next logon works OK again. If I run Get-WmiObject Win32_UserProfile | Where-Object Special -eq $false | ForEach-Object Delete this gives errors but does fix the issue. However it leaves the profile folder in C:\Users so subsequent logins get the .000 .001 extensions. Also if delprof.exe is run manually on the machine it does completely remove the profile and folder and subsequent logins are OK.

 

The issue seems to be that if you use a script to delete a profile (no matter how you do it) then you see these errors the next time the profile is created but if you use the tools manually then the issue is not present.

 

A colleague has tested a script that runs BOTH Get-WmiObject Win32_UserProfile | Where-Object Special -eq $false | ForEach-Object Delete AND delprof.exe and reports that using both these tools in a single script run at logoff deletes the profiles cleanly and does not cause the issue when a subsequent new profile is created.

Edited June 17, 2019 by jpbp200

[JasonNVSD]

If I delete the profile using System/system Info/ advanced system settings/user profiles etc etc this deletes the newly created (but now corrupted) profile OK and next logon works OK again.

You can invoke this with powershell. For example:

Get-WmiObject -Class Win32_UserProfile | Where LocalPath -Like "C:\Users\*" | foreach Delete

[jpbp200]

You can invoke this with powershell. For example:

Get-WmiObject -Class Win32_UserProfile | Where LocalPath -Like "C:\Users\*" | foreach Delete

 

Hi Jason, thanks, yes I realise that. I mentioned further on in my post that BOTH methods work when run on the affected workstation. It is when they are invoked from a script set to run via GPO that the issues arise.

Edited June 18, 2019 by jpbp200

[Benzini00]

Hi all,

 

Microsoft are slowly working through the issue, lots of basic troubleshooting which we had already carried out prior to opening our support call, but they obviously need to check for themselves.

 

I mentioned that others were experiencing the same/similar issue, the support engineer, Shipra Singh, told me to share the case number and description so that others can log a call and reference it, this should help speed up resolution as Microsoft will then be able to see it's not an environment, device or build issue specific to ourselves.

 

119060524001140 In-built UWP apps not working with roaming profiles in Windows 10 1903

 

I'll post further information as and when progress is made.

 

Many thanks,

 

Benzini00

[BOOT]

Did you remove the Microsoft.MicrosoftSolitaireCollection app?

[Benzini00]

Hi BOOT3988,

 

Yes, we've removed it from every build since first deploying Windows 10.

 

Has something changed with that app that you're aware of, dependencies or otherwise?

[ful56_uk]

Hi BOOT3988,

 

Yes, we've removed it from every build since first deploying Windows 10.

 

Has something changed with that app that you're aware of, dependencies or otherwise?

 

read this

 

[BOOT]

Essentially, removing the Microsoft.MicrosoftSolitaireCollection app breaks dependencies for the vast majority of apps.

[Benzini00]

Oh wow ... I feel the pain of 'kr0k0f4nt' from the reddit post!

 

Right, time to test removing apps during the MDT task sequence rather than directly from the .wim

 

I'm going to follow this as it was mentioned in the comments on the reddit post: https://www.scconfigmgr.com/2019/05/03/remove-built-in-apps-for-windows-10-version-1903/

 

More shortly ...

[JasonNVSD]

read this

 

 

So the popular advice in the comments is to leave all the provisioned apps there. Personally, I don't care whether they waste their time on solitaire--the kids just play web games anyway. The reason we remove provisioned apps is so that they aren't installing during login. With shared computers and short classes, login times are critical.

[Benzini00]

I've been testing a few deployments over the last 2 days based upon the findings in the reddit post, at first I was hopeful that the removal of Microsoft Solitaire Collection or the use of DISM to remove unwanted UWP apps from the .wim was causing the issue but sadly that doesn't appear to be the case.

 

Here's what we've tried thus far:

 

1. Un-modified 1903 .wim - Removed our usual unwanted UWP apps using DISM and left Microsoft Solitaire Collection installed - Deployed with MDT LiteTouch - Same issue, UWP apps open on first login but fail to do so on subsequent logins.

 

2. Un-modified 1903 .wim - Deployed with MDT LiteTouch - Used a Task Sequence item to run a script to remove UWP apps during 'State Restore' phase leaving Microsoft Solitaire Collection installed - Same issue, UWP apps open on first login but fail to do so on subsequent logins.

 

3. Un-modified 1903 .wim - Deployed with MDT LiteTouch - Previous Task Sequence script disabled so all UWP apps install - Same issue, UWP apps open on first login but fail to do so on subsequent logins.

 

 

Having re-read the reddit post it appears the OP was unable to launch UWP apps at all when using a new account, whereas we can launch all UWP apps during the initial session but not during subsequent sessions.

 

Testing continues ...

Edited June 20, 2019 by Benzini00

[Arthur]

Testing continues ...

The last time Windows 10 had the app removal issue I successfully managed to remove any unwanted apps with NTLite. This doesn't use DISM so doesn't break the apps.

 

If you have the time I reckon it would be worth a try with 1903.