none
[MS-MDE] Windows 8.1 AuthenticationServiceUrl request is not being sent after receiving DiscoveryResponse RRS feed

  • Question

  • Hi

    I am trying to implement the Enrollment protocol for Windows 8.1 Device Management.

    I got the Discovery Request from DM Client and I sent the DiscoveryResponse back with my AuthenticationServiceUrl. But I did not see the next request initiated from DM Client. I was expecting a request to AuthenticationServiceUrl that was received in the Response. 

    Below is the Request I received to the server:

    <s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/Discover</a:Action>
    <a:MessageID>urn:uuid:748132ec-a575-4329-b01b-6171a9cf8478</a:MessageID>
    <a:ReplyTo>
    <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1">https://EnterpriseEnrollment.sap.com:443/EnrollmentServer/Discovery.svc</a:To>
    </s:Header>
    <s:Body>
    <Discover xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment">
    <request xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    <EmailAddress>sumanth@abc.com</EmailAddress>
    <RequestVersion>1.0</RequestVersion>
    </request>
    </Discover>
    </s:Body>
    </s:Envelope>

    Below is the DiscoveryResponse I sent back:

    <?xml version="1.0" encoding="UTF-8"?>
    <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
       <s:Header>
          <a:Action s:mustUnderstand="1">http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/DiscoverResponse</a:Action>
          <a:RelatesTo>urn:uuid:748132ec-a575-4329-b01b-6171a9cf8478</a:RelatesTo>
       </s:Header>
       <s:Body>
          <DiscoverResponse xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
             <DiscoverResult>
                <AuthPolicy>Federated</AuthPolicy>
                <AuthUrl>prod</AuthUrl>
                <EnrollmentPolicyServiceUrl>http://10.53.192.220/aips/CertificatePolicy.svc?DevEnId={a5aba922-46f5-4de6-b44d-d67930b5ef62}</EnrollmentPolicyServiceUrl>
                <AuthenticationServiceUrl>http://10.53.192.220/aips/aipService.svc/Authenticate</AuthenticationServiceUrl>
                <EnrollmentServiceUrl>http://10.53.192.220/aips/CertificateEnrollment.svc?DevEnId={a5aba922-46f5-4de6-b44d-d67930b5ef62}</EnrollmentServiceUrl>
             </DiscoverResult>
          </DiscoverResponse>
       </s:Body>
    </s:Envelope>

    Is there any problem with the response mentioned above?

    Is there any way to check the logs of the DM Client to check why it is not sending the next request?

    Monday, January 20, 2014 9:55 AM

