I have an Exchange 2003 server, SP2 running on server 2003. I am watching the number of named properties steadily climb to the already raised quota. I did find a reference here: http://msexchangeteam.com/archive/2010/07/29/455687.aspx to a hotfix, found here http://support.microsoft.com/default.aspx?scid=kb;EN-US;972077 , that would allow me to prevent these from being created. I installed the hotfix and modified the registry per the article. However, the number of named properties is still climbing. I reinstalled and re-booted the server and am now monitoring. Any insight into why I am still getting the climb in the number of named properties even after installing the hotfix? Thanks, Paul

Incrising name properties quota will be a workaround only however in somecases it is require. Going forward you should investigate what program may be exhausting the named properties available, typically you can find references to the offending program in the events. for advance troubleshooting you can access the named properties table via MFCMapi for investigation. I have seen third party apps causing these issues, please check for those as well. Best Rgds, Ashish | Unified Comunication | MCTS | MCITP | Please remember to select option "Propose As Answer" if solution work for you | My posts hold no assurances, no promises, and they measured no rights.

There are multiple methods in which named props are added to the DB. I highly doubt the hotfix stops all methods. Exchange 2003 is more limited in handling named props compared to 2007 and 2010, some by design and some due to diminishing support of the product version. What you really need to do is stop it at the source. Run MFCMapi and then open your mailbox and run “Property Pane”/”Find All Named Props (SLOW). Then identify where the named props are and where they're coming from.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Hi Paul, Any update for your issue, above gave some good information. Some other tips for you: http://support.microsoft.com/kb/820379 Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Ok Guys, I'll have a hard run at MFCMapi. Will update with the results. -Paul

I installed and ran MFCMapi. Interestingly, checking perfmon, no named properties were added since I reinstalled and rebooted the hotfix. What I am seeing is a large number of named properties where the property name is incrementing, the type is always PT_ERROR, the value is always ERR:0x80070005=MAPI_E_NO_ACCESS, the Guid is always the same so it looks like {guid#}=PS_INTERNET_HEADERS, and finally the named prop name changes and is in the form of sz: "x-<random letters>" like "x-zoml". Sound familiar? Is there any way to see where these come from? Any suggestions?

What third party email apps do you have including outlook add ins? The hotfix and registry only stops internet X headers from being added to named props table. MAPI and authenticated promotions still occur. These are hard to identify the source. What you can try doing to try to isolate the app or source is to create a blank mailbox, do a named prop dump to get the base count, then send some test emails internally, externally, disabling AV etc and see which type of emails are generating the random named prop.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

No growth again in the last 24 hours. I'm wondering if the last reboot didn't do it. If the Guid on these is always PS_INTERNET_HEADERS, does that indicate that these are internet X headers or can this be created internally. If I could get a read on what type of client would create this it would narrow down my search. Is there really no debug logging that would tell me who/what/when named props are being created? This is a virtual server, so it really wouldn't be a problem to create a new hard drive on the array and dump as much logging as I need to it. -Paul

my understanding says that PS_INTERNET_HEADERS are indexed by the MAPI Protocol Handler. These properties are read-only. There must be debug tools however i believe only PSS guys can study output logs.Best Rgds, Ashish | Unified Comunication | MCTS | MCITP | Please remember to select option "Propose As Answer" if solution work for you | My posts hold no assurances, no promises, and they measured no rights.

The properties you described sound like those that would be generated by inbound e-mail during SMTP/MIME -> MAPI conversion. These are the x-headers that Jason discusses in the Ehlo article. This is the sort of thing the 972077 hotfix was designed to address. I'm not sure why it didn't appear to take effect after the first reboot.

Still not seeing further growth in named properties, so I think you are right. After the hotfix is applied and the server rebooted I added the registry setting. I wonder if it was that I didn't restart any services or reboot after the registry entries. It is a little ambiguous in the article 927077 and if a reboot or service restart is required then the article should be updated. I'll leave feedback on the article. Thanks everyone for the help! -Paul

Are you referring to the registry key that was referred to within the 972077 article? "GenerateNamedProperties" Did you leave it set at 0 per their recommendation? Gene