Supercharge your workflow with real-time information from the Microsoft Learn MCP Server
Stay focused and on track by connecting your AI agents directly to trusted Microsoft documentation. With the shift toward more AI-powered workplaces, developers and IT teams are spending less time searching the web and more time relying on AI tools and agents for help. But AI is only as good as the knowledge it can access—and even the most advanced AI models are working with information that has knowledge cutoffs, meaning their resources can be months out of date. Outdated or incomplete information can lead to errors, inefficiencies, and compliance issues. That’s where a new standard is emerging: Model Context Protocol (MCP) Servers. They connect AI agents directly to trusted, real-time data sources, so answers are accurate, relevant, and up to date. With the Microsoft Learn MCP Server, your AI agents can tap directly into official Microsoft product knowledge, right inside your development environment or workflow. No browser hopping. No guesswork. Just faster, more accurate results with AI guidance that helps you streamline your workflow and grow your skills while solving real-world problems. What is the Microsoft Learn MCP Server? Think of the Microsoft Learn MCP Server as your direct line to official Microsoft documentation—delivered to your AI Agent, in real time, in context, without leaving the tools you already use. Whether you’re coding in Visual Studio Code, prompting GitHub Copilot, or building a custom AI assistant, the Learn MCP Server brings relevant guidance to your fingertips. There’s no need to create custom connectors or install extra components. The service uses lightweight, streamable HTTP, so it works seamlessly with almost any MCP-compatible tool. The Learn MCP Server provides multiple ways for AI agents to surface the right information: Focused excerpts: The server can search Microsoft content and return up to 10 chunks of high-quality information—each with a title, URL, and self-contained passage. Full technical documentation: When broader context is needed, the Learn MCP Server can fetch complete pages, giving agents richer, more contextual information than a chunk alone could provide. Together, these built-in tools are designed to quickly provide you with the information you need by giving AI agents the flexibility to retrieve information in the format that best fits the task at hand—whether that’s targeted excerpts or a complete page of documentation. Microsoft Learn MCP Server If you’re a developer, that means you’ll have real-time access to definitive Microsoft resources, delivered at the right level of detail to help you solve complex problems, write high-quality code, streamline workflows, and build smarter AI agents. If you’re a technology leader, you’ll be able to equip your teams with smarter tools that provide timely, reliable resources, opening up new ways to learn and work more efficiently and effectively. Unlock smarter agentic experiences with the Microsoft Learn MCP Server Here are a few ways you can start putting Learn MCP to work: Create help desk agents that resolve tickets in minutes. Picture a support agent tackling a tricky issue. Instead of digging through pages of search results, their AI assistant pulls exact, up-to-date documentation from Microsoft Learn right into the workflow. The result? Faster resolution times, reduced escalations, and higher customer satisfaction. Develop onboarding agents that feel like personal coaching. New hires often spend weeks finding their footing, but with AI-guided Microsoft Learn resources tailored to each role, they can quickly ramp up on the tools they'll use every day—like Microsoft 365, Azure, or Dynamics 365—and build skills and confidence faster. Build more secure apps with confidence. By connecting GitHub Copilot agent mode to the Microsoft Learn MCP Server, your AI assistant can access the latest secure development practices and requirements, helping you identify vulnerabilities in open-source packages, validate configurations, and flag risky dependencies before they reach production. We’re continuing to expand what’s possible with the Learn MCP Server, so your AI agents can do even more, with even greater accuracy. In the coming weeks, a new capability will enable agents to access precise, ready-to-use code samples that improve the reliability and quality of AI-generated development work. These enhancements will make it even easier for you to build intelligent, context-aware AI agents, backed by the most current Microsoft product knowledge to help teams maximize productivity, stay secure, and deliver more value. Try it for yourself MCP servers are rapidly gaining traction as the standard for connecting AI agents to high-value, trustworthy data sources—a critical capability as organizations race to adopt AI responsibly. Microsoft Learn is already helping developers and technology leaders put this standard into practice, both by helping learners gain the skills needed to build AI agents and by enhancing the way those agents deliver knowledge to people in the flow of work. By embedding official Microsoft product knowledge directly into your workflows, you can make better decisions, accelerate development cycles, streamline operations, and avoid the pitfalls of outdated information. It’s all part of Microsoft Learn’s commitment to helping people use AI more effectively and with confidence. Explore the Learn MCP Server: Follow the step by step documentation to get started. Watch the demo video to see the Learn MCP Server in action. Visit the GitHub repository for installation guidance and troubleshooting. Walk through setting up the Learn MCP Server in Visual Studio Code with Microsoft MVP Luke Murray.Want more control over Sent Items when using shared mailboxes?
Edit 6/15/2015: We are starting to make this feature available again in Office 365. Note that the new shared mailbox Sent Items behavior is disabled by default. If you want to enable it for your users, you can do so by using cmdlets mentioned below. Additionally, we are still on track to ship this to our on-premises customers in Exchange 2013 CU9, as mentioned before. Whether a mailbox is used by multiple users as a collaborative tool or a communication gateway to customers, retaining a record of emails sent from a shared mailbox remains an important business requirement. In Exchange 2010, there was a way to configure this behavior, but we did not have this feature starting with Exchange 2013. Our customers have told us that a shared mailbox should keep a copy of emails sent from the mailbox by all members of the mailbox in its own Sent Items folder. We have taken that feedback and decided to make some changes to how sent mails are handled for shared mailboxes. We are excited to announce that once this feature is enabled for you (see below), by default all shared mailboxes will retain a copy of emails sent from the mailbox. You will no longer have to figure out which mailbox member sent an email as the shared mailbox or on behalf of it. How does it work? Emails can be sent as the shared mailbox itself or on behalf of it by member(s) of the mailbox, assuming proper permissions have been granted. This feature is designed to retain a copy of an email sent from the shared mailbox in the Sent Items folder of the shared mailbox. The same behavior can be expected for emails sent on behalf of the shared mailbox, when configured to do so. A copy of the sent mail will also reside in the Sent Items folder of the member’s personal mailbox. Note: If the user has used the Outlook 2013 feature to change the folder that Sent Items are saved to, the messages will be copied to that folder instead of the user’s Sent Items folder. Users can reconfigure this by clicking the “Save Sent Items To” button on the Email Options tab. Administrators have control over this feature for either mails Sent As or Sent on Behalf of a shared mailbox. The table below summarizes where sent mails reside when members of a shared mailbox send mail from the shared mailbox. User Mailbox Shared Mailbox Sent Items Exchange 2010 Exchange 2010 Controlled through settings in KB2632409 Exchange 2010 Exchange 2013 (any version) Controlled through settings in KB2632409 Exchange 2013 CU9 (or newer) Office 365 Exchange 2010 The sent mail will be delivered to both the Inbox of the shared mailbox as an email attachment* and to the user mailbox' sent items Exchange 2013 CU9 (or newer) Office 365 Exchange 2013 CU9 (or newer) Office 365 The sent mail will be delivered to the Sent Items folder of shared mailbox and to the user mailbox' sent items *In a scenario where the user’s mailbox is on an Exchange 2013 CU9 server (or an Exchange 2013 without CU9 installed) and the shared mailbox is on an Exchange 2010 server, the shared mailbox will get an email message that looks like the following: This behavior will continue until the shared mailbox is moved to an Exchange 2013 CU9 server. Because this can happen even between Exchange 2013 servers (pre-CU9 and CU9), you might want to wait in turning the feature on for your on-premises deployment until you have completely rolled out Exchange 2013 CU9 to all of your servers. Who can use this feature? The feature is going to be available to all customers with shared mailboxes in Office 365 (phased rollout starting on 6/15/2015), as well as our on-premises customers (starting with Exchange 2013 CU9). Note: if after installation of Exchange 2013 CU9 in an on-premises environment you do not see the new CMDlet parameters, you should run /preparead explicitly with CU9 setup. How do I enable/disable this feature? In Office 365 and Exchange 2013 CU9, this feature is disabled by default. Enable the feature In Office 365, using the Admin portal, you can select your shared mailbox by going to Groups > Shared mailboxes first: Then Edit the Sent items copy status of the mailbox: Using PowerShell, for emails Sent As the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $True For emails Sent On Behalf of the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $True Disable the feature For messages Sent As the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $False For emails Sent On Behalf of the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $False What else do I need to know? The administrator for your organization has to create the shared mailbox and add you to it as an user, before you can use it. If you are an Office 365 Small Business administrator, see Create and use shared mailboxes. If you are an administrator for a different version of Office 365 or an on-premises Exchange administrator, see the TechNet article Create a Shared Mailbox. If you are currently using a client registry key to duplicate messages sent from a shared mailbox to a sent items folder of the sender, you should remember to remove client registry keys if you enable this feature server side. If you do not remove client registry keys, you could see duplicate messages in Sent Items folders (one created by client registry keys and one by the server). If one of the transport rules prevents messages larger than certain size and the message being sent is over that size, then the message will not be delivered to the its original recipient and will also not be copied to the sent items of the shared mailbox. Philip LohExchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It
Update: please see our official documentation which is now available on this subject: Exchange Server TLS configuration best practices. Overview In part 2 of our Exchange Server TLS Guidance series we focus on enabling and confirming TLS 1.2 can be used by your Exchange Servers for incoming and outgoing connections, as well as identifying any incoming connection which is not utilizing TLS 1.2. The ability to identify these incoming connections will vary by Windows Server OS version and other factors. Part 2 will not cover disabling TLS 1.0 or TLS 1.1, nor disabling older cipher suites from being used. Part 3 of the TLS guidance series will go into detail on those topics. Assumption For Part 2 of our TLS guidance series we assume you have already audited your on-premises Exchange Servers and applied all updates called out in Part 1: Getting Ready for TLS 1.2. Please perform the activities called out in part 1 if you have not prior to moving forward with any configurations outlined in part 2. Enabling TLS 1.2 The method used to enable TLS 1.2 varies by the version of the Windows Server operating system. Some versions of Windows Server have TLS 1.2 enabled by default while others do not. Our steps will, regardless of the OS’ default state, configure TLS 1.2 so it is enabled and available for incoming (Server) connections and outgoing (Client) connections. From part 1 you should be familiar with the various components Exchange Server relies on such as Schannel, WinHTTP and .NET. Unless stated otherwise the same registry paths are used across all supported Windows Server operating systems. Enable TLS 1.2 for Schannel All Windows Server versions TLS protocols are enabled or disabled in Windows Schannel by editing the Windows Registry. Each protocol version can be enabled or disabled independently. You don't need to enable or disable one protocol version to enable or disable another protocol version. The Enabled DWORD registry value defines whether the protocol version can be used. If the value is set to 0, the protocol version cannot be used, even if it is enabled by default or if the application explicitly requests that protocol version. If the value is set to 1, the protocol version can be used if enabled by default or if the application explicitly requests that protocol version. If the value is not defined, the operating system’s default value will be used. We recommend configuring the value to have a consistent state across your servers. The DisabledByDefault DWORD registry value defines whether the protocol version is used by default. This setting only applies when the application doesn't explicitly request the protocol versions to be used. If the value is set to 0, the protocol version will be available for use by default. If the value is set to 1, the protocol version will not be available for use by default. If the value is not defined, the operating system’s default value will be used. We recommend configuring the value to have a consistent state across your servers. For example; consider what would happen if TLS 1.2’s values were set to a combination of Enabled and DisabledByDefault both set to a value of 1. In this example an application could only use TLS 1.2 if the application specifically called for TLS 1.2. If the application did not specifically call for TLS 1.2, then it would not be able to use TLS 1.2 as even though the protocol is enabled, it is not in the default list of available protocols. To enable TLS 1.2 for both server (inbound) and client (outbound) connections on an Exchange Server please perform the following. From Notepad.exe, create a text file named TLS12-Enable.reg. Copy and paste the following text into the file. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Save TLS12-Enable.reg. Double-click the TLS12-Enable.reg file. Click Yes to update your Windows Registry with these changes. Restart the machine for the changes to take effect. Enable TLS 1.2 for .NET 3.5 This step is only required for Exchange Server 2010 installations where .NET 3.5 is relied upon. Exchange Server 2013 or later installations may skip this step unless you have additional applications on the server utilizing .NET 3.5 which must be able to use TLS 1.2. The SystemDefaultTlsVersions registry value defines which security protocol version defaults will be used by .NET Framework 3.5. If the value is set to 0, then .NET Framework 3.5 will default to using SSL 3.0 or TLS 1.0. If the value is set to 1, then .NET Framework 3.5 will inherit its defaults from the Windows Schannel DisabledByDefault registry values. If the value is undefined, it will behave as if the value is set to 0. By configuring .NET Framework 3.5 to inherit its values from Schannel we gain the ability to use TLS 1.2. From Notepad.exe, create a text file named NET35-UseSchannelDefaults.reg. Copy, and then paste the following text. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 Save the NET35-UseSchannelDefaults.reg file. Double-click the NET35-UseSchannelDefaults.reg file. Click Yes to update your Windows Registry with these changes. Restart your computer for the change to take effect. Enable TLS 1.2 for .NET 4.x This step is only required for Exchange Server 2013 or later installations where .NET 4.x is relied upon. The SystemDefaultTlsVersions registry value defines which security protocol version defaults will be used by .NET Framework 4.x. If the value is set to 1, then .NET Framework 4.x will inherit its defaults from the Windows Schannel DisabledByDefault registry values. If the value is undefined, it will behave as if the value is set to 0. By configuring .NET Framework 4.x to inherit its values from Schannel we gain the ability to use the latest versions of TLS supported by the OS, including TLS 1.2. From Notepad.exe, create a text file named NET4X-UseSchannelDefaults.reg. Copy, and then paste the following text. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 Save the NET4X-UseSchannelDefaults.reg file. Double-click the NET4X-UseSchannelDefaults.reg file. Click Yes to update your Windows Registry with these changes. Restart your computer for the change to take effect. Note: When configuring a system for TLS 1.2, you can make the Schannel and .NET registry keys at the same time and reboot the server once. Validating TLS 1.2 is in use and identifying older incoming connections. Once TLS 1.2 has been enabled it may be helpful to validate your work was successful and the system is able to negotiate TLS 1.2 for inbound (server) connections and outbound (client) connections. We will provide a few methods for validating this. HTTP Based Protocols Many protocols used in Exchange Server are HTTP based, and therefore traverse the IIS processes on the Exchange server. MAPI/HTTP, Outlook Anywhere, Exchange Web Services, Exchange ActiveSync, REST, OWA & EAC, Offline Address Book downloads, and Autodiscover are examples of HTTP based protocols used by Exchange Server. Windows Server 2016 and Windows Server 2012 R2 The IIS team has added capabilities to Windows Server 2016 and Windows Server 2012 R2 to log custom fields related to encryption protocol versions and ciphers. We recommend reviewing the following blog for documentation on how to enable these custom fields and begin parsing logs for information on incoming connections in your environment related to HTTP based protocols. https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/ Windows Server 2008 through 2012 Unfortunately, the IIS custom fields mentioned above do not exist for Windows Server 2008 SP2 through Windows Server 2012. You may have to rely on alternate methods to validate TLS 1.2 is in use on these versions of Windows Server for HTTP based protocols. Your load balancer or firewall logs may be able to provide this information. Please request guidance from your vendors to determine if their logs may provide this information. Message Headers (Exchange Server 2016 Only) Message header data in Exchange Server 2016 provides the protocol negotiated and used when the sending and receiving host exchanged a piece of mail. While this is a more manual method of checking how mail arrived it can be used for testing between specific systems in a pinch. Example when viewing message header data via Message Header Analyzer at https://testconnectivity.microsoft.com Note: There is one known exception to the message headers example. When a client sends a message by connecting to a server using authenticated SMTP (also known as the SMTP client submission protocol), the TLS version in the messages headers does not show the correct TLS version used by a customer’s client or device. Microsoft is investigating the possibility of adding this information in a future update. Mail Flow via SMTP Logging SMTP Logs in Exchange 2010 through Exchange 2016 will contain the encryption protocol and other encryption related information used during the exchange of email between two systems. When the server is the SMTP receiving system, the following strings exist in the log depending on the version of TLS used. TLS protocol SP_PROT_TLS1_0_SERVER TLS protocol SP_PROT_TLS1_1_SERVER TLS protocol SP_PROT_TLS1_2_SERVER When the server is the SMTP sending system, the following strings exist in the log depending on the version of TLS used. TLS protocol SP_PROT-TLS1_0_CLIENT TLS protocol SP_PROT-TLS1_1_CLIENT TLS protocol SP_PROT-TLS1_2_CLIENT Example entries from Exchange Server 2010 A server sending mail to another system using TLS 1.2: 2018-02-22T13:53:10.494Z,<CONNECTORNAME>,08D578EB9C3F6C39,28,10.0.0.240:15443,192.168.1.42:25,*,,"TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 384 bits" A server receiving mail from another system using TLS 1.2: 2018-02-22T13:50:37.681Z,SERVERNAME\CONNECTORNAME Internet,07C578BB0E912319,22,10.0.0.241:25,192.168.1.102:63767,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 256 bits" POP/IMAP No logging exists which will expose the encryption protocol version used for POP & IMAP clients. To capture this information, you may need to capture netmon logs from your server or inspect traffic as it flows through your load balancer or firewall where HTTPS bridging is taking place. Source IP Obfuscation and identifying clients using older TLS protocol versions. In many deployments by the time client connections reach the Exchange Server, the source IP of the incoming client connection has been replaced with the IP address of your load balancer or firewall. While you are still able to identify if TLS 1.2 is being used by these connections and validate your servers are operating properly, you may be unable to identify exactly what machine is responsible for the incoming client connection if it is still using older TLS protocol versions. In this scenario you may need to request guidance from the vendor of your load balancer of firewall to be able to parse the logs of those devices to find the true IP of the incoming connection, so you may ensure those machines are also properly updated and configured. Additional Considerations There are many more considerations beyond Exchange Server when making any changes to cryptography settings within an environment. Considerations such as (but not limited to): Do your Domain Controllers and Global Catalog servers support TLS 1.2? Do partner applications (such as, but not limited to, SharePoint, Lync, Skype, etc...) support TLS 1.2? Have you updated older Windows 7 desktops using Outlook to support TLS 1.2 over WinHTTP? Do your load balancers support TLS 1.2 being used? Do your desktop, mobile, and browser applications support TLS 1.2? Do devices such as multi-function printers support TLS 1.2? Do your third-party or custom in-house applications that integrate with Exchange Server or Office 356 support TLS 1.2? The point to take home here is while we can provide guidance for interacting with Office 365, Exchange Server, and other Microsoft products - we cannot guarantee everything in your environment will be unaffected. As such we strongly recommend any steps you take to transition to TLS 1.2 and away from older security protocols are first performed in labs which simulate your production environments before you slowly start rolling them out in production. Action Items Configure your Exchange Servers so they can use TLS 1.2 for incoming and outgoing connections using the steps provided and validate the protocol is actively being used. Start identifying incoming connections using older versions of TLS after TLS 1.2 has been enabled and make plans for those clients if you intend to disable older TLS protocol versions. Remember, a “client” in these terms could be another server device but when we see it as an incoming connection to an Exchange Server we consider the host initiating the connection to be operating in the role of a client. Deploy the latest releases for Exchange 2010, Exchange 2013, and Exchange 2016 released in March 2018. These releases are the first to support turning off TLS 1.0 and TLS 1.1. Guidance on how to do this will be made available in Part 3 of this blog post series. Review With proper execution, you will be able to enable the TLS 1.2 protocol on any Exchange Server running an Exchange Server Cumulative or Update Rollup released after September 1, 2017 installed on OS’es as far back as Windows Server 2008 SP2. With all your Exchange Servers able to use TLS 1.2 for incoming and outgoing connections you should be well prepared for the eventual sunsetting of older TLS protocols. Equally important is understanding what incoming connections in your environment are not utilizing TLS 1.2 now that it is available and building a plan for each of those systems if you intend to disable the older TLS protocols. Brian Day Senior Program Manager Office 365 Customer ExperienceUpcoming changes to Exchange Web Services (EWS) API for Office 365
Update: For latest information related to basic authentication in Exchange Online, please see Basic Authentication and Exchange Online – September 2022 Update. Over the last few years, we have been investing in services that help developers access information in Office 365 in a simple and intuitive way, specifically through Microsoft Graph. Microsoft Graph and the use of OAuth 2.0 provide increased security and seamless integration with other Microsoft cloud services and is rapidly expanding developer access to the rich data sets behind Microsoft applications. As we make progress on this journey, we have continued to evaluate the role of Exchange Web Services (EWS). Today 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. Exchange Web Services will not receive feature updates Starting today, 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 will still be available and supported for use in production environments. However, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality. For more information and details on how to make the transition, please refer to the following articles: Overview of Microsoft Graph Overview of Outlook mail API on Microsoft Graph While EWS and Graph have mostly overlapping functionality, there are some differences. If you rely on an EWS API that does not have a Graph counterpart, please let us know via UserVoice of features needed for your app scenarios. Basic Authentication for EWS will be decommissioned Exchange Web Services (EWS) was launched with support for Basic Authentication. Over time, we've introduced OAuth 2.0 for authentication and authorization, which is a more secure and reliable way than Basic Authentication to access data. Please refer to the following article for more information: Getting started with OAuth2 for Microsoft Graph Today, we are announcing that on October 13th, 2020 we will stop supporting and fully decommission the Basic Authentication for EWS to access Exchange Online. This means that new or existing apps will not be able to use Basic Authentication when connecting to Exchange using EWS. Next Steps The deprecation of these APIs follows our service deprecation policies. We understand changes like this may cause some inconvenience, but we are confident it will ensure more secure, reliable, and performant experiences for our customers. We're here to help if you need it. If you have questions, please let us know in Stack Overflow with the [MicrosoftGraph] tag. Thank you in advance for updating and opening your apps to a wider range of useful and intelligent features on Microsoft Graph. We are extremely excited about the growing opportunities that Microsoft Graph offers to our customers, and we remain fully committed to continue our journey to empower developers to access Office 365 data with the most modern features and tools. Frequently Asked Questions Q: Will my application stop working when you make this change? A: It might, yes, it depends on the app itself and how it was coded. If it’s using EWS, and if it’s using Basic authentication then yes, on October 13th 2020 it will fail to connect. However, if the app is using Modern Auth/OAuth, then no, it will keep working as it did before. Q: Why October 13th 2020? Why that date? A: Starting October 13, 2020, Office 365 ProPlus or Office perpetual in mainstream support will be required to connect to Office 365 services. This announcement is posted here Office 365 ProPlus Updates. This change requires that Office 2013/Office 2016 are also required to use Modern Auth. Please see this. Q: Our in-house team created an app for meeting room scheduling, how do we go about changing that over to Graph and OAuth2.0? A: Don’t forget you can keep using EWS if you want to, so then really, it’s just the question of authentication. To get a better understanding of how to use OAuth 2.0 take a look here. Q: How does this impact my On-Premises Exchange deployment? A: It does not. This change only affects Exchange Online. Q: We require Modern Authentication + Multi Factor Auth for all our Outlook users connecting to O365, how do apps work when I have that set as a requirement? A: Applications can be written so they are treated as ‘trusted applications’. That way they can bypass the MFA requirement, more details are here. Q: How do I know which of my apps use Basic authentication to EWS? A: If you only use Outlook to connect to Exchange Online then you don’t need to worry, as long as you are using Office 2019 or Office 2019 Pro Plus you’ll be fine come October 2020. However, if you also have integrated apps into your Office 365 tenant you’ll need to check with the application developers to verify how it authenticates to Exchange Online if you aren’t’ sure. We are investigating how we can share this information with tenant admins, but have nothing available at the time of writing this blog. Q: What features does EWS have that Graph can’t provide? A: Graph is constantly evolving and adding features and functionality to provide the richest set of experiences we can. To see the latest features we’ve added to Graph, go here Overview of Outlook mail API on Microsoft Graph Q: Will this affect my Exchange Hybrid configuration? Exchange On-Premises calls into Exchange Online using EWS doesn’t it? A: Yes, it does. But it doesn’t use Basic Authentication, it uses token-based authentication, and it’s described in this blog post. How Hybrid Authentication Really Works. The Exchange Team
