SGriffin's MAPI Internals : MFCMAPI

January 2012 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Mon, 23 Jan 2012 19:40:41 GMT

No one’s taking my subtle hints about Wikipedia. One more try: It sure would be nice if someone added MFCMAPI to the article about MAPI.

The January 2012 Release (build 15.0.0.1030) is live: http://mfcmapi.codeplex.com.

I’m continuing to crunch on the UI overhaul. This release has a ton of fixes for various flicker issues and glitches, especially those which show under the Windows Classic theme. Most of the problems were bad assumptions on my part that the Classic Theme helped expose. I also worked a good bit on making my various dialogs more pretty, practically rewriting the layout engine in the process. Finally, I finished up my work on painting the system buttons. This last bit required a bit of kernel debugging to figure out why Windows liked to repaint on top of my icons when I moved the mouse around. It turns out that initialization of the window’s system menu is what caused this. If you’re interested, look at how I handle WM_CREATE.

I’m continuing to tweak the colors. Here’s another hero screenshot highlighting the ~~new~~ new color scheme, including the new system buttons:

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MFCMAPI: Rewrote/cleaned up most of the dialog rendering
MFCMAPI: Much more double buffering to reduce flicker
MFCMAPI: Custom system icons
MrMAPI: New –Restrict switch to limit output from folders
MFCMAPI: Softer color scheme
MFCMAPI: Fixed all known Classic Theme glitches
SmartView: Added PidTagRoamingBinary
MFCMAPI: Much smaller options dialog now scrolls.

Enjoy.

December 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Tue, 13 Dec 2011 20:34:12 GMT

What’s an app got to do to get on Wikipedia? You know I can’t put it there myself – that’s against the rules.

The December 2011 Release (build 15.0.0.1030) is live: http://mfcmapi.codeplex.com.

When I started working on the UI overhaul, I knew it was going to take a few releases to get it right. After all, I’m a one man development team, and while I’ve got a number of folks who do testing for me, I can’t catch everything. Since the last release, I’ve found (or been pointed at) a number of issues with the new UI, mostly relating to the abundance of themes out there. I’ve also found a new (to me) code analysis tool which has uncovered a number of potential issues. So I’ve decided to release an off schedule build to address everything. I’m still not done with the UI, but this release should be more visually stable on more machines.

Since I’ve changed some colors in this release, I took a new screenshot:

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MFCMAPI: Border painting was weird on some systems (never figured out exactly which, but did find my math error).
MFCMAPI: Underlying window bleed through in About dialog without Aero (fixed)
MFCMAPI: Clipping in the tree control as we hover highlight
MFCMAPI: Color choices conflicted with certain themes (switched to system colors which should not conflict)
Function annotations: Fixed a number of annotation and signature issues.
Other sundry code sanitation issues.

Enjoy.

Enabling Kerberos Authentication

Stephen Griffin - MSFT — Tue, 06 Dec 2011 19:58:32 GMT

We had a customer recently who was using Outlook 2010’s MAPI in their application to talk to the Exchange server. They wanted to enable Kerberos authentication, but were having trouble enabling it programmatically. They had found the property that gets changed when you enable Kerberos authentication through the UI: PR_PROFILE_AUTH_PACKAGE in the global profile section gets set to RPC_C_AUTHN_GSS_KERBEROS. When they tried setting this value in their profile though, they’d find that OpenAddressBook would return MAPI_W_ERRORS_RETURNED and subsequent calls to ResolveName would return MAPI_E_CALL_FAILED. What was really strange was if they opened the profile using Outlook or MFCMAPI, the profile would somehow be “fixed”, and their application would work.

By comparing the profile before and after “fixing” it, we were able to track the difference down to a single property, which development has given me permission to document, PR_PROFILE_HOME_SERVER_FQDN (0x662A001F). This property is located in the address book section, dca740c8c042101ab4b908002b2fe182 (aka muidEMSAB). Setting this property to the DN of the user’s directory server was sufficient to turn a non-working profile into a working profile using Kerberos authentication. For example, if my DC was named ExampleDC, I might set this property to “ExampleDC.example.com”.

So why would running MFCMAPI or Outlook fix the profile? It all has to do with the flags the customer passed to MAPILogonEx. They were passing MAPI_NT_SERVICE. To the Exchange address book provider, this indicated (among other things) that we should not load our user interface (UI) support object, since we’re running in a context that doesn’t allow UI. Later, when we’re attempting to connect to the server, we check if we have been referred to a DC yet. This is the PR_PROFILE_HOME_SERVER_FQDN property. Finding this property not set, we enter the code that would normally request a referral from the Exchange server. However, this code is dependent on the UI support object, so it does not execute. Ultimately, we decide to just talk directly to the Exchange server and let it handle proxying our calls over to the DC as needed.

This all works fine as long as we’re not using Kerberos authentication. However, as we saw in the Check Names article, you cannot use Kerberos to make address book calls to the Exchange server (Exchange 2010 may fix this, but I believe this customer was using Exchange 2007). That’s why setting PR_PROFILE_HOME_SERVER_FQDN fixes the problem, since we connect directly to the DC.

Notes:

Exchange 2010 handles address book calls made to the CAS differently from how Exchange 2007 and earlier handle them. The DSProxy process is no longer used. So the Kerberos authentication may succeed. However, the client would still be talking to the Exchange server instead of directly to the DC, which may not be desired. Setting PR_PROFILE_HOME_SERVER_FQDN will avoid this.
Logging on without MAPI_NT_SERVICE sets additional properties besides PR_PROFILE_HOME_SERVER_FQDN, but investigation has not shown any of them to be essential. I’ll update this post if this changes.

Enjoy!

November 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Tue, 29 Nov 2011 13:48:00 GMT

Still no mention of MFCMAPI on Wikipedia. I had such high hopes. Sigh.

The November 2011 Release (build 15.0.0.1029) is live: http://mfcmapi.codeplex.com.

Note that build number. That’s right. I jumped all the way from 6 (where I’ve been stuck forever) to 15. That’s the sort of jump that’s normally only accompanied by a full UI refresh. And that’s exactly what you get! I’ve overhauled just about every aspect of the UI for a more modern, some might say “Metro inspired”, look. I’ll admit, there’s still some work to be done (I didn’t get to scrollbars for instance) but this is a pretty good start. Let’s take a look:

[See the new screenshot here.]

I’ve drastically slimmed down the menus, stuffing most of the little used functionality into Advanced menus that most of you will never need to open. The old, usually empty, File menu is gone and Session now takes prominence. This should help new users immensely. Long time users of MFCMAPI may want to spend a little time figuring out where their favorite features went, but nothing’s been cut.

A note about the tree: In the past, whenever you selected or expanded a folder, MFCMAPI would register for notifications on that folder and a number of it’s child folders. This was represented in the UI by bolding the folder name. This just confused people, so now, the only time I bold a folder name is to represent the currently selected folder. You can tell if MFCMAPI is listening for notifications on a folder by looking for a little red “I’m listening”icon after the folder name. It looks like this:

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MFCMAPI: The entire UI (save scrollbars) has been updated with our new look.
MFCMAPI: The menu system has been given a long overdue scrub and overhaul.
MFCMAPI: The links in the help are now clickable.
MFCMAPI: Options shortcut – Ctrl+O brings up the newly slimmed options dialog.
MFCMAPI: While reskinnng the tree view I found several opportunities for performance enhancements. The tree should load faster, with less chatter to the server, and fewer issues with refresh as notifications come in.
Hex Editor: I’ve added commas (,) to the list of ignored characters for hex strings, making importing hex from other applications simpler.
Debug Viewer: Cancel has been replaced with Close, which makes much more sense.
MrMAPI: I’ve added pbGlobalProfileSectionGuid to our guid list

