As Paul Thurrott notes, we just announced that we’re documenting the PST file structure . I haven’t decided yet if I’ll be writing a standalone parser/viewer/validator, but I’m sure I’ll be adding some interesting stuff to MFCMAPI . I’ll let you know when I know more. digg_url = "http://blogs.msdn.com/stephen_griffin/archive/2009/10/26/inside-the-pst.aspx";digg_title = "Inside the PST";digg_bgcolor = "#FFFFFF";digg_skin = "compact"; digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin

We had a customer recently who was asking how to tell a PST had been configured as a Sharepoint PST, so they could exclude it from some processing they were doing. After some digging, I found the property that Outlook itself uses to determine a PST is a Sharepoint PST, and development gave me permission to document it: #define PR_ASSOCIATED_SHARING_PROVIDER PROP_TAG(PT_CLSID, 0x0EA0) To check if a PST is a Sharepoint PST, mount the PST using OpenMsgStore , then call GetProps on the message store

Today we’re revisiting an issue I first encountered in Outlook 2003. We had a customer, a law firm, who kept all the mail associated with a particular case in a PST. Their users would pass these PSTs around, and depending on their case load, a single user might have over 100 PSTs open at the same time. This worked fine when they had Outlook 2000, but when they installed Outlook 2003 they found if they tried to open more than 20 or so PSTs, they started getting errors such as “Outlook failed to add

Just wanted to note that the April Cumulative Update for Outlook 2007 fixes the unaligned data issue with the PST provider. So passing a statically allocated NULL string as a PST password should no longer be a problem. BTW – Outlook’s update isn’t listed in the overview article for the April Update . This is because the Outlook package was delayed for a few days. The overview article should eventually be updated to include Outlook. digg_url = "http://blogs.msdn.com/stephen_griffin/archive/2009/05/08/unaligned-data-and-the-pst-provider-redux.aspx";digg_title

The PST provider in Outlook 2007 supports Fast Shutdown . The Wrapped PST sample is built by wrapping objects from the PST provider. Ergo, if a provider built on the Wrapped PST model does not intercept queries for IID_IMAPIClientShutdown, it supports Fast Shutdown. In other words, if your Wrapped PST based provider has problems with Fast Shutdown, you need to implement IMAPIClientShutdown and return MAPI_E_NO_SUPPORT from QueryFastShutdown. And if your Wrapped PST base provider is OK with Fast Shutdown,

I’m repeating myself – I did use a variation on this title before. In this case, suppose you’re using a custom transport provider, like MrXP , and you’re delivering to a regular (not wrapped) PST. In Outlook 2003, this worked great. If you had rules set up, they all got fired on delivery. In Outlook 2007 though, this stopped working. The basic design of a transport provider is this: 1 - Outlook's protocol handler has a function which will get messages from the transport. 2 - The transport provider

I just wanted to let you know about a problem we’ve found with the February update for Outlook 2007 . If you’ve got code that calls ConfigureMsgService for the PST provider, and you’re passing PR_PST_PW_SZ_OLD (or PR_PST_PW_SZ_NEW) you might run into a crash scenario. The crash can happen if the string you’re passing for this parameter is very short (0-2 characters, plus a NULL terminator) and the starting address isn’t aligned on a 4 byte boundary. We’re working on a fix for the issue. In the meantime,

Suppose you want to register for notifications on all the visible folders in a user’s mailbox. One option would be to walk the list of folders in the hierarchy tree and register for notifications. That would work, but would be very inefficient. It also wouldn’t be dynamic, since you wouldn’t catch new folders as they’re created. And if you register for too many notifications, you might run into this problem . A more elegant solution is to register for notifications at the message store level. This

If you’ve been working with PSTs for a while, you’re probably familiar with the properties PR_PST_PW_SZ_OLD and PR_PST_PW_SZ_NEW, given in mspst.h, which are used to access password protected PSTs and also to change the password. I had a customer recently who needed to know if a PST they had was password protected in the first place, so they could process them appropriately. We did some research and found that if you added such a PST to a profile, then called OpenMsgStore on it with the MDB_NO_DIALOG

A scenario recently came up that a couple of customers have hit with Outlook’s version of MAPI. These customers are in the business of processing PST files found on a user’s machine. They may be loading them up to scan the messages for viruses, or to ensure they’re backed up. Since opening a PST requires MAPI, they would create a MAPI profile to do their work, add the PST to the profile, read the data they needed to read, then logoff the profile and delete it. These scans would happen throughout