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
Blacktoe - No. Nothing removes existing properties.
Devin - Not at the moment. I'm well aware of the issues regarding property promotion and control and a user defined preregistration list is something we are examining
Peter - No, nothing removes existing properties and so you cannot revert the change. The header filter agent should be largely unecessary.
LarryH - Bill Long owns the header filter agent, I can't speak for how he would/would not want to modify it.
Johnny - the answer to why we don't recycle involves more background teaching on the named property assignment method than I can dole out in a post. Rollover would be 100% disaster. No need to trust me on this, confirm this for yourself: Use MFCMAPI and open a brand new database. Of the 1400 and some change props preregistered, I'll bet most of them you'd preferr not be corrupted by assigning them out again.
As for build in limitations, I stand by my tenants for dealing with system limits:
A system administrator can run a healthy, available system even in the face of system limitations given three basic things - First, an understanding that the limitation exists and what it is. Secondly, appropriate tools for monitoring the system's use in regards to the limit. Lastly, an administrator needs the ability to control and limit (or expand) his exposure to the limiting event.
We're providing the first and third. As for monitoring...that you will have to wait for.
Devin - Not at the moment. I'm well aware of the issues regarding property promotion and control and a user defined preregistration list is something we are examining
Peter - No, nothing removes existing properties and so you cannot revert the change. The header filter agent should be largely unecessary.
LarryH - Bill Long owns the header filter agent, I can't speak for how he would/would not want to modify it.
Johnny - the answer to why we don't recycle involves more background teaching on the named property assignment method than I can dole out in a post. Rollover would be 100% disaster. No need to trust me on this, confirm this for yourself: Use MFCMAPI and open a brand new database. Of the 1400 and some change props preregistered, I'll bet most of them you'd preferr not be corrupted by assigning them out again.
As for build in limitations, I stand by my tenants for dealing with system limits:
A system administrator can run a healthy, available system even in the face of system limitations given three basic things - First, an understanding that the limitation exists and what it is. Secondly, appropriate tools for monitoring the system's use in regards to the limit. Lastly, an administrator needs the ability to control and limit (or expand) his exposure to the limiting event.
We're providing the first and third. As for monitoring...that you will have to wait for.