none
[MS-OXDSCLI] Autodiscovery response schema RRS feed

  • Question

  • This query is in relation to [MS-OXDSCLI] — v20140428 "Autodiscover Publishing and Lookup Protocol"

    Section 2.2.1 "Namespaces" says:
    Autodiscover requests are in the "http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006" namespace.
    Autodiscover responses are in the "http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a" namespace.

    A capture on the wire from Exchange 2013 SP1 (I don't have the build version handy, but its the configuration from the SUT server from the 2014 Interop) looks like:

    <?xml version="1.0" encoding="utf-8"?>
    <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
        <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">


    Similarly, the [MS-OXDSCLI] Section 4.2 example looks like:

    <?xml version="1.0" encoding="utf-8"?>
    <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
        <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">

    Suggestion 1: The top level Autodiscover namespace probably should be listed in Section 2.2.1

    However the XML schema in section 6.2 starts off with:

    <?xml version="1.0" encoding="utf-8"?>
    <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:import namespace="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a" />
        <xs:element name="Autodiscover">
            <xs:complexType>
                <xs:sequence>
                    <xs:element name="Response">

    I can't see that as matching the XML on the wire or the Section 4 example (since <Autodiscover> and <Response> aren't in the same namespace, no matter how I interpret the mix of default namespace from the <schema> and the <import>). A couple of validators (xmllint on the command line, and an online one in java) also mark this as invalid.

    Request A: Please advise of the correct namespaces for each element.

    There are probably other issues with the schema worth checking. One example is the <User> complex element, which in the Section 6.2 schema looks like:

    <xs:element name="User">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="DisplayName" type="xs:string" />
                <xs:element name="LegacyDN" type="xs:string" />
                <xs:element name="AutoDiscoverSMTPAddress" type="xs:string" />
                <xs:element name="DeploymentId" type="xs:string" />
                <xs:element name="DefaultABView" type="xs:string" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    That doesn't match what I see on the wire:

        <User>
          <DisplayName>Brad Hards</DisplayName>
          <LegacyDN>/o=PlugFestEx13-Exchange-Organisation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=dc91480647c642fdbd26fa</LegacyDN>
          <AutoDiscoverSMTPAddress>bradh@plugfestex13.com</AutoDiscoverSMTPAddress>
          <DeploymentId>baff715a-2e9f-4a71-9eb7-477470591436</DeploymentId>
        </User>

    (Note the missing <DefaultABView>).

    From [MS-OXDSCLI] Section 2.2.4.1.1.1 "User" some of those elements (including <DefaultABView>) are optional, but the schema needs minOccurs="0" to be added to reflect that.

    Suggestion 2: Rework the schema in Section 6.2 to reflect the optional children of <User>.

    The wire capture includes a <MicrosoftOnline> element as a child to the <Account> element:

        <Account>
          <AccountType>email</AccountType>
          <Action>settings</Action>
          <MicrosoftOnline>False</MicrosoftOnline>

    That <MicrosoftOnline> element is not included in the schema, nor is it described in the body of the document.

    Suggestion 3: Please include <MicrosoftOnline> in  Section 2.2.4.1.1.2.

    Request B: Please advise the required client behaviour (if any) for <MicrosoftOnline> element values

    Suggestion 4: Update [MS-OXDSCLI] with that client behaviour.

    [MS-OXDSCLI] 2.2.4.1.1.2.4.6 describes CertPrincipalName. I see that in the wire capture:

          <Protocol>
            <Type>EXPR</Type>
            <Server>ex2013sut.plugfestex13.com</Server>
            <SSL>Off</SSL>
            <AuthPackage>Ntlm</AuthPackage>
            <ServerExclusiveConnect>on</ServerExclusiveConnect>
            <CertPrincipalName>None</CertPrincipalName>
            <GroupingInformation>Default-First-Site-Name</GroupingInformation>
          </Protocol>

    However that element is missing from the Section 6.2 schema. In addition, [MS-OXDSCLI] 2.2.4.1.1.2.4.6 describes behaviour in terms of "not specified" and "blank" (for which I understand the element to be not present, or to be empty, but not to be literally "None").

    Suggestion 5: Update the schema to include <CertPrincipalName>

    Request C: Please identify whether "None" should be special cased, and what the required behaviour is in this special case.

    Suggestion 6. Update 2.2.4.1.1.2.4.6 with that information, if any.

    In the previous capture example, note the <GroupingInformation> element. I can't locate that in the schema or in the body of the document.

    Suggestion 7: Update the schema to include <GroupingInformation>

    Request D: Please advise the meaning and required client behaviour (if any) for <GroupingInformation> element values

    Suggestion 8: Update Section 2 and 3 (if required) with that <GroupingInformation> element information.

    The wire capture also included a protocol stanza that looked like:

          <Protocol>
            <Type>EXCH</Type>
            <Server>f79b2f2c-9e69-4a25-abf0-21416ddb63c4@plugfestex13.com</Server>
            <ServerDN>/o=PlugFestEx13-Exchange-Organisation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=f79b2f2c-9e69-4a25-abf0-21416ddb63c4@plugfestex13.com</ServerDN>
            <ServerVersion>73C0834F</ServerVersion>
            <MdbDN>/o=PlugFestEx13-Exchange-Organisation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=f79b2f2c-9e69-4a25-abf0-21416ddb63c4@plugfestex13.com/cn=Microsoft Private MDB</MdbDN>
            <PublicFolderServer>ex2013sut.plugfestex13.com</PublicFolderServer>
            <AD>EX2013SUT.PlugFestEx13.com</AD>
            <ASUrl>https://ex2013sut.plugfestex13.com/EWS/Exchange.asmx</ASUrl>
            <EwsUrl>https://ex2013sut.plugfestex13.com/EWS/Exchange.asmx</EwsUrl>
            <EmwsUrl>https://ex2013sut.plugfestex13.com/EWS/Exchange.asmx</EmwsUrl>
            <EcpUrl>https://ex2013sut.plugfestex13.com/ecp/</EcpUrl>
            <EcpUrl-um>?rfr=olk&amp;p=customize/voicemail.aspx&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-um>
            <EcpUrl-aggr>?rfr=olk&amp;p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-aggr>
            <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&amp;exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;&amp;realm=PlugFestEx13.com</EcpUrl-mt>
            <EcpUrl-ret>?rfr=olk&amp;p=organize/retentionpolicytags.slab&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-ret>
            <EcpUrl-publish>customize/calendarpublishing.slab?rfr=olk&amp;exsvurl=1&amp;FldID=&lt;FldID&gt;&amp;realm=PlugFestEx13.com</EcpUrl-publish>
            <EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&amp;chgPhoto=1&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-photo>
            <EcpUrl-tm>?rfr=olk&amp;ftr=TeamMailbox&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-tm>
            <EcpUrl-tmCreating>?rfr=olk&amp;ftr=TeamMailboxCreating&amp;SPUrl=&lt;SPUrl&gt;&amp;Title=&lt;Title&gt;&amp;SPTMAppUrl=&lt;SPTMAppUrl&gt;&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-tmCreating>
            <EcpUrl-tmEditing>?rfr=olk&amp;ftr=TeamMailboxEditing&amp;Id=&lt;Id&gt;&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-tmEditing>
            <EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&amp;exsvurl=1&amp;realm=PlugFestEx13.com</EcpUrl-extinstall>
            <OOFUrl>https://ex2013sut.plugfestex13.com/EWS/Exchange.asmx</OOFUrl>
            <UMUrl>https://ex2013sut.plugfestex13.com/EWS/UM2007Legacy.asmx</UMUrl>
            <OABUrl>https://ex2013sut.plugfestex13.com/OAB/2a19800d-7f8d-4b5d-8799-6bff1cb38fb9/</OABUrl>
            <ServerExclusiveConnect>off</ServerExclusiveConnect>
          </Protocol>

    Note the <EmwsUrl> element. I can't find that in the schema or in the body of the document.

    Suggestion 9: Update the schema to include <EmwsUrl>

    Request E: Please advise the meaning and required client behaviour (if any) for <EmwsUrl> element values. Particularly of interest is how it relates / differs from <EwsUrl>.

    Suggestion 10: Update Section 2 and 3 (if required) with that <EmwsUrl> element information.

    There is a validation problem with<EcpUrl-photo>, which occurs in a different order in the example to that shown in the schema. Not sure about the right fix for this one - I just reordered the schema entry.

    Suggestion 11: Consider reviewing final schema for validity and compatibility with Section 4 and wire examples?

    The wire capture does not include <AlternativeMailbox> or <PublicFolderInformation>, which is OK according to section 2, since these are optional.

    Suggestion 12: Update schema to reflect these as optional (i.e. minOccurs="0").

    Requests A, B, C and D are moderate priority. Request E and the suggestions are low priority.





    • Edited by Brad Hards Thursday, June 19, 2014 5:41 AM
    Thursday, June 19, 2014 5:37 AM

