Named Properties, X-Headers, and You

Published Apr 06 2009 01:44 PM 27.4K Views

EDIT 8/10/2010: Please note that this blog post covers namely the history of named properties in Exchange. For updated and current guidance of how to deal with named properties issues, please see this blog post.

Coming soon to a roll up near you is a set of changes to the way that Exchange Server handles x-headers and named properties, specifically named properties that represent x-headers. This represents a change in behavior that has been this way for nearly a decade, so it bears explanation of the old way, the new way, and how it will impact (or not) you. First though, for those new to the table I offer a history of named properties.

Property Archeology

In the beginning was MAPI. Ok, maybe the earth cooled first, and then the dinosaurs came, but you can bet that one of the first problems the dinosaurs faced was a proliferation of ways to communicate, and the need for a common API to "glue" a disparate set of transports together. For Microsoft, that glue API was called MAPI, or "Messaging API". MAPI represents almost everything as a "Property". And how do you know what properties are what? Property Identifiers, or PropIds, for the typing phobic. Property identifiers were a set of numeric values ranging from 1 to the nearly unreachable 0xFFFF. Amazing, really. This vast 64k landscape represented a nearly unlimited area for all the properties a man could ever want. Somewhere, I'm sure Bill Gates reviewed it and said "64k worth of properties ought to be enough for anyone." And all was well.

Now the early architects of MAPI saw fit to divide up the properties into ranges, each range a vast area of properties wherein we could arrange values by logical groups. For instance, we had a range of properties called "Transmittable", meaning that Exchange would pack them up and send them with a message. Another range called "Internal," meaning "You don't set these, we do." We had a range called "Non transmittable," meaning non infectious - the properties simply wouldn't hit the wire when we bundled up a message to send it out into the world.

Name that Property

And right at the middle of the range we drew the biggest line of them all. Properties below 0x8000, those would be fixed properties, for us to assign on the server and apply at will. We thought (and hoped) that other people would want to use MAPI as well. And we didn't want to be in the "Property Assigning Business." Imagine if every time an independent developer wanted to get a MAPI property for his application to use, he had to go through Microsoft? Never mind. Don't imagine that. It's too scary. The nice thing is, they didn't have to. Through the magic of Named Properties, we would create a mechanism by which developers could ask the server to reserve a PropId for their use when deployed. And all was well.

Now named properties came in two major flavors: Properties whose names were actually numbers (like the ones Outlook uses), which are nice when you have a list of them #defined in a source file somewhere, and properties whose names are, well, names. These types are called "String Named Properties", because their names are strings (Logical, is it not?). In addition each named property had a guid associated with it, allowing developers to divide their named properties into "Property Sets", kind of like Monopoly, except that no one would ever land on your space, no matter how many hotels you built unless you gave them your guid and property names. To start people out we even created some nice "starter" namespaces, with enticing names like "PS_PUBLIC_STRINGS." Most people avoided PS_PUBLIC_STRINGS like it was a housing project and rolled their own guids.

Then Came the Internet

MAPI, as you may recall from above (and if you do not, please seek medical attention now), stored everything as property sets. Messages sent on the internet are sent in a format called message/rfc822, a text format designed to be both flexible and nearly impossible to create a canonical parser for. Rfc822 messages are plain text with a set of key and value pairs in their headers. Of course, the people who contributed to rfc822 made a fundamental flaw, and that was thinking that the people interpreting their document would be rational. If an acceptable range of values for a header was "1, 2, or 3," it never occurred to the authors to include lengthy paragraphs explaining that 1, 2, or 3 were good values. 4 was not be included as a value, nor was it only to include 2, unless it also supported three. Five was right out. Now the rfc822 included support for a set of properties called x-headers (for eXperimental, or eXtended). So now we needed a way to communicate between MAPI and rfc822. And we called it Imail. Imail took the key value pairs in headers and translated them (where possible) to MAPI properties. THAT process is the substance of an article I have no desire to write, but keep in mind that Imail converts headers to properties (and vice versa).

The road to Hell

