Folders Don’t Do Named Props

A fellow engineer recently asked me how to set custom properties on a folder object in a PST. I reminded him that folders in the PST provider don’t support named properties. He was surprised to hear this. I was surprised to learn that this hadn’t actually been documented before. (If anyone can produce a link to previous documentation on this I’d be grateful!)

Neither the Exchange provider (emsmdb32.dll) or the PST provider (mspst32.dll) support named properties on folders. Both will allow you to call GetIDsFromNames and GetNamesFromIDs, but neither will allow you to set a property in the 0x8000 to 0xFFFE range. This is contrary to the MAPI documentation, which suggests that providers which support named properties would support them for both message and folder objects.

If you attempt to set a named property on a folder in a PST or cached mode (which is built on top of the PST provider), then you will get MAPI_E_NO_ACCESS in the SPropProblemArray structure returned by SetProps.

If you attempt to set a named property on an Exchange folder, you will get MAPI_E_NO_SUPPORT in the problem array.

Note that the documentation for Named Properties in the MSDN indicates that providers should return MAPI_E_UNEXPECTED_ID if they do not support named properties, so these error codes would appear to be, well, in error. However, I do not believe this is the case since the providers certainly do support named properties. They just don’t support them on certain objects, a case the documentation doesn’t allow for.

Comments (7)

  1. Chas Hayden ( says:

    How do I programatically resolve the Name of a PST File or Folder, (inside Outlook) with the actual PST file name and path? I am only looking to write a simple VBA app within Outlook 2003, that can perform archiving in a way I specify. When I create a PST with AddStoreEx I give it a path to create the file, but it just shows up as ‘Personal Folders’ regardless of path I set. I can of course rename ‘Personal Folders’ with the name property, but now how can I be sure its the right one, because I can’t retrieve the actual file path anymore. Am I stuck with doing each one, one at a time, and hope I don’t leave a stray ‘Personal Folders’ PST unnamed?

    It would be great if the MAPIFolder object had a FilePath and FileName property, or a Store Object with such properties.

  2. This is a MAPI blog – I don’t do the OOM much. Sorry.

  3. Sue Mosher says:

    Chas, if Stephen doesn’t mind my jumping in, take a look at, which is a VBA code sample for adding a new .pst file with a specific display name. The trick is to check StoreID values before and after to be sure you have the new store.

  4. Venkat says:


    Then what is best way if I want to store something on a mapi folder ?

  5. Paul-Jan Pauptit says:

    The consensus on the MAPI-L mailing list seems to be that named properties work just fine for folders inside a PST.


    Perhaps something changed since you wrote this article? It is rather important that we get to the bottom of this, as this 2006 blog post is the single most credible source on the topic. As far as I know it still isn't documented.

  6. Hrm. Looks like perhaps things have changed. However, I see no urgent need to investigate this. Dmitry's right – you're still better off using a hidden message rather than depending on behavior that can vary from store to store.