Answers

  • Hello Brad,

    I apologize for the lengthy delay in addressing this post. All of the suggestions have been reviewed and filed for further consideration. Regarding the requests, I have feedback for you about all but request A so far, and should soon have feedback for that one too.

    > Request B: Please advise the required client behaviour (if any) for <MicrosoftOnline> element values

    The value of this element indicates whether the account is hosted in a Microsoft datacenter or not. In some cases, the client can use this information to determine which protocol to use to sync, but there is no requirement that it do so.

    > Request C: Please identify whether "None" should be special cased, and what the required behaviour is in this special case.

    "None" should be special cased. "None" indicates that SSL is turned off on the server. An empty value ("") indicates that SSL is turn on, but the certificate is missing on the server.

    > Request D: Please advise the meaning and required client behaviour (if any) for <GroupingInformation> element values

    The value of this element can be used by the client to group notification subscriptions together when it is subscribing to several mailboxes at the same time. The expected scenario for this would be when a service account performs AutoDiscovery for several different user accounts, at which point all accounts that return the same <GroupingInformation> value can be batched into a single SubscribeToNotification request.

    > Request E: Please advise the meaning and required client behaviour (if any) for <EmwsUrl> element values. Particularly of interest is how it relates / differs from <EwsUrl>.

    This is the URL for the Exchange Web Management Service. There is no required client behavior surrounding this element. The similarity to the <EwsUrl> is that both URL values provide access to various web services.

    Please let me know if you have additional questions about these four issues, and I'll update the thread as soon as I have more information about the final question. Thank you again for your patience.

    [Edit 2014-09-11:

    > Request A: Please advise of the correct namespaces for [<AutoDiscover> and <Response>].

    The correct namespace for <AutoDiscover> is http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006, and the correct namespace for <Response> is http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006. The example provided in §4.4 is using the correct namespaces. §2.2.1 and §6.2 will both require corrections.

    -- end edit]

    Best regards,
    Matt Weber | Microsoft Open Specifications Team


    Tuesday, September 9, 2014 6:14 PM

