Wiz/dumb : Exchange 2007

Parsing ServerVersion: When an Int Is Really 5 Ints

Patrick Creehan — Mon, 21 Sep 2009 18:45:00 GMT

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>

MimeContent vs Mime Content

Patrick Creehan — Wed, 16 Sep 2009 22:46:31 GMT

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.

Exchange 2007 SP2 is Released

Patrick Creehan — Fri, 28 Aug 2009 01:14:16 GMT

In case you missed it, Exchange 2007 SP2 was released this week. There are some cool new features, which the EHLO blog talks about here as well as all the bug fixes etc.

One major thing to point out is that we no longer promote X- headers to custom properties on messages – though you can still get to them through the internet transport headers property.

Line Breaks in Managed Web Service Proxy Classes

Patrick Creehan — Wed, 22 Jul 2009 16:00:00 GMT

Matt, Rick, and I were working on an issue recently where when an application using EWS would set a contact’s Street address to a value containing a carriage return and line feed, like this:

  physicalAddress.Street = "1234 56 Ave NE\r\nc/oPatrick Creehan";

the address card control in Outlook would render it like this:

Ugly, right? The problem was that the XMLSerializer would strip out the line feed and leave the carriage return, which the address card didn’t like.

We could prove by sending raw XML requests in a separate application that sending 
 for the carriage return line feed would make everything right, however, if we set the street address like this:

  physicalAddress.Street = "1234 56 Ave NE&#x0d;&#x0a;c/oPatrick Creehan";

then the contact’s address card would look like this:

Even uglier! It seems that the .net framework, in an attempt to help us out is encoding our string for XML but it wasn’t letting us specify the value we knew was right.

So – the solution is to implement your own class which can handle the XmlSerialization yourself, and replace the auto-generated proxy class’s decision for the type to yours.