Enjoy.

September 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Wed, 14 Sep 2011 14:38:01 GMT

Before we get to business, a comment: MFCMAPI does not appear anywhere in Wikipedia. This is a sad. Very very sad.

The September 2011 Release (build 6.0.0.1028) is live: http://mfcmapi.codeplex.com.

We got a handful of new features this time. MrMAPI can now parse flags on the fly, For instance, if you want to know what 0x3a means in PR_MESSAGE_FLAGS, MrMAPI can tell you:
C:\>mrmapi PR_MESSAGE_FLAGS -flag 3a
Found property PR_MESSAGE_FLAGS (0x0E070003).
0x0000003A = MSGFLAG_UNMODIFIED | MSGFLAG_UNSENT | MSGFLAG_HASATTACH | MSGFLAG_FROMME

Additionally, I added a feature to MFCMAPI to sort the names of properties such that the more common name is listed first. For instance, if you looked at an Exchange profile for the property 0x6612001E, you used to see the following list of property names, in alphabetical order:
PR_CONTAB_STORE_NAME, PR_CONTAB_STORE_NAME_A, PR_PROFILE_HOME_SERVER_DN, PidTagContactAddressBookStoreName
Now, when you look at the same property, we see the name we expect to see come first:
PR_PROFILE_HOME_SERVER_DN, PR_CONTAB_STORE_NAME, PR_CONTAB_STORE_NAME_A, PidTagContactAddressBookStoreName

I also added property name lookup to the restriction editor and a switch in Options to force MFCMAPI to load MAPI from the System directory, useful for older Exchange servers where Outlook Express may also be installed.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MFCMAPI: Better property name sorting. All alternate property names are now hand sorted with the most common name first. Please let me know if you find any which could be sorted better!
MrMAPI: Flag lookup via the new –Flag switch.
MFCMAPI: Force System MAPI, allowing MFCMAPI to work again on older Exchange servers.
MFCMAPI: Prop lookup in the Restriction Editor
Hex Editor: Bug fix when editing Base64.
SmartView: Found a type of Public Folder entry ID I wasn’t parsing correctly.
MFCMAPI: Count Named Properties will now report the highest named property in more situations.

Enjoy.

July 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Fri, 22 Jul 2011 14:27:00 GMT

The July 2011 Release (build 6.0.0.1027) is live: http://mfcmapi.codeplex.com.

This round, the focus was on bulking up MrMAPI’s feature set. MrMAPI is one of the core data collection tools being used in a future update to our Software Diagnostics Platform for Outlook issues. This has driven several of the features I’ve added to MrMAPI to make it easier for the engineers writing the diagnostics to grab the bits of information they need so we can resolve issues faster.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MFCMAPI: Empty Folder can now delete one message at a time. Useful for those stubborn super large folders where the EmptyFolder API can’t complete.
MrMAPI: Fid/Mid lookup can now be performed.
MrMAPI: Open folders by name. Anywhere that takes a folder can now take a full path to the folder by name, or rooted on one of the “known” folders. The known folders list has been augmented to include the Sync Issues folders.
MrMAPI: Restrict by subject and message class. In case you just want to output certain messages.
MrMAPI: List folder contents and hierarchy tables.
MrMAPI: Better handling of non-Exchange mailboxes.
SmartView: I’ve augmented how PT_I8 is handled.

Enjoy.

Enough With The Redirects Already

Stephen Griffin - MSFT — Fri, 08 Jul 2011 20:43:00 GMT

Here’s the scenario the customer gave us: They use Outlook’s MAPI and a single MAPI profile connect to an admin mailbox, and then use CreateStoreEntryID and OpenMsgStore to open various work mailboxes to do their processing. All day they’re opening and closing these mailboxes. In some environments, after they run for some time, one of the OpenMsgStore calls will return MAPI_E_FAILONEPROVIDER. There were a number of variations of the issue, as we’ll discuss below, but what they all had in common was that they were rapidly logging in to mailboxes, at least 5 times over a 10 second span.

This was key to the issue. When we traced the process and debugged the reason for the failure, we saw the Exchange server was returning ecServerPaused when we got the error. Digging further back, we saw we were getting ecWrongServer on earlier, successful connections. If you read through the documentation on these errors, you’ll see this is a defense mechanism for Exchange. The ecWrongServer error, which never bubbles up to the caller, indicates that the mailbox requested is not on the server we’re talking to. This initiates a redirect conversation to find the right server. This negotiation is expensive, especially since the server conducting it shouldn’t have been contacted in the first place. So if the same client triggers too many redirects, Exchange returns ecServerPaused as a signal to the client that maybe it’s doing something wrong. You can find this error by calling GetLastError after OpenMsgStore fails. Outlook itself will use this information to trigger an update to the profile to ensure it’s talking to the right server.

So, armed with this information, we went looking at the customer’s code to see what they were doing wrong. They would connect to mailbox Homer on server Alpha, obtain the DNs for mailbox Bart and server Beta, and pass these in to CreateStoreEntryID. They would then use this entry ID, and still see the problem if they logged in rapidly. They did nothing wrong and still had a problem.

This is where things get complicated. First, let’s look at the output of CreateStoreEntryID (as parsed with MFCMAPI):

MAPI Message Store Entry ID:
abFlags = 0x00000000
Provider GUID = {10BBA138-E505-1A10-A1BB-08002B2A56C2} = muidStoreWrap
Version = 0x00 = MAPIMDB_VERSION
Flag = 0x00 = MAPIMDB_NORMAL
DLLFileName = EMSMDB.DLL
Wrapped Flags = 0x00000000
WrappedProviderUID = {20FA551B-66AA-CD11-9BC8-00AA002FC45A} = g_muidStorePrivate
WrappedType = 0x0000000C = OPENSTORE_HOME_LOGON | OPENSTORE_TAKE_OWNERSHIP
ServerShortname = Beta
MailboxDN = /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Bart

Note that the entry ID contains the server name “Beta”, but not the full DN, even though the full DN was passed in to CreateStoreEntryID. This is because the entry ID format generated by CreateStoreEntryID does not support using the full server DN. So only the short name is kept, and that’s all emsmdb32 has to work with. To talk to the server, we need the full DN, so we have to manufacture a DN using the information we have at hand. We do this by grabbing the DN of a known good server (in this example, Alpha) and replacing the server name. We then have a dilemma – this new DN may point to a real server, or it may be total garbage, for instance, if the OUs of the servers were different, this made up DN doesn’t exist. So instead of using this newly constructed DN to connect, we instead connect to the only server we know is functioning, using the server DN of the mailbox in the profile.

Of course, this is wrong and we get redirected, and if we repeat this dance several times we’ll hit ecServerPaused. We recognized the potential to do better by implementing a cache of recently used DNs. If the DN we constructed was on this list, we’d go ahead and try it. So the first time we connect to Beta, we redirect through Alpha, but subsequent connections will use Beta’s DN since it’s in the cache. This fix first showed up in Outlook 2003 and 2007 via 929307 and 937949 respectively. So I had the customer check that their customer’s Outlook was up to date. Sure enough, one of their clients wasn’t, and updating it fixed the problem. This didn’t fix the others though, so we debugged again.

The next site we looked at had an updated Outlook, but the the two servers were in different OUs. We’d build a (wrong) DN for Beta using Alpha’s DN. This DN wouldn’t be in our cache, so we’d connect to Alpha for a redirect. We’d then cache the (correct) DN for Beta. This same sequence of steps would repeat the next time we log in to Beta. As long as the two servers are in different OUs, we’ll always redirect. This customer was able to move mailboxes around and eliminate the problem.

We then encountered a site with a single OU and up to date Outlook where the problem still happened. A close look at a trace of the problem revealed that in this particular configuration, the customer’s code managed to log all the way out of MAPI in between mailbox logons. So the cache we went through all the trouble to maintain was torn down and rebuilt on every pass, making it totally ineffective. Keeping one mailbox open the entire time was enough to keep the cache alive.

We were able to get their code running in every environment except the ones where they couldn’t move their mailboxes and had to keep them in different OUs. For those, the only workaround they can use right now is to slow down a bit. Of course, things would be easier if there was a documented entry ID format that included the FQDN. Maybe one day there well be…

Update: I just documented the v2 Store Entry ID format.

MFCMAPI: Documentation By Committee

Stephen Griffin - MSFT — Mon, 13 Jun 2011 14:29:44 GMT

I’ve noticed over the years that a number of articles have been written documenting how to use MFCMAPI to troubleshoot various issues. I thought it would be a good idea to put together a list of these articles in one central location. So after much searching with the Bing and with the Google, I’ve put together this list:

MFCMAPI Articles

I made an effort to classify the articles by topic. I know I’ve probably missed a number of articles – if you wrote an article or are aware of one that ought to be on the list, just let me know.

Enjoy!

Large Multivalued Properties

Stephen Griffin - MSFT — Fri, 10 Jun 2011 15:33:02 GMT

We recently encountered an issue where, in the customer’s code, a call to GetProps for a particular message failed with MAPI_E_CALL_FAILED. We found that MFCMAPI had trouble getting properties on the message as well. The curious thing was that if we made a GetProps call for one or two properties, it would work. Only when we did GetProps(NULL) or called GetProps with the result of GetPropList did we see the problem. Further investigation of the RPC Client Access logs on the Exchange server (c:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access) showed several BufferTooSmall errors logged at the same time as our GetProps calls:

2011-05-27T17:45:57.201Z,13537,0,/o=SPRINGFIELD14/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,MFCMapi.exe,12.0.6539.5000,Classic,,,ncacn_ip_tcp,,,1149 (rpc::BufferTooSmall),00:00:00.0156244,,RpcDispatch: [BufferTooSmallException] Exception of type 'Microsoft.Exchange.RpcClientAccess.BufferTooSmallException' was thrown.

I had the opportunity to debug this and found some interesting details in how Exchange responds to a GetProps call. The first thing we do is gather all the properties that were requested from the store. Next, we have to pack these results into an RPC buffer to send them back to the client. An RPC buffer is of limited size, so we have to be careful not to pack too much data in to it. We assume everything will fit and count up how many bytes we used. If we used more bytes than is available in the RPC buffer, we look for the largest PT_BINARY, PT_STRING8 or PT_UNICODE property in our list (over 255 bytes) and replace it with the error MAPI_E_NOT_ENOUGH_MEMORY. Then we repeat, repacking the buffer, checking the size, and removing the largest property if necessary. If we reach a point where we’ve removed every string and binary property we can and our buffer is still too large, we fail the call and throw the BufferTooSmall exception. On the client side, we get MAPI_E_CALL_FAILED, and extended error information shows the error ecBufferTooSmall (0x47D == 1149).

This is what was happening with this message – we had removed every binary and string property we could and still the buffer needed to serialize the remaining properties was larger than the RPC buffer we were given to fill. What took up all the space? This is one of MAPI’s dirty little secrets: large multivalued properties can fill your GetProps buffer and there is no alternative way to request them. This message had a single PT_MV_UNICODE property in it which had entries on the order of a few kilobytes in size. If this property was excluded from the GetProps call, the call would work.. If this property was requested by itself, it would work. But when this property was requested alongside a number of other properties, that was enough to fill the buffer and the call failed.

We saw this problem with Exchange 2010, but this same packing logic exists in all versions of Exchange. All versions of MAPI (both Outlook and MAPICDO) can potentially hit this as well.

Recommendations for Dealing With Large Multivalued Properties

Don’t do it. If you use multivalued properties, keep the overall total size relatively small. This will greatly reduce the chance that your multivalued property will cause a failure in GetProps.
A large number of small multivalued properties can be just as bad as a small number of large multivalued properties. Don’t go adding 50 different multivalued properties to the same message and expect to be able to ask for everything in one call.
If you must put large amounts of data into multivalued properties, never ask for them alongside other properties. Always ask for them on their own. Put a comment in your code noting why you asked for them by themselves instead of rolling them into another GetProps call so the developer who comes after you doesn’t optimize the code by combining the calls.

Fun With the MAPI Spooler

Stephen Griffin - MSFT — Tue, 31 May 2011 13:51:53 GMT

Here’s a fun trick. On a machine where you have the Exchange MAPI Download installed, create a file named “Program” in the root of the system drive. Then start MFCMAPI and open a profile with an Exchange mailbox in it. You’ll get this nice error:

“The MAPI Spooler could not be started. Close and then restart all mail-enabled applications. MAPI 1.0 [000004C7]”

Of course, restarting MAPI applications, or even rebooting, won’t help. You have to delete that file, “Program”, from the root of the system drive. Only then will the MAPI spooler start.

So – what happened here? We’re using CreateProcess to try to launch the spooler. The string we pass in for the command line looks like this:
C:\Program Files (x86)\ExchangeMapi\MAPISP32.EXE –0001EFC1A5208C4

Note the distinct lack of quotes. As the documentation suggests, if you call this function with a path which has white space in it and no quotes, it will try to parse the path as if the first space separates the executable name from the parameters. So it looks for an executable named “C:\Program”. When it finds a file with that name which is not an executable, it returns an error. The lesson here is to make sure to properly quote paths passed to CreateProcess. Also, make sure you don’t have a file named “Program” in the root.

Outlook’s MAPI is not vulnerable to this problem since it no longer has a separate MAPI spooler process. I don’t believe we’ll be pursuing a fix to the Exchange MAPI download since the likelihood of such a file existing for legitimate purposes is low, and you need to be an administrator to even create it in the first place.

May 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Tue, 24 May 2011 13:50:56 GMT

The May 2011 Release (build 6.0.0.1026) is live: http://mfcmapi.codeplex.com.

This round, the focus was on a new MAPI stub library and Fuzz testing.

The new MAPI Stub Library is the product of months of hard work on the part of a few talented developers and testers in the Outlook organization. I did a good bit of testing myself and even fixed a few issues, but I did not have the honor of writing it. Incorporating this new stub library into MFCMAPI allowed me to ditch a good bit of my own import code. I highly recommend everyone to check this project out.

I found some internal tools to help with Fuzz testing. Using these, I was able to ferret out a number of issues with my SmartView parsers. I’ve actually found far fewer issues than I had expected, so it looks like my parsers were on solid footing already. I’ve fixed everything I’ve found, along with a number of issues reported through Windows Error Reporting.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

