Message Classes. Here at Simply Migrate we love Message Classes. Not only because they make your Purple Sticky Notes Purple. They are so diverse, so powerful, yet so simple.
They influence the little things that make life a little sweeter, the icon in Outlook, the way an item is displayed, which properties are supported, which messages are migrated with Simply Migrate.
If you have Outlook or use Exchange then you are already very familiar with Message Classes. Every MSG (an item in Outlook) contains a Message Class property along with many other pieces of metadata that describe the item.
Showing Message Class in Outlook
To show the Message Class of items in Outlook, right click the table header and select ‘Field Chooser’
From the Field Chooser, select “All Mail Fields” and then scroll down the list until you see “Message Class”. Finally drag “Message Class” onto the table header and revel in the unearthed beauty before you.
I’m interested, tell me more about Message Classes
The most common Message Class is IPM.Note which is generally used to represent an Email. Then there are some obvious ones IPM.Contact, IPM.Task and IPM.Appointment. Quickly however the list becomes more specific, more obscure, more niche.
The Message Class of an item is also important as it helps define the other properties/metadata that are relevant to the item. Without the Message Class an Email may have a Birthday property or a Contact may have a Start Time property. What’s worse is if you lose or mistake the Message Class an item may lose other pieces of essential information.
Some applications use Message Classes to specify different stages of a life cycle that an item (or related items) can go through. If you’ve responded to a Calendar invite then you’ve sent an IPM.Schedule.Meeting.Resp message, an acceptance will result in a sub-type of .POS (positive), if you decline .NEG (negative) and if you’re unsure .TENT (tentative).
Common email archiving solutions such as Enterprise Vault (EV) or Enterprise Archive Solution (EAS/Zantaz) indicate stubbed items by appending a new sub-type to the end of the existing Message Class (.EnterpriseVault.Shortcut for EV and .EAS for Zantaz).
How many Message Classes are there? Unlimited. Applications or Enterprises can create their own Message Classes and apply behavior based on them.
That’s a lot of business critical information contained or related to an items Message Class.
Message Classes, data migration and a long list
If you’re considering a PST, File System (.msg), Exchange, O365 Tenancy migration or EV/EAS rehydration the absolute last thing you want to hear is “we don’t support that Message Classes” or “we only support these Message Classes”. And you definitely don’t want to discover after the migration that all your Contacts have been turned to Emails and lost all the properties that make a Contact a Contact.
We’re often asked “which Messages Classes do Simply Migrate support?”
Without being smug, all of them.
Well more accurately all of them we’ve encountered. And because of the amazing array of Partners and Customers we work with, we’ve encountered A LOT. Here’s a list of some of the recent Message Classes we’ve recently migrated successfully
A “no way comprehensive” list of Message Classes
In fact we’re so confident that we’ll handle any Message Class, that we’ll even offer a prize for anyone that can find one we don’t support!
How do we do this?
The Universal Fidelity Engine
(Unfortunately I was told that The Universal Fidelity Engine (UFE) is not a suitable answer)
Which means the answer is MAPI Properties. Lots and lots and lots of glorious MAPI Properties.
Whilst MAPI Properties are a constant conversation topic at the Simply Migrate office, strangely most people don’t want to talk about them.
A little about MAPI Properties
Message Class is an example of a MAPI Property in this case describing the “type” of item. Many other properties exist describing an attribute of an item, for example, Subject, Location, Importance, Received Date etc.. (if you thought the Message Class list above was long then this list really would be obscene).
MAPI Properties are described with a Tag and corresponding value, the Tag also defines the type of the Property. There are two flavours of Tags, MAPI-defined properties and Named Properties. MAPI-defined properties are a predefined list of common properties whilst Named Properties allow application developers or service providers to create their own properties without risk of them being overwritten by someone else. Everything you see in Outlook when you open a message is contained within the MAPI Properties for the item and in fact all the things you don’t see are also stored in MAPI Properties.
Losing MAPI Properties during migration is akin to ripping a page out of book; you may not notice it at first but when you want the information it held suddenly it’s vitally important and often irreplaceable. Just imagine losing the date a message was received, a recipient, an attachment, the transport headers, whether the message was read, the colour associated with your task…
Getting back to Purple Sticky Notes
As an aside, my favourite MAPI Property (strictly speaking it’s a Named Property) is 0x8021101F (PidNameKeywords), it’s maybe not the most exotic of tags and maybe you’ve not heard of it but it makes your Purple Sticky Notes purple and that’s that’s important to me.
Because it’s important to us and we think the little things are important to you, we make sure we migrate the MAPI Property 0x8021101F along with all your faves (using the Universal Fidelity Engine!). We simply couldn’t live with ourselves if after a migration you were left staring at a wall of yellow, unless your name is Oz and you happened to want it that way.
So you can leave us to
worry about enjoy Message Classes and MAPI Properties and you can get on with migrating, simply.