One of the lesser known tricks in MAPI is that when you open a distribution list (MAPI_DISTLIST) from an address book using OpenEntry, if you don’t specify an interface what you get is not an IMailUser, but is in fact an IDistList, which inherits from IMAPIContainer. This gives you a means to access the members of the distribution list. Just call GetContentsTable and there they are. However, this trick doesn’t always work with MAPICDO when you’re talking to Exchange 2010. When you look at an Exchange 2010 address book using MFCMAPI, you’ll notice that all of the entry IDs are short term entry IDs. They don’t contain the DN of the entry being referred to. Instead, what they contain is an ephemeral ID, which is supposed to be a way to refer to an entry in the address book without constantly sending a DN back and forth. With the introduction of the Address Book Service in Exchange 2010, we split the concept of ephemeral IDs to include those generated by the Active Directory, and those generated by the Address Book service. The ID we find in these short term entry IDs is an Active Directory ID.

The upshot of all this is that when we use this short term entry ID to open an entry in the address book, we don’t get the full complement of properties we would normally expect (and that we would get if the short term Entry ID had used an Address Book ID). A side effect of this is that when we further try to call GetContentsTable, NspiGetMatches, the NSPI function which we’re calling under the covers, doesn’t understand the ID we pass to it and the call fails with the error MAPI_E_CALL_FAILED.

All is not lost, however. One of the properties we DO get using the short term entry ID is a proper long term entry ID with a full DN. And objects opened with this entry ID contain the full set of properties we normally expect to see. Further, we can now call GetContentsTable and get the members of the distribution list.

If you’re playing along in MFCMAPI, you would do this by:

1. Select the distribution list whose members you wish to see.
2. Right click on PR_ENTRY_ID in the bottom pane and select “Open as Entry ID or object”

The DL members will now appear in a new window. Back in the original window, the full set of properties for the DL will appear in the lower pane. In code, you would do this by opening the item with the short term entry ID, calling GetProps to get the long term entry ID, then calling OpenEntry again to get the full item.

This trick works for any of the PT_OBJECT type properties you expect to find on any entry in the address book, MAPI_MAILUSER included.

Enjoy!

I’ve just been given clearance to publicize this since apparently it was discussed at MEC: The MAPICDO download *will* be updated to support Exchange Server 2013. This is important because:

1. As has been discussed, Exchange Server 2013 will only allow MAPI connections over RPC/HTTP, aka Outlook Anywhere.
2. RPC/HTTP is (until now) only implemented in Outlook’s MAPI.

So without this update to MAPICDO, the only MAPI implementation which would be able to connect to Exchange 2013 would be Outlook’s MAPI.

Publication dates, instructions for usage, etc. are all forthcoming.

Enjoy!

So – there’s a potential hang in the current builds of MAPICDO, but you can avoid it, so it doesn’t have to be a huge problem.

The repro scenario for the hang is this: You’ve got an application which does thread level impersonation and also uses MAPI. Your application starts up multiple threads under different user contexts, each of which log in to MAPI. Eventually, as each of these threads completes its work, you start releasing objects. Your thread hangs while releasing a message store object. If you were to attach a debugger and knew the stacks to look for, this hang would look almost identical to the hang we fixed in MAPICDO 6.5.8244, discussed here.

What’s going on here is related to how MAPI tracks connection lists. Each user context gets its own connection list, stored in shared memory and indexed using what is essentially the CRC of the SID of the user who initiated the connection. When starting, there are no connection lists being tracked. The first MAPI thread to initiate a connection builds a connection list which is stored in this shared memory. This thread then spins up a polling thread using CreateThread. No special effort is made to adjust the thread token of this helper thread, so it ends up running with the thread token of the calling process. At some point, this thread needs to access the connection lists. As long as only one connection list exists, we assume it must be the one we need and use it – everything’s fine.

The problems happen when we have a second MAPI thread under a new user context. We create a second connection list and add this to the list. The polling thread spun up for this thread now has two connection lists to choose from. It concludes that neither is appropriate because the SIDs don’t match, and ends up shutting down without doing any work. Later, the first polling thread encounters the two connection lists and ends up shutting itself down without ever signaling that it has finished its work.

This is where the main MAPI threads are now in trouble, as they will wait for those polling threads to signal completion, which will never happen because those threads are no longer running.

