Please forgive this MS Exchange integration 101 question ...
I'm working on a proposal that requires appointments to be inserted, updated and deleted in user's Outlook Calendars. The customer uses an on-prem MS Exchange solution. Sorry, I don't yet know the version but I suspect it's a reasonably late version considering they are a large trading bank.
The EWS Managed API 2.0 seems to meet the project requirements but now I'm reading that parts of that have recently been deprecated (although that seems to only apply to Exchange On-Line).
Is the EWS Managed API the recognized and modern way to integrate with on-prem MS Exchange or should we be considering some other technology. If there's something else we should be considering, could you point me to that please.
Thanks for all help and advice.
Peter,
EWS remains supported (and no current plans to retire it - for on-prem there is no alternative). The EWS Managed API is now open source (so not supported by Microsoft as such, but source code is available from Github: https://github.com/OfficeDev/ews-managed-api).
Related
We have a business requirement (more financial compliance requirement) to monitor our production instance for any updates/releases/changes. This is to meet audit obligations so that we can prove that all changes were performed only inside of established release processes ie. no one is making changes to the CRM instance outside of this.
To be clear we already have an established release management process, but the question is being asked if there was a way to monitor the CRM instance to prove that indeed no changes are being made outside of release management. We have a Dynamics 365 online instance. I've searched for something suitable but am not able to find anything so the question here is posed to get pointers / ideas on potential solutions to this problem or even pointers to where I could begin my research into potential solutions.
As a background, the CRM application has financial data and hence we have 'over the top' financial controls/legal obligations to meet and hence the requirement.
You can explore this Change Tracking Solution from MS Labs, basically to track all the Publish/Publish All from CRM org.
The Change Tracking solution helps in tracking down the details of changes on who updated an entity, JavaScript, assemblies and processes along with the time of update. This solution is built on Dynamics 365 and as well works on Dynamics CRM 2016 (Online/ On premises)
I never tried this, but this was from a team which I worked earlier in MS internally.
If this not fits you, you can implement a custom plugin on Publish and PublishAll messages yourself. Read more
I have implemented an application which accesses calendars in an Office 356 E3 tenant. I've used the client_credentials flow and obtained Admin Consent. So far everything seems to work as expected.
Now I have a customer how wants to use my application with an Exchange 2016 on-premise setup. Is there a way to use the same application in this setup as well? Or do I have to implement a new application using EWS?
The graph API is not available on on-prem Exchange, so yes, you have to replace the graph API code with EWS code.
Depending on your use case, it is probably possible to abstract it such that your application can use either one or the other.
We had a similar issue.
You can change from Office365 Api to the MsGraph Api which supports many of the same features as the Office365 Api does. Your on premise customer needs to put his Exchange servers into hybrit mode for this. MS explained the necessary steps here.
The only problem we had is that you cant subscribe onto on premise calendars.
Here is the MsGraph Api doc
https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
You can also consider switching from Office365 to MsGraph entirely as this should also work for you Office365 customers. As I understand it MS is gonna expand the MsGraph Api in the future giving us a single point of contact for interaction with the Office suite and authentication.
#Marc LaFleur pls correct me if I'm wrong on this
First of all, I have pretty much no experience with developing Exchange Web Services-based applications.
I am developing an application that uses EWS Managed API to connect to an Exchange server. I need to support multiple Exchange versions, as I can't know in advance what version the server I'll be connecting to is running.
I was reading this article: https://msdn.microsoft.com/en-us/library/office/dd633705(v=exchg.80).aspx, and in the Unsuccessful Versioning part, it's written:
The EWS Managed API will throw an exception if the example is run because the IsAssociated property on the EmailMessage object is not available in Exchange 2007 SP1.
My question is: is there a list of which properties are available (or unavailable) in each Exchange version?
You have to keep in mind that the EWS ExchangeVersion (schema version) is not the same as the Service Version, on which Exchange is running.
Microsoft says:
[...]applications designed against earlier versions of EWS will work, in most cases, with later versions of EWS, and applications that target later versions of EWS will work if the same functionality was included in an earlier version.
You can find further information about schema versioning and your requested feature set per schema version here: https://msdn.microsoft.com/en-us/library/office/dn741586(v=exchg.150).aspx
There is no list of properties that i know off probably the closest would be if you look at the EWS Managed API source https://github.com/OfficeDev/ews-managed-api/tree/154dbc66ac018d861c73ce489839cd9f58a1b0cd/ComplexProperties .
There are strongly typed properties which Microsoft have made available on the EWS objects and you can also access the underlying extended properties these strongly type properties refer to (or that no strongly type property exists). Just because a property isn't strongly typed in a certain version of EWS doesn't mean its not accessible its just you need to use another method more on that https://msdn.microsoft.com/en-us/library/office/dn467898(v=exchg.150).aspx
There is a list of which EWS operations are available in which versions https://msdn.microsoft.com/en-us/library/office/bb409286(v=exchg.150).aspx which is generally the more important. (Eg FAI Folder Associated Item traversals where first introduced in 2010 hence why isAvailble isn't in 2007).
My company is working on a project to develop a desktop and mobile email client that can connect to different mail servers with minimal configuration for users or server admins. We want to be able to support Exchange but I've realised after some research that there are a number of issues to think about. Our goal is to be able to connect to as many types of Exchange server as possible, so we need to choose a protocol, or protocols to implement that will allow that. It seems there are 3 different protocols in use - WebDAV for older 2000/2003/2007 servers, Exchange Web Services (EWS) for 2007/2010+ servers and ActiveSync which is supported by everything post 2003 (I think).
My question is, which do you think is the best approach for implementation?
-ActiveSync seems to have the most coverage but is the biggest pain to implement. Would a dual implementation of WebDAV + EWS provide the same coverage?
Also, if there are any Exchange Admins out there, which protocols tend to be enabled by default? If WebDAV/EWS are always turned off by default then maybe ActiveSync is the only option. It seems that as the iPhone and Android support ActiveSync it is most likely to be turned on, but what about the others?
Also, would be interesting to have statistics of what servers are currently in use - i.e. how many are still using 2003, have migrated to 2010 etc.
Would like to hear your opinions.
Cheers,
Kevin
If you are building an email client and targeting Exchange, I would recommend ActiveSync. The other protocols -- WebDAV and EWS -- were not intended for generic email clients. EWS, for example, does not support transactions or syncing, so if you have multiple clients you will have to deal with tons of race conditions on your own. WebDAV requires some funky limitations and is not always enabled. ActiveSync is relatively easy to write, it just requires getting a license from Microsoft, and it always works with Exchange.
If you just want to send and read email, however, don't overlook IMAP and POP3. You'll find the broadest support for those, even though are disabled in the newest installations.
About Versions:
2003 should be hard to find, as it is out of any Support.
A lot companies have skipped 2007 Version, so you should find a lot of 2010/2013 installations.
Although Exchange 2016 was released back in october, I assume, that there arent too much installations out there (2016 is more like a CU to 2013 :) )
I am investigating developing an app for Windows Phone 7 that requires access to email/calendar information from Exchange Server (read only).
The way I see it there are 2 options EWS or ActiveSync.
WP7 only supports Basic Authentication.
By default on Exchange server installations the EWS virtual directory has Basic Authentication disabled meaning a configuration change of Exchange Server to allow EWS to be used.
The ActiveSync protocol looks like it would take some time to get your head around and develop an implementation.
The questions are
1. How common is it for people to enable basic authentication for EWS? Is this something that most businesses are likely to not want to do?
How difficult is it to learn and use the ActiveSync protocol? Is it something that could be done in days, weeks or months?
1) To find out about the common configuration of EWS servers I'd spek to some sysadmins and ask them. Maybe try on https://serverfault.com/
1) How difficult something is to learn very much depends on the skills and experience of the person learning and the teaching resources available. This is a non-trivial protocol so I wouldn't expect learning it to take days. There will also be a licensing cost of implementing Excahange ActiveSync which I suspect would make it an expensive option.
Option 3: Create your own web service that acts as a proxy to EWS and does the authentication for you. Ugly and a bit painful, but if your app is architected well, once WP7 supports better authentication, switching to directly hit EWS should be pretty simple.
ActiveSync is painful and does not support everything that EWS supports. I would recommend going the EWS route if you have that option.
If your going to use ActiveSync, think again... it uses wbxml and you would need to create your own API for doing calls - this means crating tokenized blobs which must be 100% perfect and account for all aspects of whatever type of messaging items you are going against or will risk creating bad items or even poison ones. The devistation caused by bad EAS calls could well exceed your customer base... so, you need to be very careful. Also, while the specs are public, it needs an very expensive license. If you license, you would need to get a support contract with a specific schedule in order to get develper support. With a team of developers, it will likely take 3-5 or so years to do a full implementation client side and work out most of the bugs. So, as far as the skills in email development, you and your other developers would need to be pretty hard-core. There may be third party APIs which wrap EAS calls... however, you should be sure that they are licensed and that that the license would cover your development - so, you would need to research those on your own.
EWS has more features and is far, far easier to use and is what is suggested... further, there is no special licensing, etc.
Using a proxy web service+Exchange Managed APIs so that WP7 can go against Exchange without writting a ton of code:
http://www.telerik.com/products/windows-phone/getting-started/exchange-client.aspx
... can also use this approach to use NTLM.
Before considering EAS...
http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx