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

[Benzini00]

The 'back-end' team at Microsoft have confirmed they are working on a fix for this issue, no timeline or method of fix delivery is available at this time, one assumes it will get bundled in with one of the monthly Windows Updates.

 

More as and when I hear anything.

[jpbp200]

So the workaround I have in place is to delete the profiles using a combination of the PS command AND delprof2.exe run in a single script at startup. This does completely remove the profile and I have not seen the issue since.

[Benzini00]

Hi jpbp200,

 

Could you detail how you're running both the PS and delprof2.exe in a single script? I think you mentioned earlier on in this thread that you had trouble doing this via GPO, or that it didn't work? Maybe I misread that?

 

Sounds like this would be a good workaround until the Microsoft fix makes an appearance and would mean we can start deployment of 1903.

[jpbp200]

I created a folder in NETLOGON and put delprof2.exe in it then the below script runs at startup. You can put delprof2.exe anywhere that can be accessed at startup I guess. Put the path to the folder of choice where delprof2.exe is in the "" where it says [PATH TO DELPROF]

 

 

 

New-PSDrive -Name "delprof" -PSProvider "FileSystem" -Root "[PATH TO DELPROF]"
$Profiles = Get-WmiObject Win32_UserProfile | Where-Object Special -eq $false
$localProfiles = $Profiles | Where-Object LocalPath -notmatch "default"
$paths = $localProfiles.LocalPath

$usernames = $paths -split "C:\\Users"
$localProfiles | ForEach-Object Delete
cd delprof:
foreach ($username in $usernames) {& .\delprof2.exe /q /id:$username /i /r}
cd C:
Remove-PSDrive -Name "delprof"

Edited July 3, 2019 by jpbp200

[jessica]

Have you heard back from Microsoft about a fix yet?

[Benzini00]

Hello Jessica,

 

I keep regularly chasing Microsoft about this, spoke to them last Thursday, no further news, they keep telling me it's with the 'backend team' and there's no timeline for a fix ... appalling, to say the least.

 

I'll post here as and when their response changes.

[tech-man]

We are seeing this exact issue as well! Watching with a lot of interest!

 

 

Hello Jessica,

 

I keep regularly chasing Microsoft about this, spoke to them last Thursday, no further news, they keep telling me it's with the 'backend team' and there's no timeline for a fix ... appalling, to say the least.

 

I'll post here as and when their response changes.

[jdsok]

We are having the exact same issue with students on mandatory roaming profiles. It's starting to be a real pain!

[LeonC]

I use Mandatory profiles with RES Workspace. I get the issue mentioned here on both a customized and non customized Windows 1809 image. I run the following Powershell command at logon and it has resolved the issue for me for all of the modern apps I have tried.

 

Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\Microsoft.UI.Xaml.2.1_2.11906.6001.0_x64__8wekyb3d8bbwe\AppxManifest.xml"

Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\Microsoft.UI.Xaml.2.1_2.11906.6001.0_x86__8wekyb3d8bbwe\AppxManifest.xml"

 

Perhaps this will help someone else.

[LeonC]

Just an update to this post. I made a little script that registers all versions of the Microsoft.UI.Xaml instead of a static version. This avoids any maintenance following Microsoft Updates.

 

The first part needs to run with administrator privileges to be able to access the WindowsApps folder, but the second part needs to be run as the user to register the applications within their session. I achieve this using the Ivanti Workspace Dynamic Permissions feature. If you don't have this, you could split this into two scripts. The first script could be run with admin or system privileges at machine start up. The second script could then be run in the user context when they login.

 

 

#Get list of installed versions of Microsoft.UI.Xaml

Get-ChildItem "C:\Program Files\WindowsApps" | Where-Object {$_.name -like "Microsoft.UI.Xaml*"} | Select Name | Export-CSV -Path C:\Support\MicrosoftApps.csv -NoTypeInformation

 

#Register each installed version of Microsoft.UI.Xaml

