Topic Last Modified: 2007-09-24

This topic provides information about Events 9666, 9667, 9668, and 9669 that may be logged in your Exchange server's Application log. These events are logged when a database on an Exchange server with the Mailbox server role installed approaches or reaches the maximum limit of named properties or replica identifiers. To learn more about named properties and replica identifiers, see Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases.

Warning Events 9666 and 9668

When a new named property or replica identifier is created for a mailbox or public folder database and the quota warning threshold is reached, the warning Event 9666 or 9668 is logged in the event log. The threshold warning is 20 entries less than the configured quota. The named property or the replica identifier will be created successfully. You may see one or both of the following events in the Application log when this happens:

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

    Important:
    There are separate limits for authenticated named properties and named properties that are not authenticated. Event 9666 is logged for both types of named properties. You need to correlate the configuration values in your server's registry to the event description to determine which pool of named properties is exhausted.
  • Event ID: 9668

    Type: Warning

    Category: General

    Source: msgidReplidsQuotaWarning

    Description: The number of replica identifiers created for database "<database name>" is close to quota limit. Current number of replica identifiers: <number of replica identifiers>. Quota limit for replica identifiers: <configured quota>. User attempting to create the replica identifier: <user name>.

Error Events 9667 and 9669

If the database has reached the named property or replica identifier quota limit and an attempt is made to create a new named property or replica identifier, the error Event 9667 or 9669 will be logged in the event log. The named property or the replica identifier will not be created successfully. You may see one or both of the following events in the Application log when this happens:

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

    Important:
    There are separate limits for authenticated named properties and named properties that are not authenticated. Event 9667 is logged for both types of named properties. You need to correlate the configuration values in your server's registry to the event description to determine which pool of named properties is exhausted.
  • Event ID: 9669

    Type: Error

    Category: General

    Source: msgidReplidsQuotaError

    Description: Failed to create a new replica identifier for database "<database name>" because the number of replica identifiers reached the quota limit (<configured quota>). User attempting to create the replica identifier: <user name>.

In addition, any MAPI clients, such as Microsoft Office Outlook, that attempt to create named properties may receive the error code 0x80040900 (-2147219200 in decimal). This error code corresponds to MAPI_E_NAMED_PROP_QUOTA_EXCEEDED. This error is typically received when the user attempts to send a new message or save a new message in the user's Drafts folder.

Resolution

It is simpler to recover from the situation where a database reaches the configured quota for named properties or replica identifiers. If the database reaches the absolute maximum of 32,766, the recovery process is more complicated and is more disruptive to your Exchange environment.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

  • Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Recovering from Reaching the Configured Quota for Named Properties or Replica Identifiers

If you are receiving the warning Event 9666 or 9668, you can increase the configured quota for the named properties or replica identifiers to prevent interruption to the Exchange production environment. Because the configuration requires you to dismount and remount the databases, you should schedule a maintenance window at the earliest time your change management process permits. If you are receiving the error Event 9667 or 9669, it is likely that your users are already receiving errors and you should implement an emergency maintenance operation to increase the configured quotas. For detailed steps about how to increase the quotas for named properties and replica identifiers, see How to Configure Named Properties and Replica Identifier Quotas for Exchange 2007 Databases.

Important:
Do not increase the quotas to the hard limit of 32,766 entries. If you must increase the default quota for either named properties or replica identifiers, you should identify the root cause for the situation and not allow the named properties or replica identifiers to reach the maximum limit.

Recovering from Reaching the Hard Limit of 32,766 Entries for Named Properties or Replica Identifiers

If all named properties or replica identifiers are exhausted for a database, you must perform a recovery process, which is disruptive to your Exchange environment.

To recover a mailbox database

  1. Create a new mailbox database on the same server or a different Exchange server with the Mailbox server role installed.

  2. Move all mailboxes from the database you need to recover to the new mailbox database.

  3. On the Exchange server that has the mailbox database you need to recover, do the following:

    1. Dismount the mailbox database you need to recover.

    2. Delete the database file that corresponds to the mailbox database you need to recover.

    3. Mount the mailbox database. This creates a blank database file for the mailbox database.

  4. Move all the mailboxes back to the recovered blank mailbox database.

To recover a public folder database

  1. Create a new public folder database on a different Exchange server with the Mailbox server role installed.

  2. Configure replication between the public folder database you need to recover and the new public folder database you created. For detailed steps about configuring public folder replication, see How to Configure Public Folder Replication.

    Important:
    If you already have replication configured for your public folders, it is likely that the other public folder databases in your organization also contain the items that used up the named properties and will also reach the hard limit. Recovering from this situation requires you to configure aging on your public folders so that older content that is not being accessed and might be consuming named properties is purged. Alternatively, you can also distribute the contents of the public folder database across multiple public folder databases.

  3. After all the content is replicated, do the following on the Exchange server that has the public folder database you need to recover:

    1. Dismount the public folder database.

    2. Delete the database file that corresponds to the public folder database you need to recover.

    3. Mount the public folder database. This will create a blank database file for the public folder database.

  4. Allow the content to be replicated back to the recovered public folder database.

Recommended Follow-Up

After you recover from the depletion of named properties or replica identifiers, you should attempt to discover the reason why an increased number of named properties or replica identifiers are used. First, you should use Performance Monitor to closely monitor the rate at which the named properties and replica identifiers are created in your environment.

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.

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

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

If you are unable to determine the root cause, and if the number of named properties and replica identifiers created on your servers continue to rise, contact Microsoft Customer Service and Support. For information about how to contact support, visit Microsoft Help and Support.

For More Information

For more information about managing databases, see Managing Storage Groups and Databases.

To learn more about the security and protection features in Exchange 2007, see Security and Protection.