Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Topic Last Modified: 2009-07-15

Microsoft uses the Messaging API (MAPI) as a means to connect different messaging transport components. The MAPI specification represents most objects as properties. To identify these properties, MAPI uses identifiers, known as property identifiers or PropIDs.

Property identifiers are a set of hexadecimal values that range from 1 to 0xFFFF. This allows for 65,534 properties. These properties are divided into the following groups, known as ranges:

The properties in these ranges are known as standard properties. Standard MAPI properties have fixed IDs and represent all properties that are below 0x8000.

In addition to these ranges, there is one other range. This range is the largest and represents all properties that are at 0x8000 and above. The properties in this range are known as named properties. Named properties provide a way for vendors to extend the standard MAPI property set by adding their own properties.

Named properties are made up of the following two main types:

Because the named properties do not have specific IDs assigned, MAPI provides a facility to dynamically create unique IDs for named properties and to maintain a persistent mapping between a named property and its unique ID. However, the dynamic creation of these IDs means that the property IDs for named properties can vary from computer to computer.

The Microsoft Exchange Information Store service maintains a table of named properties for each database. When the information store processes a message that contains custom information, the store automatically adds an entry to the named properties table for any custom property that has not been previously processed.

Messages that are sent over the Internet are transferred in a format that is known as Message/RFC822. This is a text format that includes messages in plain text together with headers that contain a set of key and value pairs. RFC822 includes support for a set of properties that are called X-headers.

To translate messages from Message/RFC822 format to MAPI format, Exchange uses a component that is called Imail. Imail takes the key values pairs from an RFC822 message, and, if possible, translates the key value pairs into MAPI properties. Imail also provides the reciprocal translation, taking MAPI properties and translating them into RFC822 key value pairs.

Starting with Microsoft Exchange 2000 Server, the Imail component included supporting headers that are called "Ad-hoc" headers. These are headers that Exchange preserves for possible future uses. One of the header types that was included in the Ad-hoc header definition was X-headers. Therefore, Exchange stored the X-header information for later usage. 

For example, if a company implemented a new application that integrates with Exchange and used an SMTP X-header, the Microsoft Exchange Information Store service created a named property for that custom information when it processed the first message that contained the X-header.

Any subsequent messages that include the same X-header do not cause Exchange to create additional named properties.

Exchange stores these named properties with the message(s) that contain the particular X-header. Microsoft published the PS_INTERNET_HEADERS namespace to group the X-headers from messages that were received over the Internet.

Named Properties Limits

The following list summarizes some important points about named properties:

  • X-headers are fields in Message/RFC822 messages that hold certain important values.

  • Named properties is the method that Exchange uses to reserve an ID for a particular value.

  • Named properties fall into the range of property identifiers from 0x8000 to 0xFFFF. Therefore, there is a limit to the number of named properties that may be created in a messaging database (MDB).

  • After a named property has been allocated, it may not be deallocated. The property remains reserved for the particular name and GUID combination.

    It is technically possible to recover allocated named properties. However, the process is impractical and would require dismounting the MDB for as long as it took to examine each message to determine which properties were unused.

Because there are a fixed number of named properties available, Exchange uses a quota system to track the number of allocated named properties. In this system, the Store.exe process warns you when available named property IDs are close to becoming exhausted. When a second threshold is reached, the Store.exe process no longer allocates named property IDs.

Named Property Exhaustion

Although many programs use named properties, Microsoft Outlook is the largest user of named properties. When named property IDs become exhausted, Outlook cannot map a named property. In this scenario, you may experience symptoms that resemble the following:

  • Event IDs 9666 and 9667 are logged in the Application log. For more information, see Events 9666, 9667, 9668, and 9669 Received When Named Properties or Replica Identifiers Are Depleted for An Exchange Database.

  • Messages that contain properties that cannot be mapped are not delivered. When you examine the message tracking information for an affected message, you notice information that resembles the following:

    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:

  • When an add-in that adds named properties or X-headers to messages is installed in Outlook, certain messages may not be sent to other users in the organization. In this scenario, the sending user receives a non-delivery report (NDR) that resembles the following:

    The message reached the recipient's e-mail system, but delivery was refused. Attempt to resend the message. If it still fails, contact your system administrator.

Replica Identifiers

The issue that limits the availability of named properties also affects public folder replica identifiers. There is a maximum limit of 32,767 property IDs for each database. When this limit is reached for a specific database, Exchange can no longer create any new property IDs.

If this issue occurs on a mailbox database, you must create a new mailbox database, move all the mailboxes to the new database, and delete the mailbox database that has reached the limit for property IDs. Then you may create a new mailbox database and move the mailboxes back to that mailbox database.

If the issue occurs on a public folder database, the recovery process is more complicated. In this scenario, you must replicate all public folders to another server and then delete the affected public folder database. You can then allow the content to be replicated back to the original server. However, 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. These databases will have also likely reached the configured ID limits. To work around this issue, you must configure aging on the public folders so that older content that is not being accessed and that may be consuming named properties is purged. Alternatively, you can also distribute the contents of the public folder database across multiple public folder databases.

By default, Microsoft Exchange Server 2007 has a quota of 16,384 for named properties that are created by authenticated users and replica identifiers. The default quota for named properties created by users who are not authenticated is 8,192. These default quotas allow you to receive earlier notification about the potential depletion of property IDs. You can then take action before the maximum limit is reached and renders the database inoperable. Therefore, the quotas can help you minimize the effects of a malfunctioning application or a malicious denial of service attack. You can also configure the quotas for the number of named properties and replica identifiers. For detailed steps about configuring quotas, see How to Configure Named Properties and Replica Identifier Quotas for Exchange 2007 Databases.

X-Header Changes in Update Rollup 8 for Exchange 2007 SP1 and Exchange 2007 SP2

Starting with Update Rollup 8 for Exchange Server 2007 SP1, changes have been made to the manner in which Exchange supports X-headers.

These changes are also included in Exchange 2007 Service Pack 2 (SP2).

In earlier Exchange builds, X-headers are promoted at the database level. Therefore, if a particular user maps a named property on a database, other users on that database receive the same property ID for the name and GUID combination. Update Rollup 8 and later updates implement new rules with respect to which activities may consume named properties to store X-header values.

If a named property for a particular X-header value has already been promoted on the database, Update Rollup 8 and later updates do not remove it. Existing X-header mappings are preserved. However, if Exchange receives a message that contains an X-header that has never been promoted on the database, the new X-header promotion rules take effect.

With the new X-header promotion rules, many scenarios that would cause new named properties to be consumed to preserve X-header data will no longer work. The following sections describe some of these scenarios.

Scenarios that no longer consume named properties to preserve X-headers

Anonymous submissions

Anonymous e-mail messages from the Internet no longer consume named properties for X-headers. Although existing X-header information from anonymous e-mail messages is retained, the value of X-headers is no longer saved as a property on the e-mail message.

Embedded messages

The embedded messages feature was created as an interoperability feature for MAPI applications. This feature allows you to set envelope or top level properties. Embedded messages no longer consume new named properties.

Journal messages

Journal messages represent the largest amount of X-header consumption in Exchange. Consider the following scenario:

  • You have 100 databases in your organization together with one journal database.

  • Each messaging database (MDB) is exposed to 100 new X-headers from the Internet per month.

In this scenario, the journal MDB is subject to 100 x 100 new X-headers each month. Therefore, it does not take long to exhaust the available named properties.

Although journal messages no longer promote new X-header mappings, journal content is still saved as expected. For example, journaled reports and messages are still saved.

Scenarios that still consume named properties to preserve X-Headers

Authenticated users

Authenticated users can still create messages whose X-headers will be promoted.

MAPI applications

MAPI applications can still create named properties. (These properties that are located in the PS_INTERNET_HEADERS namespace will be X-headers). Exchange Web Services applications that use property mappings can also create named properties. These properties may also be X-headers.

No changes have to be made to applications that use X-headers from MAPI. The application should correctly request the IDs of named property combinations. For example, the application should request PS_INTERNET_HEADERS and "X-<HeaderString>."

If you use the MAPI_CREATE flag in a request, the application will automatically add the particular X-header to the list of X-headers that are preserved in the MDB. Also, if the application sets an X-header from MAPI by creating a named property mapping in the PS_INTERNET_HEADERS namespace, then it already creates a mapping for the X-header. Exchange will preserve this mapping for incoming messages and generate the mapping for outgoing messages. 

If an application does not use MAPI_CREATE when it requests named property IDs and if it requests names that fall in the PS_INTERNET_HEADERS namespace and another client has not already requested the ID, the application will not work. However, after an authorized client or MAPI client requests the X-header by name, the application will work.

Property Changes in Exchange 2010

Exchange Server 2010 includes additional improvements to address the issues that are described in this document. In Exchange 2010, named property resources are moved to the mailbox level instead of to the database level.

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.