All replies

  • Hi Brad:

    I have alerted the open specifications team regarding your inquiry. A member of the team will be in touch soon.


    Regards, Obaid Farooqi

    Thursday, June 19, 2014 6:35 AM
    Owner
  • Hello Brad,

    I apologize for the lengthy delay in addressing this post. All of the suggestions have been reviewed and filed for further consideration. Regarding the requests, I have feedback for you about all but request A so far, and should soon have feedback for that one too.

    > Request B: Please advise the required client behaviour (if any) for <MicrosoftOnline> element values

    The value of this element indicates whether the account is hosted in a Microsoft datacenter or not. In some cases, the client can use this information to determine which protocol to use to sync, but there is no requirement that it do so.

    > Request C: Please identify whether "None" should be special cased, and what the required behaviour is in this special case.

    "None" should be special cased. "None" indicates that SSL is turned off on the server. An empty value ("") indicates that SSL is turn on, but the certificate is missing on the server.

    > Request D: Please advise the meaning and required client behaviour (if any) for <GroupingInformation> element values

    The value of this element can be used by the client to group notification subscriptions together when it is subscribing to several mailboxes at the same time. The expected scenario for this would be when a service account performs AutoDiscovery for several different user accounts, at which point all accounts that return the same <GroupingInformation> value can be batched into a single SubscribeToNotification request.

    > Request E: Please advise the meaning and required client behaviour (if any) for <EmwsUrl> element values. Particularly of interest is how it relates / differs from <EwsUrl>.

    This is the URL for the Exchange Web Management Service. There is no required client behavior surrounding this element. The similarity to the <EwsUrl> is that both URL values provide access to various web services.

    Please let me know if you have additional questions about these four issues, and I'll update the thread as soon as I have more information about the final question. Thank you again for your patience.

    [Edit 2014-09-11:

    > Request A: Please advise of the correct namespaces for [<AutoDiscover> and <Response>].

    The correct namespace for <AutoDiscover> is http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006, and the correct namespace for <Response> is http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006. The example provided in §4.4 is using the correct namespaces. §2.2.1 and §6.2 will both require corrections.

    -- end edit]

    Best regards,
    Matt Weber | Microsoft Open Specifications Team


    Tuesday, September 9, 2014 6:14 PM
  • Matt,

    Thanks for the work on this. Appreciated.

    Brad

    Thursday, September 11, 2014 5:06 PM