Tag Archives: API Changes

Microsoft Graph Developer – Microsoft Search API’s schema change deprecation


If you’re using Microsoft Graph API’s Search API to search for information then this information is for you. Say using Search API in M365, in email messages, it return messages ranked by relevance, and render a dedicated search experience. The search applies to the body and attachments of messages in the signed-in user’s own mailbox.  Please note that the search API schema has changed in the beta version with some properties in a search request and response renamed or removed.

  • In the beta version, properties used in a search request and response have been renamed or removed. In most cases, the original properties are being deprecated and replaced by the current properties, as listed in the document.
  • What’s for Graph API developers? So moving forward, start updating any existing apps to use current property and type names, and to get current property names in the response.
  • Important date: For backward compatibility, the original properties and types are accessible and functional until December 31, 2020, after which they will be removed.

Makeover of Microsoft Graph’s Changelog


If you’re a Microsoft Graph API developer then you might be familiar with the Changelog.

It’s one of the best ways to keep on top of everything happening across Microsoft Graph API. Based on the feedback, Changelog is redesigned. So now, you will find the new, redesigned changelog on the Microsoft Graph Dev Center.

image

Now it comes with new functionalities like,

  • Filtering
  • Searching
  • RSS Feed
  • Automation

I love the re-design/makeover. Kudos Smile

M365: Deprecation of Discovery Service API and developer guidance


The Discovery Service API was used with earlier versions of Office service APIs for discovering Calendar, Contacts, Mail, MyFiles (for OneDrive and OneDrive for Business service endpoints), Notes (for OneNote), and RootSite (for SharePoint). The release of Microsoft Graph REST APIs allowed developers to integrate with Microsoft 365 services in a simplified way. Because there was no need for the Discovery Service API, the access to the API was limited to applications already using the API. Developers have since been migrating away from using the Discovery Service API to use the unified endpoint offered through Microsoft Graph REST APIs.

What will happen?

If you are still using the Discovery Service API to locate the service endpoint, please note that beginning November 1, 2019, API requests to the Office 365 Discovery Service endpoint api.office.com/discovery will no longer work.

What to do in such scenario?
If you are still using the Discovery Service API, please update your code to use the Microsoft Graph API, which allows integration with productivity services such as Calendar, Files, Mail, and so on. For more details, see the Microsoft Graph documentation.

Graph API : Subscription lifetime changes for Outlook resources


If your application uses user tokens to create subscriptions to Outlook resources, then you need to update your apps as needed to handle this scenario. This only applies to applications that use user tokens to create subscriptions. Applications that use app tokens to create subscriptions are not affected by this change. Existing applications do not need to do anything to enable this behavior.

We are in the process of deploying a change to the Outlook REST API and the Microsoft Graph that will expire subscriptions to Outlook-related resources (mail, calendar, contacts, tasks) automatically when one of the following events occurs:

  • The subscription is for an Intune-managed device that has been marked as non-compliant.
  • The password of the user that created the subscription has changed or been reset.
  • The account of the user that created the subscription has been disabled in Azure Active Directory.

So when the subscription is removed, the Outlook REST API will send a notification with changeType set to “SubscriptionRemoved” to signal that the subscription has been removed, and the application will stop receiving any notifications. The notification’s error value contains more information about why the subscription was removed. For more info, please refer the detailed blog post on this.

[Upcoming changes] Exchange Web Services API for Office 365


Exchange Web Services (EWS) was launched as a part of Microsoft Exchange 2007 as a SOAP based API that allows access to Exchange and Exchange Online data. Starting July 3, 2018, Exchange Web Services (EWS) will no longer receive feature updates. While the service will continue to receive security updates and certain non-security updates, product design and features will remain unchanged. This change also applies to the EWS SDKs for Java and .NET as well. While we are no longer actively investing in it, EWS is still available and supported for use in production environments.

As we make progress on this journey, we have continued to evaluate the role of Exchange Web Services (EWS). Also we are sharing our plans to move away from Basic Authentication access for EWS over the next two years, with support ending Oct. 13, 2020. These plans apply only to the cloud-based Office 365/Exchange Online products; there are no changes to EWS capabilities of on-premises Exchange products.

Here’s the related documents:

In this scenario, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality.

Hope this helps.

Support policy statement for Microsoft Graph


As new versions of the Microsoft Graph REST APIs and Microsoft Graph SDKs are released, earlier versions will be retired. Microsoft will declare a version as deprecated at least 24 months in advance of retiring an API or an SDK. So Microsoft Graph too follows the Microsoft Lifecycle Policy.

When we increment the major version of the API (for example, from v1.0 to v2.0), we are announcing that the current version (in this example, v1.0) is immediately deprecated and we will no longer support it 24 months after the announcement. When an API is marked as deprecated, we strongly recommend that you migrate to the latest version as soon as possible to avoid being affected.

For more info you can refer our support policy documentation on the same.

Hope this helps.

MAPI developers: MAPI/CDO library discontinued from Exchange 2016…


