External users are getting this error when they attempt to accept a meeting invitation sentfrom someone within our organization. The same two accounts can send regularemails between each other no problem. It only happens after a meeting request is accepted. It seems to behappening to users on a particular store, although i'm not positive about that one. We've tested this with several different external companies and even a couple of hotmail and msn accounts. No matter who our internal user sends the meeting request to, the recipient always gets this error when they try to accept. We aren't seeing the problem when internal users accept, or when an internal user accepts from an external meeting request. I've read that one of the possible resolutions is to move all the mailboxes to a new store, and then delete the old one. This sounds silly to me though since that would only buy us some time until the problem reappeared (not to mention the downtime required to move everyone.) We're native Exchange 2007 SP1, rollup 2. -jim Here's an example of the error message: 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:BE000000, 17.27161:00000000D4000000000000000000000000000000, 255.23226:31000000, 255.27962:7A000000, 255.27962:56000000, 255.17082:00090480, 0.16993:80030400, 4.21921:00090480, 255.27962:FA000000, 255.1494:00000000, 255.26426:56000000, 4.6363:0F010480, 2.31229:00000000, 4.6363:0F010480, 2.17597:00000000, 2.22787:00000000, 2.22787:00000000, 2.22957:00000000, 2.19693:00000000, 2.17917:00000000, 2.27341:00000000, 2.22787:00000000, 4.5415:00090480, 4.7867:00090480, 4.4475:00090480, 4.4603:00090480, 4.5323:00090480, 255.1750:00000000, 0.26849:2F000000, 255.21817:00090480, 0.24529:00000000, 4.18385:00090480".

Hi, Please check whether event 9667 which indicates Failed to create a new named property for database "First Storage Group\Mailbox Database" Default Exchange 2007 has limitation of 16,384 for named properties created by authenticated users and replica identifiers. The default quota for named properties created by users who are not authenticated is 8,192 If yes, then please follow the below kb to configure Named properties and Replica Identifier Quotas to value-32000 How to Configure Named Properties and Replica Identifier Quotas for Exchange 2007 Databases http://technet.microsoft.com/en-us/library/bb851493(EXCHG.80).aspx Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases http://technet.microsoft.com/en-us/library/bb851492(EXCHG.80).aspx Events 9666, 9667, 9668, and 9669 Received When Named Properties or Replica Identifiers Are Depleted for An Exchange Database http://technet.microsoft.com/en-us/library/bb851495(EXCHG.80).aspx More information share with you: How to Enable Additional Information Store Logging.http://support.microsoft.com/?id=254606 Hope it helps. Xiu

My understanding is that this would only be a temporary fix, until the named properties limit was reached again. At that point i'd need to create a new database and move all the messages. Am i undertanding this correctly? I'd like have a permanent solution instead of a short-term band aid. jim

Here are detailed discussions you got http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?query=Named+properties+quota+exceeded%3F&dg=&cat=en_US_e2dcdfff-cde7-41b1-98fb-c15563ef8d12&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=&exp=&sloc=en-us You can increase the quota and monitor the counter with perfmon as Xui suggested and another thing as you told move the mailboxes and dialtone the database but both are workaround to avoide the error for time being. You may need to find out the application if anyone is creating more named properties by dumping named properties with MFCMapi. It seems that we need to wait till next version of Exchange for fix.

I opened a case with MS Support. I had to be transferred to the Connectors department. Apparently it's a known "issue" (i.e. bug) and they're aware of it. I was told they're working on a fix, but i'll need to increase thenamed properties quota in the mean time to correct the issue for now. Hopefully we won't have to wait until the next version of Exchange.

Great, thanks for the update. I am eagerly waiting ifpermanent fix will be availabe about this

Ok, it's been a year and I'm still getting this error, has there been any fixes released? This URL comes up with nothing now? http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?query=Named+properties+quota+exceeded%3F&dg=&cat=en_US_e2dcdfff-cde7-41b1-98fb-c15563ef8d12&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=&exp=&sloc=en-us

