We have 3 Exchange 2003 SP2 Clusters with 4 storage groups spread across them and 4 Mail stores on each storage group. We recently have had one of the servers that have been getting multiple Event ID's 9667. example Failed to create a new named property for database "Storage Group A-D\MailStore-A" because the number of named properties reached the quota limit (10878). User attempting to create the named property: "Firstname_Lastname" Named property GUID: 00020386-0000-0000-c000-000000000046 Named property name/id: "X-cdx-MailScanner-OpenProtect-From" and Failed to create a new named property for database "Storage Group A-D\MailStore-A" because the number of named properties reached the quota limit (10878). User attempting to create the named property: "SYSTEM" Named property GUID: 00020386-0000-0000-c000-000000000046 Named property name/id: "X-cdx-MailScanner-OpenProtect-From" I have read the articles on raising the quota and we have done that ( I set it to 15000) but we still see the error after editing the registry and dismounting the store and bringing it back online. In the articles I have read, many users have asked if there was a way to track down where this was coming from to try an and prevent it from growing further. I have two questions. What else can I check to see why raising the quota in the registry did not work. Second, I would be interested in finding out what size the Named Property table is so I can determine if I will be forced to move all of the mailboxes to a new mailstore, delete my MailStore-A, recreate it again and move the mailboxes back. (Can I use the same name again) Thanks.

The following will answer both questions you raised: Raising the quotadoes not fix the issue. It just pushes the threshold when you get alerted. Named props do not come from a specific mailbox; they are common to the mailbox store as a whole. Every time a mailbox in the store gets a new message with a unique X-Header that's not in the props table, the store will add it to the props table. 3rd party software such as spam filtering software which also adds X-Headers and those will also get added to the named props table. Any 3rd party applications which create additional MAPI properties, those properties are also added to the table. There is no way to clear out this table unless you create a new mailbox store!! You will only have 32K of space available for named props. you can monitor the number of rows in the named props table by looking at the following performance counter: MSExchangeIS Mailbox -> Rows in NamedProps Table -> <Name of store>. You will have to enable advanced store counters to expose this value and you can look at the following link on how to do this: http://support.microsoft.com/kb/821912 Exchange 2007 SP1 handles named props differently. you can read about it in the following articles: http://support.microsoft.com/kb/821912 Exchange 2007 SP1 handles named props differently. you can read about it in the following articles: http://technet.microsoft.com/en-us/library/bb851492(EXCHG.80).aspx http://technet.microsoft.com/en-us/library/bb851495.aspx http://technet.microsoft.com/en-us/library/bb851493.aspx Note: Dave Goldman [MSFT] deserves credit for his contribution to this subject.

Thank you for your detailed reply. I am aware that raising the quota is not a fix, however I did want to raise it since we did have quite a bit of room left before we hit 32K. I did follow the steps from the following article: http://www.netomatix.com/Articles/KBArticle.aspx?a=820379, but for what ever reason I still receive an alert that the limit is still 10878. I did the pefromance monitor and it confirms that is what the table is at. Interesting enough is that all of the other stores are only around 4500. Anything you can suggest is greatly appreciated. Thanks again.

Good to know it helped. You just narrowed down to a number of mailboxes. Is there a mailbox used by some application which uses named props? Any user using third party application for spam mamagement? Anything that can create additional MAPI properties or uses named props. Exmon can help you find out most active users in real-time and may help you gather information that can lead you to finding the source of the issue. Here is the download link: http://www.microsoft.com/downloads/details.aspx?familyid=9A49C22E-E0C7-4B7C-ACEF-729D48AF7BC9&displaylang=en

I am pretty sure it is any user on that mail store. Our "Iron Port" mail server does set an x-header on spam, so I am fairly confident that is where it is coming from. Now am down to just figuring out why I cant rais the quota to 15000 as I set in the registry for that particualr store. Any thoughts on that? Thanks again.

I don't think you can set the registry only for one store. It will raise quota for all stores. If Iron port is the source, it would be affecting all stores since all your users receive email from outside, don't they?

According this article you can set the quota per each store. http://technet.microsoft.com/en-us/library/bb851493(EXCHG.80).aspx Yes, it will affect all of the stores but all of the other stores are not affected by the quota limit.The 15 other mail storesaround 4500-6000 entries where as MailStore-A is at 10878. The max it can be is 32000 so I would like to at least get by for a few more moths untill we start looking at exhcnage 2007 by raising the quota on MailStore-A to 15000 or 20000. I just am trying to find out why doing what the article stated did not change the limit. Thanks.

So the settings are no taking effect? Have you converted the GUID obtained using ADSIEdit as mentioned in article? I am sure you have, I just want to confirm. Can you please ensure the conversion is correct?

This is the registry key: Private-376f151a-2b55-451f-9159-1db2d8e8bd78 Herei is the GUID: 1A 15 6F 37 55 2B 1F 45 91 59 1D B2 D8 E8 BD 78 Here is the Registry Key that I created: Named Props Quota Here is the setting I put: 3a98 Thanks, Bob

I also discovered that it is not our IronPort server. It is just various incoming emails from other copmanies that have mofied x-header info that is exhange is trying to index. It is an odd thing that Exhcnage would want to index this info as it would seem that it is useless info if you deal with millions of emails each month. Either way if you have any other thoughts on why I cant raise the quota limit on Named Propertis let m know. Thanks so much for all your help.

Your setting and format for GUID seems to be fine. It iw weird that the setting won't take effect. Can you try changing the value to 0x4000? Will you be able to reboot the server after making the change? I will check if I can find any other reason why the change did not take effect.

We do have a transport agent for Exchange 2007 that strips all x-headers except the ones whitelisted as per config. http://www.codeplex.com/HeaderFilterAgent This however does not help with Exchange 2003.

Ok I have applied it to be 16384 (DEC). I may have over looked one item and maybe its a known thing but all of the alerts are complaining about the (Named Props Quota) when I made the change I noticed that the (NonMAPI Named Props Quota) was set to 10878. Is it possible that the alerts are the same if it is either one? I will find out tonight when I take the store offline and bring it backup because I went ahead and raised it to 16384 also. Thanks.

Well I found that it was eitheruping the Named Props Quota to 16384 or changing the NonMAPI Named Props Quota to the same limit, but either way the erros have stopped and the amount of entries in that table went from 10878 to 10897. It did this without taking the store offline which is interesting by itself. I will mark this as closed an I want to thank you for all of your help and suggestions. Thank you.

What I suspect is not upping the quota but changing the NonMAPI helped it. Which also leads to a clue of what apps/clients could be doing this sans MAPI clients.