If you’re an Exchange MAPI developer/ISV/Vendor who relies on Exchange MAPI/CDO then this blog post is for you.

Do you know Exchange MAPI/CDO library is discontinued from Exchange 2016? Please refer @ “What is discontinued at Exchange Server 2016” which talks about the same (refer snapshot as well) and provides recommendation moving forward as well…

MAPI/CDO library discontinued from Exchange 2016

In addition, you can refer Dave’s blog post on this as well. Hope this helps.

MAPI Developer: API elements deprecated in Outlook 2013


Are you an MAPI developer? Then, this article is targetted for you. The API elements (like, IXPLogon::RegisterOptions, OPTIONDATA, OPTIONCALLBACK, IMAPISession::MessageOptions, IMAPISession::QueryDefaultMessageOpt, IAddrBook::RecipOptions, IAddrBook::QueryDefaultRecipOpt)  are deprecated in Microsoft Outlook 2013. They are no longer supported and you should not use them in new projects. These API elements are deprecated in this release because of obsolete message and recipient options. For more information, you can refer the related article.

Outlook 2010: Migrating CDO based application to Outlook Object Model(OOM) library


Recently one of my developer customer migrated from Outlook 2003 to 2010. He tried running the custom application (uses CDO & Outlook 2003) in Outlook 2010. It throws the error “ActiveX component can’t create object”. 

Using the following test sample, I can reproduce the exact issue at my end:

image

As you know, Microsoft Outlook 2010 includes many architectural changes to the client-side MAPI subsystem. Of particular concern are scenarios in which Outlook is configured to use multiple Exchange accounts. Also, CDO 1.2.1 is a 32-bit client library and will not operate with 64-bit Outlook 2010. Given all these factors, CDO 1.2.1 is not supported for use with Outlook 2010 and we don’t recommend its usage with Outlook 2010. As updated earlier, in Outlook 2010 you need to re-write/migrate the code base referencing CDO to Outlook Object Model or MAPI, messaging libraries which ever suits you.  So the programs/custom applications that use CDO should be re-designed to use other Application Programming Interfaces (APIs) instead of CDO.

Starting with Outlook 2007, the Outlook object model was greatly expanded to provide functionality that was previously available only by using CDO 1.2.1. The Outlook 2010 object model includes some new features to expand on this more. For example, the Outlook 2010 object model has new functionality to operate correctly with multiple Exchange accounts. The Outlook object model also works for both 32-bit and 64-bit versions of Outlook. Developers should use the Outlook 2010 object model instead of CDO 1.2.1. Also, developers can still use Extended MAPI (which requires unmanaged C++) in some scenarios where CDO was required. However, if it is possible, we generally recommend that the Outlook object model be used instead of Extended MAPI.

In this post, we will take the above code sample and will show how you can migrate/re-write the CDO based application to Outlook Object Model library.

CDO sample – created in Outlook 2003:

   1: Dim MapiSession As Object

   2: Dim MapiMessage As Object

   3: 

   4: 

   5:   

   6: Set MapiSession = CreateObject("Mapi.Session") ' Create the MAPI Session.

   7:  

   8: MapiSession.Logon , , , False                  ' Log on to the session.

   9:  

  10: Set MapiMessage = MapiSession.Outbox.Messages.Add

  11:  

  12: With MapiMessage

  13:     .To = "testuser@contoso.com"

  14:     .Subject = "Test"

  15:     .Text = "Test"

  16:     .send showdialog:=True

  17: End With

  18:  

  19: MapiSession.Logoff

  20:  

  21: Set MapiSession = Nothing  ' Clear the object variable.

  • In order to start with, we will do it from the declaration section – you can see the CDO/OOM migrated sample and notice the changes.
  • In CDO code, it’s specified as Set MapiSession = CreateObject(“Mapi.Session”). When it comes to Outlook Object Model, then it should be converted as, Set MapiSession = CreateObject("Outlook.Application")
  • Now, we will try the next line, which is doing logon() call. In CDO, it’s MapiSession.Logon , , ,False. In OOM, it’s you need to add GetNamespace, so MapiSession.GetNamespace("MAPI").Logon , , , False
  • Next line in CDO points that a new mail item will be created in Outbox folder. In OOM, it need to be simplified: MapiSession.CreateItem(olMailItem).
    • Please note I haven’t used outbox folder like, MapiSession.GetNamespace("MAPI").GetDefaultFolder(olFolderOutbox)
  • I don’t see much changes when you specify the values for MapiMessage, except for .Send (CDO) – just needs to be trimmed as .Send(in OOM)

Once you done with migration, the OOM code (created in Outlook 2010) will look like the below:

   1: Dim MapiSession As Outlook.Application

   2: Dim MapiMessage As Outlook.MailItem

   3:           

   4: Set MapiSession = CreateObject("Outlook.Application") ' Create the MAPI Session.

   5: MapiSession.GetNamespace("MAPI").Logon , , , False

   6:                            

   7: Set MapiMessage = MapiSession.CreateItem(olMailItem)

   8: With MapiMessage

   9:     .To = "testuser@contoso.com"

  10:     .Subject = "Test"

  11:     .Body = "Test"

  12:     .Send

  13: End With

  14:  

  15: Set MapiSession = Nothing

Please note: Microsoft product support can help developer customers migrate custom programs from using CDO 1.2.1 to using other APIs. However, Microsoft will not provide support for any scenarios in which CDO 1.2.1 is used with Outlook 2010.

Happy programming!!

An insight @ Internet Explorer 10 Platform Preview


IE10 – Platform Preview? IE10 Platform Preview is released periodically to give web developers, designers, and enthusiasts an advanced look at what’s to come in the next major release of Internet Explorer.

Want to try IE 10 Platform Preview? If you want to download and try Internet Explorer Platform Preview, then I would suggest you to give a try @ the Internet Explorer Test Drive site. Please note that it is not intended to be your daily browser, and in fact will not replace the version of Internet Explorer you have installed on your computer. The binaries that ship in the Platform Preview Build package do not replace system binaries; instead, they are placed in an iepreview.exe.local folder under the Internet Explorer Platform Preview path.

image

IE 10 – Platform preview for Developers guide: This guide provides an early look at the developer features coming to the next version of Internet Explorer. By using the documentation and samples in this guide, web developers and designers can prepare to use these new features.With this, you can obtain detailed technical information about developer features before this information is published to the Internet Explorer Developer Center and to the MSDN Library. In addition to reading the guide, be sure to see the Release Notes for installation information and known issues, as well as the Internet Explorer Test Drive site for new demos and examples.

  • IE 10 Platform Preview: CSS: Internet Explorer Platform Preview adds support for several new Cascading Style Sheets (CSS) features. This trend began with Internet Explorer 8 (full compliance with the CSS2.1 standard) and continued with Internet Explorer 9 (support for CSS rounded corners, multiple background images, new color models and opacity, CSS3 Fonts and WOFF, 2D Transforms, Media Queries, CSS3 Namespaces, and more). For more info, please visit@ http://msdn.microsoft.com/en-us/ie/hh272902.aspx
  • IE 10 Platform Preview: DOM: Internet Explorer Platform Preview contains several new features related to styling in the Document Object Model (DOM). Specifically, support has been added for several components of the CSS Object Model (CSSOM), which is currently a W3C Editor’s Draft. For more info, please visit @ http://msdn.microsoft.com/en-us/ie/hh272903.aspx
  • IE 10 Platform Preview: ECMAScript 5: Internet Explorer Platform Preview introduces support for ECMAScript 5 (ES5) strict mode, as specified in the ECMAScript Language Specification, 5th edition. Strict mode is intended to improve error checking and to identify script that might not be resilient to future versions of JavaScript. ES5 strict mode is a more restrictive variant of JavaScript that has different semantics and stricter parsing from what is considered normal JavaScript. For more info, please visit http://msdn.microsoft.com/en-us/ie/hh272904.aspx
  • IE 10 Platform Preview: HTML5: As you know support for several features defined in the HTML5 Working Draft specification began with Internet Explorer 8 and was extended in Internet Explorer 9. IE10 Platform Preview supports even more of this emerging standard with support for the new features like Asynchronous Script Execution, Drag and drop, File API, Forms validation etc. For more info, please visit http://msdn.microsoft.com/en-us/ie/hh272905.aspx
  • IE 10 Platform Preview: Web Performance: IE 10 adds support for web performance as defined in the W3C Web Performance Working Group specification. Three new web platform features are now available in IE10 Platform Preview: The requestAnimationFrame method, Page Visibility API , setImmediate method. These three platform APIs enable developers to make browsers use computer hardware more efficiently, improving both performance and power management of websites. These new API’s have been designed in collaboration with other browser manufactures through the W3C Web Performance Working Group. The next version of Internet Explorer is anticipated to be the first browser to implement all three APIs. For more info, please visit http://msdn.microsoft.com/en-us/ie/hh272906.aspx

If you need further information, you can look on the following resources: Download | User Guide | Release Notes | Developer Guide | Blog.

VS 2010: Increase IntelliSense performance using Windows Automation API


The Windows Automation API library enables accessibility tools, test automations, and pen services to access a standard user interface across operating system versions.

Do you know applications that use Windows Automation APIs can significantly decrease Microsoft Visual Studio IntelliSense performance if Windows Automation API 3.0 is not installed? For example, the Windows pen and touch services can significantly decrease Visual Studio IntelliSense performance if Windows Automation API 3.0 is not installed.

You can download the update from http://support.microsoft.com/kb/981741. This update is available as a stand-alone download for 32-bit editions of Windows XP and for Windows Server 2003. This update is not available for 64-bit editions of Windows XP. The Windows Automation API is a component of the platform update for Windows Vista and of the platform update for Windows Server 2008.