Here’s my simple class:

     [SoapTypeAttribute(Namespace = "http://schemas.microsoft.com/exchange/services/2006/types",TypeName="text")]
     public class mstring:IXmlSerializable   
     {
         private string m_string = string.Empty;
 
         public override string ToString()
         {
             return m_string;
         }
         
  
         public static mstring CreateMString(string str){
             mstring newmstring = new mstring();
             newmstring.m_string = str;
             return newmstring;
         }
 
         public static implicit operator mstring(string str)
         {
             return CreateMString(str);
         }
 
 
         #region IXmlSerializable Members
 
         public System.Xml.Schema.XmlSchema GetSchema()
         {
             return new System.Xml.Schema.XmlSchema();
         }
 
         public void ReadXml(XmlReader reader)
         {
             m_string = reader.ReadContentAsString();
         }
 
         public void WriteXml(XmlWriter writer)
         {
             string outString = m_string;
             outString = HttpUtility.HtmlEncode(outString);
 
             outString = outString.Replace("\r", "&#x0d;");
             outString = outString.Replace("\n", "&#x0a;");
 
             writer.WriteRaw(outString.ToString());
         \

A few things to point out is that I decorated this class with the XML namespace for the Exchange Web Services so that it doesn’t fail schema validation. Also, I didn’t really test whether this works when binding to an existing contact – there may be more work needed in the ReadXML section. In order to support still setting the Street property to a string, I had to override the implicit operator. That allows me to set Street to a string even though technically, now Street is an “mstring.” You’ll notice that the work of actually writing the correct value occurs in WriteXml which we got by implementing IXmlSerializable. Now when the SOAP infrastructure goes to build the request, it will call into our interface to serialize this class.

That reminds me, the last thing you need to do to hook all this up is to go into the web service proxy class Reference.cs and modify the PhysicalAddressDictionaryEntryType so the street properties use your new mstring class instead of string:

     /// <remarks/>
     [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.4918")]
     [System.SerializableAttribute()]
     [System.Diagnostics.DebuggerStepThroughAttribute()]
     [System.ComponentModel.DesignerCategoryAttribute("code")]
     [System.Xml.Serialization.XmlTypeAttribute(Namespace="http://schemas.microsoft.com/exchange/services/2006/types")]
     public partial class PhysicalAddressDictionaryEntryType {
         
         private mstring streetField;
         
         private string cityField;
         
         private string stateField;
         
         private string countryOrRegionField;
         
         private string postalCodeField;
         
         private PhysicalAddressKeyType keyField;
         
         /// <remarks/>
         public mstring Street {
             get {
                 return this.streetField;
             }
             set {
                 this.streetField = value;
             }
         }
 
         /// <remarks/>
         public string City {
             get {
                 return this.cityField;
             }
             set {
                 this.cityField = value;
             }
         }
         
         /// <remarks/>
         public string State {
             get {
                 return this.stateField;
             }
             set {
                 this.stateField = value;
             }
         }
         
         /// <remarks/>
         public string CountryOrRegion {
             get {
                 return this.countryOrRegionField;
             }
             set {
                 this.countryOrRegionField = value;
             }
         }
         
         /// <remarks/>
         public string PostalCode {
             get {
                 return this.postalCodeField;
             }
             set {
                 this.postalCodeField = value;
             }
         }
         
         /// <remarks/>
         [System.Xml.Serialization.XmlAttributeAttribute()]
         public PhysicalAddressKeyType Key {
             get {
                 return this.keyField;
             }
             set {
                 this.keyField = value;
             }
         }
     \

and (after removing the email address so the address will fit on the card) it looks like this:

Cake.

ConfigureMsgService fails with MAPI_E_INVALID_PARAMETER (0x80070057)

Patrick Creehan — Fri, 10 Jul 2009 16:02:00 GMT

I recently helped a customer with an issue where they were calling ConfigureMsgService and that call was failing, returning an HRESULT of MAPI_E_INVALID_PARAMETER (0x80070057). After debugging it, we established that the reason that ConfigureMsgService was failing was that the PR_PROFILE_HOME_SERVER_ADDRS property was missing from the profile. Outlook seemed to work fine, logons worked, sending mail worked; it was just that ConfigureMsgService would fail. We tried recreating the profile, but still the property wasn’t being set on the profile.

It turns out that PR_PROFILE_HOME_SERVER_ADDRS gets its value from PR_EMS_AB_NETWORK_ADDRESS, which in turn, gets its value from the networkAddress attribute on the server object in Active Directory. That value was set correctly, but permissions to that object were not. After following the requirements laid out on technet for permissions to AD objects, we determined that the Authenticated Users group was missing the ACL for Read All Properties on the server object. Once we set that permission and recreated the profile, the property was set correctly on the profile and ConfigureMsgService started succeeding.

DeleteItem Ignores ChangeKeys

Patrick Creehan — Thu, 09 Jul 2009 00:49:45 GMT

According to our documentation, DeleteItem calls should fail with a ErrorStaleObject error when the ChangeKey is not the most recent one. This, however, is not the case. In Exchange 2007, the ChangeKey is completely ignored in DeleteItem calls. This decision was made on the logic that if you are trying to delete an item, chances are you don’t care if you have the most recent copy or not. But, what if you do?

You could try doing a GetItem, check the ChangeKey and then call DeleteItem right after, but that still leaves a small window of time between your GetItem and your DeleteItem calls where the item may have been changed.

Here’s a workaround which will help you implement the logic yourself using pull notifications.

Do a Subscribe on the folder of the item to subscribe for Pull notifications.
Next, do a GetItem and ensure that you do, in fact, have the most recent copy.
Do your DeleteItem.
Do your GetEvents to check for notifications.
If you get just a MovedEvent, then your item was deleted without having been modified (you get a MovedEvent because the item was moved to the Deleted Items folder). You may get a DeletedEvent depending on which flags you passed to DeleteItem. If you get a ModifiedEvent before your MovedEvent, you can then go retrieve the item from the Deleted Items folder and check the values of the properties from the item there. If you hard deleted the item (and therefore got a DeletedEvent) you cannot go get the latest copy from Deleted Items, because it isn’t there.
Unsubscribe.

OnSyncDelete Delete

Patrick Creehan — Tue, 30 Sep 2008 20:58:09 GMT

The Exchange team is looking for some feedback on business scenarios that will be impacted by removing store sinks from the code. With Exchange 2007 and beyond, the new technology designed to replace store sinks is EWS Notifications and Transport Agents....(read more)

Can’t Get Raw MIME in Transport Event in Exchange 2007 SP1

Patrick Creehan — Wed, 13 Aug 2008 22:02:37 GMT

If you wrote a Transport Agent for Exchange 2007 RTM which was accessing the raw MIME message which doesn’t seem to work after installing SP1, there’s a good reason for that. In SP1, we moved content conversion to after the OnRoutedMessage event. This...(read more)

You Say Toemaytoe I Say Tahmahtah

Patrick Creehan — Wed, 16 Jul 2008 16:23:29 GMT

We’ve seen a bunch of folks asking recently if their Exchange 2007 CAS server can talk to their Exchange 2003 mailbox server. The answer is <gasp> it depends on what you mean.

It depends on what technology you are referring to and what you mean by “talk.” Are you referring to WebDAV calls? Then yes. Are you referring to OWA? Then sorta. Are you referring to Exchange Web Services (EWS), then no. There are really two things at play here: proxy and redirection. That is, can an Exchange 2007 CAS server serve as a proxy for calls to the backend mailbox server, or can it successfully redirect calls to the mailbox server where the call can be handled.

In Exchange 2003, HTTP calls were simply forwarded on from the front-end to the back-end. The back-end server would receive the HTTP request and handle it and then forward the response back up through the front-end. In Exchange 2007, however, the front-end CAS handles the HTTP request and speaks RPC to the back-end server.

When a request is received by a CAS server, it knows how to figure out who should handle the request – whether it needs proxied to a different CAS, or can be sent directly to an Exchange 2003 or 2007 back-end. For example, when a request is received for the /exchange virtual directory on a mailbox on an Exchange 2003 server, the HTTP request is forwarded to the appropriate server. So in this way, OWA still works from your 2007 CAS – even though the client will see the OWA 2003 interface. The same is true for activesync clients requesting the \Microsoft-Server-ActiveSync vdir.

If an Exchange Web Services call hits an Exchange 2007 CAS and the CAS is able to determine that the mailbox is on an Exchange 2003 back-end the call will fail since proxying cannot be performed.

Here’s more on the topic:

Overview of Exchange Server 2007 CAS Proxying and Redirection

Understanding Proxying and Redirection

How does E2k7's API Stack Stack up?

Patrick Creehan — Fri, 20 Jun 2008 22:21:02 GMT

Check this out:

Exchange Server 2007 Legacy API Property Mapping

This helps you compare WebDAV/CDOEX props to EWS properties. Also discussed are CDOEXM and WMI replacements and the look ahead.

MAPI_E_FAILONEPROVIDER (0x8004011d) after installing Windows Server 2003 SP2

Patrick Creehan — Sat, 12 Jan 2008 00:56:00 GMT

Sorry for the duplication, I'm just rebranding an earlier post of mine because many people have never heard of SNP and may discount the post due to the title. If you are getting MAPI errors because of RPC connectivity problems, and you have SP2 installed for Windows Server 2003, this is probably what's affecting you, especially if you have a Broadcom NIC.

http://blogs.msdn.com/pcreehan/archive/2007/10/16/ooh-snp.aspx

Exchange Server 2007 SDK July update is now available

Patrick Creehan — Sat, 28 Jul 2007 06:43:00 GMT

Happy coding!

http://www.microsoft.com/downloads/details.aspx?familyid=7A44A56A-1DFD-4C26-B99A-1E680E914444&displaylang=en

Foreign Connectors aren't just bridges over the Rio Grande

Patrick Creehan — Tue, 29 May 2007 22:42:00 GMT

Matt Stehle had a great post on building foreign connectors, the gateway connectors replacement for Exchange 2007.

Check it out.