Just a quick one for starters today (as I have a bunch of stuff I want to get out there). However, I want to quickly run through a problem I had over the last few days with the latest iteration of Windows 10.
Everyone (hopefully!) knows what UWP applications are – Universal Windows Platform apps (also known as Store apps, Metro apps, Modern apps, Universal apps). They are the “self-contained” applications that are deployed to Windows 10 when a user logs on for the first time, and are gradually increasing in number and scope. The user can visit either the Windows Store or the Windows Store for Business to add more UWP apps to the ones that are automatically deployed when they log on.
Recently, I noticed that during some testing on the latest version of Windows 10 (version 1709, fully patched as of Jan 18), that the UWP app deployment was not happening properly. Normally I remove most of the auto-deployed UWP apps from the image, but in this case I was trying to test with fully vanilla Windows 10 images. Intermittently, a user would log on for the first time and receive a desktop and Start Menu that looked like this
A few of the UWP apps had deployed, but most of them (including the Store itself) were missing. It wasn’t a timing or connectivity issue – leaving the VM for a long period of time made no difference, multiple logins made no difference, and Internet connectivity was good.
Oddly enough, running the following PowerShell (which normally reinstalls and repairs all UWP apps in the image) also made no difference at the next initial logon
Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}
However, when logging on with some other user accounts to the same machine, we would observe that all of the UWP apps were deploying correctly, as shown in the image below
Investigation revealed that the user account that didn’t work was identical to the one that did work – except for one difference, the errant user account had a network home drive defined on the user object in Active Directory
Bizarrely enough, setting the Home folder attribute back to “Local path” stopped the deployment from failing (once the local copy of the errant user account was removed).
Digging deeper, I found that when the Home folder attribute was set, a number of errors appeared in Event Viewer at logon from source ESENT, reading something like this
Error ShellExperienceHost (5584,P,0) TILEREPOSITORYS-1-5-21-2950944927-1203068717-1704750700-2614: An attempt to open the device with name “\\.\C:” containing “C:\” failed with system error 5 (0x00000005): “Access is denied. “. The operation will fail with error -1032 (0xfffffbf8).
Clearly, it seems there is an attempt to read or write somewhere that is failing. However, these home folders had worked fine on all previous versions of Windows 10, and the permissions had not changed.
However, having vast experience with Microsoft changing the context of how various tasks run, I elected to add the “Domain Computers” group to the ACL for the home drives as a test…
…and to my surprise, everything now started working as expected, a user with a home folder defined in AD could now log on and get the full set of UWP apps correctly deployed.
I’m not entirely clear why this was happening – nothing appeared to be written to the home drive that I could see. If I’d had time, I’d have liked to change the permissions back and run a session 0 Process Monitor to find exactly why I was seeing this behaviour. However, as with all things Windows 10, I expect this will probably be rectified by Microsoft in an update without ever telling us that an issue has been fixed (that’s the way now – there is never any detail).
So if you find you’re having trouble with the Store or bunches of UWP apps missing when you log on to Windows 10 1709, check the permissions on your networked home folders.
Share
