EHLO Me!

This is a follow up to the article previously posted, already revisited and slightly changed.

As the last update to that revision states the workaround originally offered (previous tricks with switches and mfcmapi’s  doodling with views)  did not work consistently and thus it would be honestly to say it apparently did not uncover the core of the problem.
The problem was dragging, this  dreading issue has been occurring pretty frequently and every time we  ended up recreating the mailbox as per Microsoft solution provided in the case we had with them.

Today I’ve had another case escalated  with the same problem and I felt it was the right time to best the beast finally.
Having spent a decent amount of time I found a really working method to fix such a problem without mailbox recreation.

Here’s the overview of the process and a little bit of explanation:

1.    Key misconception of previous approaches that corruption in such cases is on mailbox level (hence the workable solution was to recreate a mailbox). This is not true as the problem is folder level and we need to remedy the folder in question to fix it (Calendar or Contacts in all cases).
2.    Methods we tried included export the data, scanning it against scanpst, import it back – that did not help as the corruption of data is only part of the problem (scanpst took care of that part) while the other one remained untouched – folder corruption. Sometimes we tried purging folders’ content with mfcmapi and it worked – however, emptying the folder is useless when we talk about folder level corruption, attempts to delete this folder and recreate from the scratch were to no avail as when the folder is corrupted even mfcmapi cannot delete it right away popping up with exception error.
3.    In order to get rid of corrupted folder we need:

a) create a folder named, say, Contacts2 with mfcmapi

b) change PR_CONTAINER_CLASS to something like IPF.Note to make it pretend it is a simple message

c) Empty items using context menu of mfcmapi

d) correctly quit mfcmapi and re-login to Outlook profile again, try to delete corrupted folder with mfcmapi – it should work this time and it can safely be deleted (granted you have a copy of the data from corrupted folder locally of course). In case it does not get deleted we may leave it hidden for a time being (PR_ATTR_HIDDEN set to True). Pre-requisites for successful deletion may include cleaning all ACL entries too.
4.    Once the corrupted folder is gone (or at least hidden) we should import scanned data back, re-grant permissions, re-add shared folder in delegate’s mailbox, re-name newly created folder (I assume it was Contacts2 or something). Important to understand you will not be able to use default folder name as long as the old corrupted folder exists in the mailbox (even if it’s hidden). Without re-adding shared folder to the delegate’s profile you will keep receiving errors like ‘folder cannot be opened’/’folder cannot be displayed’/’you don’t have permissions’ etc. Profile recreation is not needed if the folder is re-added properly.
I believe that’s it. Summarizing the above information that most troublesome part of the process is getting rid of corrupted folder – as it is crippled it does not want to let go easily.
P.S. Quite nice to know MS decided not to bother that much about the same problem when we opened the case regarding this with them. Seems like they also prefer axe rather than scalpel sometimes.

I hope I haven’t skipped anything important and this will be a valuable bit of knowledge.