This is a question that we hear frequently since we have released Exchange 2007. And our answer has to be heard loud and clear: going forward Exchange Web Services should be the API of choice for...
Updated Jul 01, 2019
Version 2.0
Blog Post
One of my biggest beefs is this tendency for creating "new APIs" that don't cover everything that the existing APIs can do. Instead of choosing functions that you think will make EWS desirable, start by systematically covering off the functionality of APIs you want us to ditch (eg can we do 100% of the old CDOEX operations using PowerShell/EWS?). And work through them one API at a time. If you selectively prioritize and cover only a third each of WebDav, Exoledb, and cdoex then some developers may need to use all five and we'll be bracing for yet another "big new thing" API that makes it even worse. If EWS could do 100% of CDOEX operations then no one would have to straddle EWS and CDOEX. You could even consider implementing a new version of CDOEX that layers on EWS so legacy code could keep working without having to maintain CDOEX anymore.
BTW, ExchangeShell and the EMC philosophy of only providing GUIs for PowerShell/ExchangeShell capable operations is great. But the person who did the new OAB wizard didn't read the memo. The window for "Select OAB Virtual Directory" definitely does not use Get-OabVirtualDirectory. It becomes obvious if you bring down one of your CAS servers.
BTW, ExchangeShell and the EMC philosophy of only providing GUIs for PowerShell/ExchangeShell capable operations is great. But the person who did the new OAB wizard didn't read the memo. The window for "Select OAB Virtual Directory" definitely does not use Get-OabVirtualDirectory. It becomes obvious if you bring down one of your CAS servers.