New MAPI Stub Library
MrMAPI: Reduced default help length (use –? to get full help)
MrMAPI: Corrected smartview parser to output to console when output file not specified
MFCMAPI: Open Profile By Name
SmartView: Fixed several crash and hang issues in SmartView parsers.
XML Output is now scrubbed for invalid characters.
Retail builds are now compiler optimized.

Enjoy.

Picking an API

Stephen Griffin - MSFT — Mon, 11 Apr 2011 13:19:00 GMT

Angela just posted an article on extending Outlook on her blog, and an article on picking the right API on the MSDN. Both articles make several mentions of MFCMAPI and are thus worthwhile reads. The MSDN article is an especially good one-stop overview of all the APIs and technologies available in Outlook, with special attention paid to details such as managed vs unmanaged code, bitness, and threading

Note that both articles are written very much from Outlook’s point of view. The presumption is that Outlook is part of your solution. This may not necessarily be the case. If you are considering server side solutions, your top choices will likely be either Exchange Web Services (EWS) or the MAPI download, though there several other Exchange based APIs which you can read about in the Exchange Server 2010 SDK.

Enjoy!

April 2011 Release of MFCMAPI.Net

Stephen Griffin - MSFT — Fri, 01 Apr 2011 12:36:00 GMT

The April 2011 Release (build 7.0.0.1234) is live: http://mfcmapi.codeplex.com.

I know I just released the March update a few days ago, but I just got permission from development to release this. I have thrown off the shackles of C++ and fully embraced the awesome power of the CLR. MFCMAPI.NET is a complete rewrite of MFCMAPI using the .Net framework.

The productivity gains were immediate. I was able to completely rewrite MFCMAPI, from scratch, in just 20 minutes. Since I had allotted a full hour for the conversion, I spent the extra time adding some new features, such as:

Fix My Calendar: This feature will automatically identify whatever problem is plaguing your calendar and Fix It.
Do That Thing I Just Did, But Everywhere: Ever found a problem on a large number of messages that you could fix just by editing a single property? With this revolutionary new feature, MFCMAPI.Net will record the steps you performed on one message and play them back on all of the other messages. What if you only need to edit a subset of your messages? Don’t worry, this feature Just Knows which messages to update. It’s that easy!
No MAPI Required: The most amazing feature of MFCMAPI.Net, and the one of which I am most proud, is No MAPI Required. That’s right – MFCMAPI.Net doesn’t need MAPI installed to function! In fact, it doesn’t need an Exchange server either. How does it work? Simple: the cloud.

Even after implementing those amazing features, I still had a half hour left, so I decided to fix a few other outstanding issues for the Outlook and Exchange product teams. Look for announcements soon of the following hotfixes:

Unicode MSG file and PSTs in MAPICDO.
64 bit support in MAPICDO.
Unified 32 and 64 bit support in all versions of Outlook and MAPI. That’s right – all 32 bit MAPI code will now work without any changes against 64 bit MAPI, and vice versa.
Return of Exchange Client Extensions in Outlook 2010 and above.
The EDK is back!

All in all, it was a super productive 45 minutes coding with .Net. I even had time for a nap! I look forward to doing it again.

Enjoy.

March 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Wed, 30 Mar 2011 15:54:00 GMT

The March 2011 Release (build 6.0.0.1025) is live: http://mfcmapi.codeplex.com.

The singular focus of this round is MrMAPI: I made it much smaller and added a bunch of new features to help out some of our upcoming diagnostics initiatives. Hopefully people will find interesting ways to use these features.

The biggest new feature is contents table output for special folders. This provides a quick way to get a ton of data that typically you’d have to fire up MFCMAPI for and navigate through myriad windows. I’ve also exposed a command line for converting between .MSG and .EML files. This was also doable with MFCMAPI, but now you can do it from the command line or in scripts.

I wanted to take a minute and point out the hard work of Randy Topken, who published the CalCheck tool, which uses MrMAPI for some of its parsing. Hopefully this release of MrMAPI will allow him to add even more cool checks to his tool.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MrMAPI: Contents Table output
MrMAPI: MAPI<->MIME conversion
MrMAPI: MSG file property dumps
MrMAPI: Force online (for bypassing cached mode)
MrMAPI: Verbose switch turns on all debug output for troubleshooting.
MrMAPI: Smaller binary achieved by cutting much of MFCMAPI’s code from the build.
SmartView: Parse PR_RULE_ID
MFCMAPI: Fixed the Resend Single Message feature, which had never worked quite right.
Message property dumps again include embedded message information.
Message property dumps (both in MFCMAPI and MrMAPI) should be significantly faster.
Body property stream errors are better exposed.
Several crashes were fixed.

Enjoy.

MAPI And Virtualization

Stephen Griffin - MSFT — Thu, 03 Mar 2011 13:31:17 GMT

I promised before that I would take an in depth look at Click-to-Run and MFCMAPI. I’ve done so and the results are mixed. I couldn’t find a way to launch MFCMAPI on its own into the virtual environment, but I did find a trick to load it along side Outlook.

Click-to-Run, described here is a mechanism for delivering Office to client machines. It’s built on top of App-V (formerly SoftGrid). Using Click-to-Run, you can stream Office to a client machine (so that you can run it while it’s still installing) and it also runs virtually, reducing the number of co-existence scenarios. Enterprises can use this to reduce installation, support, and upgrade costs. We even use it to deliver trial versions of Office 2010.

The virtualization behind Click-to-Run is the source of the problem we have with MAPI. Since MAPI is installed by Outlook, and since Outlook is virtualized, applications running outside the Click-to-Run don’t have access to MAPI. We describe what does and doesn’t work here:
http://support.microsoft.com/kb/981242

MFCMAPI falls in the “doesn’t work” category, but that doesn’t mean there aren’t tricks you can use. In the previous post, Kevin noted that he could use an Outlook 2010 Add-in to launch MFCMAPI inside the virtual environment. This will work, but I found another trick: use a little known feature of the File/Open dialog.

Here’s the trick as I perform it:

Open Outlook Data File - File/Open/Open Outlook Data File
Navigate to c:\windows\system32
Select "All Files" from the file type dropdown.
Locate cmd.exe, right click, and select Open.
The command prompt is now running in the virtual environment. Cancel Outlook Data File dialog.
Run MFCMAPI from the command prompt.

The advantage of doing the trick this way is you don’t have to install anything special to make it work. Also, once you have the command prompt open, you can run any application you want from inside the virtual environment, not just MFCMAPI.

Some caveats:

This trick obviously only works if Outlook is running. If you’re having trouble getting Outlook to log on and you wanted to use MFCMAPI to look at the profile, you may be out of luck. Of course, you could always try building a new profile using the Mail Control Panel and using that profile to get in to Outlook, and then do your troubleshooting.
If you close Outlook, I think your command prompt and anything launched from it will also be closed. If you have multiple virtual Office application installed, you might try doing the trick from one of the other Office applications and leaving it open, allowing you to open and close Outlook.
If you have a policy applied which doesn’t allow you to create PSTs, you can’t use that entry point into the File/Open dialog. You might try using Attach File from a mail message instead.
The ideal fix here would be to add MFCMAPI (or whatever MAPI based application you need to run) to the virtual environment. This involves a lot of stuff about App-V that I just don’t understand. Until someone shows me it can be done, I’ve concluded it’s impossible. :)

If I haven’t been clear – this is a trick to getting MFCMAPI to run in this environment. It’s not supported and not guaranteed to work. Use at your own risk.

