Windows 10 Store Applications With Sysprep
Monday 6th November, 2017 13:22
It's not always feasible to use tools like MDT to deploy the standard Windows 10 image and rely on Active Directory and WSUS to install additional software or configure and patch the system. Sometimes you need to hand someone a hard drive that's ready to boot up in a laptop. That, and because the image would be about 300GB to copy over the network, is why I've been using Sysprep to prepare Windows 10 for deployment across a range of laptops. This seemed to go okay earlier this year with Anniversary Update 1607, but while trying to put together a similar build using the recently released 1709 ISO from Microsoft it all went horribly wrong. The root cause? Microsoft Store applications.
Microsoft recently updated their guidance to warn about this issue:
Note To prevent Microsoft Store from updating apps, unplug the Internet connection or disable Automatic Updates in Audit mode before you create the image.
That's because as soon as Windows 10 can reach the Internet it will update your applications by default. People have come up with workarounds, but not everyone can rely on WSUS or firewall rules.
The workaround I've used is to install Windows without connecting a network cable, making sure not to enter the password for WiFi, and keeping the switch disabled to turn off WiFi until you can disable the updates. With this airgap in place, you can either manually add the registry key or modify the local group policy setting using gpedit.msc:
Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Store > Turn off Automatic Download and Install of updates
This setting configures the registry key HKLM\SOFTWARE\Policies\Microsoft\WindowsStore with the DWORD AutoDownload with a decimal value of 2.
This same registry key also controls the local group policy setting:
Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Store > Turn off Automatic Download of updates on Win8 machines
If you configure one local group policy setting, it should set the other automatically. At this point I also configure the other Store settings with suitable values, including "Turn off the Store application", but that shouldn't be necessary for everyone.
For good measure, at this point I run the following command from an elevated Command Prompt:
gpupdate /force
And then to really make sure everything's definitely okay, I reboot the computer. This might seem like overkill, but getting this wrong at the start means you might waste hours of time.
Once the system's back up it should be safe to connect to the Internet, either over WiFi or using a network connection. This seems to be working for me.
I've read vague statements that this doesn't always work (my best guess is group policy or the registry key wasn't applied before Windows starts checking for updates, so although it only had Internet access after the setting was created it's possible that Windows may not have checked the updated value and adjusted its behaviour - restarting the three Store related services may help if you don't want to do a full reboot?). I've also read that other people have tried the firewall rule trick and still had updates install.
I still see somewhat unusual behaviour, as it looks like Windows identifies that new applications exist and a download arrow seemed to appear in the Start Menu for many applications. I'm still not entirely sure what causes that. There have been some suggestions it's down to settings such as "Windows Components > Cloud Content > Turn off Microsoft consumer experiences" allowing Windows to check for updated Store applications but not downloading or installing them, so it may be worth configuring that setting before connecting to the Internet. Definitely one I'll try if I decide to jump through the hoops of building a brand new image again.
With the Store applications remaining "stock" (even if it knows of newer ones existing), it should be fine to run Sysprep. I no longer receive those errors, although if I run Sysprep from a non-Administrator account it does seem to affect the Start Menu for that account (new accounts are fine; I've not re-enabled and logged into the Administrator account to check if that's also affected), which is also why I've avoided using the CopyProfile option in my unattend.xml answer file. For now, I manually delete the registry key after recreating the airgap (WiFi disabled, no network cable) immediately before running Sysprep, but I'm thinking of adding the reg command to SetupComplete.cmd so it'll only delete the key after running Sysprep. That way users will be able to download and install the new Store apps.
Some people may want to remove the applications from their build (I agree that many of the applications should not be present by default, especially for Enterprise edition installations). You can do this manually using PowerShell, and there's a Windows 10 Decrapifier 2 script that's worth a look (it can apparently remove all but the essential applications).
Despite best efforts, you may still run into issues where applications are installed for users that aren't provisioned. If you hit that problem and it affects an account that has since been deleted, you may be screwed. I tried looking into that at one point, and it may be possible to stop services and open up the SQLite3 database in order to remove entries for the user (if you filter by the affected application/package you can probably work out the user's ID) but I gave that a try during one failed attempt, and while Sysprep was happy to run and shut the system down, it never came back up again cleanly. Maybe I missed something, but depending on what you need to configure it may be quicker to start again.
Microsoft recently updated their guidance to warn about this issue:
Note To prevent Microsoft Store from updating apps, unplug the Internet connection or disable Automatic Updates in Audit mode before you create the image.
That's because as soon as Windows 10 can reach the Internet it will update your applications by default. People have come up with workarounds, but not everyone can rely on WSUS or firewall rules.
The workaround I've used is to install Windows without connecting a network cable, making sure not to enter the password for WiFi, and keeping the switch disabled to turn off WiFi until you can disable the updates. With this airgap in place, you can either manually add the registry key or modify the local group policy setting using gpedit.msc:
Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Store > Turn off Automatic Download and Install of updates
This setting configures the registry key HKLM\SOFTWARE\Policies\Microsoft\WindowsStore with the DWORD AutoDownload with a decimal value of 2.
This same registry key also controls the local group policy setting:
Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Store > Turn off Automatic Download of updates on Win8 machines
If you configure one local group policy setting, it should set the other automatically. At this point I also configure the other Store settings with suitable values, including "Turn off the Store application", but that shouldn't be necessary for everyone.
For good measure, at this point I run the following command from an elevated Command Prompt:
gpupdate /force
And then to really make sure everything's definitely okay, I reboot the computer. This might seem like overkill, but getting this wrong at the start means you might waste hours of time.
Once the system's back up it should be safe to connect to the Internet, either over WiFi or using a network connection. This seems to be working for me.
I've read vague statements that this doesn't always work (my best guess is group policy or the registry key wasn't applied before Windows starts checking for updates, so although it only had Internet access after the setting was created it's possible that Windows may not have checked the updated value and adjusted its behaviour - restarting the three Store related services may help if you don't want to do a full reboot?). I've also read that other people have tried the firewall rule trick and still had updates install.
I still see somewhat unusual behaviour, as it looks like Windows identifies that new applications exist and a download arrow seemed to appear in the Start Menu for many applications. I'm still not entirely sure what causes that. There have been some suggestions it's down to settings such as "Windows Components > Cloud Content > Turn off Microsoft consumer experiences" allowing Windows to check for updated Store applications but not downloading or installing them, so it may be worth configuring that setting before connecting to the Internet. Definitely one I'll try if I decide to jump through the hoops of building a brand new image again.
With the Store applications remaining "stock" (even if it knows of newer ones existing), it should be fine to run Sysprep. I no longer receive those errors, although if I run Sysprep from a non-Administrator account it does seem to affect the Start Menu for that account (new accounts are fine; I've not re-enabled and logged into the Administrator account to check if that's also affected), which is also why I've avoided using the CopyProfile option in my unattend.xml answer file. For now, I manually delete the registry key after recreating the airgap (WiFi disabled, no network cable) immediately before running Sysprep, but I'm thinking of adding the reg command to SetupComplete.cmd so it'll only delete the key after running Sysprep. That way users will be able to download and install the new Store apps.
Some people may want to remove the applications from their build (I agree that many of the applications should not be present by default, especially for Enterprise edition installations). You can do this manually using PowerShell, and there's a Windows 10 Decrapifier 2 script that's worth a look (it can apparently remove all but the essential applications).
Despite best efforts, you may still run into issues where applications are installed for users that aren't provisioned. If you hit that problem and it affects an account that has since been deleted, you may be screwed. I tried looking into that at one point, and it may be possible to stop services and open up the SQLite3 database in order to remove entries for the user (if you filter by the affected application/package you can probably work out the user's ID) but I gave that a try during one failed attempt, and while Sysprep was happy to run and shut the system down, it never came back up again cleanly. Maybe I missed something, but depending on what you need to configure it may be quicker to start again.