Fortunately, most MAPI server applications don’t work this way. Most MAPI server applications run as a single service account which has appropriate permissions to log in to the various mailboxes it needs to. So either there is no impersonation at all, or all of the MAPI threads impersonate the same user. Either way, there is no opportunity to run in to this problem.

So – if you do happen to run in to this issue, you should look in to creating a single service account to handle all your MAPI work, then reduce/eliminate your thread level impersonation.

The (very late) October 2012 Release (build 15.0.0.1036) is live: http://mfcmapi.codeplex.com.

As part of my work to get MFCMAPI and MrMAPI working well in side-by-side scenarios where both Outlook 2013 and an earlier version of Outlook are installed, I’ve added a –version switch to MrMAPI. This will help us ship builds of OCAT that work properly in these situations

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

• MrMAPI: Added –version switch.
• MFCMAPI: Corrected column name in mailbox table
• MFCMAPI: Fix blank headers when headers are dragged around.
• MFCMAPI: Corrected an unnecessary crash in an Outlook+EMS (unsupported) scenario
• MFCMAPI: Updated a number of flags, tags, and dispids

Enjoy.

I’ve just been given permission to announce we’re targeting the release of the updated MAPICDO which will support Exchange 2013 to coincide with the release of Exchange 2010 SP3.

Exchange 2010 SP3 was announced a while back on the Ehlo blog. As you can see from that announcement, SP3 provides much needed changes to allow for coexistence between Exchange 2010 and Exchange 2013. The updated MAPICDO is part of this work.

I don’t have dates for SP3, but you can track the Ehlo blog for that.

When Outlook’s POP3 provider syncs with a POP3 mailbox and the user chooses to leave a copy of the messages on the server, it has to remember which messages it has already downloaded so it doesn’t accidently download the same message twice. It does this by tracking the UIDL of each message it has downloaded in a binary property on a hidden message. This post describes how Outlook locates this binary property. My next post will detail how to parse this property.

Locate the Message

1. Get PR_SEARCH_KEY from the profile (from the profile section MUID_PROFILE_INSTANCE)
2. Open the Associated Contents for Inbox.
3. Build this restriction:

   SRestriction rgRes[3]; 
   SPropValue rgProps[3]; 
   rgRes[0].rt = RES_AND; 
   rgRes[0].res.resAnd.cRes = 2; 
   rgRes[0].res.resAnd.lpRes = &rgRes[1]; 
   rgRes[1].rt = RES_PROPERTY; 
   rgRes[1].res.resProperty.relop = RELOP_EQ; 
   rgRes[1].res.resProperty.ulPropTag = PR_CONVERSATION_KEY; 
   rgRes[1].res.resProperty.lpProp = &rgProps[0]; 
   rgRes[2].rt = RES_PROPERTY; 
   rgRes[2].res.resProperty.relop = RELOP_EQ; 
   rgRes[2].res.resProperty.ulPropTag = PR_MESSAGE_CLASS; 
   rgRes[2].res.resProperty.lpProp = &rgProps[1]; 
   rgProps[0].ulPropTag = PR_CONVERSATION_KEY; 
   rgProps[0].Value.bin = pVals[iSearchKey].Value.bin; // PR_SEARCH_KEY from the profile 
   rgProps[1].ulPropTag = PR_MESSAGE_CLASS; 
   rgProps[1].Value.LPSZ = (LPTSTR)"IPM.MessageManager";

4. Find the message using FindRow.
5. If this fails, change the restriction:

   rgRes[1].res.resProperty.ulPropTag = rgProps[0].ulPropTag = PR_SEARCH_KEY;

   And re-run the FindRow
6. If THAT fails, for non-Exchange stores (compare PR_MDB_PROVIDER to pbExchangeProviderPrimaryUserGuid), restrict instead on PR_SUBJECT (using printf style substitution here for brevity):: 
   

   "Outlook Message Manager (%s) (KEY: %s)", PR_PROFILE_NAME, HexFromBin(PR_SEARCH_KEY)

7. Open the message located in step 5, 6, or 7.

For Outlook 2010 and higher, you can substitute the following for steps 3-6:

