locked
number of named properties reached the quota limit (8192) on Exchange 2003 RRS feed

  • Question

  • I am getting the message below on Exchange 2003 server, I read a few articles on named properties and I am not sure exactly what the whole thing is about.  At this point it looks like things are chugging along fine, not sure if there is any loss of functioality at this point, if there is anything major looming, or what the best way to approach this would be.

    Event Type: Error
    Event Source: MSExchangeIS
    Event Category: General
    Event ID: 9667
    User:  N/A
    Computer: servername
    Description:
    Failed to create a new named property for database "First Storage Group\Mailbox Store (servername)" because the number of named properties reached the quota limit (8192).
     User attempting to create the named property: "username"
     Named property GUID: 00020386-0000-0000-c000-000000000046
     Named property name/id: "x-starscan-received"

    For more information, click http://www.microsoft.com/contentredirect.asp.

    Monday, September 17, 2012 4:49 PM

Answers

  • I found my own answer, below are 3 sites compiled into one holistic answer

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

    UPDATE
    30/07/2010
    : See Enhancements
    in Exchange 2007 SP2 for Named Props Quota

    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.



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

    ######UPDATE######

    As
    per:

    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

    To use Performance Monitor to
    monitor the rate at which the named properties and replica identifiers are
    created in your environment:



    1. Enable
           additional Microsoft Exchange Information Store service logging
           on the Exchange server that you need to monitor. For detailed steps
           about enabling additional Microsoft Exchange Information Store
           logging, see the Microsoft Knowledge Base article 254606, 
      XADM: How to Enable Additional Information Store Logging.<<below

     



    1. Start Registry Editor (Regedt32.exe).
    2. Locate the Library value under the following
           key in the registry:

               
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Performance
    3. On the Edit menu, click String.

               

               
      For Microsoft Exchange Server 5.5:

                Change the value from
      c:\exchsrvr\bin\mdbperf.dll to c:\exchsrvr\bin\mdbperfX.dll, and then click OK.

               

               
      For Microsoft Exchange Server 2000 and Microsoft
           Exchange Server 2003
      :

                Change the value from
      c:\Program
           Files\exchsrvr\bin\mdbperf.dll
      to c:\Program Files\exchsrvr\bin\mdbperfX.dll, and then click OK.

               

               
      For Microsoft Exchange Server 2007:

                Change the value from
      c:\Program
           Files\Microsoft\Exchange
           Server\bin\perf\%PROCESSOR_ARCHITECTURE%\mdbperf.dll
      to c:\Program
           Files\Microsoft\Exchange
           Server\bin\perf\%PROCESSOR_ARCHITECTURE%\mdbperfx.dll
      , and then click OK.
    4. Quit Registry Editor.

     

    Pasted from <http://support.microsoft.com/?kbid=254606>

     

     



    1. Use
           Performance Monitor to capture performance counter values. For more
           information about using Performance Monitor, see
      Monitoring server performance. Capture the values for the
           following performance counters:

      • MSExchangeIS Mailbox\Rows in
              NamedProps Table
      • MSExchangeIS Mailbox\Rows in
              ReplidMap Table
      • MSExchangeIS Public\Rows in
              NamedProps Table
      • MSExchangeIS Public\Rows in
              ReplidMap Table


    Analyze the performance data
    you captured to identify trends and try to find a correlation between the
    increases in these counters over time with the activity on your network.

    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…

     

    Pasted
    from <http://msexchangeguru.com/2009/09/04/event-id-9667/>

     

     

    We can check the GUID for each mailbox store by ADSIEDIT tool.

     

    If you are running Exchange 2003, here is detailed steps for your
    reference:

     

    1. On Exchange Server 2003, click Start -> Run, type
    “adsiedit.msc” and press OK to open ADSI Edit utility.

     

    Note: The ADSI Edit tool is included with the Windows Support
    Tools. To install the Windows Support Tools in Microsoft Windows 2000,
    double-click Setup.exe in the Support\Tools folder on the Windows 2000 Server
    CD. To install the Windows Support Tools in Microsoft Windows Server 2003,
    double-click SUPTOOLS.MSI in the Support\Tools folder on the Windows Server
    2003 CD.

     

    2. Navigate to: Configuration
    >> services >> Microsoft Exchange >> First Organization
    >> First Administrative Group >> Servers >> Server name
    >> InformationStore >> First Storage Group >> Mailbox Store.

     

    3. Right Click on the Mailbox Store object and select
    Properties.

    4. Please find the “ObjectGUID” value.

     

    Pasted
    from <http://social.technet.microsoft.com/Forums/en-US/exchangesvrgeneral/thread/a0bda30b-ac9f-4405-813e-6710b8e28765>


    • Marked as answer by wwodzien Wednesday, September 19, 2012 2:01 PM
    Wednesday, September 19, 2012 2:01 PM