MRMAPI, the Little Brother of MFCMAPI

MFCMAPI, the well-respected reveal-behind-the-scenes utility for Exchange, has a little brother called MRMAPI, which is now capable of reporting the bloat that exists within OST and PST files.

MRMAPI has an interesting history. MAPI is full of tags that are used to describe the properties of items stored in Exchange mailboxes. Originally we just stored messages but now all manner of different items are stored in mailboxes including things like administrative audit entries. And as the variety of stored items expanded, so did the set of MAPI property tags. No human being is capable of remembering the full set, especially as tags use perfectly obvious and highly memorable names like PidTagAddressBookContainer (or 0xFFFD0003 as the tag is known to MAPI).

MRMAPI first appeared as MrTag, a utility to report all known MAPI tags. It has been expanded over time and is a great way to find out what tags exist so that developers reference the right tag or don’t end up creating a new tag when one already exists.

I suspect that few outside the select group of programmers who care about MAPI would give MRMAPI any time if it just existed to tell you what MAPI property tags exist. But it is interesting when it provides an insight into the white (unused) space that exists in PST and OST files.

Related:Can I Use Microsoft Outlook as a Makeshift Helpdesk Ticketing System?

Software vendors have created businesses based on telling people of the horrors of white space in Exchange databases and the need to practice database defragmentation at frequent intervals. Once this was quite a popular habit and people chatted at conferences about their experience of running ESEUTIL and how successful they were at recovering disk space. The need to defragment a database largely disappeared from Exchange 2003 onward, but that didn’t stop the defragmentation police lecturing others about their poor management of white space.

In any case, you can copy the latest version (March 27) of MRMAPI along with MFCMAPI from Codeplex. And because it is a Codeplex project, you can copy the source code along with the executables.

Running MRMAPI to report the unused space in a PST or OST is a matter of putting the executable in a convenient folder, opening a CMD window, and then typing MRMAPI –pst –I “filename”. As you can see in the screen shot, I ran the program against a PST that I had on my PC and found that the file had over 30% free space. Running MRMAPI against my OST showed that less free space was in this file, which was the expected outcome as I had only recently rebuilt the OST after moving to a new PC. If you run the program against an OST, make sure that it can access the file. I had to close Lync down before MRMAPI was happy.

Originally the program failed when I tried running MRMAPI against an OST. Apparently the program hadn’t been tested against an OST generated by Outlook 2013, which compresses some data items that earlier versions leave alone. Stephen Griffin, the developer of MRMAPI and MFCMAPI, attempted to guide me through the process of making the necessary change to the source code to fix the problem, but my sadly degraded programming skills failed miserably, mostly because it’s hard to transfer COBOL skills to C++. In any case, the bug is fixed in the current release, which proves the importance of making sure that you download new versions of utility programs.

Why is all this important? Well, we’ve always known that the file size reported by a PST does not accurately reflect the real data. When you import data from a PST by running the New-MailboxImportRequest command (or by using Microsoft’s PST Capture tool or one of its commercial competitors), you might have to update mailbox quotas to allow the Mailbox Replication service to load the data from the PST into the target mailbox. Knowing how much to increase the quota by seems like a very good thing. Mind you, seeing that Exchange 2013 has changed the way that it “charges” for internal mailbox overhead against mailbox quota so that some mailboxes might apparently increase by 30% over the size reported by Exchange 2010, perhaps it’s still best to increase mailbox quotas by the PST size + 50% before attempting any import. At least the import job will complete…