I have previously mentioned Mobile Device Management (MDM) for Windows Phone 8 without really going into much detail other than acknowledging its existence. While I can’t go into every detail there is to know in this post either I thought I’d look into the API to try to provide a general understanding of how it works.
Microsoft has written some documentation on the low-level details in a pdf document:
This document is intended for developers trying to implement the MDM API, so it may or may not be exactly what you are looking for if you’re just trying to understand the high-level stuff. (The doc leaves out a few details so developers might not be able to cross the finish line based on this doc alone either.) You might want to skim the QA part of it though.
MDM is nothing new to the Windows Phone platform, or more correctly "Windows Mobile", as MDM sort of skipped a generation in the Microsoft world. MDM was a major part of the operating system in Windows Mobile 5 and onwards (obviously with plenty of changes between versions 5.0 and 6.5). In Windows Phone 7.x not so much… But we’re turning over a new leaf with version 8 and MDM has been reintroduced.
In the "old days" MDM was implemented based on a standard called OMA DM. If you’ve been around for a while you’ll recognize this as the attempt to standardize MDM across mobile operating systems. Nokia invested heavily in it for Symbian, but Apple didn’t exactly get onboard when iOS arrived and it sort of faded out of the picture. I’m not saying Apple is the reason for this – there were certainly issues with the standard itself as well contributing to the decline. But this is merely anecdotal stuff – it doesn’t matter in the bigger picture. The point I’m trying to make is that if you are familiar with OMA DM you understand the basics of how Windows Phone 8 does MDM since this has been carried forward.
Since we’re veering off course already – why are Microsoft using this "dead" standard for their new OS? Well, I’m not calling any shots inside Microsoft so I can’t give the specifics of their choices. If I were to guess it’s to reuse components they already had, and not re-invent the wheel. I’m guessing major parts of it has been copy-pasted on the client side from Windows Mobile 6.5, and on the server-side they could reuse some of the code from the System Center family. (Both SC Mobile Device Manager 2008 and SC Configuration Manager 2007.)
In my opinion there’s three distinct phases/parts involved in managing Windows Phone 8 devices:
– Server discovery
Only the management part involves OMA DM. The first two parts are a one-time process and doesn’t involve MDM as such; it’s just about setting the stage for the final part.
I’ll describe these further, but first, let me go into some other distinguishing features of the MDM agent in Windows Phone 8.
While MDM clearly must be built into the operating system of the device you’re using there’s different approaches that can be taken when implementing MDM. If you take iOS as an example; Apple has defined the MDM API in terms of what you can and cannot do to the OS. (Enabling power-on-password, wiping, etc.) They have also defined that these settings should be loaded into the device in the form of a "plist" which is a type of XML document. But how to load this plist? Through a web page? Through a dedicated app? How should a generic app (it needs to be generic to be in the App Store) provision itself? There’s a range of options, and how it’s implemented is mostly in the hands of the MDM vendor. So, while MDM vendors supporting iOS are mostly able to do the same things
Microsoft decided to go for a different approach. There is no third-party agent to install. There is only the native agent in the OS, and the server will need to adapt to this accordingly. The user will have to manually start the enrollment process and follow the wizard. Whether MDM vendor A or MDM vendor B provides the server the client experience will be the same. There is the possibility to differentiate one MDM solution from another by providing a "Company Hub", which ties closely into MDM, but this is considered a separate (and optional) part. How you enroll the device to the MDM platform is defined by Microsoft, and will be the same experience across MDM platforms.
Before the device can be managed it needs to locate the server that will manage it. Following the trend from products like Exchange Server and Lync this is done through an autodiscover process. The device instructs the user to input his email address and corresponding password, and the email address is used to form the URL for the server. The dns prefix is enterpriseenrollment so for email@example.com as the email address the FQDN would be https://enterpriseenrollment.contoso.com/enrollmentserver/Discovery.svc.
The device will first issue an HTTP GET to this address, and if it receives a response it will proceed to do an HTTP POST to the same address requesting the addresses of the policy and enrollment servers. (Implementation note: the response to the GET does not have to contain anything. A simple HTTP 200 will be sufficient.)
If this DNS record does not exist the device will prompt the user to supply the server address manually.
The response will contain one or two URLs pointing to the servers that will be used in the next phase.
The enrollment phase is split into two parts. Since the enrollment itself requires enrolling for a client certificate it is possible to send the device a policy for generating the certificate request. This is purely optional in the current implementation, and the amount of policies supported by current devices is minimal so it feels superfluous at the moment. You can change the key size to a lower amount than the default size of 2048 bits which doesn’t make sense to me. (You cannot change it to a larger value like 4096 as far as I know.)
If you are future-proofing your MDM solution you might as well code up a policy response which just serve up the default settings.
The next step is that the device will create a private key, and send along a certificate request to your server. The certificate request is in a standard base64-formatted string which the MDM will send on to a CA of the vendor’s choosing. The MDM server will send the certificate back to the device as a base64 string for the device to complete. The certificate will be in an OMA CP XML document wrapped into a SOAP response, and this XML will also contain the address for the OMA DM part of the MDM server as well as some other settings relating to the MDM relationship. In OMA DM terms this is the bootstrap message. (The technical details like OMA CP, SOAP, etc. are of course largely irrelevant to understand the process as such, I’m just including it for the sake of not "glossing over" the finer points. If these acronyms means nothing to you it doesn’t matter.)
There is nothing in the protocol that dictates that you use a Microsoft CA. You can opt for OpenSSL or another third-party option if you like. If you do decide to use a Microsoft CA there is a small detail that might send you off down the wrong path. The API doc mentions using the MS-WSTEP ( for policy request) and MS-XCEP (for certificate request) protocols. The device will send SOAP messages adhering to these protocols, and the MDM server will need to adhere accordingly. If you are not familiar with these protocols, (I sure wasn’t before looking them up), they are implemented server side by Microsoft already in the form of "Certificate Enrollment Policy Web Service" and "Certificate Enrollment Web Service" which are part of the CA role. However the device adds some custom properties which means the CA will respond with "Bad request" if you try and direct the messages that way. So, you’re thinking, "I’ll just pass it to the MDM server and do a kind of proxy thing to strip away the custom stuff and still use the services on the back-end". Makes sense; I agree. However when you try to request a certificate in this manner the CA will assume that the certificate template to use is included in the request, but the device does not conform to this requirement. (Since this is one of those properties in the policy response it doesn’t implement.) Which means that passing along the certificate request from the device will end up being rejected by the CA since there is no template included. And you need to install the Enterprise CA to be able to use the web services, so it’s not an option to skip templates either…
You could also be tempted to try to use NDES (especially if you’re already supporting iOS devices) since MS-XCEP and SCEP serve the same purpose. Let’s avoid the details; you can skip this option as well. It will not work. (At least not out of the box without extensive workarounds.)
If the device accepts the final XML sent from the server it will let the user know, and then sit back and wait for the policies to appear. Here’s another catch for you. MDM in WP8 does not support server push, it will only work with a client side polling mechanism. Meaning that you cannot force the device to connect, it will connect as defined per the schedule defined in the bootstrap message. So after enrolling you either need to connect manually to receive policies immediately or wait.
Oh, and by the way; the no-push restriction also applies to remote wipes, so they might not be as instantaneous as you’d prefer either.
After the enrollment phase the device will go into the on-going management phase. At this point it turns to communicating with the MDM server via OMA DM, and the user need not worry with interacting with the MDM server – it’ll hopefully just play along nicely in the background.
That’s all there is to it really. From the IT Pro perspective it’s fairly simple since there’s so few options for failure. (I’m sure there will be minor snags from time to time if you’re trying to enroll a bunch of users all over the world, but that’s life.) For the end-user it should be fairly easy to work out too. For the MDM developer – well, that’s not part of this post anyways
I’d still like to see a more feature complete MDM API, with server push, more settings, and more features. Maybe there will be more in the next update to Windows Phone.