Bug 741842 - MAPI error MAPI_E_CALL_FAILED (0x80004005)
Summary: MAPI error MAPI_E_CALL_FAILED (0x80004005)
Keywords:
Status: CLOSED DUPLICATE of bug 827371
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution-mapi
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-28 05:58 UTC by Gianluca Cecchi
Modified: 2012-06-27 12:54 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-06-27 12:54:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Gianluca Cecchi 2011-09-28 05:58:35 UTC
Description of problem:
evolution fails to connect to exchange 2007 server

Version-Release number of selected component (if applicable):
evolution-mapi-3.0.3-2.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1. open evolution with a mapi connection configured to exchange 2007
2. wait for inbox sync
3. 
  
Actual results:
red box at top with the message
Error while Refreshing folder 'Mailbox - Cecchi Gianluca/Posta in arrivo'.
Fetching items failed: OpenMessage: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred

Expected results:
Inbox in sync with server

Additional info:

It was ok with 
evolution-mapi-3.0.2-2.fc15.x86_64

it seems the problem arose with update:
evolution-mapi-3.0.3-2.fc15.x86_64

Comment 1 Gianluca Cecchi 2011-09-28 09:14:02 UTC
Searching around for bugs I found these ones

https://bugzilla.redhat.com/show_bug.cgi?id=722880
https://bugzilla.redhat.com/show_bug.cgi?id=558651

In my case evolution stopped working correctly after latest updates (investigating if any actions at server level too... not under my control):

Sep 16 09:21:17 Updated: openchange-0.9-18.fc15.2.x86_64
Sep 16 09:22:05 Updated: evolution-mapi-3.0.3-2.fc15.x86_64

At this moment it doesn't connect anymore at start giving the error:
fedora MAPI error MAPI_E_CALL_FAILED (0x80004005)

So I tried the offline/online option, even if initial connection with sync didn't complete at all and I had not much hope... but it seems to work....

Running evolution from terminal, not at the beginning but at a certain point (probably during the offline/wait 30 seconds/online phase) I get this:

(evolution:6970): camel-CRITICAL **: camel_data_wrapper_get_mime_type_field: assertion `CAMEL_IS_DATA_WRAPPER (data_wrapper)' failed

(evolution:6970): camel-WARNING **: No content for medium, nothing to write

Let me know if you need more information to debug/solve

Comment 2 Milan Crha 2011-09-29 11:21:49 UTC
Thanks for a bug report. Is the error shown always with OpenMessage call? It may worth it to try to downgrade evolution-mapi, whether update of this package really caused this issue.

Comment 3 Gianluca Cecchi 2011-09-29 12:58:30 UTC
Actually after the offline/sleep 30 seconds/online actions I was able to get the connection again.
And after closing and reopening evolution itself, it continues to connect normally.
So it seems that the offline/online cleans up something "broken" at connection level...

From Exchange admin guy I received confirmation that during these days, due to maintenance operations, he had to switch the Exchange service from one node of the cluster to the other one and back several times...
This could be related in some way...

And I confirm that this morning (probably another switch, not verified yet):
- I open evolution and get e-mails correctly for about one hour
- I get the error trying to access an unread message
- further attempts of opening unread messages or send/receive e-mails get the error too
- an offline/sleep some seconds/online operation (using the icon at bottom left of the evolution window) solves the problem and I can read the unread messages and get new messages ...

HIH debugging
Gianluca

Comment 4 Milan Crha 2011-09-30 09:02:14 UTC
Thanks for the update. The change on the connection forced by server makes sense here. Evolution-mapi doesn't auto-reconnect in such cases, especially if the error message is so vague (the code MAPI_E_CALL_FAILED returned from OpenChange's libmapi can happen in various circumstances, thus evolution-mapi cannot think that this code means broken connection and that it should reconnect).

I would close this as upstream, in favour of bug [1], which is pretty close to your issue, I would say. You've a workaround to go offline/online at least for now. Are you fine with it, please?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=608327

Comment 5 Gianluca Cecchi 2011-09-30 09:41:15 UTC
In my case actually the Exchange IP remains the same, because it is a Virtual IP carried on by the cluster services at Exchange Server side  and it moves with the service itself.
Probably there is  short time when the ip is not reachable during failover and evolution doesn't try to reconnect ? Or perhaps it registers some other info othere than the ip, that doesn't match when there is a cluster node failover?

Comment 6 Milan Crha 2011-09-30 14:12:34 UTC
Maybe. This all is not recognizable in evolution-mapi directly, because it's using openchange's libmapi, which is tight to samba4. So how does that transfer the server address into connection through the cluster I do not know, unfortunately.

Comment 7 smfaall 2012-06-26 08:07:50 UTC
Reported error:ModifyRecipients : Erreur MAPI MAPI_E_CALL_FAILED (0x80004005)".

I get this error message when I trying to send email to multiples adresses and after upgrading fc16 to fc17. There is any problem for sending email to only one recipient.

evolution-mapi-3.4.3-1.fc17.x86_64
evolution-3.4.3-1.fc17.x86_64
evolution-NetworkManager-3.4.3-1.fc17.x86_64
evolution-devel-3.4.3-1.fc17.x86_64
evolution-data-server-devel-3.4.3-1.fc17.x86_64
evolution-help-3.4.3-1.fc17.noarch
evolution-data-server-3.4.3-1.fc17.x86_64

Comment 8 Victor da Costa 2012-06-26 20:31:07 UTC
I'm on the same situation reported by smfaall

Comment 9 Milan Crha 2012-06-27 12:54:48 UTC
Thanks for a ping here. This is supposed to be fixed within bug #827371, namely by update mentioned in bug #827371 comment #16. I'm marking this as a duplicate of the other bug.

*** This bug has been marked as a duplicate of bug 827371 ***


Note You need to log in before you can comment on or make changes to this bug.