Indexed Search With MAPI and Exchange


In Outlook 2013, we took a change to improve how we build search folders when searching against Exchange 2010 and higher for text we’d expect to find in commonly indexed fields. Prior to this change, we’d build a search folder restriction that looks like this:

PR_SUBJECT contains ‘text’ || PR_BODY contains ‘text’ || PR_SENDER_NAME contains ‘text’ || …

If you use Outlook 2013 and create an online search folder (say, by just doing a search), then look in MFCMAPI, you’ll find the search criteria is greatly simplified:

0x0eaf001f contains ‘text’

Development has allowed me to document this property:

#define PR_SEARCH_ALL_INDEXED_PROPS_W PROP_TAG(PT_UNICODE, 0x0EAF)

Use of this property in building your searches has a few benefits:

  • Your restriction is greatly simplified
  • The Exchange server can better understand the intent of the search and use this to better optimize it.
  • As new properties are indexed on the server side, the utility of your searches increases without rewriting client code.

This property will work against Exchange 2010 and higher.

Comments (4)

  1. Dmitry Streblechenko says:

    This would not work against a cached store, would it?

  2. Hari says:

    I tried understanding this further when I search "body:(k1 k2 k3 k4 k5)" i get these additional content restrictions listed with below tags vs "k1 k2 k3 k4 k5" which uses just 0EAF001F

    80EC001F

    80E9001F

    80ED001F

    80EE001F

    80EB001F

    80EA001F

    Any ideas what these are related to?

  3. Those would be named properties (the ID is > 0x8000), so the values are meaningless in isolation. You can map the ids back to names in your environment, which may shed some light on what that restriction is about.