Category Archives: Exchange 2003

#5.2.1 when sending emails from Exchange 2010 to Exchange 2003

You will find a lot of posts related to this issue. I read a bunch of them on internet too. What interested me more is a cause behind this problem. Although this problem is very generic and doesn’t occur in every organization after upgrading to Exchange 2010 there are many people I see who reported the same problem in various forums. In all cases I saw on internet, users on a specific store experienced this problem.

Typical symptoms are:

A user with mailbox on an Exchange 2010 store sends an email to another user with mailbox on Exchange 2003 store and receives an unexpected NDR even though the recipient user account exists and the message is well within configured size limits.

Delivery has failed to these recipients or groups:
Naphade, Milind
There’s a problem with the recipient’s mailbox. Please try resending this message. If the problem continues, please contact your helpdesk.
Diagnostic information for administrators:
Generating server:
#< #5.2.1> #SMTP#

You also see the application log full of Event IDs 9666, 9667

Microsoft Exchange SMTP 5.2.1 is generated when the message is too big or the recipient is missing SID on it. This can not be a cause for sure because the same recipient can receive other emails without any problem. So, I decided to drill down a little more  and figure out what happens when these NDRs are generated by Exchange 2003.

Event IDs 9666 and 9667 are logged to indicate that the exceeded named properties quota in a particular information store database. Above mentioned NDR is very closely related to the event IDs 9666 and 9667. Microsoft Exchange team has a very good post on their blog explaining the named properties (so called named props). I strongly recommend you reading it first here –> Confused About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!

So, here is what happens when an email sent from Exchange 2010 to a recipient on an Exchange 2003 information store:

According the post linked above, Microsoft Exchange Server 2003 allows 16,384 named props creation for authenticated users by default however, insertion of new named props is stopped once the rows in the table exceed the number 16,384 for authenticated users and 8,192 for non-authenticated users. Unless the row limit is hit the server will continue accepting creation of new named props in the named props table. These named props are typically created by an application that connects to the exchange information store using MAPI. This can be an enterprise application which can read/write into database using MAPI connection or an outlook plug-in which uses exchange information store database for reading or writing information in mailbox. Also, custom properties/headers attached to the emails coming from internet are also inserted into the named props table. For example: if you have a spam filtering mechanism that stamps an additional header called x-spamScore-linux in the inbound message, this header is automatically added in named props table by Microsoft Exchange information store service. This is definitely required to display the message and its properties in outlook correctly. This behavior causes the named properties table to fill with new named properties.

Coming back to the original topic of NDRs: for an instance just imagine a scenario where you exchange 2003 store database named props quota has reached and there is no room in the table to add new named props and a user from Exchange 2010 using outlook 2010 sends an email to another user on the exchange 2003 store. As described earlier named props table reached to the maximum limit will not be able to add new named props attached with the message coming from Exchange 2010 server and hence store will generate an intermittent NDR.

Are you saying this happens to every message sent from Exchange 2010? Answer is NO. It does not happen to every message. This would happen only if the message contains additional named properties attached to it which are absent in the Exchange 2003 information store named props table and need insertion in the table. In most of the cases a plain text email sent using Outlook would get delivered but an HTML email or a meeting request may bounce back to the sender.

How should I fix it? Microsoft already has an official support article that talks about the named props limit handling which is linked in the above linked article from MS Exchange Team. Following that article would be enough.

At the end, I tried explaining the stuff to the best of my understanding. If you think that this post could have some more detailed information please do feel free to comment or write to me directly using the contact form. I will update the post accordingly.

The client operation failed. Error is [0x80004005-0x0004b9-0x000501]

Our server engineering team was investigating an issue on a bounce back a user got and the whole team spent a lot of time researching on below message.

From: System Administrator
Sent: Tuesday, April 20, 2010 4:53 PM
Cc: Recipient Name
Subject: Undeliverable: Trainings

Your message did not reach some or all of the intended recipients.

Subject: RE: Trainings

Sent: 4/20/2010 4:45 PM

The following recipient(s) cannot be reached:

Recipient on 4/20/2010 4:53 PM

This message could not be sent. Try sending the message again later, or contact your network administrator. The client operation failed. Error is [0x80004005-0x0004b9-0x000501].

At the first glance it seems like a problem with permissions on recipient mailbox. However,the error "0x80004005-0x0004b9-0x000501" comes from trying to submit a message on the Exchange transport. The code 0x0004b9 is an ecNullObject from Store, indicating that the failure occurred because an object referenced was null. This implies that this user was having some intermittent networking issue that happened to hit at the time the message was submitted.

This behavior is by design and the error is expected when network failures occur. If your computer is connected via wireless or a WAN link, then random failures on the network can be common, and that would explain the behavior. Even on a local area network, RPC failures are not uncommon.

In general, this problem is likely caused by intermittent network connectivity issues, or possibly out-of-resource problem on the client machine.

I suggest getting back to the user and requesting them to re-submit the message if similar kind of problem occurs in future as well.

Week Numbers 1 week ahead in Outlook

Today when I came in office I saw an email from my boss. He was asked by one the bussiness heads that why the week numbers in outlook would show one week ahead?

Here is a little background about the week numbers:

Week number according to the ISO-8601 standard, weeks starting on Monday. The first week of the year is the week that contains that year’s first Thursday. The highest week number in a year is either 52 or 53 and outlook is fully compliant to this specification.

Normally, when we configure the outlook profile we do not pay much attention to a very small calendar setting which actually manages all this week number related stuff. Its pretty simple to configure. In common situations the calendar is configured to use the 1 Jan of the year as the first week of the year. Which results in this mismatch of outlook calendar numbering.

 To correct it you can simply go to 

Tools –> Options –> Calendar Options –>