CHAR g_szGeneralKey[] = "General Key"; 
const SBinary g_binGeneralKey = {sizeof(g_szGeneralKey), (LPBYTE)g_szGeneralKey};

Now, use these values for PR_SEARCH_KEY and PR_PROFILE_NAME and run through steps 3-6. If this fails to find a message, fall back to the original steps 3-6.

Open the Attachment

There may be more than one attachment on the message. Try the following, in order (note again the use of printf style notation)::

1. Look for an attachment whose PR_ATTACH_LONG_FILENAME matches "BlobPOP%s", szEmailAddress
2. Look for an attachment whose PR_ATTACH_FILENAME matches "BlobPOP%s", szEmailAddress
3. Look for an attachment whose PR_DISPLAY_NAME matches "BlobPOP%s", szEmailAddress
4. Look for an attachment whose PR_ATTACH_FILENAME matches "Blob%.8x", dwAcctUID, where dwAcctUID comes from PROP_ACCT_MINI_UID.

PRO_ACCT_MINI_UID is a property you can retrieve via the Account Management API. Here’s the definition:

#define PROP_ACCT_MINI_UID PROP_TAG(PT_DWORD, 0x0003)

Open the Blob

The POP3 UIDL data blob is stored in PR_ATTACH_DATA_BIN.

Parse the Blob

We’ll discuss how to parse this blob in my next post. Stay tuned.

Enjoy!

In my previous post, we discussed how to locate Outlook’s POP3 UIDL history. Now that we have the blob, let’s look at how to parse it:

The encoded uid of the message has been escaped so only alphanumeric characters and the character '$' are present. Non-alphanumeric characters in the original UID are represented as '$'+ 2 digit hex encoding. For instance, the character '-' is encoded in the UID as $2d

For example, this blob:

030017002B623230313230393036313331313338304243353335444224326445413633243264313145312432644137354324326430303231354144374242373400 
2B623230313230393036313331313337313433444242434224326445413636243264313145312432644135463224326430303232363443313534424100 
2B623230313230393036313331313339323445383833333324326445413334243264313145312432644133414324326430303231354144374631353600 
2B623230313230393036313331313336333446324533383124326445423236243264313145312432644244353924326430303231354144383043324300 
2B623230313230393036313331313339333733443545363924326445413236243264313145312432644231363024326430303231354144393946303000 
... 

0300 Version: PBLOB_VERSION_NUM 
1700 Count: Count of restags (0x17 = 23) 
2B623230313230393036313331313338304243353335444224326445413633243264313145312432644137354324326430303231354144374242373400 Tag 1 
2B623230313230393036313331313337313433444242434224326445413636243264313145312432644135463224326430303232363443313534424100 Tag 2 
2B623230313230393036313331313339323445383833333324326445413334243264313145312432644133414324326430303231354144374631353600 Tag 3 
2B623230313230393036313331313336333446324533383124326445423236243264313145312432644244353924326430303231354144383043324300 Tag 4 
2B623230313230393036313331313339333733443545363924326445413236243264313145312432644231363024326430303231354144393946303000 Tag 5 
...

2B623230313230393036313331313338304243353335444224326445413633243264313145312432644137354324326430303231354144374242373400 = 
"+b201209061311380BC535DB$2dEA63$2d11E1$2dA75C$2d00215AD7BB74" 
+ = Successful get 
b = Content is body 
2012 = Year 
09 = Month 
06 = Day 
13 = Hour 
11 = Minute 
38 = Second 
0BC535DB$2dEA63$2d11E1$2dA75C$2d00215AD7BB74 = UID

0BC535DB + $2d + EA63 + $2d + 11E1 + $2d + A75C + $2d + 00215AD7BB74 = 
0BC535DB + '-' + EA63 + '-' + 11E1 + '-' + A75C + '-' + 00215AD7BB74 = 
0BC535DB-EA63-11E1-A75C-00215AD7BB74

So the first UID encoded in this blob is "0BC535DB-EA63-11E1-A75C-00215AD7BB74", and the body was successfully retrieved on 9/6/2012 at 13:11:38.

Here’s a nice article on choosing between mail apps and add-ins for Outlook development:

http://blogs.msdn.com/b/officedevdocs/archive/2012/12/10/when-should-i-choose-to-create-a-mail-app-versus-an-add-in-for-outlook.aspx

