IWP72 | Deploying Windows Phone apps for the Enterprise
- Posted: Mar 05, 2014 at 1:48 PM
- 48,060 Views
- 3 Comments
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Right click “Save as…”
This week we talked about publishing applications for Windows Phone for the Enterprise. There are a few different possibilities to start distributing your applications to your users. In the video we talked about three different possibilities:
Through the store
As a beta
When distributing application through the store the process is exactly the same as apps for consumers. You build your app and submit it so Microsoft can certify the application. If you access corporate data you need to make sure Microsoft has access to a test account which they need to validate the application. Testing is the same as any other application and you need to fulfill all store policies.
You can choose to publish the application hidden so it can only be installed when users have the deep link to the app. Best practice is to secure your corporate data with an login because when other people get access to the deeplink they can all install the application.
The 2nd way is to distribute the application as a beta app in the store. You need to provide all live id of your users and send them the link to the store. The advantage of beta is they don't expire anymore. If you want to remove access to the application for your users you need to build in a mechanism yourself. You can't force the apps to be removed from the phone once the users have the app installed. The check if the user is allowed to the beta is only performed during install
The last option is to side load applications. This can be done through an MDM solution like intune or you can sideload apps through email or website. Let's get into a little bit more detail how you can privately distribute your applications.
First step is you need to create a developer account at http://dev.windowsphone.com/. You need to make sure you create a company account and not an individual developer account. Part of this process is Microsoft asks for some proof if you are really the company you tell us you are.
Once you have created this developer account you can buy an Enterprise Mobile Signing Certificate from Symantec. Currently we only support Symantec certificates to sign your corporate Windows Phone applications.
When you request the certificate from Symantec you have to copy the Symantec Id from the screen above.
Once you have paid Symantec they also do some validations and they will create the certificate for you. Make sure you request and download the certificate from the same machine. The certificate is valid for 1 year.
Once you have the certificate you can use this to create a so called Application Enrollment token (or AET). This token needs to be distributed to the phones before they can run applications signed with the Symantec certificate.
When you have installed the Windows Phone SDK there are also a few tools installed which helps you sign your applications and create the AET. The following command creates the Application Enrollment Token:
"c:\program files (X86)\Microsoft SDKs\Windows Phone\v8.0\Tools\AETGenerator\AETGenerator.exe" "c:\temp\cert.pfx password"
When you run this tool the AET.xml, AET.aet and the AET.aetx files are generated. The .aetx file needs to be distributed to the phones. This file is an XML file which contains the publisher ID which is signed by the certificate and is used every time the phone tries to start a side loaded app.
You can sent the AETX file through email or a (secure) website to your users or use an MDM environment to automatically distribute this file once they enroll in your corporate environment. InTune for example generates this file automatically for you when you upload the certificate to the management environment.
The Application Enrollment token is valid for a year. After a year you need to renew the token on every device.
Every time you start a side loaded application on your phone the Execution Manager extracts the publisher id from the signed application. This is used to find the associated AET. The AET must be present and valid (not expired, revoked or disabled). If the AET is still valid the application is launched. So when you replace the AET with a new one it still contains the same publisher id and the applications will still launch.
When you install an application this check is performed as well, the extra check which is performed at install time is if application is signed with a valid certificate. This means when you renew your certificate you need to resign your apps, otherwise people are not able to install the apps. Applications installed on your phone will still work as long as the AET is valid.
Every 24 hours the phone tries to connect with the Microsoft Servers to validate its Enterprise Application Token. The phone sends the device ID, publisher ID's and enterprise app ID's to the server. The servers check if the publisher ID is revoked or not. If the ID is revoked applications of that enterprise are blocked from being installed or launched.
This is checked every 24 hours or every time a phone is enrolled or an application is installed.
If the phone cannot phone home after 7 consecutive attempts the install of enterprise apps is blocked, but installed applications can still be launched. This covers the scenario where users are working offline or without internet connectivity for an extended period of time. If the phone cannot phone home for over 30 days the applications are blocked from launching.
The following figure shows the data which is send to the Microsoft servers.
And this is the response Microsoft returns:
Before you can distribute your apps you need to sign them with the certificate bought from Symantec. The following command line can be used to sign the apps (the tools are installed with the Windows Phone SDK)
XapSigntool.exe sign /SignTool "c:\Program Files (x86)\Windows Kits\8.0\binX86" /f "c:\temo\certificate.pfx" /p password "c:\temp\application.xap"
Some MDM providers can sign the application for you, so you only need to upload the XAP file to their system and they will take care of it.
So let's summarize the differences between public and private distribution.
You need to purchase an MDM solution. But you will have automatic Application Enterprise token distribution and renewals. You will have full MDM management capabilities like the different policies available. You can un-enroll devices. You can only enroll to one MDM system at a time. You can automatically update apps and you will get a built-in private app inventory.
You need to distribute your apps through an Intranet server or email. You have to manually distribute the AET. You can only un-enroll a phone by a full phone reset. You can enroll to multiple companies simultaneously, applications need to be updated manually and there is no automatic private app inventory.
There are a few different ways to distribute your enterprise applications to your employees. The managed approach through an MDM environment gives you the most flexibility. Also distributing your applications through the store is still a possibility as long if you provide Microsoft some test credentials. Building applications is the same as regular consumer apps so start building your enterprise applications for Windows Phone.