Custom UserProroperty removal from mailitems - need expertise.

[piotrck]

Hello Guys,
I have came across MFCMAPI when a bug has been discovered in Outlook add-in by exceeded amount of custom properties. I found some ways how to remove those properties both programmatically and by using MFCMAPI, removing them manually. However, when I tried to compare lists generated in MrMapi that contains named properties I see no difference i.e. I can see the same custom property, even though I have removed this property from email and there is no evidence of removed custom property in that email what make me little bit uncertain whether MFCMAPI tool actually works.

Is any one have more knowledge that me and would share some information how MFCMAPI deletion works?

Thank you in advance!
Piotr

[EinmalIM]

Hi Piotr,

if you run in an error, that no more custom properties can be created, I don't think that deleting a custom property will help. Under the hoods Exchange accesses properties through 16-bit IDs. Roughly properties from 0x1 to 0x7fff are predefined and custom properties start from 0x8000. They need to be mapped to either a custom id or name. Whenever a new custom property is used, Exchange will reserve an ID and map it to that property per mailbox. So each custom property will get a unique property ID >= 0x8000. That mapping is not removed when you remove the value of a custom property from an item. So you have a limit of around 32k custom properties per mailbox. Could that be your problem?

Regards
Sven

[piotrck]

Hello EinmalIIM,
Thanks for your reply, I did not provide too much details but you are quite right, there is a number of unique properties starting 0x8000 which are generated by plugin. I tried to follow Microsoft documentation and found a methid UserProperties.Remove.
https://docs.microsoft.com/en-us/office/vba/outlook/how-to/navigation/deleting-a-property
Next, I wrote little console app and I did run through all custom properties, it finds it and seems to removing them but as I mentioned it did not change anything. The user can send or receive email but cannot receive an invite for a meeting. This is very annoying, the error is
554 5.2.0 STOREDRV.Deliver.Exception:QuotaExceededException.MapiExceptionNamedPropsQuotaExceeded.

Could you please share how we can possibly overcome this problem, for example, is it possible to increase number of custom properties in mail headers in Outlook 365 or is it possible to remove them in other way?

I highly appreciate your help.

Best,
Piotr

[bradhugh]

Hi Piotr,

Removing unnecessary custom properties from the items (all of the items), is the correct first step to recover from this scenario. However, to actually reduce the number of custom "named" properties that are in-use, the named property table has to be rebuilt. The supported way to do this is by moving the mailbox to a new database in Exchange in a special way called a "non-signature-preserving" move. Specifically, this is using New-MoveRequest or New-MailboxRelocationRequest with -DoNotPreserveMailboxSignature. This is available to Exchange on-premises administrators, but is not available to tenant admins in Office 365. If this is Exchange Online / O365, you'd need to work with support to get them to file an escalation to have this kind of move done on your behalf.

Brad

[piotrck]

Good afternoon @bradhugh ,
I am very thankful and grateful that you and @EinmalIM made all the effort to explain the source of this problem as well as provide steps to recover from this scenario. I have requested my colleague for database migration and this has made this trick with migration working, I was hoping this will work but waited for official information until today, finally mailbox back to working state.

I know it is bit out of the topic but do you possibly know how custom properties can be saved in safe manner without the risk of getting into the same trouble. At the moment, we have gone away of saving any custom properties in militem until we find better solution (not on local machines).

Thank you very much for your help!

[bradhugh]

@piotrck Saving custom properties is completely fine, but you should only create a few for your application. Each property is made of an Guid / ID (int) pair or a Guid / Name (string) pair which uniquely identifies your property. You should use a static GUID for your application and define all your custom properties within that namespace. For most applications, you should be able to achieve your goals with less than 5 custom properties. The important thing to note is that the property identities (whether Guid/Name or Guid/Id) should be statically defined within your application; they should never be dynamically generated. If you think about it as a dictionary, the property identity is the key. Without this key, you can't efficiently search against or obtain the value of your property. You can store whatever data you want within the property value, but you shouldn't attempt to store any data in the key (property identity). Let me know if this makes sense. If you have any scenario questions, happy to try and answer. Microsoft also offers developer support that can assist with these kinds of things.