When Exchange 2000 (may it rest in peace) came onto the scene, we rewrote large portions of Imail (a process we would repeat for Exchange 2007). Part of the rewriting included the addition of what were called "Ad-hoc" headers. In other words, headers we would preserve because we thought at some point they might be useful (or just so we could emit them when we vomited forth the message for internet clients). X-headers fell into the bucket of ad-hoc headers, values we would preserve in case someone needed them. As you hopefully recall (because I just covered it, again, see the doctor if not) MAPI properties are identified by "IDs" and X-headers, these could be created by any moron with a text editor. If he added "x-williamrobert:yeeeeeehaaaaaaw" to his message, we'd preserve it. Now, we couldn't possible know the value of every x-header to ever be created (or else I would have immediately done a GetProps() on PR_TOMORROWS_LOTTO_NUMBERS), we used named properties to represent these X-headers. Specifically, we used String Names for the Named properties, because, well, we had the name of the x-header, and as you may have noticed it is a string. So, if an inbound message contained X-headers, we would create named properties to represent those values and store them on the message. In fact we published another "Starter Namespace", PS_INTERNET_HEADERS. The astute among you may immediately derive that properties in this namespace were internet headers. Those of you who could not derive this, leave now, no questions will be asked of you. Even "better", MAPI applications could actually emit X-headers should a message ever be condemned to the internet by setting a tring named property in the PS_INTERNET_HEADERS namespace.


X-headers, as covered before, are a (seemingly random) set of characters that theoretically represent valuable data. Named properties are a method to reserve an ID for a given piece of data. Named properties fall into the range of 0x8000 and up. So there is a definite "upper bound" to the number of named properties that can ever exist on a MDB. Once a named property is allocated, it's gone for good, forever reserved to that name and guid combination. Through the years people have often asked why we can't recover them. The answer is that it's technically possible. If the database were dismounted one could crawl every message, making a list of every property, every guid and every id. One could then combine the list of allocated named properties and determine which ones cannot be in use. In practice this is nearly impossible if you ever want the mail store to be available again.

One of the biggest consumers of named properties is Outlook (who have a nigh endless array of properties and names for them neatly arranged). Should Outlook be unable to map a named property, bad things happen. So we created a quota system by which the STORE process would begin warning you when named property exhaustion was fast approaching. And at a second threshold it would refuse to give out new named property IDs. And we clamped down the number of x-headers we would allow any message to create. Of course, we still allowed some to be created, and that means that "bad things will happen." On a survey I did of real production databases at Microsoft, I was amazed at the sheer amount of crap that was being stored in x-headers. Specifically, we have at least one mailer out there that adds x-<today'sdateandtime>:True to every message. In the world of the internet, where anyone and his dog can create x-headers, allowing an unrecoverable resource to be consumed by anonymous submissions is not acceptable.

Changes Coming

So this is changing. If you like it, good, it's changing. If you don't like it, sorry, it's changing. If it enrages you, seek counseling, and it's still changing. We are putting the clamp down on x-header promotion and putting it hard. When we say that what it actually means is that we are changing the way that new x-headers are promoted. X-headers in E12 are database wide, meaning that if user A maps a named property on a database, user B on that database will get the same ID for the same name and guid combination. If a named property for a give X-header already has been promoted on a database, i.e. we've already created a mapping from x-williamrobert to 0x803f, we will continue to preserve the data for x-williamrobert, and we'll do it in the property with the id 0x803f. If a message comes in with x-billybob, and that header has never been promoted on the database before, the new rules take effect. The new rules control who gets to consume named properties to store x-header values. When the new promotion rules go into effect, many scenarios that once created new named properties to preserve X-header data will not:

Anonymous submissions: Sorry, anonymous mail sender from the internet. I do not know you and you do not get to consume precious resources on my server. If I've already saved off a named property for x-somerandomheader then I don't mind preserving the data, but if not, the value of x-somerandomheader will not be saved as a property on the message.

Embedded messages: This feature was created as an interop feature for MAPI applications to be able to set envelope or top level properties. Embedded messages with your six hundred voice over ip x-headers, no new named properties for you.

Journal Messages: This one will likely prove controversial but journal messages represent the biggest concentration of x-header consumption that is possible. Consider if you have 100 databases in your organization (really 101). Each MDB is exposed to 100 new x-headers from the internet per week. The journal mdb will be subject to 100x100 new x-headers a month. It will go through them faster than my son does a bag of microwave popcorn. Journal messages will not promote new x-header mappings. Journal content - that still gets journaled. Journal reports, yep, still saved. Your messages? Still in the journal mailbox. X-headers being mapped to named properties where they did not exist before: No.