Bottom line: if you can do what you need to do from a mail app, it’s the way to go, especially since apps developed for Outlook will work in OWA..

I’ve just checked in a fix for the Wrapped PST sample that should allow it to work with Outlook 2013. Let me know if you find any problems with the sample. I haven’t tested the other samples yet as they don’t appear to get as much attention as the wrapped PST.

Enjoy!

The January 2013 Release (build 15.0.0.1037) is live: http://mfcmapi.codeplex.com.

We’ve been working a few issues lately related to the size of a OST versus the size of a mailbox. I’ve added some features to MrMAPI to aid in these sorts of issues. First is the –Size switch, which calculates the size of all the items in a folder and it’s subfolders. You can combine it with the –Folder switch to get the size of any folder. For instance, using the @2 notation to refer to the Contacts folder, I can get the size in my own mailbox as follows:

C:\>mrmapi -size -f "@2"
Folder size (including subfolders)
Bytes: 388867
KB: 379
MB: 0

The second feature uses the documentation of the PST file format to read the header of a PST/OST file and report free space. Note that this does require that the file not be loaded in Outlook when you run it. Simply closing Outlook is sufficient. Here’s an example run against an OST here:

C:\>mrmapi -pst -i c:\Users\sgriffin\AppData\Local\Microsoft\Outlook\outlook.ost
Analyzing c:\Users\sgriffin\AppData\Local\Microsoft\Outlook\outlook.ost
Unicode PST
File Size           = 2.71 GB (2911577088 bytes)
Free Space          = 1.05 GB (1132028480 bytes)
Percent free        = 38.88%

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

• MrMAPI: Added –PST for PST whitespace calculations
• MrMAPI: Added –Size for folder size calculations
• MrMAPI: Corrected handling of –Store parameter
• QuickStart: Using QuickStart now populates the main window UI when appropriate
• Property Editor: If you paste a property name in with extra whitespace or commas, these are now ignored
• SmartView: Added a few more properties

Enjoy.

Some of you may have already noticed this by now, but the logic used to load MAPI providers has changed in Outlook 2013. Previously, we would use LoadLibrary to load a MAPI provider. This API has logic in it to search the user’s PATH for the provider, which is great if you placed the provider somewhere on the user’s PATH. In Outlook 2013, though, we call LoadLibraryEx, passing the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS flag. The effect of this flag is that Outlook no longer searches the path.

Fortunately, you can still put your provider wherever you want by putting the full path in MAPISVC.INF. You may need to rethink how you load your own dependencies, but now that you know what’s going on that problem shouldn’t be insurmountable. BTW – Process Monitor is invaluable in investigating this sort of issue.

http://msdn.microsoft.com/en-us/library/ee159108(v=exchg.80).aspxIf you’ve got an application that processes e-mails paying attention to the PR_RECEIVED_BY_* and PR_RCVD_REPRESENTING_* properties, you may notice these properties showing up on e-mails in the Sent Items folders of your users. That is, messages submitted by a user who doesn’t explicitly mark themselves as a recipient will still appear (in these properties) as if they received the message. This may interfere with your logic, especially if you have a need to distinguish mails a user sent from mails a user received.

Before we get into an explanation of why this is happening, some workarounds:

• PR_MESSAGE_RECIP_ME, PR_MESSAGE_TO_ME, PR_MESSAGE_CC_ME: These Boolean properties will be true or false depending on whether the user is in the recipient list, specifically as either a TO or CC recipient. Together, these properties will cover every case except for when the user was BCC’d.
• PR_TRANSPORT_MESSAGE_HEADERS: Typically only present on inbound message.
• PR_SENDER_SMTP_ADDRESS: Typically only present on inbound messages. There are several related properties in the PR_SENDER_* family with the same quality.

Together, you should be able to use these properties to heuristically decide if a message was, from the user’s perspective, sent or received. And do note that any algorithm you put together here will by necessity be a heuristic. There is no single property that tracks whether a message in a user’s mailbox was sent by the user, received by the user, neither, or both.

