Share via

Outlook 2003 Also Rules

  • Article

A little follow-up to the Outlook Rules post, concerning getting rules to fire when you’ve got a wrapped PST store. I had noted in the original post that rules “just worked” in Outlook 2003. Turns out I was partially right. They can work in Outlook 2003, but you have to do something a little special that I had somehow overlooked in my original investigation. Here’s how I explained your should fire a notification for Outlook 2003:

In Outlook 2003, the way you solve this is to use the IMAPISupport object that was passed to you during logon. From there, you would call Notify, passing fnewNewMail and the details of the new message.

The tweak here is in the structure you pass to into the Notify call. Since we’re passing fnevNewMail, we use a NEWMAIL_NOTIFICATION structure, which contains a ulFlags member. The only flag currently documented for this structure is MAPI_UNICODE. To get notifications working in Outlook 2003, we need to OR in a new flag, MSGFLAG_OUTLOOK_NON_EMS_XP. This flag has the same effect the NON_EMS_XP_SAVE flag has for Outlook 2007, which is to let Outlook know this message did not originate from the Exchange transport, so it knows rules need to be processed client side. This flag is only required for Outlook 2003, though we’ve seen no side-effect to also passing it in Outlook 2007. Unlike Outlook 2007, Outlook 2003 does NOT use the ITEMPROC_FORCE flag.

Definition of the new flag:

MSGFLAG_OUTLOOK_NON_EMS_XP 0x00010000 A client can call IMAPISupport::Notify with a fnevNewMail notification, passing MSGFLAG_OUTLOOK_NON_EMS_XP in the ulFlags member of the NEWMAIL_NOTIFICATION structure to indicate that the message is being delivered to a PST and should be eligible for rules processing.This flag is only available if the message is being saved to a PST.

We will most likely not be adding this flag to the Outlook MAPI documentation since it only applies to Outlook 2003.

Comments

  • Anonymous
    April 04, 2011
    I have a question. I am using wrapped pst, so when I try to add subfolder to Calendars, which has PR_SOURCE_KEY=6AEB7B5C6FE88D4186C448B529B025BA0000000000000000, my subfolders is added to IPM_SUBTREE instead. But if Calendar has PR_SOURCE_KEY=6AEB7B5C6FE88D4186C448B529B025BA00000000000B0000 then subfolder is added properly to Calendar. Why does it happen?