The fix is included in next update rollup of SP1 of Exchange 2007, UR8. Named Properties, X-Headers, and You http://msexchangeteam.com/archive/2009/04/06/451003.aspxAmit Tank | MVP - Exchange | MCITP:EMA MCSA:M | http://ExchangeShare.WordPress.com

Do they have a fix for Exchange 2003? We are about 10 instances from reaching out quota. I was planning on doing an offline defrag this weekend, and wondered if it would have any positive contributions. Thanks.

How do you make those changes?"MapiExceptionNamedPropsQuotaExceeded:16.18969:BE000000,

On Fri, 18-Dec-09 23:18:16 GMT, carmenchacha4343 wrote:>How do you make those changes?"MapiExceptionNamedPropsQuotaExceeded:16.18969:BE000000, See this URL:http://technet.microsoft.com/en-us/library/bb851493(EXCHG.80).aspxYou should also install Rollup 9 on Exchange 2007.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

http://msexchangeteam.com/archive/2010/07/29/455687.aspx ed About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!

I am having the same problems with id 9667, And I am running exchange 2007 sp3 with rollup 5. Is there not a fix out for this yet?

On Thu, 15 Dec 2011 18:16:17 +0000, l0cc wrote: >I am having the same problems with id 9667, And I am running exchange 2007 sp3 with rollup 5. Is there not a fix out for this yet? Not if the properties are being allocated to the various X-headers in messages that arrive via authenticated SMTP connections. This can be modified to remove (or allow) whatever headers you want: http://headerfilteragent.codeplex.com/ --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Fri, 16 Dec 2011 19:22:38 +0000, l0cc wrote: >Basically it's this, users from outside organization is trying to send these invites to a meeting to my users. Is the problem with the sender email server then? The problem is that the number of assigned MAPI properties in that database has been exceeded. The reason _why_ they've exceeded the quota is that authenticated users are sending messages with unnecessary X-headers. Those X-headers, when promoted to MAPI properties, consume one of the "X" number of allocated MAPI properties for the database. >for exchange 2007 sp3 w/rollup 5, I would need to install the headerfilteragent to resolve this issue? If the messages are being sent using an anonymous SMTP session the X-headers shouldn't making it to the database. The fact that they are tells me that you may, indeed, need to use the agent. But, IIRC, the agent only works if the session is "anonymous". If you apply the agent (by making a change in the code) to authenticated sessions you have to be careful not to remove X-headers that Exchange creates and depends on for correct operation. >Also I have emails go through FOPE filter and then passed onto my server. Would this be causing the issue with the headers? I believe so. You probably have that receive connector set as "externally secured". That effectively bypasses all the X-header removal stuff. >Also on the http://headerfilteragent.codeplex.com/ site, it said that this issue was fixed with sp1 w/rollup 8. Wouldn't this fix also be included int he sp3 as well? Yes, for anonymous connections. See: http://technet.microsoft.com/en-us/library/bb851492(EXCHG.80).aspx Scenarios that still consume named properties to preserve X-Headers Authenticated users MAPI applications To get around those errors you see in the application log, you can raise the number of alloted MAPI properties. See: http://technet.microsoft.com/en-us/library/bb851495(EXCHG.80).aspx Treat that as a temporary fix. If new X-headers continue to arrive they'll continue consuming MAPI propertie IDs. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Fri, 16 Dec 2011 21:17:56 +0000, l0cc wrote: > > >From what I have read from your links provided(thanks again), It's the way the sender is creating unnecessary X-headers in the email. So I can't do anything about that, I will have to use the headerfilteragent on exchange 2007 or upgrade to exchange 2010. > >As for FOPE, I don't have anything receive connector at all, I just have my firewall set to receive from the range of IP's that FOPE uses, and reject all other connections. Are you sure? If you're having an external, 3rd-party, software manage perimeter security for e-mail (disregarding IP address connections), I'd have though that you'd be trusting them to "do the right thing". Please verify that your receive connector doesn't have the "Externally secured" box checked on the "Authentication" tab. And, just to be thorough, do you have more than one receive connector? >As for the headerfilteragent whitelist, do you recommend any x-header whitelist that would be safe to put in, more importantly what X-headers to whitelist that doesn't cause any issues for correct operation on exchange? Have a look at the message headers in messages already in your mailbox (from both internal and external senders). What headers are used in your organization I don't know. For Exchange 2007, this is a starting point: http://technet.microsoft.com/en-us/library/bb232136(EXCHG.80).aspx If you have Sharepoint libraries sending e-mail you may (and will) have other X-headers. If you have any applications that send e-mail they may use their own X-headers. FOPE probably inserts X-headers as well. >Rich, I really appreciate you for taking the time in answering my questions/problems. > >edit to add: > >http://technet.microsoft.com/en-us/library/bb232136(EXCHG.80).aspx > >What is the difference between the above link and the heaerfilteragent, seems like it does the same thing? headerfilteragent is more specific custom headers? The header firewall (that's the same link I referenced above) only works on anonymous connections (or on users you've given certain permissions to). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Fri, 16 Dec 2011 23:26:35 +0000, l0cc wrote: > > >I have two receive connectors, and both doe not have the "Externally secured check". > >This problem is much more of a problem than I thought, and all of this because of a meeting invite. I looked at one header which was strange, the email invite, the header is "x-mimeole produced by microsoft exchange v6.5" I really don't see anything else that would cause this problem. > >And the reason I know what the failed email looks like, I have the archive for exchange which I can see the headers of incoming email. It passes the filter and archiving fine, then when it comes to my server, it rejects it because of the problem in this thread. I can't mentally wrap my head around this problem. It always comes back to how the originating sender and the server creates the x-headers. > >I dont't want to install the headerfilteragent and then cause unknown email problems because of headers that I seem to have missed to put in the whitelist. Too bad there isn't a blacklist as well. Changing the code is easy enough to do. But if the same X-header occurs in a million messages it's still only going to have just one MAPI property assigned to that value. >Can I also ask about the link in a previous post, http://blogs.technet.com/b/exchange/archive/2010/07/29/3410545.aspx > >Would since I am up to date on the service packs and RU's, would it be safe to add the registry value? By "the registry value," were you referring to the one that disables the promotion of X-Headers completely (i.e. "Header Promotion mode")? If so, then the answer would be yes (you'd be running SP3 and that registry value was available in SP2) -- provided nothing you do depends on those X-headers being present. >Also From what all I read so far, alot of it, Looks like I need to create a new data store and move the mailboxes to the new one? The answer to this is "maybe". By moving the messages to a new database only the X-headers in the existing messages will be assigned MAPI property values in the new database. But if all of the X-headers that caused the original problem are still present in the messages being moved then you'll have exactly the same problem in the new database! You can use this to raise the limit on the MAPI properties: http://technet.microsoft.com/en-us/library/bb851493(EXCHG.80).aspx Just don't go nutz. If you still use the 8192 default value, then raise the limit to 10,000 to get some breathing room. Since you're running SP3 you can use the get-namedproperty cmdlet to help: http://technet.microsoft.com/en-us/library/ee207161(EXCHG.80).aspx If you suspect the problem is X-headers, try this to get a list of all the X-headers that have been promoted to MAPI properties (there are three command below the 2nd one probably wrapped): Add-PSSnapin Microsoft.Exchange.Management.Powershell.Support Get-NamedProperty <NAME> -mappingmode all -force | fl >c:\temp\prop.txt Select-String c:\temp\prop.txt -pattern "name\s+\:\s+x-.*" "<NAME>" is the name of a mailbox in the database with the problem This script will warn you when new MAPI properties have veen added to the database: http://it-erate.com/exchange-named-properties-table-growth/ >and since I am up to date on updates, this error should not come up since there was updated code to prevent this from happening? I am totally confused now. Being on SP2 (or SP3) helps, but it doesn't prevent the same problem from happening if the source of the problem is authenticated users. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I don't understand why couldn't there be a clean up agent to just remove all the MAPI X-headers and have the database just start all over. Below is the link about creating a new database store, moving the mailbox to the new db store and running Run Cleanup Agent, what do you think about it? http://msexchangeguru.com/2009/09/04/event-id-9667/ And just to make sure I am understanding this again, if anyone sending new email to my mail server and uses x-headers that are already there then there would be no problem, but if there is new ones not already in the database then it would get the 9667 error and send a NDR. I think I am leaning towards just creating a new database store and moving the mailboxes, sounds easier and buys me some time to get the headeragentfilter installed. Get the props table and see what the common headers are and put those on the whitelist. Maybe look at the headers of my internal emails first and go from there to populate a white list. >Can I also ask about the link in a previous post, http://blogs.technet.com/b/exchange/archive/2010/07/29/3410545.aspx > >Would since I am up to date on the service packs and RU's, would it be safe to add the registry value? >By "the registry value," were you referring to the one that disables the promotion of X-Headers completely (i.e. "Header Promotion mode")? If so, then the answer would be yes (you'd be running SP3 and that registry value was available in SP2) -- provided nothing you do depends on those X-headers being present. Also from your response about the registry value, I checked and I don't see a value in the registry on the exchange server.

