• Wiz/dumb

    Parsing ServerVersion: When an Int Is Really 5 Ints

    • 0 Comments

    I recently had a case where a customer was asking how to figure out the mailbox version of a given user using Exchange Web Services (EWS). We noticed there is a node returned in the AutoDiscover response message called ServerVersion, but this value seems pretty opaque. Here’s a snippet from the AutoDiscover POX response from my test server:

    <Protocol>
      <Type>EXCH</Type>
      <Server>MAILBOXEX7.domain.com</Server>
      <ServerDN>/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAILBOXEX7</ServerDN>
      <ServerVersion>720280B0</ServerVersion>
      <MdbDN>/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAILBOXEX7/cn=Microsoft Private MDB</MdbDN>
      <PublicFolderServer>MAILBOXEX7.domain.com</PublicFolderServer>
      <AD>domainDC.domain.com</AD>
      <ASUrl>https://casserver.domain.com/EWS/Exchange.asmx</ASUrl>
      <EwsUrl>https://casserver.domain.com/EWS/Exchange.asmx</EwsUrl>
      <OOFUrl>https://casserver.domain.com/EWS/Exchange.asmx</OOFUrl>
      <UMUrl>https://casserver.domain.com/UnifiedMessaging/Service.asmx</UMUrl>
      <OABUrl>https://casserver/OAB/4c44408b-66b7-42d9-8247-316fca26961c/</OABUrl>
    </Protocol>

    The ServerVersion value returned in AutoDiscover is a 32-bit integer value represented in hexidecimal format (720280B0). The integer by itself doesn’t mean anything. It turns out, this integer is really a serialized structure. Here’s how it breaks down:

    0x720280B0 (or 1912766640 in decimal) represented in binary is 01110010000000101000000010110000. If we break this binary chunk up into 5 pieces, we’ll see the structure we are after:

    0111  001000  000010  1  000000010110000

    0111  (7) - The first 4 bits represent a number used for comparison against older version number structures. You can ignore this.

    001000 (8) – The next 6 bits represent the major version number.

    000010 (2) – The next 6 bits represent the minor version number.

    1 (1) – This bit is just a flag that you can ignore.

    000000010110000 (176) – The last 15 bits is the build number.

    So I can see that my server is running build 08.02.0176.

    To parse this value in code is quite easy if you use the binary shift operators. The following sample is in C#, but similar constructs exist in most languages. GetServerVersionIntFromString simply gets the ServerVersion value from the AutoDiscover response body and converts the string value “720280B0” into an unisigned integer using UInt32.Parse

    UInt32 intServerVersion = GetServerVersionIntFromString(sb);

    uint build = intServerVersion & 0x7FFF;
    //get bottom 15 bits
    uint minor = (intServerVersion >> 16) & 0x3F;
    //get 6 bits from 16 bits in
    uint major = (intServerVersion >> 22) & 0x3F;
    //gets 6 bits from 22 bits in

    I should point out that in Exchange 2010 and above, a new AutoDiscover option is being made available – AutoDiscover SOAP. If you know you will be targeting an Exchange 2010 server, you can use the SOAP AutoDiscover calls which can return you the server major and minor build numbers in a more easily consumable format.

     

    <s:Header>
      <a:Action s:mustUnderstand="1">http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetUserSettingsResponse</a:Action>
      <h:ServerVersionInfo xmlns:h="http://schemas.microsoft.com/exchange/2010/Autodiscover" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <h:MajorVersion>14</h:MajorVersion>
        <h:MinorVersion>0</h:MinorVersion>
        <h:MajorBuildNumber>639</h:MajorBuildNumber>
        <h:MinorBuildNumber>20</h:MinorBuildNumber>
        <h:Version>Exchange2010</h:Version>
      </h:ServerVersionInfo>
    </s:Header>

  • Wiz/dumb

    MimeContent vs Mime Content

    • 0 Comments

    Recently, I helped a customer with an issue where they were wondering if it was essential to set the ToRecipients, CcRecipients, and BccRecipients if they were setting the same values in the MimeContent property when doing a CreateItem call in Exchange Web Services. While trying to test out the scenarios, I thought “maybe it depends on the order of the elements in your <t:Message>. I soon realized that the order of the properties in the <t:Message> node seemed to matter. As it turns out, MessageType inherits from ItemType and MimeContent is defined on the ItemType where the recipient properties are defined on the MessageType and both of these are xs:sequence types. This means that their elements must appear in a specific order. Any deviation from the prescribed sequence results in a schema validation error returned from EWS. That meant that the MimeContent property itself always had to appear before the recipient properties since MimeContent is the first element described in the ItemType.

    Here’s the schema for the ItemType and you can see that MimeContent is first.

    <!-- Core contents of an item. -->
    <xs:complexType name="ItemType">
      <xs:sequence>
        <xs:element name="MimeContent" type="t:MimeContentType" minOccurs="0" />
        <xs:element name="ItemId" type="t:ItemIdType" minOccurs="0" />
        <xs:element name="ParentFolderId" type="t:FolderIdType" minOccurs="0"/>
        <xs:element name="ItemClass" type="t:ItemClassType" minOccurs="0" />
        <xs:element name="Subject" type="xs:string" minOccurs="0" />
        <xs:element name="Sensitivity" type="t:SensitivityChoicesType" minOccurs="0" />
        <xs:element name="Body" type="t:BodyType" minOccurs="0" />
        <xs:element name="Attachments" type="t:NonEmptyArrayOfAttachmentsType" minOccurs="0" />
        <xs:element name="DateTimeReceived" type="xs:dateTime" minOccurs="0" />
        <xs:element name="Size" type="xs:int" minOccurs="0" />
        <xs:element name="Categories" type="t:ArrayOfStringsType" minOccurs="0" />
        <xs:element name="Importance" type="t:ImportanceChoicesType" minOccurs="0" />
        <xs:element name="InReplyTo" type="xs:string" minOccurs="0" />
        <xs:element name="IsSubmitted" type="xs:boolean" minOccurs="0" />
        <xs:element name="IsDraft" type="xs:boolean" minOccurs="0" />
        <xs:element name="IsFromMe" type="xs:boolean" minOccurs="0" />
        <xs:element name="IsResend" type="xs:boolean" minOccurs="0" />
        <xs:element name="IsUnmodified" type="xs:boolean" minOccurs="0" />
        <xs:element name="InternetMessageHeaders" type="t:NonEmptyArrayOfInternetHeadersType" minOccurs="0" />
        <xs:element name="DateTimeSent" type="xs:dateTime" minOccurs="0" />
        <xs:element name="DateTimeCreated" type="xs:dateTime" minOccurs="0" />
        <xs:element name="ResponseObjects" type="t:NonEmptyArrayOfResponseObjectsType" minOccurs="0" />
        <xs:element name="ReminderDueBy" type="xs:dateTime" minOccurs="0" />
        <xs:element name="ReminderIsSet" type="xs:boolean" minOccurs="0" />
        <xs:element name="ReminderMinutesBeforeStart" type="t:ReminderMinutesBeforeStartType" minOccurs="0" />
        <xs:element name="DisplayCc" type="xs:string" minOccurs="0" />
        <xs:element name="DisplayTo" type="xs:string" minOccurs="0" />
        <xs:element name="HasAttachments" type="xs:boolean" minOccurs="0"/>
        <xs:element name="ExtendedProperty" type="t:ExtendedPropertyType" minOccurs="0" maxOccurs="unbounded" />
        <xs:element name="Culture" type="xs:language" minOccurs="0"/>
        <xs:element name="EffectiveRights" type="t:EffectiveRightsType" minOccurs="0" />
        <xs:element name="LastModifiedName" type="xs:string" minOccurs="0" />
        <xs:element name="LastModifiedTime" type="xs:dateTime" minOccurs="0" />
      </xs:sequence>
    </xs:complexType>

    That’s followed by the MessageType schema that is an extension of ItemType. This is where the recipient properties appear.

    <!-- - - - - - - - - - - - - - - - - - - -->
    <!--   Message type: derived from item   -->
    <!-- - - - - - - - - - - - - - - - - - - -->
    <xs:complexType name="MessageType">
      <xs:complexContent>
        <xs:extension base="t:ItemType">
          <xs:sequence>
            <xs:element name="Sender" minOccurs="0" type="t:SingleRecipientType" />
            <xs:element name="ToRecipients" type="t:ArrayOfRecipientsType" minOccurs="0" />
            <xs:element name="CcRecipients" type="t:ArrayOfRecipientsType" minOccurs="0" />
            <xs:element name="BccRecipients" type="t:ArrayOfRecipientsType" minOccurs="0" />
            <xs:element name="IsReadReceiptRequested" type="xs:boolean" minOccurs="0" />
            <xs:element name="IsDeliveryReceiptRequested" type="xs:boolean" minOccurs="0" />
            <xs:element name="ConversationIndex" type="xs:base64Binary" minOccurs="0" />
            <xs:element name="ConversationTopic" type="xs:string" minOccurs="0" />
            <xs:element name="From" type="t:SingleRecipientType" minOccurs="0" />
            <xs:element name="InternetMessageId" type="xs:string" minOccurs="0" />
            <xs:element name="IsRead" type="xs:boolean" minOccurs="0" />
            <xs:element name="IsResponseRequested" type="xs:boolean" minOccurs="0" />
            <xs:element name="References" type="xs:string" minOccurs="0" />
            <xs:element name="ReplyTo" type="t:ArrayOfRecipientsType" minOccurs="0" />
            <xs:element name="ReceivedBy" type="t:SingleRecipientType" minOccurs="0" />
            <xs:element name="ReceivedRepresenting" type="t:SingleRecipientType" minOccurs="0" />
          </xs:sequence>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>

    If you think about how the server will process this XML SOAP request, it will get the MimeContent first and then the first-class properties after that. So the server will build out its entire MIME message based on the content of the MimeContent property and then override those values with the first-class properties that follow. The same holds true for other properties like Body, Subject, etc.

    After I figured all this out, I found this already clearly explained in Inside Microsoft Exchange Server 2007 Web Services explaining this same phenomenon when attempting to set the subject:

    Well, during a CreateItem call, properties are processed on a first-come, first-served basis.  You first create an empty message, set the contents from the MIME, and then set the explicit subject. This really isn’t a problem in practice although it has some interesting implications. The schema mandates a specific ordering of elements within item instances. In other words, trying to put the subject before the MimeContent property results in a schema validation error. Therefore, which property overwrites which is dictated by the ordering as defined in the schema. (page 176)

    They later go on to say the only time you’ll have a conflict is when you try to also set the same properties using the extended properties, so avoid doing that. There’s no need to set both the first-class property and it’s equivalent extended property.

Page 1 of 1 (2 items)