Is public folder replication failing on your Exchange 2000 server? Do you notice the following events in your application log when you turn up diagnostic logging on the problem server?
Event id 3086 and Event id 3085:
Category: Replication Errors
Source: MSExchangeIS Public Store
Type: Warning
Message: Error 0x8007000e occurred while generating an outgoing replication message.
3086 and 3085 events occur for different reasons and each reason has a unique code. The code for this particular problem is 0x8007000e which translates to MAPI_E_NOT_ENOUGH_MEMORY. But please don’t go buying more memory sticks to slap onto your server because the problem isn’t memory depletion. The problem is that you have run out of a particular type of MAPI Property ID referred to as the Named Property (While it is possible to get this error because of a low memory condition on your server, you will likely find out about memory problems in more rude and obvious ways). MAPI has a tendency to present generic error codes for various error conditions and MAPI_E_NOT_ENOUGH_MEMORY tends to be the ‘catch all’ error code for every kind of resource constraint. In this situation the scarce resource is property IDs. I figured this out by doing a live debug on one of our customers’ servers during the wee hours of the night, the only time they would let me do this.
The MAPI specification defines two kinds of properties. Standard MAPI properties and named properties, commonly known as named props. As per the description in Inside MAPI a named property is a custom property that is known by name rather than a hard-coded ID. Although MAPI defines a property tag for almost every imaginable purpose, it also allows vendors to extend the predefined property set by creating their own properties or publishing the property type and a string or numeric name. But access to any property is based on the property ID, not the name, so how do you Get or Set a named property? A client or service provider that needs to access a named property must ask the object on which the Get or Set Props call is made to create an ID corresponding to the published name. Only the property name is fixed; the ID is dynamically created. The ID must be produced by the provider, which must maintain its own internal mapping of names to IDs. The range for named props is 0x8000 to 0xFFFF giving a provider an effective range of 32766 possible entries from which to allocate and return IDs to clients.
The Exchange information store uses named props/prop IDs extensively for tasks such as processing SMTP X-headers (custom headers used by applications and institutions as opposed to standard headers like To: From: Date: etc) and DAV properties that are not well known. For example if you send a message to a public folder and the message has an SMTP X-header “X-spam-confidence level” that your company uses internally a named prop is created. Over time heavy usage of named props can result in a self Denial of Service attack. In Exchange 2000 the default prop ID limit for each MDB (database) is 32k and cannot be changed. Once the limit of 32k has been reached unfortunately the only recourse is to save off the public folder content you need to PST files, delete the public folder store, create a new one and finally allow it to build back up via replication from other public folder servers. The good news is that Exchange 2003 allows you to set lower quotas for prop IDs so that you have more flexibility if the problem ever happens. By setting the values lower an Administrator is alerted to about the depletion and can take action before the range of IDs is exhausted. This can also help you stave off malicious Denial of Service attacks. See article 820379 in our public knowledge base for details on how to configure these quotas.
- Jasper Kuria