Now – when/why does Exchange 2013 stamp these properties? When first: It appears Exchange 2013 will stamp these properties when Outlook (any version) submits a mail from a profile with only one Exchange mailbox in it. These properties will then be present on the copy of the message which ends up in Sent Items (or wherever the sent copy is to be saved). If the profile contains multiple Exchange accounts (aka Multi-Ex, possible in Outlook 2010 and higher), then Exchange 2013 does not appear to stamp these properties on the message that ends up in Sent Items.

Why: Exchange 2013 has a completely new store, written in managed code (the old, native, store.exe no longer exists). As part of this work, we found that it was possible for the transport to attempt to deliver a message multiple times. Part of the work involved in making sure this didn’t happen was to ensure these properties were set on messages as we processed them for transport. The difference in behavior with Multi-Ex is attributable to the fact that Outlook builds the messages it intends to submit differently in Multi-Ex.

It was suggested to me that this change in behavior means our documentation is now incorrect. I do not agree with this assessment. For instance, here’s a snippet from the MSDN documentation of PR_RECEIVED_BY_NAME:

Contains the display name of the messaging user who receives the message...These properties are an example of the address properties for the messaging user who receives the message. They must be set by the incoming transport provider.

And the [MS-OXOMSG] protocol doc:

The PidTagReceivedByName property ([MS-OXPROPS] section 2.961) contains the e-mail message receiver's display name, as specified by the DisplayName field of the RecipientRow structure ([MS-OXCDATA] section 2.8.3.2).

Note that the documentation does not indicate anything about what should or should not be present on sent items. It only documents these properties in relation to received messages. What happens with sent messages is undefined behavior, so any behavior is acceptable, as is changing behavior. I’m sending this article over to the protocol team, however, so they can note this behavior with respect to Exchange 2013.

As several of you have noted, we recently released an update for the MAPICDO package. This is the update you have all been waiting for, as it is now possible to build an RPC/HTTP enabled profile to connect to Exchange 2013. What several of you have also noticed is that this update did NOT come with any guidance for HOW to build such a profile. Such guidance does exist, but hasn’t been published yet. I had delayed commenting on this new package until the guidance was ready, but it’s taking longer than I thought it would.

I’m working with the team responsible for publishing the guidance to get it out the door. We’ve almost got it ready, so I expect to see it up on the download site (or the Exchange blog) any day now. Once that guidance is published, Dave will most likely publish an updated version of his How to Build a Profile For MFCMAPI guidance. I’ll link to both as soon as they’re public.

So – I’ve been playing a lot with Apps for Office lately. I even wrote and published an app:

http://office.microsoft.com/en-us/store/message-header-analyzer-WA104005406.aspx

My management encouraged me to put together a presentation on everything I learned while developing this app. I did, and they asked me to record a video of me delivering this presentation. So – now you all get to hear me drone on about App development. Here’s the entry on the Partner Technical Services blog containing my presentation:

http://blogs.technet.com/b/ptsblog/archive/2013/03/20/microsoft-office-lessons-learned-developing-apps-for-the-office-store.aspx

And here’s the direct YouTube link:

Microsoft Office - Lessons Learned Developing Apps for the Office Store

and the direct link to the slide deck:

https://skydrive.live.com/view.aspx/Documents/AppsForOffice.pptx?cid=8d22925062e717b6&id=documents&authkey=!AOsqoQIn-Xb4nBk&&wdSlideId=274

In case you don’t want to dig through the slide deck for the links I reference, here they all are:

Finally, my JQuery EWS parsing trick:

(function ($) {
     $.fn.filterNode = function (name) {
returnthis.find('*').filter(function () {
returnthis.nodeName === name;
         });
     };
 })(jQuery);
