Named Properties problems: A workaround

If you are already familiarized with the named property concept on Exchange 2003…well this usually means that you had to deal with all the trouble it may cause. If not, there are a couple of links that might help you in building an understanding of what we are talking about:

https://msexchangeteam.com/archive/2009/04/06/451003.aspx

https://msexchangeteam.com/archive/2009/06/12/451596.aspx

https://technet.microsoft.com/en-us/library/bb851492.aspx

To make a long story short, a named property is the way in which Exchange deals with all those X-headers that exist out there in the Internet and that are appended on a message by almost every application that may touch the mail (anti-spam, anti-virus, Outlook add-ons)

The need for creating these named properties derived from the following clear fact: Exchange talks MAPI, but out there, in the Internet, RFC822 is the standard for message creation and delivery. Thus, once an Internet mail reaches an Exchange organization boundary, a conversion process must take place: it’s during this conversion process that we transform rfc822 headers into MAPI properties and, of course, vice-versa.

So far so good but here comes the problem: there is only so much named properties that can be created for each database, and sooner or later, we will hit that upper limit. Once the limit is reached, all sorts of problem will start to happen; the most common scenario is the following: users hosted on the database confronted with named properties exhaustion will not be able to receive mails. The store will throw a NDR for each mail destined to a user on that database, because he will not be able to convert the message headers into MAPI properties (i.e "The message reached the recipient's e-mail system, but delivery was refused. Attempt to resend the message. If it still fails, contact your system administrator. <servername.domain.com #5.2.1>"). This will happen for both internal and external generated messages, because Outlook is also a great consumer of named properties and he will also suffer from the lack of available named properties.

The hard limit for named properties is set at 32,766 entries and recovering from hitting it is a pain: basically you will have to move out all the users from that database , scratch it and then move back the users onto this new ‘’blank ’’ database. (More info on this process: https://technet.microsoft.com/en-us/library/bb851495.aspx )

 Now what we would like to achieve is to find a way that will allow us to avoid such a troublesome scenario….and luckily we did. It’s actually quite simple:

The idea is to install an Exchange 2003 bridgehead server into your organization because in this way we can move the message conversion process from the server that hosts the mailbox onto the bridgehead. The bridgehead will be the first server in the Exchange organization that will deal with RFC822 headers and the conversion of these headers into named properties will take place here instead of the mailbox server. In this way, once we will ran into named properties issues, we will have to deal with those on the databases hosted on the bridgehead server and not on those on the mailbox server. So instead of having to scratch a database with users, we will scratch instead a database on the bridgehead server that hosts no users.

 It’s safer, cleaner and less time consuming.

Enjoy.