Enjoy!

January 2011 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Thu, 20 Jan 2011 17:00:07 GMT

The January 2011 Release (build 6.0.0.1024) is live: http://mfcmapi.codeplex.com.

This round of work had two foci: Speed startup time of MFCMAPI and MrMAPI, and add features to MrMAPI.

I have been ignoring startup time of MFCMAPI for a while now, since it started up “fast enough”. But MrMAPI was designed to be run in batch scripts, and a slow startup time really adds up over multiple runs. They share the same code, so any work improving one improves the other. I found a number of opportunities to squeeze cycles out by sorting some arrays in the source and by improving the algorithms I use to shuffle them around when we’re starting. But the biggest improvement will happen if you happen to run MFCMAPI or MrMAPI from a directory with a lot of other files in it, such as a tools directory. We get a great speedup by remembering which files are and are not add-ins to MFCMAPI, so we don’t keep retrying them.

Other than the speed-up work, MrMAPI got most of the love. I added a host of new features: Error lookup, guid lookup, ACL and Rule table exports, and nickname cache parsing are the big ones. I’ve also uploaded a 64 bit version of MrMAPI since some of the features actually log in to a profile, and we need to support 64 bit Outlook.

When you download the new version of MFCMAPI, make sure to download MrMAPI for all of your property tag needs.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

SmartView: Parse nickname cache.
MrMAPI: Error lookup – mostly MAPI errors
MrMAPI: GUID lookup – every GUID MFCMAPI knows can be searched
MrMAPI: Smartview can now accept either hex or binary files with the –b switch
MrMAPI: Help banner: tells what MrMAPI can do.
Startup optimization
Smartview: Parse PR_FORM_HOST_MAP

Enjoy.

Outlook 2010 MAPI Reference

Stephen Griffin - MSFT — Fri, 19 Nov 2010 19:20:35 GMT

A couple of days ago, we published an update to the Outlook 2010 MAPI reference. Rather than try to summarize everything we did, here’s the mini press release Randy sent out to announce that we were done:

The updated 11/15/2010 release of the Outlook 2010 MAPI Reference is now live on MSDN.
Additionally, I’m happy to announce that the Outlook 2010 Auxiliary Reference is available on MSDN.
This publication completes our developer documentation for Outlook 2010.
Outlook 2010 developer documentation consists of the following reference titles:
Outlook 2010 MAPI Reference
Outlook 2010 Auxiliary Reference
Outlook 2010 Developer Reference
Outlook 2010 Primary Interop Assembly Reference
Outlook Social Connector 1.1 Provider Reference

New and Updated Contents for Outlook 2010 MAPI Reference

Support for 64-bit Microsoft Outlook—Reference topics for applicable API elements have been updated to correspond to new header files that support 64-bit Outlook. These header files are now available as a download at Outlook 2010: MAPI Header Files. A new code sample is provided in How to: Check the Version of Outlook to show how to check whether the installed version of Outlook is 64-bit Microsoft Outlook 2010. If your existing 32-bit MAPI application is going to be running on a 64-bit operating system with 64-bit Outlook installed, you will need to rebuild your 32-bit application as a 64-bit application. For more information about MAPI support for 64-bit Outlook, see Building MAPI Applications on 32-Bit and 64-Bit Platforms.
Fast shutdown support for MAPI clients—MAPI clients can now initiate a quick shutdown and have the MAPI subsystem notify loaded providers to minimize data loss from the fast shutdown. Additional interfaces have been added for the client and provider to support fast shutdown. For more information about fast shutdown, see Client Shutdown in MAPI.
Stream structure for field definitions for an Outlook item—Documentation for a binary stream for the PidLidPropertyDefinitionStream property has been added. This property specifies definitions of all custom fields and data-binding settings for built-in fields of an Outlook item.
More properties—Documentation for an additional 38 tagged properties and named properties has been added to this release.
Option of linking explicitly to MAPI functions—MAPI developers can now choose to explicitly link to the MAPI stub of the default MAPI client (for example, Msmapi32.dll of Outlook) without going through the MAPI library and the Windows MAPI stub. For more information about explicit linking as compared with implicit linking, see How to: Link to MAPI Functions.
Message Store Provider Example—The Sample Wrapped PST Store Provider Example has been updated to support 64-bit architecture.
Nickname Cache—Documentation for the Nickname Cache has been added. Microsoft Outlook 2010 interacts with the nickname cache file, also known as the “.nk2 file.” The .nk2 file is where Outlook 2010 persists the autocomplete list, which is the list of names that displays in the To, Cc, and Bcc edit boxes while a user is composing an e-mail.
Using Multiple Exchange Accounts—Documentation for the MAPI Address Book API has been added. This API has been enhanced to support multiple Exchange accounts in Microsoft Outlook 2010. To resolve addresses correctly with multiple Exchange accounts, you use the new functions that take an account context so that calls to the address book search the correct Exchange account.

My involvement in this project was as tech reviewer and author of MFCMAPI. I tried to shove as much of the new documentation into MFCMAPI as possible, including SmartView parsers for PidLidPropertyDefinitionStream and PidTagUserFields, both of which have been long standing requests. I also wrote or contributed to many of the code samples. The bulk of the work though was done by a small crew of folks on the Office Content Publishing team who know so much more about content than I could ever hope to know. They did an excellent job.

As always, feedback is welcome.

Enjoy!

Call MrMAPI, That’s My Name, That Name Again Is MrMAPI!

Stephen Griffin - MSFT — Wed, 17 Nov 2010 16:40:48 GMT

I said yesterday that MrMAPI deserved a full post, so here it is.

MAPI has a lot of property tags. You’ll find lists of them in the MSDN, and a number of them are documented in various and sundry KB articles. The problem with this documentation is that it’s of very little use when you’re debugging a GetProps call, trying to figure out what the property 0x0E6D001E is, or when you’re trying to remember an interesting property you read about, but all you know for sure is that the name of the property had the word “street” in it. For years, we had internal Microsoft only tools that were of some help in this – they were built from the Exchange or Outlook source and included in them a large number of properties that you could look up. With these tools, you could look up a property by tag number and learn its name. They also provided limited support for searching in the other direction, looking up a property by name and learning its tag.

The problems I had with these internal tools were twofold:

They didn’t know every property.
They were internal only.

I tackled the first problem in two phases. Over the years I had been hand tuning arrays in MFCMAPI that consisted of every property we’ve ever documented in the MSDN, in KBs or in blogs. Using these as a baseline, I wrote Perl scripts to search the Exchange and Outlook source trees for anything that looked like a property and built augmented arrays of every property ever in existence. With these in hand, I built a tool I dubbed MrTag. This tool has been very successful here in support, as well as over in the product team where they use it to check on availability of unused property tags. We still had the problem that the tool was internal only, since it contained internal information.

Now – I originally planned to take the arrays from MFCMAPI and build an external version of MrTag, but that would have been yet another project for me to support and manage. Then inspiration struck – I could code up a command line for MFCMAPI and just let MFCMAPI do the work! Unfortunately, it’s not possible to add a command line interface to a Windows application that works as I expect a command line tool to work. That is, if I pass command line parameters, I want the output to display back in the command window. Maybe I’ll write up the reasons for that later. I finally settled on adding a new project configuration to the MFCMAPI project that builds strictly as a command line tool with no Windows UI. I then just had to port the property lookup logic from MrTag, and MrMAPI was born! Now the world has access to a first class property lookup tool, and I have less code to maintain. Everybody wins! Since this tool is just a variant build of MFCMAPI, as I add and tweak the property lists, it will stay up to date.

