none
What all kind of code level upgrades need to be considered while preparing for exchange server 2016 migration? RRS feed

  • Question

  • Hello Friends,

    Firm is preparing to upgrade exchange server 2010 to 2016. I am analyzing possible impacted areas across all our project components. I believe there may be impact on EWS, and MAPI library usage in our projects with this migration.

    Can somebody please help me to understand all such impacts that we should look out for and consider upgrading such libraries etc?

    Thanks.


    sureshh...

    Friday, July 21, 2017 6:02 PM

Answers

  • Hello Friends,

    Firm is preparing to upgrade exchange server 2010 to 2016. I am analyzing possible impacted areas across all our project components. I believe there may be impact on EWS, and MAPI library usage in our projects with this migration.

    Can somebody please help me to understand all such impacts that we should look out for and consider upgrading such libraries etc?

    Thanks.


    sureshh...

    EWS applications should function fine going from Exchange 2010 to Exchange 2016; however, please be aware that Microsoft has made it clear they plan on going forward with the REST API and EWS will likely be deprecated in a future release of Exchange.
    • Marked as answer by sureshh Friday, August 4, 2017 9:43 PM
    Saturday, July 22, 2017 6:15 PM
  • Any application that uses MAPI may be impacted by connectivity differences eg "

    The MAPI/CDO library has been replaced by Exchange Web Services (EWS), Exchange ActiveSync (EAS), and Representational State Transfer (REST)* APIs. If an application uses the MAPI/CDO library, it needs to move to EWS, EAS, or the REST APIs to communicate with Exchange 2016." ref https://technet.microsoft.com/en-us/library/jj619283%28v=exchg.160%29.aspx . If your using MAPI via Outlook then it should be okay but even with your EWS apps which should work okay you need to test,test,test.

    Cheers
    Glen

    • Proposed as answer by Andy DavidMVP Friday, August 4, 2017 6:48 PM
    • Marked as answer by sureshh Friday, August 4, 2017 9:43 PM
    Sunday, July 23, 2017 10:26 PM
  • That is just Outlook Object Model OOM code, as it uses Outlook as the underlying MAPI provider you shouldn't have any problems with that code.  Its more when you upgrade Outlook itself eg somethings that run fine in Outlook 2010 may need to reworked in Outlook 2016 because of differences in the UI etc. This is regardless of the Exchange version so you can test your Outlook code just by updating the version of Office your using on one workstation and test that against the current Exchange server. The Standalone version of MAPI https://www.microsoft.com/en-au/download/details.aspx?id=39045 (which is what I'm referring to when I say CDO/MAPI) is a library that you can use to logon to a server without needing Outlook installed. If any code your running requires Outlook to be running then it will generally just be using the OOM. 
    • Marked as answer by sureshh Wednesday, August 9, 2017 1:27 PM
    Wednesday, August 9, 2017 12:23 AM

