Common issues when implementing Windows Phone 8 Enterprise Mobile Device Management.

This blog describes a number of common issues encountered when implementing Windows Phone 8 Enterprise Mobile Device Management protocol along with troubleshooting tips which ISVs can use.  TIP: check the download link regularly to see if the documentation has been updated and some of the information below may have already been added to the documentation by the time you read this blog.

This blog assumes you have read the Windows Phone 8 Enterprise Mobile Device Management protocol document and are familiar with Open Mobile Alliance: SyncML protocol.


One major problem ISVs encounter during implementation of an Enterprise MDM service is the lack of debugging capability of the DM client on Windows Phone.  At the time of writing this blog the Windows Phone device is effectively a black box... there is no way for an ISV to get logging information out of a retail phone.  The alternative is to use network logging tools like Fiddler to examine the traffic to and from the device. 

  Most of the network traffic we are interested in debugging will be over an SSL encrypted connection.  In order to view these communications you need to use a tool which supports SSL packet inspection.  Fiddler does this by acting as a proxy and using a man-in-the-middle technique in which the proxy supplies it's own SSL certificate to the client, however this certificate is not trusted by the phone so you must manually install the certificate on the phone.  (see the Fiddler documentation for instructions on configuring HTTPS traffic recording. )

  A second option is to use a more traditional network capture utility, like NetMon or WireShark, which can decrypt traffic using the servers certificate... One caveat is that decryption requires access to the private key for the server SSL certificate which may be a problem if your server is using a commercial root authority. ( See your preferred network capture tools' documentation for instructions on decrypting SSL packets. ) 

Discovery and GetPolicies

  The Discovery and GetPolicies steps are fairly simple, and well documented, so most problems can be diagnosed by comparing the contents of your network capture against the samples in the documentation. 
  However, I will point out a few things that people commonly overlook:

  • You need a domain name server (DNS) which can resolve the appropriate host name.  This means that you cannot use an IP address in place of the host name.
  • All services must support secure connection (HTTPS) and the Subject Name, or Subject Alternative Name, of the Server SSL certificate must match the host name of the server.  (...wildcard certificates are not allowed.)
  • In the GetPoliciesResponse, the only policies which Windows Phone 8 supports are minimalKeyLength, hashAlgorithmOIDReference, and the associated <oID> node... other values in the response payload are ignored.
  • TIP: It's a good idea to write some test code to double check your XML payloads.  One of the most confusing issues I have had to diagnose was the result of an extra space in a namespace definition in one of the XML payloads.  (This applies to all enrollment steps.)


  The majority of problems you are likely to run into revolve around the RequestSecurityToken and RequestSecurityTokenResponse.

  Generating the Client Certificate:

    There are several things you should be aware of in regards to the PKCS#10 request for a client certificate and the resulting client certificate.

  • The client certificate you send in response to this request must have the same public key value as specified in the PKCS#10 request.
    If you return a client certificate with a different public key the enrollment will report success but the client certificate will not be able to use the pre-generated private key. 
    • This will prevent Company Hub download from working over HTTPS.
    • This will also prevent SyncML from connecting if the server requires client certificate
    • And will prevent the device from being able to renew the certificate when it expires. 
      • Note: once the certificate expires the user will be unable to launch any company signed apps associated with this enrollment. The only way to recover from this state is to un-enroll the device and then go through the enrollment process all over again.

        The following items only affect Company Hub download over HTTPS... these do not affect any other aspect of device management.

  • Windows Phone 8 uses a hard-coded value for Subject in this request, B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1, and assumes that the server will replace this value in the supplied client certificate. 
    If the server returns a client certificate containing the same Subject value this can prevent the Company Hub download from working so the server should ALWAYS override the Subject.
  • The client certificate's Subject property should be encoded using ASN.1 string type: "PRINTABLE_STRING".
    Versions of Windows Phone 8 available at the time of writing this blog are unable to retrieve a client certificate unless the Subject property is encoded using ASN.1 string type: "PRINTABLE_STRING".  (note: PRINTABLE_STRING is a subset of UTF8STRING.)
  • The client Certificate's Subject property should not contain any null (0) bytes.  Since the CertificateSearchCriteria is stored as a string any null characters will be treated as string terminators causing the string to be truncated which prevents the company hub download service from finding the certificate.

Contents of the wap-provisioningdoc

  Next I'll discuss some issues related to the contents of the wap-provisioningdoc supplied in the RequestSecurityTokenResponse.


  • The value of SSLCLIENTCERTSEARCHCRITERIA must begin with "Subject=" as plain text followed by the URL encoded contents of the Subject property and should end with "&amp;Stores=My%5CUser".


  • There seems to be a lot of confusion regarding the function of the APPAUTH entries due to the names associated with the AAUTHLEVEL parameter.

    These entries contain the initial credentials used to for authentication during the SyncML process.  You must provide entries for both CLIENT and APPSRV in order for Windows Phone to initiate a SyncML session with the server.

    • The APPAUTH entry with AAUTHLEVEL of "CLIENT" represents the credentials which the server will send to the client.  These credentials must use DIGEST authentication.

    • The APPAUTH entry with AAUTHLEVEL of "APPSRV" represents the credentials which the client will send to the server when initiating a SyncML session.


  • The OmaDmRetry registry keys control the behavior of the initial SyncML session and subsequent periodic polling schedule.  Note: These values only affect the scheduling if set during initial enrollment or during renewal so if you make a mistake you will need to un-enroll then re-enroll.

    • If the phone fails to connect to your SyncML server immediately after enrollment completes then check to make sure that the values for AuxRetryInterval and AuxNumRetries are greater than zero.  The default values are 15 and 10 respectively.

    • The periodic polling schedule, specified by Aux2RetryInterval and Aux2NumRetries, will not start until the initial SyncML session completes successfully.

      • If the phone is unable to connect to the SyncML server after exhausting all retries then the user will need to select the manual refresh from the Company Apps detail page in order to kick-start the periodic schedule.

      • The same problem can occur if the phones clock is moved forward beyond the time when the initial sync would have exhausted all retry attempts.  (i.e. Current Time + NumRetries * RetryInterval + AuxNumRetries * AuxRetryInterval)


  • The first level node under EnterpriseAppManagment is the "Enterprise ID".  The values for Enterprise ID and EnrollmentToken should be identical to the values in the *.aetx file created by the AETGenerator tool.  see How to generate an application enrollment token.

  • An enterprise signing certificate is required for creating the EnrollmentToken.  If you do not yet have an enterprise signing certificate then you should not include the EnterpriseAppManagment node in your wap-provisioningdoc.

  • CRLCheck: A certificate authority may include a certificate revocation list (CRL) Uri in the server certificate. In some cases, where the CRL publishing point is not reachable from the internet, you may need to set CRLCheck =0 to disable checking so that connection to the server can succeed.

  Company Hub Download troubleshooting:

  • If your company hub does not install, first check to see if there is any connection attempt at the server side. 
    Note: normal IIS server logs do not include failed connection attempts so you will need to use a tool like netmon on the server.

  • If you see download begin but abort prematurely:
    check to see if your server is responding with 206 (Partial Content)... if so make sure it also includes a Content-Range header.  If Content-Range header is missing then the download will fail.  
    Note: If you have trouble getting the server to send the Content-Range header then try disabling re-startable download for this file type.              

  • If using HTTPS scheme: 

    • If you see a connection attempt but download does not start then the problem is likely related to the server SSL certificate or some other server security setting.     

    • If you see no connection attempt at all then the problem is likely with the client certificate or CertificateSearchCriteria.
      Use certutil -asn <cert>.cer to dump the raw ASN encoding data for the certificate and check the following items:   

      • Make sure the client certificate's Subject property is using ASN.1 string type "PRINTABLE_STRING".     

        06 03                   ; OBJECT_ID (3 Bytes)
        |  55 04 03             ; Common Name (CN)
        13 06                   ; PRINTABLE_STRING (6 Bytes)
           54 65 73 74 43 4e    ;   TestCN

      • Make sure the CertificateSearchCriteria matches the Subject property of the certificate.  From the sample above the CertificateSearchCriteria should be: "CN=TestCN".

      • Make sure there are no null characters in the Subject property.   


Certificate Renewal

  • You must set the EntDMID of the DMClient CSP prior to certificate renewal.  The value of EntDMID is used in the certificate renewal request.  If this value is not set then the renewal request will not be sent.


  • Digest (MD5) authentication: When initiating a SyncML session the server must send a hash of the credentials agreed upon previously. (see APPAUTH above.)

    This calculation uses a random seed or "nonce" to increase security.  Usually, after the initial request and response packages, the client will send a challenge with a 'NextNonce' value.  The server must respond with a new hash value calculated using this nonce and must store this nonce value to use in future sessions with that device...until the client sends another challenge request with a new nonce.

  • Below is a code example of how this hash value is calculated: 

/// Calculates the OMA DM MD5 Digest hash for the given input parameters.
///<param name="Name">The ProviderID as specified in the APPLICATION provisioning during enrollment.</param>
///<param name="Password">The AAUTHSECRET from the APPAUTH configuration.</param>
///<param name="ServerNonce">The Base64 encoded AAUTHDATA from the APPAUTH configuration or the NextNonce value from the most recent challenge ('chal'). </param>
private string calculateHash(string Name, string Password, string ServerNonce)

string hash = "";

// first compute hash of <username>:<password>
string tmp = String.Format("{0}:{1}", Name, Password);

byte[] buffer = Encoding.UTF8.GetBytes(tmp);

MD5 md5Hash = MD5.Create();

byte[] output = md5Hash.ComputeHash(buffer);

// convert result to Base64 string, add a colon separator, and get a byte array of the string.
string tmp2 = String.Format("{0}:", Convert.ToBase64String(output));

byte[] tmp3 = Encoding.UTF8.GetBytes(tmp2);

// convert input: ServerNonce from Base64 to a byte array.
byte[] tmp4 = Convert.FromBase64String(ServerNonce);

// Combine the arrays into a single buffer.
byte[] buffer2 = newbyte[tmp3.Length + tmp4.Length];

tmp3.CopyTo(buffer2, 0);

tmp4.CopyTo(buffer2, tmp3.Length);

// Compute the hash of the resulting buffer.
output = md5Hash.ComputeHash(buffer2);

// Convert the byte array into a Base64 string for inclusion in XML payload.
hash = Convert.ToBase64String(output);

return hash;




  The items described above are the most frequently asked questions and reported problems which I have encountered. 
  But there are some minor issues people report less frequently which I did not have space to cover.  If there is enough interest, and I have enough content, I may follow up with a second blog.

 Comments are welcome,both below and on twitter:#WSDevSol.

Related information:

Introduction to ASN.1 Syntax and Encoding

Debugging Windows Phone 7 device traffic with Fiddler - Fiddler ...‎

Configure the Windows Phone 8 Emulator to work with Fiddler ...





Comments (25)

  1. Rahul Tolani says:


    This is what i'm getting from command –

    certutil -asn clientCertificate.crt


            |  |        |     ; Common Name (CN)

    00f1:    |  |        13 25                      ; PRINTABLE_STRING (25 Bytes)

    00f3:    |  |           42 31 43 34 33 43 44 30  2d 31 36 32 34 2d 35 46  ; B1C43CD0-1624-5F

    0103:    |  |           42 42 2d 38 45 35 34 2d  33 34 43 46 31 37 44 46  ; BB-8E54-34CF17DF

    0113:    |  |           44 33 41 31 00                                    ; D3A1


            |  |              ; "B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1"


    so my subject property will be:


    But this is what i'm using.

    <parm datatype="string" name="CertificateSearchCriteria" value="CN%3DB1C43CD0-1624-5FBB-8E54-34CF17DFD3A1"/>

    Still after enrollment company hub doesnt gets installed.

    Please help  in this!!



  2. Hello Rahul,

    Can you try with the CertificateSearchCriteria value like this:

    <parm datatype="string" name="CertificateSearchCriteria" value="CN=B1C43CD0%2D1624%2D5FBB%2D8E54%2D34CF17DFD3A1"/>

    I have replaced %3D with the equals sign, and the '='/ dashes with the escaped equivalent %2D characters.



  3. Eric Fleck says:

    As you can see, your subject has a null character at the end "…44 33 41 31 00" << '00' is null character.

    You should be providing a different Subject value instead of using the value from the request.

  4. Rahul Tolani says:

    Hi !!

    I tried many things but yet couldn't solve it.

    Please help me in the below questions:

    1. Device CSR's subject itself contains a null character.

    Device CSR =>

















    Subject property =>

    $ openssl req -in RequestSecurityToken.csr -noout -subject


    2.So after signing, the client certificate has the same subject property name

    i.e CN=B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1x00

    3.Even if we try and change or try to override the property in the CSR's then

    signing fails saying..

    "Signature did not match the certificate request"

    4.Is their any other way to get through this ??

    stuck here from long time…




  5. TharinduW says:

    Excellent post I have faced all the issues until the enrollment and stuck at the enrollment now. Basically my enrollment getting success but after that no communication with the MDM.

    "What you meant by The client certificate you send in response to this request must have the same public key value as specified in the PKCS#10 request."

    I simply requesting the certificate with the Request token received from the device. Am I suppose to process the request.

    CCertRequest certReq =  new CCertRequest();

    CCertConfig certConfig =  new CCertConfig();

    if(3 == CertReq.Submit(BASE64|PKCS10|FORMATANY, request, "", certConfig.GetConfig(0)))


         string clientCert = CertRequest.GetCertificate(BASE64);


    Am I doing something wrong here?

  6. Hi Eric,

    Whenever I change Subject property of device certificate to any other value let say "CN=MyTestMDM",enrolment always failed.

    But If I keep subject same as that of CSR from device(CN%3DB1C43CD0-1624-5FBB-8E54-34CF17DFD3A1),then enrolment happens but hub app never get installed.

  7. TharinduW says:

    Hi Matle

    Are you using a Certificate Template to change the Client Certificate subject. If not try using a certificate template to set the subject name.

    Can you also let me know whether after you successfully enrolled does the device calling to your DM URL.

    I'm not getting the DM URL called even after successfully enrolled.


  8. Hi TharinduW ,

    After enrolment, device polls successfully.No issues in polling also.but hub app is not installed even though we check the checkbox for installation of hub app.

    And how yo use certificate template to set the subject name?

  9. Hi TharinduW,

    Device polls successfully after enrolment.But company hub app is not getting installed even after we chack the chaeckbox shown for installation of hub app.

    And how to use certficate template to change client certificate subject?

  10. Pankaj Maurya @Vaibhav Matle says:

    Hi Vaibhave,

    Will you please explain some details how you did the enrollment as we are stuck at enrollment. Service is discovered properly but after that POST request always getting error ………………..


  11. TharinduW says:

    Hi Vaibhav

    In the CA you you have a certificate template. You can create a duplicate template from the Computer template. In the new template open properties and select the Subject Name tab. Select Build from this Active Directory information. In the Combo box select Common name. And then add the new template to the Certificate Template folder under CA server.

    When you submit the certificate request, request attributes should have the following "CertificateTemplate:yourCertTemplateName".

    I am facing some issues in the enrollment will you be able to help me. Basically after account is added device does not connect to my Management Server URL. Appreciate if you can help.


  12. Pankaj Maurya says:


    Will you please explain some details how you did the enrollment as we are stuck at enrollment. Service is discovered properly but after that POST request always getting error 404. The 2 GET requests made to the same URL by the device succeed with the code 200 0 0…….. All communication is happening on https channel only. Please help.


  13. Pankaj Maurya says:

    Hi Eric,

    I have setup my server and registered it with the subdomain "enterpriseenrollment.domain-name" as described in the WP8 MDM protocol documentation. I have a "A record" on the public DNS pointing to my server's IP address.

    The service has been written and published at the /EnrollmentServer/Discovery.svc on the server.

    When the service is hit on the same url using a web-form it returns the desired output. In addition the device initiated 2 GET requests sent to the server succeed with a 200 0 0.

    The POST request however returns with a 404 0 0, even though the service is very much present and up. All device and server interaction is happening on HTTPS, and I am using a self signed SSL certificate. The Root CA and the SSL Certificates are installed on the device. Both http and https bindings are enabled on IIS.

    Please suggest where I might be going wrong.

    Thanks and Regards

  14. tarquin hall says:

    So many information in one blog. This is awesome man. I am really impressed by the way you share your thoughts about enterprise in your blog.

  15. col says:

    I am stuck at the enrollment server setup. I am able to set discovery service but facing issues while proceeding further. What are the XCEP and WSTEP servers? Do I need to actually write code and implement them or I just need to install them and use if yes then how ?

  16. Eric Fleck says:

    You need to write some code in your server layer to handle these messages.  Your server can leverage an existing Certificate service for the actual certificate allocation but you need to do some validation and translation in your MDM implementation layer.

    MS-XCEP and MS-WSTEP are SOAP based message protocols.  Windows Phone 8 Enterprise Device Management client supports only a subset of these protocols, as defined in the MDM protocol doc.  

    Also, in the Windows Phone 8 MDM clients' implementation of MS-WSTEP the device expects the BinarySecurityToken to contain a wap-provisioning XML, not a simple certificate.

  17. zait says:

    I have a problem with my implementation – enrollment is all fine, but whatever i respond to the first SyncML message with, the device simply re-sends the same payload once and then disconnects. Also after initial retries are exhausted it no longer tries to connect – this means that the session wasn't established correctly. I have copied over SyncHdr <cred> structure and replaced the digest with the ProviderId:AAUTHSECRET (from CLIENT):NONCE(from CLIENT) in the correct formula (using the method in this blog).

    Any ideas?

  18. Eric Fleck says:

    @zait, the first thing that comes to mind is: are you incrementing the MsgID in your response?  (i.e. client sends request MsgID=1, server should respond with MsgID=2.)

    Also make sure that your response acknowledges the credentials which the client sent with a 212 status.

  19. Abimaran Kugathasan says:

    Hi Eric,

    How can I encode the subject name with Printable_String format?

  20. RajaRamesh says:

    Hi Eric,I got authentication required label instead of enrolled label.

    I have doubt in my <wap> xml code. In  APPAUTH field what is "nonce" ?. What value i need to give. What is nonce.

    I am getting device information after the enrolment process .

    Please advise me.

    Any advise would be greatly appreciated.

  21. Eric Fleck says:

    'nonce' is a term used for a random numeric value used only once before generating a new number.  

    In this case we recommend that the numeric value should be a 16 byte value (buffer).  The numeric value / buffer should be encoded using Base64 binary encoding, ex: string nonce= Convert.ToBase64(byteBuffer)  

  22. slwheat says:

    Are there any other criteria for the SSLCLIENTCERTSEARCHCRITERIA? An MSDN forum thread (…/windows-81-enrolment-wstep-stage) leads me to believe that there may be something else wrong with mine. Even though it matches the subject of my certificate exactly and is URL encoded, the device still rolls back the certificate installation. It may not be the SSLCLIENTCERTSEARCHCRITERIA which is my issue, but I'm sort of grasping at straws here.

  23. slwheat says:

    It may be worth noting that I only experience this issue when using the Federated enrollment scheme. I use the same process to generate certificates and create the provisioning XML when using OnPremise enrollment. The process and values work correctly for OnPrem, but they fail for Federated. Any help would be appreciated.

  24. Certificate Enrollment Web Service says:

    Hello Eric, Facing a problem in generating CSR from PKCS#10 device RequestSecurityToken. Is it require to generate on every request from device certificate enrollment web service.

    Any help would be appreciated.

  25. MDM win10 says:

    Hi Eric,

    I am having problems in the MDM implementation for win10 devices, specifically the certificate enrollment step (which includes wap creation).

    Could u please have a look at this forum question that I have raised :…/mdm-enrollment-for-windows-10-mswstep-certificate-enrollment

    Any kind of help will be appreciated.


Skip to main content