Wiz/dumb : Exchange

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>

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.

TNEF (Chapter 2): Old School

Patrick Creehan — Wed, 28 Jan 2009 02:09:40 GMT

As discussed in Chapter 1 of this captivating series, MAPI contains an interface to allow developers to create and read TNEF data. This interface is the ITnef interface. There are only a few methods in this interface and they are, for the most part, self explanatory. The entire process of creating a TNEF stream can be done in just a few steps:

Call OpenTnefStreamEx to get a TNEF stream to write into.

Make sure you pass in TNEF_ENCODE since you’ll be creating TNEF. If you were reading TNEF, you’d pass in TNEF_DECODE instead. The other flags to worry about here are TNEF_BEST_DATA, TNEF_COMPATIBILITY, and TNEF_PURE. All of these just signal to MAPI how you want the properties you add to the TNEF stream treated. They will either be all converted to the old-school attributes (TNEF_COMPATIBILITY) – you shouldn’t use this one; some will be converted to attributes but also written to the attMAPIProps section (TNEF_BEST_DATA); or they will all just be written to the MAPI props and none of them written to the attributes (TNEF_PURE).
Call EncodeRecips and pass in the Recipient table you get from a call to IMessage::GetRecipientTable on your message.
Call AddProps passing in an SPropTagArray of non-transmittable prop tags and use the TNEF_PROP_EXCLUDE flag.

There are essentially two schools of thought for building your TNEF: exclude the props you don’t want and let MAPI deal with the rest; or choose carefully which props you do want to include and add them each piecemeal. These are the reason for having the TNEF_PROP_EXCLUDE and TNEF_PROP_INCLUDE flags. One of them says here are the properties I don’t want you to encode (TNEF_PROP_EXCLUDE) and the other, TNEF_PROP_INCLUDE, says I want you to include all of these properties.

There’s another method, SetProps, which does just that, sets the value of a property in the TNEF stream to a value you supply. This allows you to modify the data of the message you are trying to encode, or add additional properties that weren’t on the original.

Back to AddProps for a moment. The flags that supports don’t stop with TNEF_PROP_INCLUDE and TNEF_PROP_EXCLUDE, There is also TNEF_PROP_ATTACHMENTS_ONLY which says “of the properties I’ve given you to work with, I only want you to include/exclude the ones that have to do with attachments. Contrast that with TNEF_PROP_MESSAGE_ONLY which says "”of the properties I’ve given you to work with, I only want you to include/exclude the ones that have to do with the message itself – not attachments.” Then there’s the CONTAINED flags: TNEF_PROP_CONTAINED and TNEF_PROP_CONTAINED_TNEF. TNEF_PROP_CONTAINED means that these properties are going on an attachment; and the TNEF_PROP_CONTAINED_TNEF means I have TNEF data I’m going to give you to put in an attachment – like if you already had a TNEF blob you wanted to include as an attachment, which I’ll demonstrate below.
Once you get all your properties added and included/excluded properly, you call Finish and you’re done. One thing that makes it a little complicated though, is that you have to keep alive all the pointers and streams, etc you’re using in your TNEF until Finish is called, because that’s when all the internal work is actually done. So when you call Finish, that’s when MAPI says, Oh, ok, let me go get that recipient table you gave me. If you’ve already released it, then the process fails.

So it’s pretty easy to do this. This is essentially the way that MFCMAPI demonstrates how to do it (look in File.cpp under SaveToTNEF). There are problems associated with doing it this way when it comes to Unicode properties and when having multiple embedded messages.

The more complicated way to do this to work around some of the issues described above is to add the properties you want explicitly, including each attachment.

