Confused About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!
Published Jul 29 2010 04:00 PM 21.4K Views

One of my favorite things about my job is that I get to learn new stuff everyday! It's like being in school all of the time! And yes, I was that person in class that always ruined the curve for everyone else.

If you have been using either Exchange 2003 or Exchange 2007 for any length of time, you may have experienced the dreaded Named Properties Depletion warning in your Application Event log. If you haven't, they look like this:

Named Properties Warning for Mailbox Databases:

Event ID: 9666
Type: Warning
Category: General
Source: msgidNamedPropsQuotaWarning
Description: The number of named properties created for database "<database name>" is close to quota limit. Current number of named properties: <number of named properties>. Quota limit for named properties: <configured quota>. User attempting to create the named property: <user name>. Named property GUID: <GUID of named property>. Named property name/id: <name of named property>.

Note: Event ID 9666 can refer to Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI) creation of named properties. For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

Even worse is getting the error events.

Named Properties Error for Mailbox Databases:

Event ID: 9667
Type: Error
Category: General
Source: msgidNamedPropsQuotaError
Description: Failed to create a new named property for database "<database name>" because the number of named properties reached the quota limit (<configured quota>). User attempting to create the named property: <user name>. Named property GUID: <GUID of named property>. Named property name/id: <name of named property>.

Note: Event ID 9667 can refer to Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI) creation of named properties. For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

By the time the error is recorded, you are probably getting calls from your end users wanting to know why they can't send or receive mail. I am not going to explain the history and impact of Named Properties since Jason Nelson wrote several excellent blogs on this (which I use all the time). Check them out here:

Named Properties, X-Headers, and You
http://msexchangeteam.com/archive/2009/04/06/451003.aspx

Named Properties, Round 2: What lies Ahead
http://msexchangeteam.com/archive/2009/06/12/451596.aspx

Service Pack 2 Preview: Get-NamedProperty
http://msexchangeteam.com/archive/2009/08/06/451948.aspx

Understanding how Outlook, CDO, MAPI, and Providers work together
http://msexchangeteam.com/archive/2005/04/08/403512.aspx

Now to clear up the biggest misconception about setting quota limits for named properties for an Exchange 2003 or Exchange 2007 databases:

Setting the quota limits does not increase the number of named properties that can be created in an Exchange 2003 or Exchange 2007 database.

The number of named properties that can be created in an Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

Setting the quota limits for named properties for an Exchange 2003 or Exchange 2007 database increases the threshold of when you are going to get the warning and error messages in the Application Event log.

Please read the above again; it's kind of important.

For Exchange 2003 and 2007, the maximum number of named properties that can ever be created is 32,767 per database.

There is not a way to ever increase the number of named properties that can be created in Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

It took me several readings of all KB and TechNet articles before I picked up on that. So if you didn't get it, please do not feel bad. I spent a lot of time with one of our Senior Escalation Engineers trying to understand it. Right before I wore out their last nerve, a light bulb went on over my head and I finally understood it. Now I explain it to my colleagues and customers, my cat Spike and strangers at the gas station.

And now for something completely different or a little more in-depth view of NamedProps:

The way this really works is that we have a table in the database called NamedProps. Every Named Property that gets added to the database gets its own row in this table. The limit on the NamedProps table is a limit on the number of rows in the table, which are 32,767.

The quotas, of course, are set much lower than that, so that you have some warning before you run out of rows. It doesn't matter if the user is authenticated or not - they all go into the same NamedProps table. So you could have 32k created all by authenticated users, or 32k all created by unauthenticated users, or 10k created by unauthenticated and 22k by authenticated, or whatever... it doesn't matter who created them, the bottom line is that the maximum is 32k rows in that table.

Once your table passes 8k rows (by default), we stop allowing new named props from unauthenticated clients. It's entirely possible that those 8k rows were all created by authenticated clients, but it doesn't matter. We continue allowing new names from auth clients until we hit 16k, and then we deny them as well. This is assuming the quotas are at the default of 8k/16k.

Below is a table with the named properties quota limits:

 

Exchange Version

Maximum size of the data type

Default Quota

Default Warning Issued

Default Error Issued

2003 Mailbox Store

Authenticated Users & Non-Authenticated Users 32,767

Authenticated Users: 16,384

Non-Authenticated Users: 8,192

Authenticated Users:

16,364

Non-Authenticated Users: 8,172

Authenticated Users:

16,384

Non-Authenticated Users: 8,192

2007 Mailbox Store

Authenticated Users & Non-Authenticated Users 32,767

Authenticated Users: 16,384

Non-Authenticated Users: 8,192

Authenticated Users:

16,364

Non-Authenticated Users: 8,172

Authenticated Users:

16,384

Non-Authenticated Users: 8,192

For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

You can increase the thresholds so you don't get the warnings until, say 22,000. We don't recommend setting the warning quota any higher than 16,000 so you will have adequate time to take action.

And we definitely don't recommend setting the error quota to 32,767 because at that point everyone in your Exchange organization is miffed with you and you find yourself uploading your resume to a popular job site on the Internet.