$items = Import-CSV C:\Support\MicrosoftApps.csvforeach ($item in $items){ $foldername = $item.Name Write-Host $item.Name Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\$foldername\AppxManifest.xml"}

[Benzini00]

Having not heard anything from MS support for a number of months, despite sending regular emails requesting an update on the ticket, I'm sure you can all imagine my surprise having downloaded build 1909 only to find this issue still exists!

[Lee_West]

Hi Folks,

 

We were having a similar issue. We've got all options set to delete profiles at logoff, but nothing worked. The solution was to make one of the groups they are part of Domain Guests. Guest profiles get wiped at logoff and we've barely had an issue since. For example, all our students are part of a student group for which ever campus they are on, etc xxx.students. That was the group we added to Domain Guests.

 

Works really well for us in terms of deleteing profiles at log off and we've had no issues with the APPX things.

[Benzini00]

Hi all,

 

Still trying to get this issue resolved over 8 months later, Microsoft support keep closing the case and marking it as resolved when it clearly isn't!

 

@LeonC I can't seem to get the second part of your powershell to work, would you mind checking and re-posting?

 

$items = Import-CSV C:\Support\MicrosoftApps.csv foreach ($item in $items) {$foldername = $item.Name Write-Host $item.Name Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\$foldername\AppxManifest.xml"}

 

 

Just an update to this post. I made a little script that registers all versions of the Microsoft.UI.Xaml instead of a static version. This avoids any maintenance following Microsoft Updates.

 

The first part needs to run with administrator privileges to be able to access the WindowsApps folder, but the second part needs to be run as the user to register the applications within their session. I achieve this using the Ivanti Workspace Dynamic Permissions feature. If you don't have this, you could split this into two scripts. The first script could be run with admin or system privileges at machine start up. The second script could then be run in the user context when they login.

 

 

#Get list of installed versions of Microsoft.UI.Xaml

Get-ChildItem "C:\Program Files\WindowsApps" | Where-Object {$_.name -like "Microsoft.UI.Xaml*"} | Select Name | Export-CSV -Path C:\Support\MicrosoftApps.csv -NoTypeInformation

 

#Register each installed version of Microsoft.UI.Xaml

$items = Import-CSV C:\Support\MicrosoftApps.csvforeach ($item in $items){ $foldername = $item.Name Write-Host $item.Name Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\$foldername\AppxManifest.xml"}

[Gio_W]

Hi Benzini00

I managed to get it working without errors:

Machine startup script:

New-Item -ItemType Directory -Force -Path C:\Support
Get-ChildItem "C:\Program Files\WindowsApps" | Where-Object {$_.name -like "Microsoft.UI.Xaml*"} | Select Name | Export-CSV -Path C:\Support\MicrosoftApps.csv -NoTypeInformation

User Logon script:

$items = Import-CSV C:\Support\MicrosoftApps.csv
foreach ($item in $items) { 
$foldername = $item.Name 
Write-Host $item.Name 
Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\$foldername\AppxManifest.xml"    
 }

 

What error are you getting?

 

Hi all,

 

Still trying to get this issue resolved over 8 months later, Microsoft support keep closing the case and marking it as resolved when it clearly isn't!

 

@LeonC I can't seem to get the second part of your powershell to work, would you mind checking and re-posting?

 

$items = Import-CSV C:\Support\MicrosoftApps.csv foreach ($item in $items) {$foldername = $item.Name Write-Host $item.Name Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\$foldername\AppxManifest.xml"}

[Benzini00]

Hi @Gio_W,

 

Apologies for the delay responding, thanks for posting the code again, it was a formatting issue on my side, doh!

 

The scripts appear to work in terms of allowing the UWP apps to at least open on subsequent logins/different devices when using roaming profiles, however, all UWP apps get reset which means the user will experience first-run conditions, not a deal breaker but it could be annoying if certain UWP apps are used regularly ... I guess this is what happens when UWP app settings aren't stored within the 'Roaming' folder of the users profile though, thanks Microsoft!

 

When using the scripts we're experiencing a long delay during user logon, the user is presented with a black screen for a minute or so before finally seeing the desktop, has anyone else observed this behaviour too?

 

In other news, still nothing back from Microsoft about the roaming profile / UWP issue, has anyone else logged this issue with Microsoft, if so would you mind sharing your case numbers?

[turnerr12]

Hi Benzini00

I'm guessing as you have not posted since Feb on this that you have still not heard anything from MS? We are also having the problem now.

[Benzini00]

Hi turnerr12,

 

I've pretty much resigned myself to the fact this will never get fixed unless it's taken out of the hands of 1st & 2nd line support, in this case MS seem to have farmed support out to Convergys, unfortunately they're more interested in closing the ticket than resolving it, no doubt because they want their support stats to look good for Microsoft ... I keep being told the issue is with the 'backend team' and then shortly after the ticket is closed and marked as resolved, obviously it's not resolved, so I re-open the ticket and the process repeats.

 

It's now been over a year and the whole experience has been abysmal to say the very least.

 

Please feel free to report your experience to Microsoft and reference our case number, if more people report this hopefully it'll get the attention it requires, our case number is: 119060524001140

[Garacesh]

I don't suppose I'd be so lucky that a solution was found in the past few months?

 

I thought this issue was down to me using mandatory profiles in my last school, but I've done everything local here and the issue still presents itself.. Once you remove a profile, the UWP apps that I left in the image (Calculator, Photos, Snip & Sketch etc) fail. Except Camera, for some reason Camera still works. Sticky Notes, too.

 

I'm assuming my only option is 'go with third party flavours' (Speedcruch, Irfanview, Greenshot, etc)

[BOOT]

How are you removing profiles?

Delprof, ProfileList registry and Users\Profile folder deletions are going to break the sync between the UWP App registry and the Profile.

[Benzini00]

Hi Garacesh,

 

The furthest we got was Microsoft admitting that UWP apps are pretty much broken when it comes to the use of roaming profiles.

 

During lockdown I investigated our options and found that using FSLogix pretty much resolved the issue due to the way it captures the entire profile rather than just the 'Roaming' aspect, after configuration & testing we took the decision to deploy across our desktops for staff & students, it's all working perfectly so far! ... For mobile/laptop devices we decided to go for local profiles as using FSLogix off-network was too slow across DirectAccess/VPN, the majority of 'important' folders are already redirected to OneDrive and the people using mobile devices typically use the same device on a long term basis and rarely have need to use a desktop device on campus.

 

If you're licensed for FSLogix and have a decent amount of network storage to provision it (typically around 5Gb per user profile, although de-dupe and compression is giving us over 50% savings at the moment) then I'd highly recommend it!

Edited October 22, 2020 by Benzini00

[Garacesh]

How are you removing profiles?

Delprof, ProfileList registry and Users\Profile folder deletions are going to break the sync between the UWP App registry and the Profile.

On my test rig, manually, Users+Registry.

'Out in the wild', using the GPO method, but there was an issue with extensions/default software that necessitated removing all profiles, which has now bork'd software.

 

 

@Benzini00 we aren't using roaming profiles though, and nor do we have the infrastructure to at the moment. Just local ones, with group policy and folder redirection doing the gruntwork.

[JasonNVSD]

After struggling with this for years, the problem seemed to be caused by using an unattend/answer file during OSD that does things to the default user profile. We eliminated it completely with 1909 and have had zero problems since.