The basic difference in the strategy is that instead of calling AddProps with TNEF_PROP_EXCLUDE, call it with TNEF_PROP_INCLUDE and give it the SPropTagArray you get from a call to GetPropList on the message. You’ll need to filter out the non-transmittable properties (such as custom props and things like the Store EntryID). Once you add all the message props, call GetAttachmentTable and loop through each attachment and do one of two things, if it’s not an embedded message, just add the attachment data with AddProps on PR_ATTACH_DATA_BIN; otherwise, you’re going to recurse over yourself and build a TNEF stream from the embedded message. When you call Finish on it, then you’ll add it to the parent TNEF stream by calling AddProps with PR_ATTACH_DATA_OBJ and using the TNEF_PROP_CONTAINED_TNEF flag and give it the stream for your TNEF blob. Once you unwind all the way, you’ll have your “master” TNEF stream. Essentially, you’ll follow the steps here: http://msdn.microsoft.com/en-us/library/cc839833.aspx

TNEF (Chapter 1): Basics

Patrick Creehan — Fri, 16 Jan 2009 19:17:36 GMT

I’ve worked quite a few cases recently regarding problems some folks have had either reading or composing TNEF content. I’ve learned quite a bit myself as a result, and I thought I’d share. I decided I would do a series of blog posts on the topic and hopefully save some of you the time I spent learning all this.

So, being the first post on the topic, I suppose now would be a good time for a review on just what TNEF is and how it’s structured.

TNEF stands for Transport-Neutral Encapsulation Format. If you use Outlook or any other MAPI client as your mail client, you may know that MAPI is a protocol for communication between the client and the mailbox server. MAPI defines a set of interfaces which the client can use to work with the data in the mailbox. The MAPI structure for the data is hierarchical with messages being contained in containers, which themselves can have a parent container, all the way up to the root of the store. MAPI also defines a set of properties understood by the client and, in some cases, the server. If all mail sent could stay on this one server and only go between clients on this one system, this would be all we need; but we know that’s not the case. A very large quantity of e-mail is sent over the internet to foreign systems every day. The vast majority of those use an industry-standard protocol called SMTP (Simple Mail Transfer Protocol) to send messages in an industry-standard format called MIME (Multipurpose Internet Mail Extensions). MIME is composed of body parts, which can in turn be composed of additional body parts themselves. MIME also allows you to add headers to each of the body parts which allow you to describe the content of that body part. So one body part may be a Word Document attachment, so the MIME headers on that body part would contain the MIME type such as application/doc and the transfer type, such as base64. The content of that body part would then contain a base64 encoding of the document. The headers for the root body part contain information such as the subject of the message, the sender and recipient information, etc.

As a message makes its way through transport from one person’s email client to another person’s, it encounters many “hops” (brief stops at SMTP servers in the routing path) which have the opportunity to modify the headers. They do this in order to track the path the message took or to flag it as SPAM, verify the sender address, etc. So there’s a chance the headers you specify when you send the message won’t be the same as when the message arrives at the destination. The headers also only support text values. One of the problems discovered early on about the MIME format was that it has no concept of “rich text.”

In early versions of Outlook, users wanted the ability to send and receive email that contained rich text bodies. Microsoft devised a plan to create an attachment to the messages it was sending that would have a certain content-type and would come to have a well-known name, “winmail.dat”. This attachment would contain an encapsulation of the MAPI properties that could represent this rich body that would work across any transport and be readable by any system that supported MIME.

The original structure just supported a very simple structure that was basically Name/size/value. These were called “attributes” and the names of these attributes are still prefixed by “att.” Many of the attribute names can be seen here: http://msdn.microsoft.com/en-us/library/cc765736.aspx. The most important of these attributes for the purposes of our discussion will be the attMAPIProps. This attribute contains a list of MAPI properties that the receiving system can set on the message once it has converted the other MIME parts into their MAPI format. Some of the TNEF attributes can be directly translated into MAPI properties as defined by the link earlier in this paragraph, but there is not a 1-1 mapping between TNEF attributes and MAPI properties – hence the attMAPIProps attribute. Attachments and recipient data can also be encoded into the TNEF structure, which we’ll examine more later.

