The Windows Store came with Windows 8 and gets even more integration with 8.1 Update. In my opinion, it is ok for consumers but really throws things for a loop in the enterprise environment. There isn’t much difference between downloading and installing a program from the Internet and using the Windows Store.
In particular, I have come across a few scenarios where a Windows 8 app is wanted to be installed automatically for all new computers. Another case has been a lab environment using mandatory profiles that wanted to take advantage of a Windows Store app but was unable to even enter the store.
When trying to open the Windows Store from a mandatory profile, I received the message “You can’t access the Windows Store because you’re signed in to this PC using a temporary or guest account. Please sign in using a different type of account.” I didn’t want the lab users to get that message nor did I really want them installing apps in this controlled environment, even if they would get wiped out after a reboot. A group policy setting under Computer Configuration and User Configuration, Administrative Templates, Windows Components, Store: Turn off the Store application allows you to prevent access to the Windows Store. If you try to launch the Store, users will now get a message saying “Windows Store isn’t available on this PC. Contact your system administrator for more information.” This setting also seemed to remove the Store from the taskbar, an annoying change that Windows 8.1 Update brought.
After applying that setting, it successfully blocked access to the Store but also meant the apps that were already installed were unable to open and had an ‘X’ on the tile.
When looking in the Apps View, the provisioned (pre-installed) apps had a faded ‘Error’ next to them and were unable to open. This would make for a lousy first impression to an open lab environment.
Since these apps were not going to work anyways, I decided to remove them. The PowerShell script to do so is very easy:
Get-AppxProvisionedPackage -online | Remove-AppxProvisionedPackage -online
Some apps like the Store will give an error and be skipped over because they can not be removed. The command removed the tiles for the other built-in apps that it could. As a side benefit, it also sped up the Welcome sign in animation from 65 seconds to just 9 seconds.
Now that I had gotten the disabled apps removed, it was just a matter of adding back the apps that I did want. Microsoft has plenty of documentation on installing Modern Apps or Windows Store Apps using PowerShell:
- Sideload Windows Store Apps
- Deploying enterprise apps
- Planning to deploy Windows 8 apps in Configuration Manager
- Deploying Metro style apps to businesses
- Manage client access to the Windows Store
- Sideload apps with DISM
The documentation makes a distinction between loading apps from the Windows Store and loading LOB (Line of Business) apps. These also seem to be distinguished by the terms side-loading versus provisioning. LOB apps are those that you or a partnering organization has coded in-house but doesn’t want listed in the Windows Store for just anybody to buy. Microsoft’s pages detail the PowerShell code to install the apps but it skips over the simple fact: how do you get the app install file (.appx) in order to use the script? In the case of working with a developer, it makes sense that they can provide you with the signed .appx file.
Very few other developers, such as those making free apps through the Windows Store, provide those .appx files from a website. As a developer, the Windows Store is supposed to provide them some benefit, such as advertising their app and providing the bandwidth to get it out there. Meanwhile, a consumer might appreciate the Windows Store because it puts all of these free and paid apps in one place, instead of being scattered around the Web. Also, it’s an assumption but their presence in the Store implies Microsoft is vouching for them as legitimate applications.
Getting the appx file
Using Fiddler, a web traffic debugging proxy, you can download the app from the Windows Store and capture the URL of where the .appx file is available. Then, you can copy the URL and download it using your standard browser. The download comes as a .zip file but you just rename the .zip to .appx.
Install Fiddler on a Windows 8.x computer and follow the configure Fiddler for Windows 8 guide. Open the Store and get to the app you wish to acquire. Clear all records in Fiddler so you have less traffic to dig through by clicking the X (delete) button on the toolbar. Then switch back to the store and choose to install the app. Now, you switch back to Fiddler and watch the web traffic come in. You will likely see a few URLs to .appx or .appxbundle files.
Right-click on the .appx URLs (this may take some trial and error to find the right one) and choose to copy the URL. Then paste the URL into Internet Explorer and if prompted to download a file choose to save it. The URL is only available for a short time, so you’ll need to follow up the Windows Store download quickly with downloading it through IE. If it didn’t work or gave you an access denied message, try another one of the .appx URLs.
Once you have the file downloaded, you will notice that it is saved to your computer as a .zip file. Just rename the file to anything you want with the extension .appx or .appxbundle to match what Fiddler showed. You can look around in the .zip file first if you would like to get an understanding of what all is in the file and to see information about the app.
Sometimes apps might have dependencies, so you will need to download those as well. They’ll be listed in Fiddler just like the actual app and you’ll want to grab those too and also rename them to match the .appx file extension.
When downloading the app, you might need to do the process repeatedly. You can right-click on the app on your Start Screen to uninstall it and then trigger the install process again in the Store to monitor the traffic with Fiddler again. You can also uninstall the app using PowerShell if this will help automate the process.
#Removes Skitch Touch Get-AppxPackage –Name Evernote.Skitch | Remove-AppxPackage
Installing the app
Once you have your .appx file for the app, you can now install it through PowerShell. This means you can also use it in a logon script to automate the process of providing the app to the computers/users that may need it.
Use Powershell to install the .appx file through a script. This is very easily done with Add-AppxPackage:
Add-AppxPackage -Path “C:PathToAppxapp1.appx”
UNC paths are also fair game:
Add-AppxPackage –Path “\ServerShareFolderAppsapp1.appx”
To take care of dependencies, you can either install them prior to the app install:
Add-AppxPackage -Path “C:\Path\To\Appx\winjs.appx”
Add-AppxPackage -Path “C:\Path\To\Appx\app1.appx”
Or you can include dependencies in a single line:
Add-AppxPackage C:\app1.appx –DependencyPath C:\winjs.appx
One of the free apps from Microsoft that I wished to include for the lab environment was the Windows Scan app. It is very simplistic and should be easy to use. It had a dependency for VCLibs.120.00. This was installed with the computer by default but was removed along with the other provisioned apps. Installing the Windows Scan app, I was able to spot it in Fiddler and download the VCLibs .appx file and install it ahead of the Windows Scan app. Alternatively, you could be more granular with removing the provisioned apps in this instance.
Application
In my testing, it has been very consistent to install these apps on demand at logon while also speeding up the logon process. I was able to save the .appx files to a server share and script the app install process. This script is then loaded at logon via Group Policy.
A Group Policy setting may need to be enabled for this to work in your environment: Allow deployment operations in special profiles
It is found under Computer ConfigurationAdministrative TemplatesWindows ComponentsApp Package Deployment
This policy setting allows you to manage the deployment of Windows Store apps when the user is signed in using a special profile. special profiles are the following user profiles, where changes are discarded after the user signs off:
Roaming user profiles to which the “Delete cached copies of roaming profiles” Group Policy setting applies
Mandatory user profiles and super-mandatory profiles, which are created by an administrator
Temporary user profiles, which are created when an error prevents the correct profile from loading
User profiles for the Guest account and members of the Guests group
If you enable this policy setting, Group Policy allows deployment operations (adding, registering, staging, updating, or removing an app package) of Windows Store apps when using a specialprofile.
If you disable or do not configure this policy setting, Group Policy blocks deployment operations of Windows Store apps when using a special profile.
Updates
I can’t say that I speak from experience, because I’m not sure if the apps have updated in the month since I implemented this, but my working theory is that you are on the hook to manually install updates if the user does not have access to the Store. You will have to recapture the appx file and update your script source to point to the updated version.
The downside with this is that you won’t get the latest features or security fixes. The upside is you’re basically working in a vacuum. The app worked well at the point of deployment, so it should continue to work well as long as it still has the dependencies it needs.
If the user has access to the Store, I believe the apps will keep themselves up to date. In this scenario, it implies that they don’t have a mandatory profile, so the app would only need to be installed once instead of each sign in. From there, the user (or the Store automatically in the background) should be able to update the app.