Microsoft – Why did you enable Store and apps for built-in admin?
I have written earlier about this topic, but as I feel it is absolutely the worst decision Windows 10 developers have ever made, I need to write about it again: Microsoft, why did you enable Store and Store apps for the built-in administrator account in version 1709? A bad decision, and one that’s still causing major issues, especially when trying to generalize an image with Sysprep in Audit Mode.
Quoting myself, I wrote this a year and a half ago:
In one of their worst decisions ever, the Windows and Windows Insider teams now allow the built-in administrator account to use, install and update UWP apps, and also allows that same administrator account to be switched over to a Microsoft account. Both of these “features” appeared in version 1709. Both are illogical, stupid and unnecessary features that should be removed. Worse yet, switching the built-in admin to a Microsoft account is also irreversible. In fact, once it has been switched over, there’s no way to stop using one’s MS account to sign into the built-in admin account!
Version 1709 also enabled Store and Store apps for the built-in admin account. Up to version 1703, the only Store app working when signed in as the built-in admin was Windows Settings. Not even Edge browser could be used, if you wanted to use Internet you had to use Internet Explorer. This made complete sense. When signed in as built-in admin, there should be no reason whatsoever to let that user access the Microsoft Store and apps, or switch this local built-in admin account to a Microsoft account, especially considering that this switch is irreversible.
I am especially worried about this because of the issues it causes for Windows image customization and generalization. On an official Microsoft Docs article, last updated in May, 2017, Microsoft says the following:
Installing new Microsoft Store apps or updating your existing Microsoft Store apps before generalizing a Windows image will cause Sysprep to fail. Sysprep /generalize requires that all apps are provisioned for all users; however, when you update an app from the Microsoft Store, that app becomes tied to the logged in user account. The following error appears in the Sysprep log files (located at %WINDIR%\System32\Sysprep\Panther):
<package name> was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
Then, half a year later with version 1709, Store and Store apps were enabled for the built-in admin account. When customizing and preparing a Windows 10 image in Audit Mode, as soon as you are signed in with the built-in admin, the Store starts updating its apps, and when sysprepping with the /generalize switch, the error message shown in title image appears. Of course, I can remove provisioning and apps with PowerShell before generalizing the image, but that shouldn’t be necessary.
In my very subjective, personal opinion, Microsoft should fix this NOW. There is absolutely no reason to use the built-in admin account as a normal user account, and therefore, absolutely no reason to allow it to switch over to an MS account, or use the Microsoft Store and Store apps. I would be quite interested in hearing from the dev team, why this change was made? And, why haven’t they fixed it yet? Like yesterday?
Kari
Author: Kari Finn
A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.