Understanding Windows Phone 8 MDM

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:
http://download.microsoft.com/download%2F5%2FC%2F4%2F5C460CE2-3B0F-45CE-805D-1A3D5697639C%2FWP8_Enterprise_Device_Management_Protocol.pdf

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
– Enrollment
– Management

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.

Server discovery
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 andreas@contoso.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.

Enrollment
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.)

Implementation note:
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.)

Management
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 Smile

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.

115 thoughts on “Understanding Windows Phone 8 MDM”

  1. I have not looked closer into managing the company hub app with MDM. Partially because there are things about it in the current version of Windows Phone I find slightly convoluted.

    The enterprise apps themselves should be managed through the company hub app, and not MDM.

    I suggest reading the docs – while it’s not always easy to decipher all CSPs are documented with sample SyncML.

  2. Hi,
    I am trying to put up wp8.1 mdm server. this guide was helpful for initial understanding of enrollment process but am still not sure of how the device will poll to server i mean on which url will it poll to server for getting new policies / mdm commands.
    and m still bit confuse about the ca server setup and putting up webservice url on which wp8 is going to hit during enrollment
    can anyone help me on this?

  3. Could you be a little bit more specific on the confusion? Do you have a CA setup that isn’t working, or is it a matter of configuring said CA?
    Out of the box the the WP devices cannot request a certificate from the CA, but I’ve got code that shows how you can proxy the request through your MDM server:
    http://mobilitydojo.net/2013/04/30/programmatically-enrolling-for-certificates-from-certsrv/

    This is used during enrollment (and annual renewal of certificate).

    For the ongoing management of the devices you need to provide the device with an MDM server URL during enrollment. This can be any URL you choose. The device will then do an HTTP POST at the interval you specified (also in the enrollment phase).

  4. Hello,

    I am setting up MDM server for windows phone 8.1,
    At first GET request is successful, but next POST request is not sending to my server.what would be the issue?

  5. Hi Andreas,
    I would like to complete discovery phase for windows phone in mdm but i don’t know the discovery.svc methods can you please help me to complete discovery phase.I am struck here from last one month onwards

  6. Building a WCF service for the discovery phase is probably the easiest. If you can describe what kind of error you’re seeing that might help pointing you in the right direction.

  7. Hi Andreas,

    Thanks for this very precious pieces of informations. However, I m quite lost between several Microsoft’s explanations and yours. I’m trying to push settings (like APN name, wifi config …) via OMA CP on a Win Phone 8.1. By using this protocol, do we still need to do these 3 phazes (Discovery, Enrollment and Management) ?

    As I think OMA CP need to do a bit of OMA DM exchange before working, I think yes but I hope you got the answer.

  8. In the old days of Windows Mobile 5/6.x one could deploy OMA CP fairly easily as long as it was signed properly, but those days are gone. To be able to do config these days one needs to cover the OMA DM protocols more broadly.
    Working backwards from what we want to achieve:
    – The management phase needs the device to be bootstrapped and set up to trust the server issuing the commands.
    – The bootstrapping is done in the enrollment phase.
    – To start the enrollment phase the client needs to know where to find the server for doing this, and this is covered by the discovery phase.

    So, in short, yes you need all three phases. The management phase also needs to implement an OMA DM flow, where OMA CP will be a part of some actions, but not all.

  9. Hi Andreas,
    according to windows phone 8 mdm document we are giving the request as
    http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
    I have windows server 2012 in that server i have created one domain vwatch in that i have created host as enterpriseenrollment.I have created application name enrollmentServer in IIS . In discovery service i have created one method Get-request it returns the : http://EnterpriseEnrollment.vwatch.com/EnrollmentServer/Discovery.svc . While hiting that method i am geting error handshake error due to unexpected packet format by using the fiddler

  10. @Andreas

    Thanks a lot for your time. I’m more here in a telephony operator point of view so the WP8.1 devices I’m trying to push settings can not have their professional section configured. I have to find a way to automatically set the requirements to use OMA-CP mechanisms. I will try to push a certificate along with the prov.xml file containing TPS and PPG informations, reboot phone and try to send a simple setting.

    I’ll post my success here (at least I hope so) =) thx again !

  11. @Alex

    I work for a mobile operator so I’m familiar with the concern 🙂
    There are some extra APIs and access levels for operators. I don’t remember all the details though, like if you could do a full bootstrap or if it was limited to things like APN settings.

  12. *Desperate help* in implementing simple Windows Mdm server for Windows 10. Haven’t done WCF in so long. Been reading and working with WCF, but frustrated as I’m constantly pulled on other issues. Enrollment would be a great start. Any sample C# solution/project to get me going would be greatly appreciated.

    Not sure what I”m doing wrong:

    <endpoint address="" name="IDiscoveryService" contract="WindowsEnrollmentServer.IDiscoveryService" binding="webHttpBinding" behaviorConfiguration="web" bindingConfiguration="transport"

    Interface:
    [OperationContract]
    [WebInvoke(Method = "GET" UriTemplate = "")]
    string Discover();

    [OperationContract]
    [WebInvoke(Method = "POST" UriTemplate = "")]
    string DiscoveryParameters();

Leave a Reply

Your email address will not be published. Required fields are marked *

*