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.
In theory, it seems like this version of MAPI could allow a legacy app to connect to Office 365. Any reason why this might not work ?
Hypothetically speaking, should this MAPICDO package work with Office 365 ?
Second comment -- first one did no appear even after several hours.
Since MS Exchange Server comes only in 64-bit version, since MS Exchange Server 2007, are there any plans to release a 64-bit version of MAPICDO package, or to include a 64-bit versions of MAPI dlls?
Dan - your logic is flawed. The server is 64 bit, but clients do not need to be 64 bit. There are no plans nor need to release a 64 bit MAPICDO package.
upon "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...'
Any news upon this?
Because without creating profiles new MAPICDO isn't very usable... :-)
Understood - we're still working on it.
Hi Stephen, I have posted an update after your response from Mar 25 2013, 6:46 am, but I do not see it here;
My response was something along the lines:
I might have not made myself clear; I know that MAPICDO package is to be used by client applications, that do not need to be 64 bit, as the server.
However, on a resource intensive application, it makes sense to build a 64 bit client and overcome the limitations posed by the 32-bit architecture. Now, you've made it clear that, I would say unfortunately, there are no plans to ship 64-bit MAPICDO packages.
On the other side, MS Outlook 2010 (and possible subsequent versions), comes with 64 bit supporting MAPI dll, as far as I know.
Is it possible/supported to install such a version of MS Outlook on an Exchange Server (that has Client Access server role at least, but it could have all roles in a standalone deployment), and have a client application use that 64 bit MAPI coming with Outlook?
Stephen, thanks so far...
1. Is there maybe some info/support within new MFCMAPI?
2. upon what Vern already asked 3 weeks before (without any answer yet):
Is new MAPICDO-package able to work with Office 365 ?
3. Is new MAPICDO-package able to create Unicode-PSTs ?
This may be a bit off-topic but, with your experience in programming MAPI for Exchange Servers, what is the best solution (performance and stability wise) to develop an application to export data, at item level, from Exchange mailboxes?
I would really appreciate your answer.
Dan - for new development you should use Exchange Web Services (EWS).
1 - MFCMAPI can be used to create profiles for 2013, but you'll need details on the new props you have to set in the profile
2 - Don't know why it shouldn't work.
3 - No.
I still have one question, regarding your recommendation to use EWS for new development: I have read some posts where people were saying that applications using EWS were much slower that using MAPI. For applications dealing with large Exchange databases, where performance is crucial, can you comment on EWS vs MAPI please?
Thank you for all your info and help,
It is possible to write slow EWS applications, especially if you're not carefully optimizing your requests to only get the information you absolutely need, and to not request information you already have.
That response of yours is very political :-).
Of course you can write slow EWS applications, but so you can with MAPI; however, assuming a well written application is implemented with EWS, how would perform to extract, let's say, individual mailboxes, vs a well written application using MAPI?
Do we have any news about guidance for HOW to build profile for Ex2013?
We still waiting.
I look forward to reading about how to create RPC/HTTP enabled profiles for Exchange 2013.