Whenever you get a new Windows PC or use a PC configured for work or school you may have noticed there are many apps pre-loaded and available for use on the device. This is an important part of the Windows experience as well as a critical technology for schools and the workplace. Today we’ll introduce the basics of what we call “pre-installed apps” and then follow that up with discussion of more advanced topics.
How Preinstalled Apps Work
A typical app install can be broken down into two fundamental steps: 1) Staging, and 2) Registration. When we stage an app, we place the all the files in the app package into the file system and set appropriate ACLs. Once staged, the app can then be registered for the current user. Registration is where we do all the setup to make the app available to the user and integrated with the operating system, such as creating user-specific app data locations, enabling discovery of app extension points like file type associations, and creating the app tiles. There are many more interesting things that happen but the most important takeaway is that registration absolutely must happen per-user, while staging the app only needs to be done once and can be done without any users. We need only stage an app once for any number of users, but each user must be logged in to register the app.
In order to preinstall an app for a user, we still need to do these same two steps of stage and register. Staging is easy enough; it can be done anytime and even done offline into the Windows image long before the PC is even manufactured. But registration requires a user to be logged in, and for a new PC or new user account that can’t happen until the user signs in for the first time. To complete the pre-installation we must register the app on behalf of the user after the user signs in. We accomplish this using a system service which knows about all the pre-installed apps that need to be registered and then automatically triggers the registration when the user first signs in. We call this service the App Readiness Service, or ARS.
So in an over-simplified nutshell, pre-installed apps work by staging the app package onto disk and then configuring it for automatic registration for each user the next time that user signs in.
All app provisioning is encapsulated within the DISM tool, and it does both the staging and ARS setup. To do provisioning, you need an app package (in .appx or .appxbundle form) and any dependency packages. We won’t go into detail here, as we already have reference documentation for that.
This will list all of the apps that are pre-installed on the image.
This stages the appx package and configures it for pre-install. All dependencies must be provided as well, which can be found in the SDK or with store-downloaded packages.
This can be used to remove a pre-installed app. Note that it does not remove the app if it is already registered for any users – this only strips the auto-registration behavior so it will not be auto-installed for any new users. If no users have yet installed the app, this command will also remove the staged files.
All of these commands are also available using Powershell.
Licensing only applies when provisioning a Windows Store app. Enterprise or really any app that isn’t from the Windows Store can be provisioned without a license. If an app is from the Store a machine-license must also provided when the app is provisioned. At this time, all pre-installable Windows Store apps must be free apps and configured to be pre-installable via the Windows Store Dev Center. Once it is configured the pre-installable package and license can be downloaded and then provisioned onto any image.
Here are some related resources for preinstalled apps.
Thanks for reading!
David Bennett, Program Manager – Microsoft