Repackaging Windows Store Applications
On a recent project I worked within, Windows 8.1 workstations required the ability to install a freeware Store application although the network restrictions limited access to the internet.
SCCM does provide the option of deploying Windows Store applications. The process involves manually installing a Modern UI Application on a workstation and then browsing to that workstation to obtain a list of installed AppX applications. When SCCM Deploys a Store application, it’s effectively passing a URL to a workstation or user that invokes a fresh install from Store itself. This is a huge problem if the end users won’t have physical connectivity to the Store!
Thankfully it’s relatively easy to recapture Windows Store Application to deploy the software as an AppX file.
Windows Store / Physical Files
A huge advantage over traditional Windows Installer Packages is that Windows Store applications deploy all their files into single subdirectory.
This example will demonstrate re-packing an extremely useful utility from a talented developer, Guillermo Rueda called My Explorer. I’ve spoken with Guillermo and am extremely grateful that he has provided his work freely to the world at large. His intention is to open source the project and I would encourage anyone who uses the My Explorer application to show their appreciation to him by rating it in the Windows Store.
Unfortunately, Microsoft does not provide a method for downloading the self-contained AppX installers which may be used in offline networks.
When Windows store applications are installed to a machine, they create a unique directory under:
After an application is installed, we can browse to the WindowsApps folder to retrieve the application files. This will require changing the owner on the WindowsApps folder (in the Advanced Security Settings) to be able to see what’s been written
Inside the folder, the applications can be seen in their folder structure.
AppX Package Structure
After an AppX / Metro / Modern UI applications is installed, some files are left over as remnants from the original installer. This includes the microsoft.system.package.metadata folder, the AppxSignature.p7x file and the original AppxBlockMap.xml (which outlines what the files actually are). These can be removed or archived from the copied directory.
A cleansed directory will look similar to the image below.
Once the unneeded files are removed, a file mapping text file can be recreated as part of the new AppX creation process. The mapping file is an INI file that references the absolute path to files you have copied against the relative destination of those files. As the source file location is pretty much identical to the desired destination, the file is easy to create by using a bare DIR command in dos (eg. dir *.* /s /b>tempfile.txt etc). The finished File Mapping will look similar to the text file below.
The File Mapping text file is read by the MakeAppx.exe utility that is part of the Windows 8.1 SDK (http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767(v=vs.85).aspx)
All AppX format applications must be signed and before the package can be created a valid AppX format signature will need to be created.
AppX Signing Certificate
The Deployment Guys have created an in depth, step-by-step guide for creating an internal AppX compliant certificate template that can be used in an internal Domain.
After creating the Certificate Template and generating a personal signing certificate, the important property will be the Subject field.
With this example, the certificate I’m using utilises CN=LaurieRhodes. When you create the certificate you will be prompted to create a password for use with that certificate. The subject field of the signing certificate must be written in the AppxManifest.xml file of the application. The Publisher attribute must match what is embedded within the signing certificate.
Take note that the Manifest may list other dependency applications which will also require repacking for the application to work. This particular example requires the dependency package “Microsoft.WinJS.1.0”
On the machine with the Windows SDK installed, I was able to recreate a new package with the command syntax below:
Re-Packing the AppX installer
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makeappx.exe" pack /h SHA256 /m "My Explorer\AppxManifest.xml" /f AppXFileMapping.txt /p MyNewAppPackage.appx
To Sign an AppX File
One the AppX file has been created, it must be signed with the created personal certificate. The syntax will be similar to:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /fd sha256 /f "AppXSigningCert.pfx" /p MyPassword " MyNewAppPackage.appx "
Installing the Package
As this example required two packages to be recreated and re-signed from the Windows store, the Powershell syntax for installing the new application
PS C:\> Add-AppxPackage c:\temp\MyExplorer.appx –DependencyPath c:\temp\Microsoft.WinJS.1.0.appx
As long as the Group Policy setting “Allow All Trusted Apps to Install” is enabled for the target workstation, the result is a fully functioning application that can be deployed without access to the Store.
Again, thanks to Guillermo Rueda for his work with application in the first place!