In Exchange 12 (“E12”), we have focused our public API story on:
Web Services for accessing information stored on the server
Managed Agents for processing mail flowing through the serve...
Updated Jul 01, 2019
Version 2.0
Blog Post
First I'd just like to say thanks for this site, it's really helpful and it's nice to be able to communicate with you guys.
I work for a software house who have specialised in Outlook/Exchange solutions, so naturally we're very worried about the directions Exchange is taking.
Our solutions are often based on public folders, so of course we're very upset about the loss of those.
What we've struggled with is the constant introduction of new 'strategic' directions and new APIs only to find that they then get replaced or become 'legacy'.
What we're crying out for here is one API that lets us get to all of the features of Exchange, ideally from any box (client as well as server), is simple to program and performs well. A .Net based class library would be great.
There's so many unsatisfactory ways to access Exchange/Outlook its ridiculous.
We've tended to stick with CDO 1.21 as that's remained constant (perhaps a little too constant), is accessible from the server and the client and performs. Additionally we use OOM on the clients (swapping to CDO to get any decent performance and access things we can't in the OOM). We also use sink events (although we don't like them much).
The loss of public folders makes a lot of it academic to us as we will probably have to migrate out of Exchange altogether.
I broadly welcome the web services,
I just hope that they and new 'stated direction' is are to stay and won't go the same way as all of the others.
Any news on what's going to replace public folders and how we're going to migrate ?
Personally I'd like to have seen the direction as:
1) Migrate the database to SQL server.
2) Replace MAPI with an up to date API accessible from .Net.
3) Keep and improve public folders and forms.
4) Migrate the forms engine to Winforms.
5) Migrate the VB script in Outlook forms to the new .net 'scripting' engine.
6) Web services for access where the other API is not available.
7) An improved workflow/eventing model on the Exchange box.
A shame it's not going to happen ....
I work for a software house who have specialised in Outlook/Exchange solutions, so naturally we're very worried about the directions Exchange is taking.
Our solutions are often based on public folders, so of course we're very upset about the loss of those.
What we've struggled with is the constant introduction of new 'strategic' directions and new APIs only to find that they then get replaced or become 'legacy'.
What we're crying out for here is one API that lets us get to all of the features of Exchange, ideally from any box (client as well as server), is simple to program and performs well. A .Net based class library would be great.
There's so many unsatisfactory ways to access Exchange/Outlook its ridiculous.
We've tended to stick with CDO 1.21 as that's remained constant (perhaps a little too constant), is accessible from the server and the client and performs. Additionally we use OOM on the clients (swapping to CDO to get any decent performance and access things we can't in the OOM). We also use sink events (although we don't like them much).
The loss of public folders makes a lot of it academic to us as we will probably have to migrate out of Exchange altogether.
I broadly welcome the web services,
I just hope that they and new 'stated direction' is are to stay and won't go the same way as all of the others.
Any news on what's going to replace public folders and how we're going to migrate ?
Personally I'd like to have seen the direction as:
1) Migrate the database to SQL server.
2) Replace MAPI with an up to date API accessible from .Net.
3) Keep and improve public folders and forms.
4) Migrate the forms engine to Winforms.
5) Migrate the VB script in Outlook forms to the new .net 'scripting' engine.
6) Web services for access where the other API is not available.
7) An improved workflow/eventing model on the Exchange box.
A shame it's not going to happen ....