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
-
Create a new mailbox database on the same server or a different Exchange server with the Mailbox server role installed.
-
Move all mailboxes from the database you need to recover to the new mailbox database.
-
On the Exchange server that has the mailbox database you need to recover, do the following:
-
Dismount the mailbox database you need to recover.
-
Delete the database file that corresponds to the mailbox database you need to recover.
-
Mount the mailbox database. This creates a blank database file for the mailbox database.
-
Move all the mailboxes back to the recovered blank mailbox database.

To recover a public folder database
-
Create a new public folder database on a different Exchange server with the Mailbox server role installed.
-
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.
|
-
After all the content is replicated, do the following on the Exchange server that has the public folder database you need to recover:
-
Dismount the public folder database.
-
Delete the database file that corresponds to the public folder database you need to recover.
-
Mount the public folder database. This will create a blank database file for the public folder database.
-
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
-
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.
-
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.
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.