MSDN documents the general structure of TNEF but it’s hard to understand. Last year, when Exchange decided to be among those systems that elected to publicly document their protocols, they created [MS-OXTNEF].pdf, which documents very clearly the structure of the TNEF data and how to parse it. Don’t get too nervous, though. I have parsed a 3MB TNEF blob manually myself, but in Exchange 2007, we provide managed code interfaces to allow you to read (or write) this data very easily. In subsequent posts, I’ll dive more into the structure and into the managed classes, as well as the legacy MAPI ITnef interfaces, and more into problems you may experience in developing TNEF-enabled applications.

MAPI Docs Moved

Patrick Creehan — Thu, 04 Dec 2008 18:34:00 GMT

So, the Exchange team decided they didn't want to maintain the MAPI documentation anymore since they don't ship MAPI anymore. So the Outlook team stepped up and took over the docs. As such, you can now find them under the Outlook branch in the MSDN left-nav.

http://msdn.microsoft.com/en-us/library/cc765775.aspx

Steve Griffin has been working with the Outlook team on prettying them up and updating them for a few months, and they're now better than ever! He even got a new icon for MFCMAPI out of the deal!

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)

Forwarding Appointments in Outlook Prepopulates “To” Field With All Attendees

Patrick Creehan — Fri, 19 Sep 2008 20:38:00 GMT

We’ve had a lot of folks calling in recently about this one. The symptoms are that if you go to your calendar in Outlook and forward a meeting, the To field is prepopulated with all attendees of the meeting and the Subject field is not prefixed with “FW:.”...(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

Outlook Requests Can't Get a Date

Patrick Creehan — Wed, 23 Apr 2008 21:52:00 GMT

There exists a scenario in which attendees to a meeting in Outlook will receive an updated meeting request from the originator that appears to be "out-of-date." In the InfoBar, Outlook will display a message that says "This request is out-of-date." If the attendee attempts to accept the meeting request, they get an error dialog box. Now, this is expected if there was an update that was made but a later update was already made - that's sort of what that functionality in Outlook was designed for. However, in this scenario, you see a new meeting request and very shortly after you get an update to the same meeting. It's clear that the update didn't come before the original request, so how can it be out-of-date?

This scenario exists where an appointment is modified by an application using CDO 1.21. In order to get the problematic behavior, the machine running the CDO 1.21 code has to have the clock set to a time earlier than the client machine. If CDO 1.21 modifies the appointment and sends updates within the time delta between the two machines, the update will appear to Outlook to be earlier than the original request.

Imagine the scenario:

CLIENT_MACHINE_1 and CLIENT_MACHINE_2 have a current system time of 3:00 PM.

CDO121_MACHINE has a current system time of 2:57 PM.

3:00 PM	User1 on CLIENT_MACHINE_1 sends a meeting request to User2 on CLIENT_MACHINE_2.
3:01 PM	User2 accepts the meeting request and the appointment is added to User2's calendar.
3:02 PM	CDO 1.21 code runs on CDO121_MACHINE server and modifies the appointment on User1's calendar and sends the meeting request update (stamped 2:59 PM which is the current system time on CDO121_MACHINE) .
3:03 PM	User2 receives the updated meeting request and Outlook displays the update as being out-of-date.

The problem boils down to a difference in meeting update behavior between Outlook and CDO 1.21. There's a sequence number property on meeting requests that Outlook increments each time an update is made to a meeting. Outlook examines this sequence number first when deciding which update is newest - this code was put in place for scenarios like this primarily for pop3 clients, which only use sequence number. The timestamp is used as a secondary factor in deciding which is newer. CDO 1.21 wasn't designed with some of these modern calendaring scenarios in mind and doesn't (and won't ) support incrementing the sequence number - it's simply copied over as are most props.

So...if everyone just synchronizes their clocks to the same time server often enough, we'll all be happy :).

If you have CDO 1.21 code which causes this to occur to some of your clients, here are a few ideas that you can try:

in your processing, don't process meetings that have the timestamp later than the current system time on the machine your code is running on.
Push for your customer to keep machine times in their environments synchronized. This should at least minimize the impact. Clearly this won't account for scenarios where users are using home computers over a VPN or RPC/HTTP connection or using mobile devices that may have clocks synchronized to a different source.

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

Ooh, SNP

Patrick Creehan — Tue, 16 Oct 2007 23:46:00 GMT

We've recently been seeing an elevated number of cases where networking issues are adversely affecting performance and causing other problems with messaging technologies. The common thread in many of them is that the problem only started to occur after Windows Server 2003 SP2 was installed. I recently learned that we shipped a new feature in SP2 and turned it on by default. This new feature is called Scalable Networking Pack, or SNP. It was actually originally shipped as a download for SP1, but was included in SP2 by default.

The Exchange team has posted an article on how SNP affects Exchange and also gives a good list of links and troubleshooting steps.

SNP was built to increase performance on the networking stack, and does for newer network adapters that support it. However, for older network adapters, it can cause significant delays which cause timeout problems and connection problems leading to various problems.

The basic troubleshooting steps at this point are

Read the Exchange team's post linked above and pages they reference so you understand the issue
Install the hotfix at http://support.microsoft.com/kb/936594
Upgrade your network adapter drivers to the most recent version
Disable the SNP features by setting the following registry keys:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

EnableTCPChimney=dword:00000000

EnableTCPA=dword:00000000

EnableRSS=dword:00000000

UPDATE:

I've just had another case where SNP was the culprit. The customer had clustered Exchange 2003 boxes with recently applied SP2. They were using backup software which was using CDOEXM to get information about the environment. These calls were failing with 0x8000FFFF (E_UNEXPECTED) but after debugging we saw that RPC was getting RPC_S_SERVER_UNAVAILABLE (1722 0x6ba) errors. This prompted me to ask about SNP. Disabling SNP via the steps above resolved the issue.

UPDATE (1-8-07):

Yet again, another customer with clustered Exchange 2007 boxes. They had a MAPI application which was unable to OpenMsgStore on mailboxes that had migrated from Exchange 2003 (MAPI_E_FAILONEPROVIDER). Debugging the process I could see RPC_S_SERVER_UNAVAILABLE errors. Sure enough, they had SP2 installed. Disabling SNP resolved the issue. The reason nonmigrated mailboxes worked was that MAPI was just guessing the ServerDN since resolving against the DS didn't work. If the mailbox had never been migrated, this guess ended up being correct; for migrated mailboxes, it was wrong and the failure bubbled up.

ARGH: Large WebDAV PROPPATCH requests fail with 401/401.5

Patrick Creehan — Tue, 17 Jul 2007 19:09:00 GMT

I had a case recently where one of our products, Duet, was doing a large PROPPATCH against Exchange 2003 and it was failing with a HTTP 401 error. The customer noticed that small PROPPATCH requests succeeded, but large ones (bigger than say 25 KB) would fail. Well, we knew that it couldn't be a permission problem, because small ones succeeded, right?

After more digging around and more test scripts, we discovered that large PUT requests worked just fine and that the large PROPPATCH would work for Exchange Admins. The clues are starting to come together. I was immediately reminded of a known issue with CDOSys where large attachments are first cached to the TEMP directory before being sent via transport . If the user executing the code does not have permissions to the temp directory, they get an 80004005 Access Denied when they try to Send the message. Could we be doing something similar with WebDAV, writing the request to the disk first for large requests?

Sure enough, a FileMon indicated that we would receive an ACCESS DENIED when trying to create a file in the C:\WinNT\Temp directory called something like $ETn.tmp, where n is an integer that increments.

In my test environment, where I had previously been unable to reproduce the customer's problem, granted Authenticated Users the ability to Create Files, Write, and Read from this directory. By adding an explicit Deny ACE to this folder for my test user, I was finally able to reproduce his behavior exactly.

If your Exchange or IT Admins have locked down your server by modifying or removing this ACE, try giving your test user Modify permissions on the C:\WinNT\Temp directory and see if you don't get a better result.

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.