You may ask yourself "where is my beautiful..."; hold on, wrong question.

Is there a way to suppress the creation of future for named properties for an Exchange 2003 or Exchange 2007 database? And what about Exchange 2010?

I am glad that you asked!

For Exchange 2007 SP1 RU1 - RU7, there is a transport agent named HeadFilterAgent that is available for download at:

http://headerfilteragent.codeplex.com/

Exchange 2007 RU 8 for Service Pack 1 and Service Pack 2 (and later) have new code that prevents future promotion of named properties. And this code is already in Exchange 2010 so no action is needed on your part.

For Exchange 2003, we have a hot fix for Service Pack 2 that enables the control for the creation of x-headers for named properties using a Registry Editor entry:

972077 "Outlook cannot display this view. Unknown Error" error message is generated in Outlook client and Event ID 9667 is logged on an Exchange Server 2003 server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972077

After you apply this fix, you may follow these steps to set a registry entry to control the promotion of X-headers for named properties:

1. Click Start , click Run , type regedit , and then click OK .

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS

\ParametersSystem\InternetContent

3. On the Edit menu, point to New , and then click DWORD Value .

4. Type GenerateNamedProperties , and then press ENTER .

5. Quit Registry Editor.

A 0 value of the GenerateNamedProperties attribute will not generate new named properties.

The default behavior (of the promotion of X-headers for named properties) is true when this registry entry is not found or set to 1.

Let's recap:

Setting the quota limits does not increase the number of named properties that can be created in an Exchange 2003 or Exchange 2007 database.

There is not a way to ever increase the number of named properties that can be created in Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

You can suppress the promotion of named properties in Exchange 2007 SP1 RU1 - RU7 using the transport agent named HeadFilterAgent . Or by applying Exchange 2007 SP1 RU8 or Exchange 2007 SP2. For Exchange 2003 SP2, a hot fix is available that utilizes a registry setting to suppress the promotion.

- Eileen O'Rourke

29 Comments
Not applicable
URL points to local file ( file:///C:/Users/ninob/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/DHGYUGYA/(http:/msexchangeteam.com/archive/2009/04/06/451003.aspx )
Not applicable
Thanks Michael... no idea how I managed that - but I fixed it now!
Not applicable
I've read this twice now (harder than it sounds ;) and can't see the answer to this bit:

"And what about Exchange 2010?"

Assume this just flat out isn't an issue for Exchange 2010?
Not applicable
Paul, it's in the section for E2K7 RU1 for SP1:
----------------
Exchange 2007 RU 8 for Service Pack 1 and Service Pack 2 (and later) have new code that prevents future promotion of named properties. .!!!!!And this code is already in Exchange 2010 so no action is needed on your part!!!!!
Not applicable
Thanks for this article.  It has helped me out a lot.
Not applicable
So, Am I correct in assuming that as soon as I have Exchange 2007 SP2 or Exchange 2010 (or Exchange 2007 SP1 UR8 if you want) I'm safe?

<Jack />
Not applicable
Will my users experience performance problems after the named prop values hit 16,384 and I have changed the default value to 32,767?
Not applicable
We  have approx 30+ exchange servers.  I have come to dread the 9667 events and their brethren.  They always portend undeliverable emails, and annoyed user phone calls.  Im so glad someone has done something about this!!!

Thanks!
Not applicable
Ah, I would have assumed the (and later) applied to the Exchange 2007 line only and maybe referenced SP3 and any subsequent SPs.
Not applicable
Hi,

you asked the question below in your article:

'Is there a way to suppress the creation of future for named properties for an Exchange 2003 or Exchange 2007 database? And what about Exchange 2010?'

But you don't give an answer to the question 'And what about Exchange 2010?', so how about it? ;)
Not applicable
Exchange 2007 RU 8 for Service Pack 1 and Service Pack 2 (and later) have new code that prevents future promotion of named properties. ----->And this code is already in Exchange 2010 so no action is needed on your part.<----------

Not applicable
Sorry, completely overlooked that one. Apparently I was looking for the bold part ;)
Not applicable
For Exchange2010,  has the underlying "32,767" limitation (as a consequence of the NamedProps data element size) been corrected at the database store level?

(Please don't tell me that we're in for 5 more years of the same known limitation of the NamedProps table as constrained by a 32-bit integer! )

What are the backward compatibility issues when faced with Outlook 2007 client software connecting to Exchange 2010 mailbox back-end?    Can the NamedProps 32,767 table size limitation be corrected without breaking backward-compatibility with earlier versions of Outlook?
Not applicable
So Exchange 2007 SP1 RU8 and SP2 and Exchange 2010 have code to prevent the promotion of Named Properties, right?

But only from Anonymous internet sources, which I understand to mean coming-in on the default receive connector.

We run Exchange 2007 SP2 and we use internal smtp gateways with an Exchange Receive connector create just for them (which only allows anonymous access), named Props are still promoted.
Not applicable
@Jason - Correct, until you get to SP2.  In Sp2 and later, you can set Header Promotion mode to turn off creation of x-header named props, period.