function callback(asyncResult) {
var response = $.parseXML(asyncResult.value);
var responseDOM = $(response);
var Prop = responseDOM.filterNode("t:InternetMessageHeaders")[0];

Enjoy!

The March 2013 Release (build 15.0.0.1038) is live: http://mfcmapi.codeplex.com.

A few smaller changes this round: I’ve upgraded the project to support Visual Studio 2012. I also fixed a bug in the new PST parsing, and inserted a new dialog into the “Open from GAL” path to give the user the opportunity to adjust the server DN (this should help in testing Exchange 2013 scenarios).

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

• MrMAPI: Fixed –PST whitespace calculations to account for Outlook 2013 OSTs correctly
• QuickStart: Added binary output to Nickname quickstart
• SmartView: Added parsing for Contact Address Book container entry IDs
• MFCMAPI: Added dialog to allow Open from GAL to edit the server DN
• Upgraded projects to Visual Studio 2012
• MFCMAPI: Fixed visual artifact which creeps in to folder hierarchy (vertical line next to the arrows)

Enjoy.

The March 2013 Second Release (build 15.0.0.1039) is live: http://mfcmapi.codeplex.com.

This is an emergency build to correct a problem a few people were having running MFCMAPI on Windows XP.

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

• MFCMAPI: On Windows XP, got an error that it was not a valid win32 application.

Enjoy.

Anybody remember that Message Header Analyzer App for Office I wrote about last month? Well, the folks who do support for Exchange and Office 365 caught wind of it and liked it. In fact, they liked it so much they asked me to port the code into their Remove Connectivity Analyzer. Here’s the blog entry they just put up yesterday announcing this:

http://blogs.technet.com/b/exchange/archive/2013/05/01/introducing-message-analyzer-an-smtp-header-analysis-tool-in-microsoft-remote-connectivity-analzyer.aspx

So even if you don’t have Exchange 2013, you can still use the Message Header Analyzer by going to https://testconnectivity.microsoft.com/?tabid=mha. Feature requests and bug reports can either be directed through the feedback link on that site or by contacting me.

Enjoy!

Recently, I’ve had a few different customers coming to me asking about Outlook’s interaction with the Credential Manager. If you’ve not looked at the Credential Manager before, you can read a bit about it here. Interaction with the Credential Manager is fairly straightforward. There’s one function, CredWrite, which is used to store credentials, and another, CredRead, which is used to retrieve them. The customers who contacted me both had the same goal: use CredWrite to cache a set of credentials for Outlook to use so the user isn’t prompted for a password.

While this seems a simple request, it turns out that once you start considering all the various scenarios for which Outlook has to cache credentials (O365, Exchange on-Premise, machine in the domain versus out of the domain, multiple profiles, multiple credentials for a single profile), it gets complicated real fast. Even if you figure out how to cache credentials for Outlook to use for one scenario, a slight change to that scenario means the credentials have to be cached differently. So while the set of functions to be used in managing credentials is simple, the logic that goes into making these calls is very complex. We ran this by development just to make sure, but the results were as we expected: We cannot support any third party manipulation of the credentials used by Outlook. If a user wants to cache credentials, they need to enter them at the credential prompt.

It;’s here! It’s finally here! The May 2013 update of MAPICDO is live here:

http://www.microsoft.com/en-us/download/details.aspx?id=39045

At that same link, you’ll also find the long awaited configuration guidance. It’s not immediately obvious it’s there. Just hit the Download link and it will be offered to you. As a reminder, this configuration guidance will help you in configuring an RPC/HTTP (aka ROH) profile using this MAPI/CDO download package. These instructions do NOT apply equally to Outlook’s implementation of MAPI. Attempting to use these guidelines to build a profile for Outlook’s MAPI, or attempting to “port” a profile between the two implementations WILL lead to failure.

Installation details:

• This version is 6.5.8320.0. All of the files in the update are dated April 29th, 2013.
• If you already have a version of the MAPI Download installed, you must uninstall it before installing the new version. The installer does not upgrade, nor does it warn you if you try to install it without uninstalling the previous version.

Fixes:

• ROH now works when running under Local System context
• Proxy server settings are no longer case sensitive.
• PR_PROFILE_RPC_PROXY_SERVER can now be set using Unicode.
• Improved support for mixed 2010/2013 environments.

Enjoy!

Now that MAPICDO has been updated to support connecting to Exchange 2013 using RPC/HTTP, and the guidance for programmatically building profiles has been published, Dave has published a pair of articles which will be very helpful for customers using MFCMAPI in such environments. The first covers using the guidance to build a profile for connecting to Exchange 2013:

http://blogs.msdn.com/b/dvespa/archive/2013/05/21/how-to-mfcmapi-create-mapi-profile-exchange-2013.aspx

The second article covers a scenario likely to be encountered during migrations/upgrades, building a profile that works against both Exchange 2013 and Exchange 2010:

http://blogs.msdn.com/b/dvespa/archive/2013/05/27/omniprof.aspx

Enjoy!