So who gets to do this?

Well, obviously this doesn't remove the ability to map x-headers entirely. That's not a bad idea, but it isn't the case at the moment. Authenticated users can still create messages whose x-headers will be promoted. MAPI applications can also create named properties (and should those lie in the PS_INTERNET_HEADERS namespace, those would be x-headers). EWS applications using property mappings can create named properties which might be x-headers. Remember - once one person maps the named property on a database, the property will then be preserved for any inbound message. What we are controlling is who gets to decide to consume the named property.

If you have an application that consumes x-headers from MAPI, be not afraid, for I bring you tidings of "your application will still work." If you wrote your application correctly then it already asks for the ids of the named property combinations (PS_INTERNET_HEADERS and "x-whateverstringitisyouareafter"). And if you are using the MAPI_CREATE flag on that request, your application will automatically add the x-header to the list of x-headers to preserve on a database. Similarly, if your application was setting an x-header from MAPI by creating a named property mapping in the PS_INTERNET_HEADERS namespace, then you are already creating a mapping for that X-header, and it will be preserved inbound (and emitted outbound).

If your application does not use MAPI_CREATE when asking for named property ids, and you are asking for names that fall in PS_INTERNET_HEADERS, and it is not a property that any well written client would already have asked for, your application will break. At least until the first authorized (or MAPI) client asks for that x-header by name. Then it works.


This is the sort of change we hate to produce in mid product cycle. It's the kind of change people hate to hear about, even if it won't affect them one whit. It's the kind of change that leads to phantom support calls as "Well, my application relies on property x-contoso, and I can't be bothered to map it. I swear it wasn't here before, and now it is." For Exchange 14 we are making further changes in this same area. We're moving the named property resources to be at a mailbox level, not a server level, and including this change as part of the product baseline.

Jason Nelson

Not applicable
Will Event ID 9667 for MSExchangeIS be suppressed now that the journal does not promote new x-header creation?  How will this fix current 9667 events?
Not applicable
Will there be an easy way that we can take an existing list of headers we want to pre-promote into mailbox databases?
Not applicable
Thank you.  This is a much needed and appreciated fix.  If we increased the quota from the default using the registry key "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeIS<Server Name><Database Type-GUID>Named Props Quota" will we be able to revert this to default?  If I understand this post correctly we won't be able to revert to the default because this rollup only prevents additional anonymous x-headers from being created.