All replies

  • Hi sumanthmp,

    Thank you for your question. A member of the Protocol Documentation support team will respond to you soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Monday, January 20, 2014 7:08 PM
  • Hello Sumanthmp -

    I'll help you with this issue. Can you please send me a mail to - dochelp at Microsoft dot com so that I can share steps/tools to collect traces on windows client to troubleshoot the issue.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Monday, January 20, 2014 7:15 PM
  • Thank you Tarun chopra, I sent a mail to dochelp as suggested and waiting for the reply.
    Tuesday, January 21, 2014 4:13 AM
  • Thanks. I received your email and shared steps to collect traces.  Let's communicate through dochelp and update this thread once the issue is resolved.

    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, January 21, 2014 5:55 AM
  • I was able to solve the problem by just updating the Windows 8.1 to the latest
    Friday, January 24, 2014 5:53 AM
  • Thanks sumanthmp for the update.

    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Friday, January 24, 2014 5:30 PM
  • Hello, I'm having the same problem, and Windows 8.1 is already at the latest version up-to-date..Any suggestions? I'm using a lenovo tablet2

    In the application event log I found an event like this:

    Package windows.immersivecontrolpanel_6.2.0.0_neutral_neutral_cw5n1h2txyewy+microsoft.windows.immersivecontrolpanel was terminated due to low system resources 

    which i think is somehow related to this issue ? 

    Thursday, May 1, 2014 11:23 AM
  • Hello Deniz Cakirkaya,
    The purpose of this forum is to support the Open Specifications documentation. You can read about the Microsoft Open Specifications program from http://www.microsoft.com/openspecifications/en/us/default.aspx . The library of Open Specification documents can be accessed from http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).aspx
     
    Based on the description of your issue, it appears to be related to product implementation rather than protocol specific. You can reach out to Microsoft platforms product support team for assistance on this issue. If you have a Premier support agreement with Microsoft product support group, you could contact your assigned Microsoft technical account manager for assistance in opening a case. Otherwise below are some resources that provide contact information and explain various methods of obtaining support.
     
    http://support.microsoft.com/kb/319726/en-us
    http://support.microsoft.com/gp/microsoft-support-options

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Thursday, May 1, 2014 3:22 PM
    Moderator
  • Hello Sreekanth,

    I found out that the event is not the related to my issue, but it's more like the built in agent is not generating the discovery request as it's supposed to. 

    According to MS-MDE (3.1.4.1.3.1) the built-in OMA-DM API agent is supposed to generate the first Discovery request with RequestVersion:nil, right? On the other hand, I'm referring to the Windows Phone 8.1 MDM Protocol (page 14), for there are similarities in the discovery phase to Windows 8.1, and there it clearly states that the RequestVersion in the discovery request is updated as "2.0" in Windows Phone 8.1 . However, the device I'm using (Windows 8.1 Enterprise), generates the Discovery request with RequestVersion=1.0. 

    My discovery service returns the discovery response as per MS-MDE, but there are no more requests coming from the OMA-DM API agent -- can it be that my agent's version is not somehow up-to-date?  my OS seems to be up-to-date, as I've already indicated. 

    Thanks

    Friday, May 2, 2014 1:59 PM
  • Hello Deniz Cakirkaya,

    A member of open specifications team will contact you to investigate this issue.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Friday, May 2, 2014 5:47 PM
    Moderator
  • Hello Deniz Cakirkaya,

    I'll be assisting you with this inquiry and would like to update that the MS-MDM\MDE specifications are applicable only to Windows 8.1 and not to windows phone,  Windows phone is handled by different team.

    Based on your response that you are interacting with windows 8.1 (not windows phone), please send a mail to my attention at - dochelp at Microsoft dot com so that I can share steps to take traces from your client and troubleshoot further.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Friday, May 2, 2014 5:57 PM
  • Hello Tarun Chopra, 

    I'm referring to the MS-MDE (for windows 8.1 device management) where it states that:

    "3.1.4.1.3.1 DiscoveryRequest

    RequestVersion: The value MUST be set to nil."

    I've been trying to "turn on" workplace on 2 different windows 8.1 tablets, and I see "RequestVersion:1.0" in the generated discovery requests by the enrollment client.

    I don't know if this is the reason why the enrollment client does not send the following authentication request ?

    Can you please clarify these points too?

    Thanks

    Monday, May 5, 2014 8:01 AM
  • Hello Deniz -

    We have received your mail at dochelp. Let's try to troubleshoot the issue through dochelp and once issue is resolved, we will update this thread with the outcome. Hope that's fine.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Monday, May 5, 2014 11:26 PM
  • I worked with Tarun and we were able to resolve the access_denied issue which was coming from authhost.exe process.

    The issue I was experiencing was due to the fact that:

    1. Testing as a non-administrative account, if there's a trust issue regarding the SSL certificate of the Discovery server, the enrollment never happens.

    2. Testing as an administrator (as being unaware of such an issue with my SSL certificate - since I had already installed the root CA certificate - but didn't notice that Fiddler was messing with the certificates I was testing with), enrollment never happens by design.

    Tarun, once again, many thanks for helping me on this. 


    Thursday, May 15, 2014 2:54 PM