Enough history – here’s how to use MrMAPI. I’ve excerpted part of the command line help:

MrMAPI [-S] [-D] [-N] [-T <type>] <number>|<name>
Property Tag Lookup:
-S   Perform substring search.
        With no parameters prints all known properties.
-D   Search dispids.
-N   Number is in decimal. Ignored for non-numbers.
-T   Print information on specified type.
        With no parameters prints list of known types.
        When combined with -S, restrict output to given type.

Without any switches, MrMAPI just looks up the property number or name, so you can look up 0x0037 or PR_SUBJECT and get results. You use the –S switch to perform a substring search. This is how you’d find that property that had street in it’s name. With no string, it will give you a list of every property that MrMAPI knows – nearly 4 thousand of them. If for some reason the property number you’ve run across is in decimal, you can use the –N switch to indicate this. The –D switch allows you to look up named properties – something our other internal tools never supported. The term dispid comes from the fact that most of the named properties begin with dispid, such as dispidReminderNextTime. In recent years, we’ve started giving these properties names beginning with PidLid, much as we’ve started giving property tags names starting with PidTag. MrMAPI is comfortable with both naming conventions, and if you look up a property using one name it will always tell you the other.

The –T switch is interesting. On its own, it can be used to print a list of MAPI property types. Combined with a search, we can restrict our output by type. So, for instance, if we wanted to find a PT_LONG property with “address” in it, we could use the switched “-s address –t PT_LONG”.

If you’ve played with MrMAPI a bit, you’ve probably noticed I’ve only covered half of what it can do. The other thing it does right now is SmartView parsing from the command line. For day to day use, if you’ve got a hex string you want to parse with SmartView, MFCMAPI’s Hex Editor (Ctrl+H) is probably more convenient. The command line SmartView parser is prep work for some automated analysis tools we’re working on. It also allowed me to write some test cases for the SmartView parsers, since I’m finding that the parsers are easy to break if I’m not careful. I plan to do a lot of work in this area and will talk about it more later when it becomes more interesting.

Hopefully you will all find MrMAPI to be useful. I’m very interested in getting feedback. If you find a flaw in the way it works, or find that we’ve documented a property that it doesn’t know about, please let me know so I can fix it. You’ll always find the latest version of MrMAPI on the download page for the latest release of MFCMAPI.

Enjoy!

November 2010 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Tue, 16 Nov 2010 18:15:00 GMT

The November 2010 Release (build 6.0.0.1023) is live: http://mfcmapi.codeplex.com. I’m also excited to announce the release of MrMAPI at the same location.

MFCMAPI work this round consisted of one new SmartView parser and a smattering of small features and bug fixes. The really exciting work was rebuilding MFCMAPI into a command line tool I’d dubbed MrMAPI. MrMAPI exposes two of MFCMAPI’s best features from the command line: Property tag lookup and SmartView parsing. It really deserves a blog entry of it’s own but for now, here’s a taste of what it can do:

C:\>mrmapi 0x3001001E
Property tag 0x3001001E:
Exact matches:
0x3001001E,PR_DISPLAY_NAME,PT_STRING8
0x3001001E,PR_DISPLAY_NAME_A,PT_STRING8
0x3001001E,ptagDisplayName,PT_STRING8
Partial matches:
0x3001001F,PR_DISPLAY_NAME_W,PT_UNICODE
0x3001001F,PidTagDisplayName,PT_UNICODE
C:\>mrmapi -s last_mod
Searching for "last_mod"
0x0E590102,PR_LAST_MODIFIER_SID,PT_BINARY
0x0E6D001E,PR_LAST_MODIFIER_SID_AS_XML,PT_STRING8
0x30080040,PR_LAST_MODIFICATION_TIME,PT_SYSTIME
0x3FFA001E,PR_LAST_MODIFIER_NAME,PT_STRING8
0x3FFA001E,PR_LAST_MODIFIER_NAME_A,PT_STRING8
0x3FFA001F,PR_LAST_MODIFIER_NAME_W,PT_UNICODE
0x3FFB0102,PR_LAST_MODIFIER_ENTRYID,PT_BINARY
0x80B40040,PR_EMS_AB_GWART_LAST_MODIFIED,PT_SYSTIME
Found 8 matches.

When you download the new version of MFCMAPI, make sure to download MrMAPI for all of your property tag needs.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

SmartView: Parse PR_LAST_MODIFIER_SID
Profile: Added the ability to set the default profile
Export: Export to text now sorts the properties by tag first
Recipients: Reworked the Recipient table editor to make updating recipients much easier
MrMAPI: New tool, MrMAPI.exe, enables property tag lookup on the command line
MrMAPI: New tool, MrMAPI.exe, enables SmartView parsing from the command line
Bugs: Found and fixed a number of crashes

Enjoy.

Can’t Open A Stream Twice

Stephen Griffin - MSFT — Fri, 08 Oct 2010 22:13:59 GMT

A customer asked me to document this, as they had run in to it while developing a COM Add-in for Outlook. They were trying to do some work with attachments, and this led them to listen to the Outlook Object Model’s BeforeAttachmentAdd event. Inside this event, they used MAPIOBJECT to get the attachment, and called OpenProperty to open a stream on the PR_ATTACH_DATA_OBJ property. This worked fine in cached mode, or against a PST, but when they ran their code in online mode, OpenProperty failed with MAPI_E_CALL_FAILED.

Digging in to the problem, we found that before firing the event, Outlook had itself already opened a stream on this property. Perhaps this was the reason for the failure? I did a quick test with MFCMAPI, modifying the CAttachmentsDlg::OpenItemProp function to call OpenProperty twice in a row. Sure enough, I saw the same thing they saw. Against a PST/OST, the second call succeeded, but against Exchange online mode it failed. Exchange won’t let you open two streams on this property at the same time. Not even if the second stream is read only.

Ultimately, this isn’t much of a surprise. These are two different store providers. One operates against a local database file, while the other operates across a network. The PST provider is in a better position to negotiate two different stream interfaces operating against the same backend data than the Exchange provider would be. So we can chalk this up as another implementation difference between the two providers.

September 2010 Release of MFCMAPI

Stephen Griffin - MSFT — Mon, 27 Sep 2010 17:40:37 GMT

The September 2010 Release (build 6.0.0.1022) is live: http://mfcmapi.codeplex.com.

My work the past two months on MFCMAPI was all over the map, no real focus. I fixed a few bugs, added some Smart View parsing, and made opening random profile sections a bit easier.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

SmartView: Parsing for PR_USERFIELDS (MSDN documentation is on the way!)
Profile Sections: The old Open Profile Section dialog has been replaced with a new one with a drop down for selecting known profile sections. Also, the parser which converts what you typed to a GUID is much improved – braces and dashes are now optional. Finally, since what a GUID looks like in memory or in the registry differs from the “canonical” form, there’s now a handy-dandy checkbox to indicate when you need your string byte swapped.
IMsgServiceAdmin2: Hate the way MFCMAPI has to mark profile sections before calling CreateMsgService? By using IMsgServiceAdmin2, this problem is avoided. (MSDN documentation for this interface is also on the way!)
Bug: Importing from MSG files allows multiple files again, and will stop importing everything to the Associated Contents table.
Bug: You can now create empty string properties – not sure how long ago I broke this.

