MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

Event id: 9667 – When database reaches maximum limit of named properties or replica identifiers

So what is this Named Property anyways ??? 

Most objects for MAPI specification are represented as properties which are PropIDs. 

Range of these PropIDs can vary from 1~65535 (0xFFFF). There are 3 ranges which differentiates a PropID and anything which falls within range 32768 (0×8000 or 8K)is called a standard property. 

Now comes our hero, NAMED PROPERTY. 

Classification:- 

  1. Properties that have numbers for names.
  2. Properties that have string values for names.

Named properties are basically properties that are not well known. MAPI developers (as I told 3rd party vendors) can use them to store values that only pertain to them or in simple terms  extend the standard MAPI property by adding their application involved properties..,for ex: blackberry,fax applications etc. The definition of this  properties are stored in the named props table. This is where the problem starts, the table that stores these values only allows for 32k entries. So if let’s say you sent 32k messages to a company, each with a unique X- header or a single message with 32k X-headers, you could fill up this table, effectively causing the store to become inoperable. To provide a buffer, we set a soft limit of 16k, and further ratcheted it down to 8k. So if you do hit this limit, it provides an administrator the opportunity to take action. 

This happens if a store has been running for a really long time, an MAPI application in the environment creating a lot of named properties, or have some malicious or strange message patterns coming into the Exchange Server. 

The second use of the named props table is related to incoming SMTP messages. When mail arrives from the internet, it can contain any number of customer “X-“ headers and their associated value. The headers must be preserved in some fashion. When a message is fully converted from MIME to MAPI format, we must save these X- headers off somewhere inside the EDB file. Each unique X- header encountered becomes a separate entry in the named props table. For example if the following headers were encountered they would become 2 unique entries in the named props table. If they are encountered again in a later message, no big deal, we already have a definition for them. 

X-MyCoolCompanySCLLevel 

X-ULConvertState  

Now the fix most do for exhaustion of named property is to increase the limit!!! Upto what? No more than 32768 as the table can accommodate only that. This is temporary fix and at some point in a down the line in future problem is going to hit again, you have no other option than to move all your users to a new database where that gives you a fresh table (32K) for named property entries. (big pain if lot of users exists in your environment) 

Best way is to troubleshoot this in E2K3 is you can use MFCMapi to dump the named props table.
Help on MFCMapi below:

Run MFCMapi and then open your mailbox and run “Property Pane”/”Find All Named Props (SLOW)”, it should dump all 

Now you have the job to sort which application (spam software, archiving, Disclaimer) does eat most of the property quota and delete them. Idea behind dumping is to look at the props and figure out what program they are for and fix it. 

CopyLargeNamedPropertyToDebugOutput – Demonstrates how to read a large named MAPI property by using IStream
Best way is to troubleshoot this in E2K7 is codeplex (Not my finding, but have seen users with positive output)
How do you delete this unwanted or piled up named properties? 

Download Codeplex and run it on the server which is responsible for receiving internet emails (gateway server). 

Help on Codeplex below: 

HeaderFilterAgent for Exchange 2007: http://www.codeplex.com/HeaderFilterAgent  

Got bored ?? Lets see how to identify and resolve this issue !! 

This event id appears when database reaches maximum limit of named properties or replica identifiers and should be treated with priority. Yes we have some more events 9666, 9668, and 9669… They all tell you nothing different !!!

Event ID     : 9667 

Raw Event ID: 9667 

Record Nr.   : 164428077 

Category     : General 

Source       : MSExchangeIS 

Type         : Error 

Generated    : 2/28/2009 11:55:04 AM 

Written      : 2/28/2009 11:55:04 AM 

Machine      : EXCHANGE2K3 

Message      : Failed to create a new named property for database “First Storage Group\County Mail” because the number of named properties reached the quota limit (8192). User attempting to create the named property: “SYSTEM” Named property GUID: 00020386-0000-0000-c000-000000000046 Named property name/id: “x-vitals” 

Suggested Action: 

1. Change the Registry value of Named Props Quota to 16384 by going to following location in registry 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-00000000-0000-0000-0000-00000000 

2. Increase the Registry value of NonMAPI Named Props Quota to 16384 

3. Dismounted and remount the store 

PFA Screenshot: 

Path to follow in registry

Path to follow in registry

I’ve done this but issue still persists!!! 

Dont take a second opinion… get rid of the database before users start getting NDR’s 

To split the database:   

  1. Create 2 new mailbox stores on the same server or a different Exchange Server.
  2. Move 50 % of mailboxes from the database to the new mailbox store and the remaining ones to the second one.
  3. Make sure you right click on Mailboxes under Mailbox Store and RUN CLEANUP AGENT.
  4. Bottom line, we  should not allow a particular mailbox store database to grow more than 50 – 60 GB : http://technet.microsoft.com/en-us/library/aa996891.aspx

I’ve done this too !!! Im still getting these !!! help….. 

I wish I knew the answer…. :-(

You’ll have to consider opening a support incident with Microsoft PSS and they will dump the Prop Limit and advise further…

Ratish 

9 Responses to “Event id: 9667 – When database reaches maximum limit of named properties or replica identifiers”

  1. Ethan Says:

    I did this and it worked. Thanks for the info. Was really helpful.

  2. Paul Says:

    Good stuff… but can you identify how to solve the ‘new stores’ issue in Exchange 2003 SP2 on SBS? (Apparently limits to one public and one provate store?)

  3. Ratish Says:

    Comeon Paul… Thats by Design for SBS Exchange STD…. go for a E2K3 Ent or jump to E2K7 STD/ENT!!! :-)

  4. Guru Says:

    Paul,

    SBS is ideally considered for small companies with few Users and the limit which named props has should be more than enough for a long long time to be consumed by the store

  5. Brian Says:

    Hi ratish.I salute your knowledge ! great job
    Brian Mason
    MS Exchange consultant

  6. DIFFMEISTER Says:

    A similar issue and a way to resolve it.

    The official document can be found here for anyone who’s interested.

    http://technet.microsoft.com/en-us/library/bb851493%28EXCHG.80%29.aspx

    Hope this helps!!

  7. Ratish Sekhar Says:

    Hi DIFFMEISTER, Its the same registry I have mentioned in this article…
    Thanks anyways….

  8. Error 9667 on SBS 2003 box | Resellernews.com.au Says:

    [...] followed the KB, but the errors continued. later I found this on MSExchangeGuru.com blog:http://msexchangeguru.com/2009/09/04/event-id-9667/. So far no more [...]

  9. Named Props Quota in Exchange 2007, SP1 RU8 and beyond « MSExchangeGuru.com Says:

    [...] Ratish post here has already detailed about Named Props Quota and the trouble it creates for the Admins in Exchange 2003 and 2007 and so, I am not going to dive into it now. But the good news is that Exchange 2007 SP1 RU7 and Exchange 2007 SP2 has got in some improvements, but at the same time, not with problems. [...]

Leave a Reply