On Mon, 19 Dec 2011 06:42:57 +0000, l0cc wrote: >I don't understand why couldn't there be a clean up agent to just remove all the MAPI X-headers and have the database just start all over. Because some X-headers are legitimate. >Below is the link about creating a new database store, moving the mailbox to the new db store and running Run Cleanup Agent, what do you think about it? > >http://msexchangeguru.com/2009/09/04/event-id-9667/ That may provide short-term relief but, as I said, if the messages that contined the X-headers are still in the database then the new database will have them, too. >And just to make sure I am understanding this again, if anyone sending new email to my mail server and uses x-headers that are already there then there would be no problem, but if there is new ones not already in the database then it would get the 9667 error and send a NDR. That's true if the problem happens with something other than X-headers. But if it's an X-header the event log gets an entry and the message is delivered. Those links I provided explain the "what happens" in more detail. >I think I am leaning towards just creating a new database store and moving the mailboxes, Okay. >sounds easier Easier than modifying the registry?? >and buys me some time to get the headeragentfilter installed. Get the props table and see what the common headers are and put those on the whitelist. Maybe look at the headers of my internal emails first and go from there to populate a white list. >>Can I also ask about the link in a previous post, http://blogs.technet.com/b/exchange/archive/2010/07/29/3410545.aspx > >> > >>Would since I am up to date on the service packs and RU's, would it be safe to add the registry value? > > > >>By "the registry value," were you referring to the one that disables >the promotion of X-Headers completely (i.e. "Header Promotion mode")? >If so, then the answer would be yes (you'd be running SP3 and that >registry value was available in SP2) -- provided nothing you do >depends on those X-headers being present. > >Also from your response about the registry value, I checked and I don't see a value in the registry on the exchange server. I think I may have slipped that one in there from Exchange 2003. :-( HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent Data name: GenerateNamedProperties Data type: DWORD Data value: 0 = False, 1 = True The "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent" is still there in Exchange 2007, so go ahead and add the data. Restart the IS and see if the property promotion stops. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

We got the same issue where particularly two users were not able to mail one guy we re created NDR producing mailbox which fixed the issue. error we saw was 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:BE000000, ..... we are in exchange 2007 sp2 rollup 4

Event id: 9667 When database reaches maximum limit of named properties or replica identifiers: http://msexchangeguru.com/2009/09/04/event-id-9667/