Also if we are using the HeaderFilterAgent ( to remove anonymous x-headers we will still need to use it or do I understand this correctly that the rollup negate the need for it?
Not applicable
This is a much welcomed change. I know I have run into this problem twice on our Journal database since going production on Ex2007 last fall.
Not applicable
Would there be anyway to enhance the HeaderFilterAgent. Currently it will ONLY strip headers that begin with "x-". I have enabled it in our environment, and it does help, but I still see new (PS_INTERNET_HEADERS) named properties being created that begin with other lettersnumbers or random words, which also consume the quota?
Not applicable
A gratefully needed small step forward.  These ridiculous inbuilt limits are incredible for an enterprise class messaging system.

There are still many others that make a sysadmin despair and lose confidence in the system.  The current advice of moving users and recreating databases might be fine in small organizations, but makes me think that the system isn't 'fit for purpose' when dealing with millions of messages and tens of thousands of mailboxes.  Whoever decided upon that should be castigated.

Why not a recycling of the named properties table?  When the quota is breached.  Replace the oldest.  I appreciate a wholesale review of MAPI and it's antiquated limits would prove difficult.

Keep trying to alleviate the other ridiculous inbuilt limitations, rather than inappropriate "deal with it" advice.  Well done.
Not applicable
Blacktoe - No.  Nothing removes existing properties.

Devin - Not at the moment.  I'm well aware of the issues regarding property promotion and control and a user defined preregistration list is something we are examining

Peter - No, nothing removes existing properties and so you cannot revert the change.  The header filter agent should be largely unecessary.

LarryH - Bill Long owns the header filter agent, I can't speak for how he would/would not want to modify it.

Johnny - the answer to why we don't recycle involves more background teaching on the named property assignment method than I can dole out in a post.  Rollover would be 100% disaster.  No need to trust me on this, confirm this for yourself:  Use MFCMAPI and open a brand new database.  Of the 1400 and some change props preregistered, I'll bet most of them you'd preferr not be corrupted by assigning them out again.

As for build in limitations, I stand by my tenants for dealing with system limits:
A system administrator can run a healthy, available system even in the face of system limitations given three basic things - First, an understanding that the limitation exists and what it is.  Secondly, appropriate tools for monitoring the system's use in regards to the limit.  Lastly, an administrator needs the ability to control and limit (or expand) his exposure to the limiting event.  

We're providing the first and third.  As for monitoring...that you will have to wait for.
Not applicable
Is there any reason why the properties couldn't be at a per-message (or equivalent) level? Perhaps not as efficient, but if you're going to redesign it, why not allow 32K props per message?
Not applicable
We ran into this problem and started using the HeaderFilterAgent from Codeplex as well.

We are going to be installing Rollup 7 for SP1 this weekend and was going to implement an increase in the quota limit on all 20 of our databases.  If this is going to be included in a rollup pretty soon, we may wait on that.

I am waiting to see some reponses back from the MSEXchange team to my comments, and some of the ones above to see what they suggest we do if we currently are getting errors about not being able to add X-Header information in our event logs.

Do you suggest we still use the HeaderFilterAgent until the Rollup comes out, and will it be needed after this rollup?  If we increase the quota now, can revert back to the default after the rollup, or will that value not even really be needed anymore?

Other people that have blogged on the issue:

I was really hoping a solution for this would come out, but I just have some more questions, so I hope the team has time to respond.
Not applicable
Are you going to fix Exchange 2003 too?

And what timescale are we talking about for the fix to Exchange 2007?

Not applicable
We have a mail gateway server capable of removing x-headers from mail bound for our Exchange 2003 server.  Anyone got a list of x-headers we should not remove from incoming mail?  What x-headers are normally used by Outlook 2003?  Thanks.
Not applicable
As someone new to the exchange scene from a background in *nix i am astonished by this.  I understand that you are having to deal with a legacy design, but the whole tone of the article seems to imply that data in the x-headers are useless unless you've seen one before in a previous version of exchange or an authorised mapi application has requested one.  
x-headers are very useful sources of information about the message and it's history.
Even if you don't expose the x-header data via PropIDs then at the very least keep it so that if an email is forwarded out of exchange via smtp these headers could be reattached.  
Or why not store all the unknown x-headers in a text field that is always attached to PropID 0xFFFF?
Perhaps I'm naive and simply dont understand some of the concepts - entirely possible.  But it seems to me that just losing that data is not acceptable.
Not applicable
Phil - Nothing for E2k3 at this time.  The fix is in RU8 (so roughly May).

Glen - the headers listed in Bill Long's transport agent (linked above) are a pretty good start.

Tim - I'm pleased to say that all headers are in fact preserved in a property (PR_TRANSPORT_HEADERS) for consumption as applications desire.  It has been this way since 5.0 and is still so - even if we don't promote a prop it is still in that blob, ready for your parsing pleasure.  As for re-emission to Mime, that is the subject of another post, another day, because the matrix of what outputs what is..involved.
Not applicable
I'm a big fan of keeping MIME-messages bit for bit like they are. I still use Ex2k3 and I love the STM-database which was removed.

I think that Exchange must be able to give out an mime mail the same way it was stored in it. e.g. if I do a IMAP append I want to get that mail back. Of course:
- With ALL x-headers
- With the same mime boundaries
- With the same amount of characters in base64 encoded attachment
- Not chaning QP with base64
- Same wordrapping in headers
- With no change to HTML content, e.g. removing comments
- With the ability to fix bad stored encoding/charset
- If there is a plaintext part and a html part, they shall be preserved  (some webmailer from forwarded a mail to me and I was in the transition of mails. The version Outlooks integrated pop3-client pulled was destroyed!!! The forwarded part was gone. The version stored on a unix system was fine)
- If a mail is broken or spam, I want to be able to view the source and analyze it.
- If it is a NDR with parts of the original mail attached, I must be able to see the original mail, e.g. if I was not the person who sent the mail. It might be spam I want to investigate or something I was not supposed to see and of course I must be able to see such stuff

I understand that whenever I move the mail using Outlook, it will be destroyed. Everything that goes to a PST or with exmerge will be destroyed forever (like lost adresses).

I still don't understand anything about how Exhange 2007 would be able to preserve mime messages at least a bit using the new design without stm.

Is every HTML mail converted to RTF with some embedded markers for html-comments?

Well, I would appreciate any pointers to answers to these questions, information about removal of stm from e2k7 and about imail is very limited.

BUT: Does your posting mean that X-headers are destroyed??? As admin I must be able to see such stuff if I need it. Will I be at least able to use IMAP to go into the mailbox and fetch the mail with all x-headers??

Not applicable
Christian, as noted above message headers are preserved in in the transport headers property.  And if they are already registered on a database, they are promoted as individual properties.  As an admin you can (still) go and look at the transport headers for these values.  As for a "return of the STM", E14 doesn't do that, but I think you should look at the technical beta, as you will find it handles mime differently.
Not applicable
So, what is the recommendation current recommendation for dealing with 9667 errors? Should we apply RU8 and then up the limit, trusting that the we won't just fill up the additional properties with the new behavior? Or will our event logs be filled with 9667's forevermore. Thanks.
Not applicable
Yeah, I am wondering if we will have to do anything after installing RU8.  I have seen a few instances where we are getting these errors now, and the mail messages in question are not making it to the users mailbox.  When looking up message tracking information on the message, we see a FAIL event with reason:

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: MapiExceptionNamedPropsQuotaExceeded:16.18969......blah blah blah numbers

We have not increased the quota, still at 8192.  I am starting to worry we are going to start getting more mail failures because of this.
Not applicable
Love the post (will be seeing the Doctor any day now)

However I have major issues with the topic. We have multiple Exchange 2003 servers currently reporting constantly that we have hit our limit for named properties (gone way past the warning point) and we need to increase it. We haven't increased it to the hard limit as yet.

After logging support calls regarding this, no one could explain to us how they were used or what would happen if we did increase our quota to another level or even what we were losing by not producing a named property for randomjunk. Everything seems to be working fine, even though many emails are trying in vain to create named properties for things like x-header:randomjunkname.

Your article states "Should Outlook be unable to map a named property, bad things happen." But you never explain what you mean. And I can't find an example of the "bad thing" on the MS site.

Care to explain why I should care if the named properties are full?
Not applicable
We are still getting the error:

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: MapiExceptionNamedPropsQuotaExceeded:16.18969......

And mail is bouncing....any update on this issue would really help.
Not applicable
Maybe the STROEDRV.Deliver errors I am seeing are part of the "Should Outlook be unable to map a named property, bad things happen" problem you blogged about in the post above?

I really wish MS would give us more info to go on right now and what we should do.  Is the fix coming soon or do we need to increase the quota on our databases?
Not applicable
JSC - our plan is to deliver this fix in Exchange 2007 SP1 RU8, which we plan to deliver within a month (subject to change if something does not go according to plan). If you are running into a problem today and will be impacted until then - increasing the limit would probably help. If you are not impacted right now - then waiting for RU8 would work.

We plan to post a follow-up post about this when RU8 comes out, addressing any questions or points that might not have been addressed in original post.
Not applicable
Thanks for the update.  We really do not want to increase the quota, it will be a pain due to the number of databases we have.  We will try to wait.  We are currently at the quota level (8192), I am curious to see how this fix handles everything and hope it fixes our issues.  Hopefully afterwards we can uninstall the Header Filter Agents we got from the Codeplex website.
Not applicable
JSC - In all cases you will wind up updating the quota, but I recommend you wait until after RU8 because if you increase it now it will simply be consumed by headers.
Not applicable
OK, thats good news to know that we will still be increasing the quota, even after the update is applied.  Will this still be a registry change followed by a dismount and remount of each database?  Or will there be an easier way to do this perhaps through the Exchange console or through the Exchange shell?  I am sure Microsoft will have detailed information on what you need to do after this update is installed.  At least I hope so.

I take it the Codeplex Header Filter agent won't be needed afterwards as well?
Not applicable
Does ANYONE know why we should care about the Named Properties quota being full?

Anyone? ... even a web link to something ... ?
Not applicable
thought not ...
Not applicable
Kevin, rather than a single explanation, I offer you a simpler way to answer the question.  

Because your question was about named property quotas, I used the words "named", "property" and "quota" in a live search (use the search engine of your choice).  I selected these words because I wanted to see what was already available about "named property quotas".  I could also have inserted the event id but that would have taken more typing.  Normally search engines rank things in terms of "relevance", so I selected the results from the top of the list, which is usally the most "relevant" ones.  The first two are for a kb 820379.  This KB relates to setting the quota, and by reading it, I found that it links to another kb, 898785, which describes one problem when this was exhausted.  The good news is that I didn't even have to click that link - one paragraph below that link is a section that lists even MORE symptoms that could occur when the quota is reached.   I'm sure if I had read the third or even the fourth result, I might have found even more information on what happens, but I leave that to you to explore.
Not applicable
Thanks xC0000005

I'm only asking to try and understand the impact of this issue.

I followed your advise and entered the words "named", "property" and "quota" in the search engine of my choice. I limited my results to articles on the Microsoft site, as the others tended to just repeat that source.

The first few results linked to which is titled "Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases". Sounds great! Unfortunately it didn't explain the impact at all on mailbox databases. It just listed the same warning I've found everywhere. Namely "If this happens on a mailbox database, you must create a new mailbox database". ... um why?

back to the searching

I decided to search for kb 820379. Found it only in an article 898785. Near the end it provides a link to 820379 however the link is broken and the Microsoft Help and Support page reports "Sorry, but we couldn't find the page that you requested."

I kept searching and found which is titled "Events 9666, 9667, 9668, and 9669 Received When Named Properties or Replica Identifiers Are Depleted for An Exchange Database". An old friend ...

However it did have one line of relevance to my question above. This is the sort of info I'm after: "... Outlook ... may receive the error code 0x80040900 ... when the user attempts to send a new message or save a new message in the user's Drafts folder." Now that is serious.

As we have already hit the set limit (but not the hard limit) on multiple of our databases we could increase the quota and have it quickly consumed by rubbish x-headers, however we have seen no impact. Especially no errors when sending an email or saving drafts.

As the topic was very important to us I thought I would ask for more info. More along the lines of "What could actually go wrong?".

Sorry to have caused enough problems for you to use sarcasm.
Not applicable
Kevin: Agree with you, xC000005's suggestion to you was very bizarre!

Here is our experience as to why this issue is very bad.  We produce an addin for Outlook and our addin adds both custom named properties and X-headers to messages sent by our users.

Some of our users have complained that with our addin installed, some of their messages sent to other users in the same exchange system get bounced with messages like:

"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. "

We believe it's due to hitting the named property limit on some exchange databases in their system.

So it seems to us that the short answer to your question "Why should we care if the named property quota is full" is that if it is, messages don't get delivered!
Not applicable
Yeah, gotta go with Martin on this.  The storedrive errors I posted above came from a person who had installed an Outlook add-on that added additional named properties.  He is a VP, and it sucks to tell him he shot himself in the foot by doing this.  Stupid quota.  Hurry up fix!
Not applicable
Man, haven't heard of MAPI in forever! Thanks for the trot down memory land.
Not applicable
I'm hitting the soft limit (8192) on one db, when I do increase, what do you suggest for the next limit?
Not applicable
Also, although the error says I'm hitting the soft limit (8192), will it update the value when it hits a larger number or is this error just generic with (8192).
Not applicable
This error is generic, and increasing it is a double edged sword - increase it and the newly "available" properties will likely be consumed by headers.  Do not increase it and you risk NDRs when a message containes non internet header named properties which need to be mapped.
Not applicable
So what is recommended, wait for RU8 and then adjust?
Not applicable
Myself, depending on how many actual NDRs you are seeing due to this, I'd bump it by 100 or so and watch to see what the property count stays at.
Not applicable
Any ETA as to when Update Rollup 8 is going to be released? I'm running into the named properties issue again on my mailbox databases.
Not applicable
May 19, 2009 - It's out!

Update Rollup 8 for Exchange Server 2007 Service Pack 1:
Not applicable
we haven't recieved any complaints about ndrs yet...
Not applicable
Ok Rollup 8 for SP1 is out now and we have plans to intall it.

Since we are already at the quota limit (8192), after we install Rollup 8 do we need to do anything, or do we need to up the quota limit after the rollup is applied?  If so, to what number?

From above:
"We plan to post a follow-up post about this when RU8 comes out, addressing any questions or points that might not have been addressed in original post."

Haven't seen a follow up post yet
Version history
Last update:
‎Jul 01 2019 03:43 PM
Updated by: