EDIT 8/10/2010: Please note that this blog post covers namely the history of named properties in Exchange. For updated and current guidance of how to deal with named properties issues, please see t...
Updated Jul 01, 2019
Version 2.0
Blog Post
A gratefully needed small step forward. These ridiculous inbuilt limits are incredible for an enterprise class messaging system.
There are still many others that make a sysadmin despair and lose confidence in the system. The current advice of moving users and recreating databases might be fine in small organizations, but makes me think that the system isn't 'fit for purpose' when dealing with millions of messages and tens of thousands of mailboxes. Whoever decided upon that should be castigated.
Why not a recycling of the named properties table? When the quota is breached. Replace the oldest. I appreciate a wholesale review of MAPI and it's antiquated limits would prove difficult.
Keep trying to alleviate the other ridiculous inbuilt limitations, rather than inappropriate "deal with it" advice. Well done.
There are still many others that make a sysadmin despair and lose confidence in the system. The current advice of moving users and recreating databases might be fine in small organizations, but makes me think that the system isn't 'fit for purpose' when dealing with millions of messages and tens of thousands of mailboxes. Whoever decided upon that should be castigated.
Why not a recycling of the named properties table? When the quota is breached. Replace the oldest. I appreciate a wholesale review of MAPI and it's antiquated limits would prove difficult.
Keep trying to alleviate the other ridiculous inbuilt limitations, rather than inappropriate "deal with it" advice. Well done.