@Pete_Heilig_Gartner - Re-read the original "Named Properties, X-Headers, and You" post.  The issue is (of course) that all clients consuming MAPI everywhere would need to be recompiled (along with new versions of MAPI.DLL, all service providers, and all utilities).  It isn't just a matter of sticking more bits on the _SPropValue, modifying the macros to work against 64 bit ints, modifying all existing property tags, creating a mapping scheme from old PTAGs to EPTAGS, changing the unpacking (and packing) code and changing the underlying database format.  It's getting every client (including ones that no longer even have source code) to be able to retrieve a list of properties where things get dicey.

As mentioned, named properties are now a per mailbox resource in E14.
Not applicable
Hi.  Is there a reason why this page looks funny in Windows Mobile?  Anyway a bit of advice, do a second writeup soon!
Not applicable
We run exchange server 2007 SP1 with RU9, still hit the event 9667.  Can anybody tell me is this problem also fixed on exchange server 2007 SP1 with RU9.

The following is mentioned is this blog, I am an exchange server user from non-Enligsh region. :) , Thank you in advance.
"Exchange 2007 RU 8 for Service Pack 1 and Service Pack 2 (and later) have new code that prevents future promotion of named properties. And this code is already in Exchange 2010 so no action is needed on your part."
 
Not applicable
or, after applying the hotfix of RU9, we still need to do something additionally.
And my clients are outlook 2003
Not applicable
Like many things with MS, there has to be a "gotcha" associated with not promoting named properties....  What is it?  If the named property promotion can be turned off now, why was it ever kept in the first place?  What purpose was it originally intended to serve?  For example, we have LOTS of IMAP users and isn't the named property used for something important when converting a message to IMAP for display in the client?  What other impact might there be if we turn off the named property promotion?
Not applicable
@EOD - good question.  I can't wait for an answer.

@xC0000005 - Thanks for the tip.  We updated to Exchange SP2 from SP1 just to take care of this problem specifically and we're still getting the same problem.  How could i turn off header promotion?
Not applicable
We got the 9667 Error with our Ex 2003 SP2. I installed the Hotfix - KB972077 set the registry key and  rebooted. Than I switcht the virtual Server to the patched clusterknode.

But the Error still occurs.

We have the issue with the public folder DB and its a cluster. Is one of the former not supported?
Not applicable
There is still a "got'cha" in regards to named-property promotion:  x-headers in messages encapsulated in TNEF (i.e.: winmail.dat) will be promoted by store.exe... and there seems to be no way around it.

Not applicable
I'm wondering, for exchange 07 does the reg key (GenerateNamedProperties) need to be added and enabled to disable the named prop promotion?
Not applicable
I am still confused.  We have Exc 03 SP2 and patched to date.  We are getting 9667 (lots of them).  MS tech support wants me to follow KB820379 to stop the errors.  I need to fix them so they do not return.  From what I can tell, this is just a "quick fix" and we will soon have the same errors again.  Is your fix above to run the hot fix on both side of my cluster, then modify the registry to 0 to stop the promotion of x-headers?  Is there any issue with setting this to 0?
Not applicable
A very simple question, but I can't seem to find the answer anywhere:

Q: Can you have the same LID (Property long ID) in different GUID/UUID namespaces?  I read [MS-OXPROPS].pdf, the answer seems to be "no" although in theory you can.

Thanks
Not applicable
i see
Not applicable
This was exactly was I was looking for!  I found this article to be the best source of information about the topic.  Is there a way to purge the table to "start over" if you get to close to the hard limit?  I would hate to have to create a new database and move the mailboxes in order to fix this issue.
Not applicable
I'm a little foggy on some of this.  
The hard limit of 32767 is a combination of Mapi Named Props and non-Mapi Named Props, correct?  So if I set a quota of 20000 on Mapi and 16000 on non-Mapi, I'm overcommiting myself.  So if my Mapi rows reach 15000 and my non-Mapi reach 17000+, will I receive a warning or will I crash headlong into the magic 32767 limit?  
I know this article suggests not going over 16000, but lots of other blogs/forums don't.  I just want to make sure I'm reading it right.  Please correct me if I'm wrong.

Thanks!
Not applicable
Every once in a while I get the error message listed below. It does not happen on all messages bound for the message store in questions just some of the messages.

After reading the information I am still unclear as to whether or not you have to do something to stop the named properties from being generate.

We are currently running E2K7 SP3.

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9667
Date: 10/19/2010
Time: 12:22:09 PM
User: N/A
Computer: MIL-SVR-EXCH-01
Description:
Failed to create a new named property for database "Storage GroupsTORE" because the number of named properties reached the quota limit (8292).
User attempting to create the named property: "SERVERNAME$"
Named property GUID: 8b68cc02-773b-4851-989e-bb806518ccbb
Named property name/id: "AvgProcessed"
Version history
Last update:
‎Jul 01 2019 03:53 PM
Updated by: