none
Implementing Autodiscover Server RRS feed

  • Question

  • Hello,

    We are working on an Autodiscover server implementation.  The scope is very small, to accept requests for a given address, and issue the <redirect> verb for another email address.

    The protocol documentation isn't clear, however, about which error codes should be used in a given situation.

    What are the proper error codes for:
    If the submitted request doesn't validate as XML?
    If the sumibtted request doesn't validate as AutoDiscover?

    Our current draft specificies a 404 error for both of these, but I am wondering if an AutoDiscover error response might be the better/best choice.

    thanks for any insight,

    Andrew


    Andrew Laurence UC Irvine

    Tuesday, March 13, 2012 7:50 PM

Answers

  • Hello,

    It turns out the redirectAddr failures in MacOutlook and Apple Mail/iCal were due to a whitespace error in our output XML.  This has been corrected, and they now work.

    However, we have encountered another issue in the validation of the ActiveSync Autodiscover schemas.  I will post that in a moment.

    -Andrew

    Andrew Laurence, UC Irvine

    • Marked as answer by atlauren Tuesday, May 1, 2012 4:16 AM
    Tuesday, May 1, 2012 4:15 AM
  • Hi Southbranch,

    I don’t have any insight into why your testing results are OK with WP7 and Android and not iOS, so you may want to post on the Apple iOS forum, https://developer.apple.com/devforums/

    The Type element in the Autodiscover response will only be CertEnroll if the server supports it.  Therefore, it is not mandatory.

    This will be clarified in a future version of the documentation.

    I hope this answers your question.

    Regards,
    Mark Miller | Open Specifications Support Team

    Tuesday, May 8, 2012 8:51 PM

All replies

  • Hi Atlauren

    Thank you for contacting Microsoft. A member of Open Specification Team will be in touch soon.

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Wednesday, March 14, 2012 4:08 AM
  • Hi Andrew,

    [MS-ASCMD] Section2.2.3.162.1 Status (Autodiscover) essentially states “Protocol error” will be the Status, and indicates the ErrorCode will contain the actual Autodiscover ErrorCode.

    Section2.2.3.61 ErrorCode:

    The ErrorCode element is an optional child element of the Error element in Autodiscover command responses that specifies an error number that indicates the cause of the error.

    …value of 600 means an invalid request was sent to the server; a value of 601 means that a provider could not be found to handle the AcceptableResponseSchema element value that was specified

    To answer your questions, look at ErrorCode 600 (Invalid request) and 601 (the requested schema version is not supported by the server).

    This reference should help with further enumeration of the Autodiscover ErrorCode, http://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.autodiscover.autodiscovererrorcode(v=EXCHG.80).aspx

    This MSDN article may also be helpful, http://msdn.microsoft.com/en-us/library/hh352638(EXCHG.140).aspx

    I hope this answers your question.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM


    Tuesday, March 27, 2012 2:02 PM
  • We are also implementing the Autodiscover server and we are currnently in a testing phase with devices from WP7.5, iPhone and Android.

    We have these results/thoughts/questions:

    • It seems to work fine for WP7.5 and Android.
    • But iPhone calls the Autodiscover service 2-3 times before showing the user an extra textbox with 'server.company.com'. After filling this in it works fine, however, it would really be great to get rid of this extra step! For instance should the tags Url and Name be exactly the same? Se our response below. Any comments ?
    • We take it as the CertEnroll in not mandatory? (protocol does not say..)

    Many thanks in advance

    <?xml version="1.0" encoding="utf-16"?>
    <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/requestschema/2006">
      <Response>
        <Culture>en:us</Culture>
        <User>
          <DisplayName>thomas_smith</DisplayName>
          <EMailAddress>thomas_smith@compnay.com</EMailAddress>
        </User>
        <Action>
          <Settings>
            <Server>
              <Type>MobileSync</Type>
              <Url>https://sync.company.com/Microsoft-Server-ActiveSync</Url>
              <Name>https://sync.comnay.com/Microsoft-Server-ActiveSync</Name>
            </Server>
          </Settings>
        </Action>
      </Response>
    </Autodiscover>
    Sunday, April 1, 2012 1:42 PM
  • Hello Southbranch,

    Thank you for your inquiry about Autodiscover related protocol. One of the Open specifications team member will contact you shortly.

    Please note that it is best to post your question as a separate thread for tracking purposes.

     
    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Sunday, April 1, 2012 2:46 PM
    Moderator
  • Hi Southbranch,

    Attempting to answer your questions:

    Q: But iPhone calls the Autodiscover service 2-3 times before showing the user an extra textbox with 'server.company.com'. After filling this in it works fine, however, it would really be great to get rid of this extra step! For instance should the tags Url and Name be exactly the same? See our response below. Any comments?

    A: This behavior may be related to what you specified in the Type element.  It appears you are specifying Type = MobileSync.

    2.2.3.110.1 Name (Autodiscover):

    If the Type element value is "MobileSync", then the Name element specifies the URL that conveys the protocol. If the Type element value is "CertEnroll", then the Name element value is NULL.

    Also, 2.2.3.170.1 Type (Autodiscover),

    The following are the valid values for the Type element:

    • MobileSync—Indicates that the URL that is returned by the URL element (section 2.2.3.172) can be accessed by clients.

    • CertEnroll—Indicates that the URL that is returned by the URL element can be accessed by clients that have a valid certificate over a Secure Sockets Layer (SSL).

    If the server supports both "MobileSync" and "CertEnroll", the response buffer includes multiple Server elements (section 2.2.3.149) that contain a URL value for each Type element value.

    Q: We take it as the CertEnroll in not mandatory? (protocol does not say..)

    A: Perhaps the following reference will answer your question.

    4.2.4 Response - Case Server Settings

    The following example shows an Autodiscover command response (section 2.2.2.1.2) that provides server URL information for two services: MobileSync and CertEnroll. The client can use the MobileSync URL to configure the synchronization settings. The client can also optionally use the CertEnroll information to obtain a client certificate for SSL negotiation.

    Another MSDN reference that may be helpful, Autodiscover for Exchange ActiveSync developers.

    I hope this answers your questions.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Monday, April 9, 2012 7:54 PM
  • Thanks for info.

    Yes, we are using "MobileSync" for the Type element and the values for Name and Url elements as in the example above. Anything else does not seem possible according to the protocol in case of offering a device sync service...? The reason why iPhone does 2-3 requests before showing the textbox for entering the full server url (e.g. sync.mycompany.com) is still however a mystery to us.

    In regards to CertEnroll. Yes we are aware of that the client optionally can use this info and so on. But to my knowledge we cannot find any protocol wording specifying whether or not the Tag itself is mandatory for the server to include in the answer or not.

    Monday, April 16, 2012 10:58 AM
  • Our application is in experimental testing.  Thus far we are only implementing the 2.2.3.1.1.2.3 RedirectAddr action, in order to route clients from our external namespace to internal addresses/namespaces.  Testing with Outlook 2007 and 2010 shows positive results.

    http://msdn.microsoft.com/en-us/library/ee237946%28v=exchg.80%29.aspx

    However, Outlook:Mac 2011 (14.2) does NOT follow the redirect.  The application shows that it receives the query from Outlook:Mac, and sends back the action response.  I would have expected it to follow and obey the action/directive in the Exchange Autodiscover protocol.

    Is this a bug in Outlook:Mac? 

    Thank you,
    Andrew


    Andrew Laurence, UC Irvine

    Friday, April 20, 2012 6:33 PM
  • Atlauren,

    FYI. I am unfamiliar with the potential Mac bug, and we are only testing our AutoDiscover against devices., so I can't help you there. We chose the "direct access" method using a subdomain like http://autodiscover.MyCompany.com/Autodiscover. It seemed to be the most straightforward route and it has given us no problems in terms of the access.

    Have you by any chance tested your service against the iPhone and seen any similar behavior as above? 

    Saturday, April 21, 2012 10:48 AM
  • I thought Outlook didn't use ActiveSync and thus not the AutoDiscover either...?

    Saturday, April 21, 2012 11:11 AM
  • Hi Laurence,

    An engineer from the Protocols Team will respond soon


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Saturday, April 21, 2012 3:17 PM
    Moderator
  • Hi Andrew and Southbranch,

    It is customary that one thread deals with one question. Now this thread contains multiple questions, all different from the original one.
    Andrew, I am the engineer who will be working with you on your issue posted on 4/20.
    Southbranch, as recommended by Sreekanth on 4/1, please post your questions on separate threads.

    Regards,
    Vilmos Foltenyi - MSFT

    Tuesday, April 24, 2012 10:29 PM
  • Hi Andrew,

    Please provide more information about the RedirectAddr failure. What is the topology of your setup, including versions?

    I would like to see what happened before the failure, too, could you provide an unencrypted network capture starting from the TCP/IP connection establishment? Be sure that the capture doesn’t contain any confidential information. If the size of the capture is less than 5MB you can send it as attachment to ‘dochelp (at) microsoft (dot) com’. If the size is bigger than 5MB I can create a secure workspace for you to upload the trace. In either case in the e-mail indicate that it is for me.

    Thanks, Vilmos

    Wednesday, April 25, 2012 6:55 PM
  • Hello,

    It turns out the redirectAddr failures in MacOutlook and Apple Mail/iCal were due to a whitespace error in our output XML.  This has been corrected, and they now work.

    However, we have encountered another issue in the validation of the ActiveSync Autodiscover schemas.  I will post that in a moment.

    -Andrew

    Andrew Laurence, UC Irvine

    • Marked as answer by atlauren Tuesday, May 1, 2012 4:16 AM
    Tuesday, May 1, 2012 4:15 AM
  • Hi atlauren,

    We are happy to investigate a new issue for you.  Since this thread is getting quite long would you please post your new issue on a new thread?

    Regards,

    Mark Miller | Open Specifications Support Team

    Tuesday, May 1, 2012 12:35 PM
  • Hi Mark,

    Thanks.  I posted it here:

    http://social.msdn.microsoft.com/Forums/en-US/os_exchangeprotocols/thread/cd42c415-2d57-405d-8d35-390c47e20d4c

    -Andrew


    Andrew Laurence, UC Irvine

    Tuesday, May 1, 2012 4:26 PM
  • Hi Southbranch,

    I don’t have any insight into why your testing results are OK with WP7 and Android and not iOS, so you may want to post on the Apple iOS forum, https://developer.apple.com/devforums/

    The Type element in the Autodiscover response will only be CertEnroll if the server supports it.  Therefore, it is not mandatory.

    This will be clarified in a future version of the documentation.

    I hope this answers your question.

    Regards,
    Mark Miller | Open Specifications Support Team

    Tuesday, May 8, 2012 8:51 PM
  • Hi Mark,

    Thanks for the response and the comment about the CertEnroll.

    Wednesday, May 9, 2012 7:47 AM