We just put a code sample and accompanying documentation up on Code Gallery for something we’re calling adjacent windows. Basically, this is the practice of using the Windows API to hook Outlook’s windows and insert your own panes, which you are then responsible for managing. The important thing to remember here is that doing this is not supported. We strongly encourage you to use the supported technologies for extending Outlook, such as form regions. However, if you do choose to extend Outlook with adjacent windows, we offer these best practices to ensure coexistence with other solutions which do the same thing.
This is the first sample I’ve ever posted on Code Gallery. Even though we’re not planning on supporting it, Code Gallery does give us a way to get feedback and make changes quickly if we decide we need to. So you can use the Issue Tracker or Discussions to ask questions or report issues. We’ll be looking at them – we just can’t guarantee a response or resolution.
[This is now documented here: http://msdn.microsoft.com/en-us/library/cc842312.aspx ]
I recently had a customer who noticed that their MAPI search folders weren’t updating properly when they moved to Exchange 2010. Their wasn’t anything complicated about the search criteria – they called SetSearchCriteria passing a RES_CONTENT type restriction looking for PR_MESSAGE_CLASS matching their item type. The search folder which was initially built was correct – it had all the items in it which it was supposed to have and nothing else. But as items were created and deleted, the search folder didn’t keep up. Additionally, they noted that the same criteria worked on Exchange 2007, and that on some Exchange 2010 servers, they didn’t see the problem at all.
To troubleshoot this issue, the first thing we did was use MFCMAPI to look at the search folder they created. If you right click on a folder with MFCMAPI, you can select Edit Search Criteria, which will cause MFCMAPI to call GetSearchCriteria and display the results. Comparing the working search folders to the non-working search folders exposed the problem – all of the non-working folders had the SEARCH_STATIC flag set on them. So as far as Exchange was concerned, all of these folders were working correctly. The static folders didn’t update, while the non-static, or dynamic folder, updated dynamically.
But why were these folders static? This was caused by Content Indexing. On the Exchange 2010 servers where the folders were working, Content Indexing wasn’t. In fact, I went to a non-working server and manually disabled Content Indexing. When I rebuilt the search folder SEARCH_STATIC wasn’t set. It turns out, on Exchange 2010, search folders backed by Content Indexing are always static. A little digging uncovered that on Exchange 2007, even though we had intended Content Indexing backed search folders to be static, we had accidently made them dynamic. So that’s why the folders were working on 2007.
Once we realize Content Indexing is the problem, the fix is simple – when building the search folder, ask that Content Indexing not be used. There’s a flag for this, NON_CONTENT_INDEXED_SEARCH (0x20000). Once we passed this flag, Exchange didn’t use Content Indexing to build the search folder, SEARCH_STATIC wasn’t set, and the search folder started updating dynamically.
The Exchange team just announced the availability of Update Rollup 4 for Exchange 2010. We got a number of MAPI fixes in there:
979810 You cannot connect an Exchange Server 2010 mailbox by using a MAPI client
980353 A MAPI application that is used to access Exchange Server 2010 mailboxes crashes when the application accesses an address book
980354 "MAPI_E_INVALID_PARAMETER" error message when you copy email messages from an Exchange Server 2010 mailbox
980852 The RpcClientAccess process on an Exchange Server 2010 server crashes when you access a mailbox by using a MAPI application
The last one is particularly interesting because this crash was stopping MAPI applications from accessing recovery mailboxes.