This post is part two in a five-part series on MAM deployment models. For previous posts in the series, see: Introduction.
Last week, we kicked off a new series with an introduction to MAM deployment models. And when we say “introduction,” we mean it: we want to go back to the basics to talk at the 101-level about how different MAM deployments work.
Few platforms are as misunderstood as Windows Mobile—which is what we’re starting with today.
The complexity of Windows Mobile deployments lies in the fact that Microsoft has attempted mobility a number of times. Each time, they’ve changed the way they run it.
This creates a scenario where a Windows 8 phone is different than a Windows 8.1 phone, which is different than a soon-to-be-deployed Windows 10 phone. This brings additional complexity for vendors when deploying on the platform.
There are a few challenges related to Windows Mobile deployments:
Binary bundles: You can build apps that go across Windows 8.1 Desktop and Mobile—but you need to bundle them with an ARM binary, as well as x86 and x64 binaries. It’s great to have a bundle, but keep in mind: users are downloading a file and only using a third of it for their specific platform. What’s more, when you’re packaging an app, telling which version is which is challenging. Handling multiple chip architectures at once is complicated for developers, and uses up excess bandwidth for users.
The Application Enrollment Token (AET): All Windows Mobile apps (until Windows 10) have something called an Application Enrollment token, or AET. When you’re building an app, you first need to start with purchasing a certificate to distribute the app. Then, after your app is built, you need an AET. This tells phones which developers and apps are trusted. This is a measure to help mitigate security concerns.
Unfortunately, this can present a challenge for enterprises and employees not familiar with PKI technology. It’s an additional step for downloading apps, and each time, employees must download the AET to be able to use the app. It’s not an obvious step and can easily confuse employees through what should be a relatively simple process.
Luckily, relief is on the horizon with Windows 10 Mobile… sort of. Windows 10 will soon introduce a business app store which will allow you to easily deploy apps to enterprise users and take advantage of Microsoft’s deep understanding of the back office.
Through Windows 10, you won’t need to do the AET dance mentioned above. You’ll be able to easily distribute apps in a single package, and the phone will know how to install and manage your apps. The catch is that to use this functionality, you’ll need to have an Active Directory Account in Office 365. This isn’t a cross-platform solution, and you won’t be able to get it out to people who aren’t on Office 365 or in your domain.
If you’re a complete Windows shop, it will be worth looking at the private app capability within the Windows 10 mobile app store. Otherwise, it likely won’t solve all of your issues.
No matter what your back office looks like, one thing is for sure: MAM deployments on Windows Mobile are far from impossible. They may be more complicated than Android or iOS deployments, but we’re here to help you navigate the challenges associated with Windows Mobile.
Have a question about this post or any other posts in the series? Reach out to us in the comments or on Twitter @App47!
