Hey Steve,
Sorry for the late reply. The site didn't ping me with email, despite my settings.
The force system files option seems to do the trick. Surprised that it no longer works by default, but at least there's a way to make it work.
I'm bundling mfcmapi in a suite of tools used by our techs, and I think I'll stick with the 6.0.0.1025 since I don't have to rig the registry setting for that option.
Keep up the good work.
Ted - are you still having a problem with the April 2012 and later builds? This fix:
http://mfcmapi.codeplex.com/workitem/15088
should have affected this issue.
Hello
I apologise if this has been covered elsewhere but my searches have yet to find a solution. We have a corrupt message in a Journal mailbox which I have been unable to delete even using MFCMAPI.
Apologies also if this is the incorrect forum for such a discussion, however posted here in reference to the errors thrown within the MFCMAPI utility.
We're running Exchange 2010 SP1 (14.01.0218.013) on (VMWare) Windows Server '08 R2 Enterprise Edition.
FYI prior to attempts below, a Mailbox Repair Request through Exchange completed successfully against the database, as did an ESEUTIL integrity check.
Using MFCMAPI June 2012 release, I open the Journal Mailbox, load the Inbox contents table and click on the message - then I receive the following popup:
Error:
Code: MAPI_E_CORRUPT_DATA == 0x8004011B
Function DefaultOpenItemProp( iItem, mfcmapiDO_NOT_REQUEST_MODIFY, lppProp)
File ContentsTableListCtrl.cpp
Line 1467
From what I can gather from comments in ContentsTableListCtrl.cpp it appears DO_NOT_REQUEST_MODIFY is called if Access Denied is received from a Modify request - have verified I have full access permission (both via role and implicit) to the Journal Mailbox and mailboxes of the sender/recipient,
After clicking OK to above message, I then receive another dialog:
Error:
Code: MAPI_E_CORRUPT_DATA == 0x8004011B
Function m_lpContentsTableListCtrl->DefaultOpenItemProp( iSelectedItem, bModify, lppMAPIProp)
File: ContentsTabledlg.cpp
Line 820
MFCMAPI will then populate (what looks to be) the bottom pane with an "incomplete" property table for the message.
If I right-click on the message in top pane and select “Delete Message” (Permanent delete passing DELETE_HARD_DELETE), there is no error, but the message remains in the contents table even after Refresh (have tried other delete options as well, with same issue)
If I try to open the item, I receive the error dialogues lised above, and then also the following:
Error:
Code: MAPI_E_CORRUPT_DATA == 0x8004011B
Function OpenItemProp( iItem, mfcmapiREQUEST_MODIFY, (LPMAPIPROP*)&lpMessage)
File: FolderDlg.cpp
Line 1186
I have tried this on multiple workstations / servers with a mix of Outlook 2003, Outlook 2007, Outlook 2010 - all produce same error. Unfortunately we don't have any machines running x64 version of Outlook to test x64 version of MFCMAPI.
I have seen these errors in MFCMAPI previously, and was able to work around it then by right-clicking on the message in the content table, then selecting “Advanced\Get props by longterm EID" - this retrieved the full content/property table for the message and I was then able to delete the message successfully using MFCMAPI. I have attempted to repeat this process for the current message but it was unsuccessful this time (no further properties were retrieved after refresh).
At this point I am thinking my only option is to export mailbox content to PST (skipping bad items obviously), zap the mailbox, and then create a brand new mailbox, but I am very open to any other ideas to resolve the MAPI error first?
Thank you very much in advance for your time and advice!
In this scenario, the server is the one returning the error. MFCMAPI just reports it. Your export/import resolution sounds workable if you don't want to chase the problem on the server side. If you do want to chase it there, I'd start with looking at event logs, then the RCA logs on the CAS.
Hi Stephen
Thank you very much for your quick and helpful response :)
Hello
I've been using recent version of MFCMapi (15.0.0.1030) along with Exchange 2010 SP2 RU3.
In last few days, I had to recover calendar items from user dumpster and it is easier to do it with MFCMapi than using Outlook due to change in structure of Dumpster 2.0 (all folder items show in single dumpster and recover to single folder)
In both cases I used MFCMapi to recover "IPM.Appointment" items from "Recoverable Items" folder under user mailbox, i.e. copying from there to user calendar under top of information store, it created lot of duplicates for each meeting item copied in this fashion.
I am sure it didn't do this with previous releases - Anyone else facing same issue or have any thoughts on what could be causing this, if I am doing something wrong on my side?
Thanks in advance.
Trying to rename a default folder using the June release of MFCMAPI and getting the following error:
Error:
Code: MAPI_E_CORRUPT_DATA == 0x8004011B
Function HrSetOneProp(lpMAPIContainer,&sDisplayName)
File HierarchyTableTreeCtrl.cpp
Line 853
I have tried multiple mailboxes and getting the same result. No signs of corruption on any of the databases in the logs so I'm thinking this release does not work with e2010 SP2 and/or RU3?
If this is the case is there any timeframe on when the new release is coming?
Thanks
Inmar, could you (or someone) please explain in more detail what needed to be done?
Thanks,
Rennie
I don't repro any problems with recovering items. Can you give your exact repro steps?
Issue: User shift deletes or move items into PST file from his/her calendar. The items can be seen in dumpster OR "Recoverable Items" folder within Dumpster.
Steps:
1. Login to user mailbox via MFCMapi
2. Open content table for "Recoverable Items" Folder.
3. Sort by "Item type" i.e. IPM.Appointment.
4. Copy all IPM.Appointment messages.
5. Paste it under "Top of information Store\CalendaR" with "Message Move" checked.
Results: User will see lot of duplicates along with original recovered data.
I am thinking if it has something to do with internal corruption within appointment which was caused due to Single item recoevry and was fixed in Exchange 2010 SP2 RU3?
I repro this, but I don't think it's a problem with MFCMAPI. If you can find a build of MFCMAPI where this works, please let me know.
Exchange 2010 does not allow you to manually rename default folders. As far as I can tell, this behavior has existed since RTM. To change the default folders, you can use the set-MailboxRegionalConfiguration command.
Rennie, MAPI_E_FAILONEPROVIDER is a generic error that comes up for a wide variety of reasons. You'll need to give your specific scenario in which you're getting the error for people to be able to help you.
Steve
In my (very quick) test, using the move flag causes nothing to happen. But if I copy/paste without the move flag, the items are restored as expected.
Hi Steve,
Thanks for your reply, and thanks for your amazing MFCMAPI program.
You probably don't remember me, but you helped me make my calendar-fetching program much more efficient two years ago - almost exactly two years ago.
The problem I had a couple days ago was related to a customer switching from running their own Exchange server to going over to Office 365. If you have a moment, could you please confirm or deny that establishing a MAPI connection to Office 365 requires that Outlook has saved a mailbox password as part of the mail profile?
Thanks.
I also have a suggestion for MFCMAPI. After dabbling with MAPI now and then for over five years or so, I just recently became aware of the GetLastError() function! Knowing about that would have saved me some time in some previous trouble-shooting situations. So my suggestion is that in MFCMAPI that you follow up on all error codes by also calling GetLastError() and displaying that information if it looks interesting.
Thanks again,
Rennie
From: sgriffin [email removed]
Sent: 17. august 2012 15:43
To: Rennie Petersen
Subject: Re: Openotherusers's mailbox returns MAPI_E_FAILONEPROVIDER [MFCMAPI:271884]
From: sgriffin
Rennie, MAPI_E_FAILONEPROVIDER is a generic error that comes up for a wide variety of reasons. You'll need to give your specific scenario in which you're getting the error for people to be able to help you.
Steve
I guess I can give it a shot next time I get chance to perform recovery in this fashion. I'll update as I get chance to.
I'm having the same issue. Were you able to figure it out?
In our case the solution was as follows:
“In case anyone runs into the issue that our company had, a registry key was set on the server blocking older Outlook clients access to the exchange server (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem) Disable MAPI Clients = -10.0.0. The EMSMDB32.dll file which is installed with the MAPI Client and Collaboration Data Objects 1.2.1 is at version 6.5.8244.0 which was blocked by the key. More info can be found here:
http://technet.microsoft.com/en-us/library/aa996848%28EXCHG.80%29.aspx”
From: molotov69 [email removed]
Sent: Thursday, August 23, 2012 6:19 PM
To: Thorne, Michael
Subject: Re: "MAPI_E_FAILONEPROVIDER == 0x8004011D" from OpenMsgStore with special exchange environment. [MFCMAPI:275489]
From: molotov69
I'm having the same issue. Were you able to figure it out?
our organization is on Exchange 2010 and i can connect using outlook 2007, just not programatically. do you think this still applies?
incorporating autodiscover functionality to configure a new profile would be a good sample ( or for use in IExchangeManageStore ). Do you want to mess with WinInet? :)
Lev
>Do you want to mess with WinInet? :)
Not really. :)