Partager via

Indexed Search With MAPI and Exchange

  • Article

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

  • Anonymous
    November 08, 2013
    This would not work against a cached store, would it?

  • Anonymous
    November 08, 2013
    No - it's online only.

  • Anonymous
    April 09, 2014
    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?

  • Anonymous
    April 10, 2014
    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.