MRMAPI, the Little Brother of MFCMAPI

You've probably heard of MFCMAPI, a very useful program in the hands of any administrator who wants to learn just what's stored in an Exchange mailbox. MRMAPI is less well known, but it is also pretty useful for other reasons...

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.

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…

Follow Tony @12Knocksinna

Discuss this Blog Entry 2

on Apr 26, 2013

Can someone point me to the book (I will pay for it), that has some comprehensive list of all fix it tools for Exchange please?

I am not so familiar with the product, but just run into this. I have an assistant that would like to have an offline access to email...
She is helping 2 execs, but it is only allowed to have offline access to one due to sensitivity. I am sure that selective "Offlining" exists in such mature product, but it maybe at the level above my head.

on Apr 30, 2013

I'm not sure that there is one book that covers every possible tool that could be used with Exchange. The problem is that the tool set changes over time, so keeping up with updates is an issue.

As to offline access to email for different mailboxes, http://technet.microsoft.com/en-us/library/ee815819.aspx provides a description of how to add multiple email accounts to an Outlook profile. Perhaps this is what you want? It's hard to say without knowing how the employee works and the culture for sharing that exists between the employee and the managers.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×