Enjoy.

Let’s Try To Hash This Out

Stephen Griffin - MSFT — Wed, 18 Aug 2010 17:53:00 GMT

[This is now documented here: http://msdn.microsoft.com/en-us/library/ff960307.aspx ]

A few years ago, I blogged an algorithm to calculate the hash used by Windows Search in MAPI urls. This algorithm is now enshrined in the MSDN. I’ve been asked by development to blog some augmentations to this algorithm to bring it more in line with what we actually send to Search.

The binary blob to be encoded will be the PR_ENTRYID of the store in most cases, but for cached Exchange stores (both public and private), the binary blob should be PR_MAPPING_SIGNATURE, found in the profile.
After computing the hash for a public folder store’s binary blob, but before hashing in the OST path, we hash in the constant 0x2E505542 to make sure the hash is uniquely different from the private store’s hash. This constant represents the string “.PUB”.

Below you’ll find updated code which incorporates these new bits, along with some support code which will pull the relevant bits from the profile which can be used to tell if a store is public or private, if it’s cached, and the path to the OST. If you were to incorporate this code into your own project, the function you’d call is ComputeStoreHash, which takes as its input the session pointer as well as PR_ENTRYID, PR_SERVICE_UID, and PR_MDB_PROVIDER from the message store table. The rest of the information it needs it gets from the profile. For output, this function returns the hash as computed from PR_MAPPING_SIGNATURE, if the store is a cached Exchange store, and the hash as computed from PR_ENTRYID.

BTW – the HrEmsmdbUIDFromStore support function here is interesting. It’s a multi-ex aware replacement for using pbGlobalProfileSectionGuid to open the profile section for an Exchange mailbox. If you want, you could augment this function by having it look for PR_EMSMDB_LEGACY and reporting if the mailbox being checked is considered the Legacy mailbox which would match what you get with pbGlobalProfileSectionGuid.

I’ve tested this code against my own stores and the hashes I get match with what I see in Windows Search. Look forward to a version of this code showing up in the next version of MFCMAPI in September. Enjoy!

#define PR_PROFILE_OFFLINE_STORE_PATH_A PROP_TAG(PT_STRING8, 0x6610)

#define PR_PROFILE_OFFLINE_STORE_PATH_W PROP_TAG(PT_UNICODE, 0x6610)

#define CONFIG_OST_CACHE_PRIVATE  ((ULONG)0x00000180)

#define CONFIG_OST_CACHE_PUBLIC   ((ULONG)0x00000400)


HRESULT HrEmsmdbUIDFromStore(IMAPISession* pmsess,

                             MAPIUID* puidService,

                             MAPIUID* pEmsmdbUID)

{

  if (!puidService) return MAPI_E_INVALID_PARAMETER;

  HRESULT hRes = S_OK;


  SRestriction mres = {0};

  SPropValue mval = {0};

  SRowSet* pRows = NULL;

  SRow* pRow = NULL;

  LPSERVICEADMIN spSvcAdmin = NULL;

  LPMAPITABLE spmtab = NULL;


  enum { eEntryID = 0, eSectionUid, eMax };

  static const SizedSPropTagArray(eMax, tagaCols) =

  {

    eMax,

    {

      PR_ENTRYID,

      PR_EMSMDB_SECTION_UID,

    }

  };


  hRes = pmsess->AdminServices(0, (LPSERVICEADMIN*)&spSvcAdmin);

  if (SUCCEEDED(hRes) && spSvcAdmin)

  {

    hRes = spSvcAdmin->GetMsgServiceTable(0, &spmtab);

    if (spmtab)

    {

      hRes = spmtab->SetColumns((LPSPropTagArray)&tagaCols, TBL_BATCH);


      mres.rt = RES_PROPERTY;

      mres.res.resProperty.relop = RELOP_EQ;

      mres.res.resProperty.ulPropTag = PR_SERVICE_UID;

      mres.res.resProperty.lpProp = &mval;

      mval.ulPropTag = PR_SERVICE_UID;

      mval.Value.bin.cb = sizeof(*puidService);

      mval.Value.bin.lpb = (LPBYTE)puidService;


      (void) spmtab->Restrict(&mres, 0);

      (void) spmtab->QueryRows(10, 0, &pRows);


      if (SUCCEEDED(hRes) && pRows && pRows->cRows)

      {

        pRow = &pRows->aRow[0];


        if (pEmsmdbUID && pRow)

        {

          if (PR_EMSMDB_SECTION_UID == pRow->lpProps[eSectionUid].ulPropTag &&

            pRow->lpProps[eSectionUid].Value.bin.cb == sizeof(*pEmsmdbUID))

          {

            memcpy(pEmsmdbUID, pRow->lpProps[eSectionUid].Value.bin.lpb, sizeof(*pEmsmdbUID));

          }

        }

      }

      FreeProws(pRows);

    }

    if (spmtab) spmtab->Release();

  }

  if (spSvcAdmin) spSvcAdmin->Release();

  return hRes;

} // HrEmsmdbUIDFromStore


bool FExchangePrivateStore(LPMAPIUID lpmapiuid)

{

  if (!lpmapiuid) return false;

  return IsEqualMAPIUID(lpmapiuid, (LPMAPIUID)pbExchangeProviderPrimaryUserGuid);

} // FExchangePrivateStore


bool FExchangePublicStore(LPMAPIUID lpmapiuid)

{

  if (!lpmapiuid) return false;

  return IsEqualMAPIUID(lpmapiuid, (LPMAPIUID)pbExchangeProviderPublicGuid);

} // FExchangePublicStore


DWORD ComputeHash(ULONG cbStoreEID, LPBYTE pbStoreEID, LPCSTR pszFileName, LPCWSTR pwzFileName, BOOL bPublicStore)

{

  DWORD  dwHash = 0;

  ULONG  cdw    = 0;

  DWORD* pdw    = NULL;

  ULONG  cb     = 0;

  BYTE*  pb     = NULL;

  ULONG  i      = 0;


  if (!cbStoreEID || !pbStoreEID) return dwHash;

  // We shouldn't see both of these at the same time.

  if (pszFileName && pwzFileName) return dwHash;


  // Get the Store Entry ID

  // pbStoreEID is a pointer to the Entry ID

  // cbStoreEID is the size in bytes of the Entry ID

  pdw = (DWORD*)pbStoreEID;

  cdw = cbStoreEID / sizeof(DWORD);


  for (i = 0; i < cdw; i++)

  {

    dwHash = (dwHash << 5) + dwHash + *pdw++;

  }


  pb = (BYTE *)pdw;

  cb = cbStoreEID % sizeof(DWORD);


  for (i = 0; i < cb; i++)

  {

    dwHash = (dwHash << 5) + dwHash + *pb++;

  }


  if (bPublicStore)

  {

    // augment to make sure it is unique else could be same as the private store

    dwHash = (dwHash << 5) + dwHash + 0x2E505542; // this is '.PUB'

  }


  // You may want to also include the store file name in the hash calculation

  // pszFileName and pwzFileName are NULL terminated strings with the path and filename of the store

  if (pwzFileName)

  {

    while (*pwzFileName)

    {

      dwHash = (dwHash << 5) + dwHash + *pwzFileName++;

    }

  }

  else if (pszFileName)

  {

    while (*pszFileName)

    {

      dwHash = (dwHash << 5) + dwHash + *pszFileName++;

    }

  }


  // dwHash now contains the hash to be used. It should be written in hex when building a URL.

  return dwHash;

} // ComputeHash


void ComputeStoreHash(LPMAPISESSION lpMAPISession, LPSBinary lpEntryID, LPSBinary lpServiceUID, LPSBinary lpProviderUID, DWORD* lpdwSigHash, DWORD* lpdwEIDHash)

{

  HRESULT hRes = S_OK;

  MAPIUID emsmdbUID = {0};

  LPPROFSECT lpProfSect = NULL;

  BOOL fPublicExchangeStore  = FExchangePublicStore((LPMAPIUID)lpProviderUID->lpb);

  BOOL fPrivateExchangeStore = FExchangePrivateStore((LPMAPIUID)lpProviderUID->lpb);

  BOOL fCached = false;

  LPSPropValue lpConfigProp = NULL;

  LPSPropValue lpPathPropA = NULL;

  LPSPropValue lpPathPropW = NULL;

  LPSPropValue lpMappingSig = NULL;

  LPSTR szPath = NULL; // do not free

  LPWSTR wzPath = NULL; // do not free


  // Get profile section

  if (lpServiceUID)

  {

    hRes = HrEmsmdbUIDFromStore(lpMAPISession,

      (LPMAPIUID) lpServiceUID->lpb,

      &emsmdbUID);

    if (SUCCEEDED(hRes))

    {

      hRes = lpMAPISession->OpenProfileSection(&emsmdbUID, NULL, 0, &lpProfSect);

    }

  }

  if (!lpServiceUID || FAILED(hRes))

  {

    // For Outlook 2003/2007, HrEmsmdbUIDFromStore may not succeed,

    // so use pbGlobalProfileSectionGuid instead

    hRes = lpMAPISession->OpenProfileSection((LPMAPIUID)pbGlobalProfileSectionGuid, NULL, 0, &lpProfSect);

  }


  if (lpProfSect)

  {

    hRes = HrGetOneProp(lpProfSect, PR_PROFILE_CONFIG_FLAGS, &lpConfigProp);

    if (SUCCEEDED(hRes) && PROP_TYPE(lpConfigProp->ulPropTag) != PT_ERROR)

    {

      if (fPrivateExchangeStore)

      {

        fCached = ((lpConfigProp->Value.l & CONFIG_OST_CACHE_PRIVATE) != 0);

      }

      if (fPublicExchangeStore)

      {

        fCached = ((lpConfigProp->Value.l & CONFIG_OST_CACHE_PUBLIC) == CONFIG_OST_CACHE_PUBLIC);

      }

    }


    if (fCached)

    {

      hRes = HrGetOneProp(lpProfSect, PR_PROFILE_OFFLINE_STORE_PATH_W, &lpPathPropW);

      if (FAILED(hRes))

      {

        hRes = HrGetOneProp(lpProfSect, PR_PROFILE_OFFLINE_STORE_PATH_A, &lpPathPropA);

      }

      if (SUCCEEDED(hRes))

      {

        if (lpPathPropW && lpPathPropW->Value.lpszW)

        {

          wzPath = lpPathPropW->Value.lpszW;

        }

        else if (lpPathPropA && lpPathPropA->Value.lpszA)

        {

          szPath = lpPathPropA->Value.lpszA;

        }

      }

      // If this is an Exchange store with an OST path, it's an OST, so we get the mapping signature

      if ((fPrivateExchangeStore || fPublicExchangeStore) && (wzPath || szPath))

      {

        hRes = HrGetOneProp(lpProfSect, PR_MAPPING_SIGNATURE, &lpMappingSig);

      }

    }

  }

  DWORD dwSigHash = NULL;

  if (lpMappingSig && PT_BINARY == PROP_TYPE(lpMappingSig->ulPropTag))

  {

    dwSigHash = ComputeHash(lpMappingSig->Value.bin.cb, lpMappingSig->Value.bin.lpb, NULL, NULL, fPublicExchangeStore);

  }

  DWORD dwEIDHash = ComputeHash(lpEntryID->cb, lpEntryID->lpb, szPath, wzPath, fPublicExchangeStore);


  if (lpdwSigHash) *lpdwSigHash = dwSigHash;

  if (lpdwEIDHash) *lpdwEIDHash = dwEIDHash;


  MAPIFreeBuffer(lpMappingSig);

  MAPIFreeBuffer(lpPathPropA);

  MAPIFreeBuffer(lpPathPropW);

  MAPIFreeBuffer(lpConfigProp);

  if (lpProfSect) lpProfSect->Release();

} // ComputeStoreHash

July 2010 Release of MFCMAPI

Stephen Griffin - MSFT — Mon, 26 Jul 2010 14:14:12 GMT

The ~~July 2010 Release (build 6.0.0.1020)~~ July 2010 Second Release (build 6.0.0.1021) is live: http://mfcmapi.codeplex.com.

The scope of this release was primarily under the covers engineering, most notably to add SAL annotations. While adding these notations took seemingly forever, in the process I did run across a few potential crashing bugs, so the effort was worth it. It should pay off even more going forward.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

SAL: Added SAL notation to all functions and fixed every bug exposed in doing so.
Restriction and Property Editors: both had problems with editing new data. These problems have been fixed. The restriction editor should be much better behaved now, and the property editor will handle “Edit Given Prop” on a new prop much better.
Import MSG: Can now import a .MSG file to an associated contents table. Useful for transferring views, rules, etc from one mailbox to another for testing purposes.
Windows 2000: I accidently killed Windows 2000 support a few versions back by calling a kernel32 function that isn’t implemented in Windows 2000. This call has been switched from static linking to dynamic, so MFCMAPI should again run on Windows 2000.
VC 6 support: Has now been completely cut. Sorry. The SAL header (sal.h) just doesn’t work in VC 6.0 and I didn’t feel it was worth the effort to wrap the SAL notation in #defines which I could turn off for the sake of VC 6.
[Added for 6.0.0.21]: Fixed stupid stupid bug where a dialog pops if you open the system menu, as will often happen if you right click the icon to close the app.

Enjoy.

[Edit, 7/27/2010: Added details about 6.0.0.1021]

Content Indexing and Search Folders

Stephen Griffin - MSFT — Tue, 22 Jun 2010 14:32:00 GMT

[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.

May 2010 Release of MFCMAPI

Stephen Griffin - MSFT — Thu, 13 May 2010 14:57:00 GMT

The May 2010 Release (build 6.0.0.1019) is live: http://mfcmapi.codeplex.com.

Mostly bug fixes and the ever expanding scope of Smart View. I’ve added parsing for PT_LONG as a date, enabling parsing of a number of props I couldn’t parse before. I also added parsers for Web View Persist Objects (PR_FOLDER_WEBVIEWINFO) and Recipient Row Streams (dispidApptUnsendableRecips).

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

Smart View: Parser framework for PT_LONG. First parser adds rtime parsing.
Smart View: Added flag parsing for a bunch of new props.
Smart View: Many fuzzing fixes implemented.
Debug Viewer: Removed dismiss on Enter. Changed Pause from a button to a checkbox.
RTF: RTF streams with embedded binary containing 0A or 0D get messed up when viewing. Fixed viewer to honor hex stream first.
VC 2010: Fixed project so it will build in 2010.
Hex Editor: Fixed hex editor parsing to ignore more punctuation to make it easier to paste hex from other sources.

Enjoy.