All replies

  • Hello Friends,

    Firm is preparing to upgrade exchange server 2010 to 2016. I am analyzing possible impacted areas across all our project components. I believe there may be impact on EWS, and MAPI library usage in our projects with this migration.

    Can somebody please help me to understand all such impacts that we should look out for and consider upgrading such libraries etc?

    Thanks.


    sureshh...

    EWS applications should function fine going from Exchange 2010 to Exchange 2016; however, please be aware that Microsoft has made it clear they plan on going forward with the REST API and EWS will likely be deprecated in a future release of Exchange.
    • Marked as answer by sureshh Friday, August 4, 2017 9:43 PM
    Saturday, July 22, 2017 6:15 PM
  • Any application that uses MAPI may be impacted by connectivity differences eg "

    The MAPI/CDO library has been replaced by Exchange Web Services (EWS), Exchange ActiveSync (EAS), and Representational State Transfer (REST)* APIs. If an application uses the MAPI/CDO library, it needs to move to EWS, EAS, or the REST APIs to communicate with Exchange 2016." ref https://technet.microsoft.com/en-us/library/jj619283%28v=exchg.160%29.aspx . If your using MAPI via Outlook then it should be okay but even with your EWS apps which should work okay you need to test,test,test.

    Cheers
    Glen

    • Proposed as answer by Andy DavidMVP Friday, August 4, 2017 6:48 PM
    • Marked as answer by sureshh Friday, August 4, 2017 9:43 PM
    Sunday, July 23, 2017 10:26 PM
  • Thanks Mr. Exchange. Good point. Do you have any example on how to use REST APIs instead of EWS ?

    sureshh...

    Friday, August 4, 2017 6:38 PM
  • Thanks Glen. Yes I went through this page before I posted this question here. I want to know some code level examples of CDO/MAPI usage that need to be replaced. Also would like to understand how to use REST API in place of EWS or CDO/MAPI. Can you please share some code examples here? Thanks.

    sureshh...

    Friday, August 4, 2017 6:42 PM
  • Hello James, Thanks for info. Sorry for not being clear in my question.

    I am in fact looking for information about possible code level issues in client side UI (outlook plugins) / background applications that interacts with exchange server in some way, that we need to bother about and how to tackle those.


    sureshh...

    Friday, August 4, 2017 6:49 PM
  • If you have built an application that use the CDO/Mapi library then it won't work on Exchange 2016 so you need to be more specific with your question. If you have third party applications that have Exchange integration then you need to check with each vendor to ensure what method they use to connect to Exchange eg you may find some use EWS but some may also be using CDO which won't work once you upgrade. If you have old com based Outlook addins they should work okay but even been different versions of Outlook there are differences in the OOM so you will need to test everything. If something doesn't work then I would suggest you ask a question around that and post the code your using and someone can tell you what you need to look at changing.

    >>Also would like to understand how to use REST API in place of EWS or CDO/MAPI. Can you please share some code examples here? Thanks.

    You need to be more specific a simple internet search will yield you plenty of these types of samples, I don't know what your trying to do so can't post anything that would be useful. Its not really about using one in place of the other eg if you have any applications that currently uses CDO you'll may need to rewrite it from scratch. If its EWS you don't need to change it (but you do need to test it), if your looking to build new applications then the REST API would be what you should look at first. If your migrating however I would suggest you focus on looking for things that will stop working first if its a complex environment there Is no way of avoiding building a matrix and testing each and everything thing. 

    Cheers
    Glen

    Sunday, August 6, 2017 11:57 PM
  • Thanks Glen, understood.

    I am unable to understand if our code has any MAPI/CDO use at all as I am new to this area. Does below mean we are using MAPI/CDO in our code? Please advise.

    Examples:

    Example 1:
    MAPIFolder inboxFolder = outlookNamespace.GetDefaultFolder(OlDefaultFolders.olFolderInbox);
    if (inboxFolder != null)
    {
    	string meetingRespFilter = @"@SQL=\"http://schemas.microsoft.com/mapi/proptag/0x001a001e\" LIKE '%IPM.Schedule.Meeting.Resp%'";
        var inBoxMeetingItems = inboxFolder.Items.Restrict(meetingRespFilter);
    }
    
    Example 2:
    address = (string)mailItem.PropertyAccessor.GetProperty("http://schemas.microsoft.com/mapi/proptag/0x5D01001E");	//mailItem is of type MailItem
    
    Example 3:
    var propValue = appointmentItem.PropertyAccessor.GetProperty("http://schemas.microsoft.com/mapi/id/{00062002-0000-0000-C000-000000000046}/8229000B");

    Thanks.


    sureshh...

    Tuesday, August 8, 2017 11:28 PM
  • That is just Outlook Object Model OOM code, as it uses Outlook as the underlying MAPI provider you shouldn't have any problems with that code.  Its more when you upgrade Outlook itself eg somethings that run fine in Outlook 2010 may need to reworked in Outlook 2016 because of differences in the UI etc. This is regardless of the Exchange version so you can test your Outlook code just by updating the version of Office your using on one workstation and test that against the current Exchange server. The Standalone version of MAPI https://www.microsoft.com/en-au/download/details.aspx?id=39045 (which is what I'm referring to when I say CDO/MAPI) is a library that you can use to logon to a server without needing Outlook installed. If any code your running requires Outlook to be running then it will generally just be using the OOM. 
    • Marked as answer by sureshh Wednesday, August 9, 2017 1:27 PM
    Wednesday, August 9, 2017 12:23 AM
  • Thanks again Glen. That's clear now. In that case, I would assume our application does not use CDO/MAPI library as it needs running Outlook all the time. However, any backend processes (which connects to Exchange) might have CDO/MAPI/EWS usage. I will check further on this while checking back end processes.



    sureshh...

    Wednesday, August 9, 2017 1:26 PM