The list of things that need to be in place in order to sideload modern apps on Window 8 can be a little disconcerting, and it changes a little depending upon which edition of Windows 8 you’re deploying to. There is however really good documentation in the TechNet library that can help. Of course there is some fine detail that the documentation doesn’t really cover. It tells you where the group policy setting to enable sideloding is in the local group policy and if you were a little new to group policy or you hadn’t done it in a while you might get stuck.

First the requirements for side loading again

• You have the appx package file for the app you want to Sideload.
• The appx package file is signed, either by a code signing certificate that chains to a trusted root CA or your enterprise CA.
• Sideloading is enabled on the deployment target.
• Sideloading keys have been provisioned on the deployment target (if required).
• Your Enterprise Software Deployment software knows about Windows 8 apps or can execute PowerShell or DISM commands on the deployment target.

Providing all these requirements are met you’ll be in a good place for your deployment. Let’s take a look at what it takes to meet each requirement in turn.

You have the appx package file for the app you want to Sideload.

This really is the first step, if you don’t have the appx package you are either actually wanting to deploy an MSI based installation or, if it’s a Windows 8 app, you want to deploy something from the Windows Store. This latter process is deeplinking.

The appx package will have come from the developers of your app, that will either be an ISV, a Design or UX agency, a digital creative agency or your in house LoB app developers. All of whom should be able to provide you with an appx package. They may also give you a PowerShell script, a certificate (.cer) file and possibly a dependencies folder. You should ditch that PowerShell script immediately for your enterprise deployment, it’s only good for developer testing.

If you’re wondering why it’s only good for developer testing…the PowerShell script that visual studio creates for you will require that you “developer unlock” your device a process which breaks the security model somewhat for modern apps. Once developer unlocked a device can have any app sideloaded onto it, not just your chosen apps and what’s more they only need to be signed with a self-signed cert. One of the best things about the modern app model is that it is more secure because of trustable code.

The certificate is useless to you too, it’s a self signed cert and therefore won’t be trusted by your target devices. If you REALLY want to you can deploy the cert with group policy, but it’s poor practice and asking for trouble as there is no CRL for the cert and no way to remove it.

In summary you need only the appx file and dependencies.

The appx package file is signed, either by a code signing certificate that chains to a trusted root CA or your enterprise CA.

This is relatively simple and providing you’re not messing around deploying self-signed certs keeps things secure. The best thing to do is to issue you LoB app team or (under contract) your developers a code signing certificate issued by your enterprise CA. They will then use this to sign your app.

You might not want to do that so you can access the WDK and use the tools in there to sign the app they’ve given you.

This assumes that your devices are members of the AD DS domain and therefore can chain the certificate back to said enterprise root CA.

Alternatively they can sign the app with a code signing certificate issued by a Trusted Root CA such as Symantec.

Sideloading is enabled on the deployment target

This step is best achieved using Group Policy through AD DS, it can also be enabled using local group policy…if you want a management headache. (!) Again this is simple.

If you have a Windows Server 2012 AD DS running at the Windows Server 2012 functional level. Launch the group policy snap in. Create a new GPO and link it where appropriate. Turn the following setting on:

Computer Configuration\Administrative templates\Windows Components\App Package Deployment\ Allow Trusted Apps to Install.

Obviously you could also do this with the corresponding registry setting, which you’ll find in the template reference for Windows 8 and Windows Server 2012.

If you are running Windows Serve 2008 or later. First download the Windows 8 and Windows Server 2012 ADMX files. Then install them on a target device. I then highly recommend implementing and updating the central template store. Copy the templates to

 \\Test.Microsoft.Com\SYSVOL\Test.Microsoft.Com\Policies

replacing the obvious parts with your own domain, obviously be a little bit careful about what you over-write.

If you’re on Windows Server 2003. First start planning your migration, Group Policy central store, AD Recycle Bin and more await you. Second you’ll need to download the Windows 8 and Windows Server 2012 ADMX files then copy the files to

%systemroot%\PolicyDefinitions\

You will need to make sure you do that every time you want to do this on any admin devices.

If using group policy is impossible then perhaps you can bake your own method to update the following registry key:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1

Sideloading keys have been provisioned on the deployment target (if required).

If you are using Windows 8 Enterprise you can skip this step, if you are planning to deploy Windows 8 Pro or Windows RT, read on.

Windows 8 Pro. Ask yourself (or your SAM specialist, or boss) if you have an EA with SA. If you do why the heck are you deploying Windows 8 Pro? Check but you should be licensed for Windows 8 Enteprise – it’s far more enterprise feature rich and a few minutes now will save you hours in the future. Deploy Enterprise.

If you don’t have an EA with SA you will need to buy some Sideloading Keys from the volume licensing portal. If you do have an EA with SA then you won’t pay, but then ask yourself again why you aren’t deploying Enterprise.

Windows RT. You need to get a Sideloading key from the Volume License portal. If the devices are covered by your EA with SA then they won’t cost you a penny. If not they will.

If you end up using Windows 8 Pro or RT. You will need to enable the sideloading key, you can do that individually with the command:

Slmgr /ipk <sideloading product key>

Or you can script the installation of the key quite simply with your ESD software. If you’re using Windows RT and Windows Intune (either stand alone Window Intune or linked to Configuration Manager) then once you’ve added your Sideloading keys they will be automatically issued. Scripting is still required for Windows 8 Pro with Windows Intune.

Your Enterprise Software Deployment software knows about Windows 8 apps or can execute PowerShell or DISM commands on the deployment target.

I can’t stress how important asset intelligence is. Did the app install correctly, what version is installed, when was it installed, how and by whom. Use either Windows Intune or Configuration Manager 2012 SP1 to do your deployment if you want to manage lifecycle management. If you just want installs at build time consider MDT 2012. If you must use non-Microsoft ESD software try to get the version that supports Windows 8 apps.

If none of the above is possible, then use script based installs (and hear sharp intakes of breath constantly). Be aware you are reinventing the wheel, be aware that there is higher TCO this way.

How to script the install per user:
The following PowerShell will need to be run for each user that you want to give the application to, it also needs to be run by the user or as the user so take care if your ESD agent runs as a different user.

add-appxpackage -path C:\app1.appx –DependencyPath C:\winjs.appx

This will allow you to add the app for each existing user on a device, but you might also want to do the following so that any new users on a device also get the application.

How to provision an app for all users to be installed at first logon

There are two ways to do this, both equate to the same thing, first in PowerShell. Obviously replace the variables with the values you need.

Add-AppxProvisionedPackage-Online-PackagePath $PackagePath-DependencyPackagePath $DependencyPackagePath-LicensePath $LicensePath 

Secondly with the DISM command:

DISM /Online /Add-ProvisionedAppxPackage /PackagePath:C:\App1.appx /SkipLicense

You can also run these commands with offline images like WIM or VHD files so the represent good ways to inject a package into an image – the process is known as offline servicing.