Exchange Team Blog

Announcing Support for Controlled Connections to Public Folders in Outlook

Up to now, Administrators did not have control over which users would see public folders in their Outlook clients. If public folders were created within the organization or if an Exchange Online organization is configured to access on-premises public folders, all clients would make a connection to and show the “Public folders” object in Outlook. From there, one could control access to individual public folders (controlled through folder permissions). However, it was difficult to have only some of Outlook clients connect to public folders.

We are now introducing the ability to show the public folder object in Outlook to only a set of users who might need them. To get started, this will be available for Outlook for Windows users only.

To do this, administrators can use two parameters:

  • PublicFolderClientAccess is an optional parameter on the user object. By default, its value is set to ‘false’. Setting this to ‘true’ on a specific user designates this user as one of users who will see public folders in Outlook.
  • PublicFolderShowClientControl parameter on the organization config. By default, the value of this parameter is also ‘false’ and once it is set to ‘true’, the controlled access of public folders is enabled.

Here is an example of how to use these parameters; to enable access to only the user “Administrator” and turn the feature on for the organization:

Set-CASMailbox “Administrator" -PublicFolderClientAccess $true
Set-OrganizationConfig -PublicFolderShowClientControl $true

Important note: setting the organization parameter to true without setting user attributes to true first will make it so no users will see the public folder object in Outlook for Windows. In other words – if you want to implement this, we suggest that you plan ahead and populate user attributes first (PublicFolderClientAccess on users that need access set to true) and then set the organization level parameter (PublicFolderShowClientControl set to true). That way, users who need to have access will not lose access unexpectedly.

Why would you want to do this?

Tenant admins will now have more flexibility over which users connect to public folders in Outlook. This will benefit very large organizations who might have issues with connection limits to public folders and will reduce the load to that infrastructure.

This will also be helpful to organizations during mergers and acquisitions if moving to EXO. Imagine one organization having existing public folders, but after the companies merge – without this feature all of the users would unnecessarily connect to the public folder hierarchy.

Note: This feature is not intended to be replacement for public folder permissions, it is merely providing means to have more control over which clients connect to the public folder tree.

A few more questions answered that you might be interested in:

Will this work for only Outlook on Windows?

At this time, yes. We are working to bring this to additional clients (like Outlook for Mac or Outlook on the web) in the future and will talk about this later.

What about on-premises servers?

We are considering support for on-premises in a future CUs and we will provide details at the later time.

Is there a specific version of Outlook that I need to see changed behavior?

No. The feature works by removing the public folder information from the Autodiscover response to Outlook for Windows clients. Therefore, if the user is not enabled for public folder access they will simply not connect to the public folder tree no matter the version of Outlook for Windows they use.

In case of any questions, please do reach out to us via the comments section below. We are updating official documentation to add those parameters.

Public folder team

Disabling Basic authentication in Exchange Online – Public Preview Now Available

Several months ago we added a feature to the Microsoft 365 Roadmap which generated a lot of interest. The feature was named Disable Basic Authentication in Exchange Online using Authentication Policies and as the roadmap items stated - it provided the capability for an Admin to define protocols which should allow Basic Authentication.

Why was that so interesting? Well as you probably know, Basic authentication in Exchange Online accepts a username and a password for client access requests and blocking Basic authentication can help protect your Exchange Online organization from brute force or password spray attacks. Lately there has been an increase in the occurrence of these types of attacks, and so we are accelerating our release of this feature as it helps prevent them.

If your organization has no legacy email clients or doesn’t want to allow legacy email clients, you can use these new authentication policies in Exchange Online to disable Basic authentication requests. This forces all client access requests to use modern authentication, which will stop these attacks from impacting your organization.

We are still working on some aspects of this feature, and we’ll highlight those for you here, but in response to the increase of attacks we are seeing, we want to make authentication policies available to you now, and are therefore rolling this out worldwide immediately.

There is already an excellent article describing how this feature works and we strongly suggest you read, understand and follow the article before enabling this feature.

There are three important caveats to this feature:

  • There is a lack of telemetry for tenant admins allowing them to report on which users are using Basic Auth (and with which protocol) and once a block is enabled, whether such traffic was blocked. In other words, we can’t really tell you how well the block is working.
  • A policy change can take up to 24 hours to take effect, unless the admin calls a cmdlet (such as Set-User) to ‘tickle’ each user. (Note that ‘tickling’ is a technical term, first used here). So the block might not kick in right away, and you might have to take some action if you want it to happen faster.
  • If a user’s identity has not been replicated to Azure AD/Exchange Online, they will not be blocked and so any request received by Exchange Online will be routed to the authoritative Security Token Service (STS) where it is likely to fail. This same behavior also means that any authentication requests for unknown users in a tenant (such as might happen during a password spray attack) will also be forwarded to the authoritative STS for the domain.

We had been holding back on moving from private to public preview primarily due the first two of these - a tenant admin could misconfigure something and not realize until it’s too late due to the lack of reporting and the delayed effect of policy change.

However, given the increasing frequency of these types of attacks we would rather give you access to the capability, knowing you will all carefully read the documentation before configuring. We’ll continue to work on improving the feature set, but you don’t need to wait for us.

We acknowledge that for large customers, tickling every user using Exchange Online PowerShell (which can be unreliable for long running scripts) is challenging, but again we feel the benefit outweighs the negatives at this stage.

It’s in all our interests to prevent these types of attacks from compromising our data and users, and we hope you find these tools useful and helpful. Use them wisely!

The Exchange Team

Released: October 2018 Quarterly Exchange Updates

The latest cumulative update for Exchange Server 2016 is now available on the download center. There is no release for Exchange Server 2013 or Exchange Server 2010 as these products are both in the extended support phase of lifecycle. The cumulative update released today includes fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Updated Pre-requisite requirements .NET Framework 4.7.2 Support

.NET Framework 4.7.2 is now supported with Exchange Server 2016 Cumulative Update 11. .NET Framework 4.7.2 will be required on Exchange Server 2016 with the Cumulative Update released in June, 2019.

We have validated .NET Framework 4.7.2 on the previously released Exchange Server 2013 Cumulative Update 21 and are announcing .NET Framework support with Exchange Server 2013 Cumulative Update 21 as well.

.NET Framework 4.7.2 will be required on the forthcoming Exchange Server 2019. Windows Server 2019, which is also required for Exchange Server 2019, installs .NET Framework 4.7.2 by default.

Changes to Visual C++ Version Dependencies

With today’s release we are updating the Visual C++ runtime version dependencies on Exchange Server 2016. Effective with Cumulative Update 11, all Exchange Server 2016 roles (Management Tools, Mailbox, Edge) will require installation of Visual C++ 2012 runtime. This is a change from Cumulative Update 10 where Visual C++ 2013 was incorrectly listed as being required on all roles. Visual C++ 2013 runtime, in addition to Visual C++ 2012, is required on the Mailbox role only.

Versions of Exchange setup before Cumulative Update 11 silently installed Visual C++ 2010 and 2012 components. Exchange setup has been changed in Cumulative Update 11 and later to enforce the Visual C++ runtime requirements using setup pre-requisite rules. When installing Cumulative Update 11 or later for the first time on an existing server, setup will detect the presence of the previously installed instances of Visual C++ placed there by Exchange setup and will not indicate that the Visual C++ 2012 runtime needs to be installed.

However, when setup performs the first upgrade of a server to Cumulative Update 11 or later, it will remove the versions of the Visual C++ binaries placed there by Exchange setup previously. This removal is necessary to change setup behavior, correct the condition which caused us to issue an advisory to install MS11-025 and ensure that future Visual C++ updates are applied by Windows Update and Microsoft Update.

Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 11 or later for the first time on an existing server. The setup pre-requisite rule works as expected when using Cumulative Update 11 or later to install a new server using the Cumulative Update 11 or later package.

Note: Exchange Server 2019, when released, will include the Visual C++ pre-requisite rules enforced by setup.

Release Details

KB articles that describe the fixes in each release are available as follows:

The updates released today do not include new updates to Active Directory Schema. If upgrading from an older Exchange version or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if the logged on user has the required permissions. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin must execute SETUP /PrepareSchema prior to the first Exchange Server installation or upgrade.

Cumulative Update 11 does require an Administrator to execute SETUP /PrepareAD to ensure RBAC roles are current before applying the cumulative update released today.

Adjustment to Cumulative Update Release Schedule

Due to the delay associated with Cumulative Update 11, there will not be a cumulative update released in December 2018. Our next planned set of quarterly updates will occur in March 2019 and will include Exchange Server 2016 Cumulative Update 12 and Exchange Server 2019 Cumulative Update 1.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 21, 2016 Cumulative Update 10 or 9.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team

MS11-025 required on Exchange Server versions released before October 2018

In the security advisories released on 10/09/2018, CVE-2010-3190 was updated to apply to Exchange Server. This bulletin now applies to all versions and cumulative updates for Exchange Server released prior to October 2018.

The Exchange team is aware that the installation program for Exchange Server is applying an unpatched version of a Visual Studio released binary which was updated in the package to address CVE-2010-3190.

The Exchange team encourages customers to apply the KB2565063 update described in MS11-025 to all Exchange servers.

This action is necessary to ensure servers are protected against the vulnerability outlined in the advisory.  Windows Update and Microsoft Update will not automatically apply this update to an Exchange Server.  The installation of a cumulative update released prior to October 2018 will overwrite the affected binary even if MS11-025 was previously applied to the server.  The advisory lists the MS11-025 update as important indicating there is low to medium risk associated with the vulnerability.  Microsoft is not aware of any instances where the exploit has been used against an Exchange Server.

Applying this update does not require a reboot of the server or stopping any Exchange services.

The Exchange team considers ensuring the security of your servers and data our top priority.  We have examined the Exchange installation process to identify any additional similar scenarios where dependent binaries are not being properly updated when Exchange is installed.  We have modified Exchange installation so that all cumulative updates released after September 2018 will no longer install dependent Visual Studio binaries.  We have added pre-requisite rules to ensure that the correct version of the Visual C++ and Microsoft Foundation Class (MFC) libraries are installed via their native redistribution package before Exchange installation will proceed.  The steps taken will ensure that the correct versions of system and shared binaries are installed and that Windows Update and Microsoft Update are able to detect the need for any future updates to these dependent binaries.

The Exchange Team

Announced: improvements to Hybrid Publishing and Organization Configuration Transfer

What just happened?

During a rousing presentation that was marked by wild cheers and standing ovations, we announced a few features designed to simplify hybrid Exchange deployments and speed onboarding to Exchange Online (EXO).

The features we discussed focused on two key problems, hybrid administration and configuration as customers prepare to move to the cloud and the complexities and security blockers some customers face when publishing their on-premises environments.

Let’s review.

Administration and Configuration

Back in June, we launched Organization Configuration Transfer (OCT). The idea is to take the configurations made in Exchange Server on-premises and transfer them to Exchange Online to reduce the burden of re-configuring all your settings before onboarding. Today we announced OCTv2, due out October 2018.

What does OCTv2 do?

First and foremost, seven additional objects have been added to OCT as part of v2.

OCT OCTv2 (coming soon!)
  • Active Sync Mailbox Policy
  • Mobile Device Mailbox Policy
  • OWA Mailbox Policy
  • Retention Policy
  • Retention Policy Tag
  • All OCTv1 objects
  • Active Sync Device Access Rule
  • Active Sync Organization Settings
  • Address List
  • DLP Policy
  • Malware Filter Policy
  • Organization Config
  • Policy Tip Config

But the real difference in v2 is how we deal with object conflicts.

In OCTv1, we run a bunch of new-* commands and when we find an object on-prem that matches and object with the same name in the cloud, we simple skip over it. As part of v2, if an object with the same name already exists both on-premises and online, you can now choose to either overwrite the values of the objects in EXO or keep them as is. And, just in case you overwrite the cloud settings and didn’t mean to, we’ve provided a rollback script to undo those changes.

What are the Exchange Server Versions supported?

OCT supports Exchange Server 2016, 2013 and 2010. OCT requires the latest cumulative update or update roll-up available for the version of Exchange you have installed in the on-premises organization. But if that’s really too much of a burden, the immediate previous release is also supported. You want to run any other CUs or RUs, you’re out of luck.

Exchange Server 2019 will be supported once it reaches GA.

Hybrid Publishing

To establish a hybrid Exchange environment, customers must publish their on-premises environments. This includes, but is not limited to, adding external DNS entries, updating certificates, and allowing inbound network connections through your firewall. Over time, we’ve learned of two consistent problems here, (1) this is hard for some customers. The number of support cases asking for help in these areas tells us that. And (2) some customers, really their security wonks, do not want to publish their on-premises environments to the internet.

The Microsoft Hybrid Agent

Today, we introduced the world to the Hybrid Agent. Put simply, the goal of the Hybrid Agent is to fix those customer problems. Now, when running the Hybrid Configuration Wizard (HCW) you are presented with the option to use Exchange Modern Hybrid

This will install an agent, built on the same technology as Azure Application Proxy, this will publish your Exchange on-premises environment to EXO without requiring any of the changes customers have struggled with.

V1 of the Hybrid Agent will support the core scenarios of mailbox moves and free/busy for your hybrid deployment and is in private preview now. We’re focused on getting to public preview and GA as quickly as possible. In the meantime, we’re also working on additional scenarios we can support with the Hybrid Agent.

What’s next?

Well, if you missed the session at Ignite, go back and watch the replay (when available). Then come back here and stay tuned for updates.

Kavya Chandra, Georgia Huggins

Get Ready for Microsoft Ignite 2018

Unless you’ve been living under an IT rock, you’ll know that Microsoft Ignite is happening soon. September 24th to 28th to be exact, in Orlando Florida.

If you didn’t buy a ticket already then I’m sorry to break to you that you are too late. It’s sold out! But it’s not all bad news; far from it. We have some great sessions planned and you’ll be able to watch them LIVE.

Yes, we’re streaming many sessions at the same time as they are delivered to the attendees live. Make sure you go back to the Microsoft Ignite 2018 site on the 24th and watch them there, or get links to breakout sessions.

The Session Catalog went live this week and you can use it to find the sessions you want to see right away. There are a few sessions I wanted to shout out to make sure you knew about them.

There are many more sessions, breakout and theaters. And many of the sessions are being delivered by the awesome MVP’s we have, but I can’t list them all here. So go take a look at the catalog and start figuring out what you want to go and see, or tune in to, LIVE.

For those of you actually in Orlando we have a special treat. We are sponsoring the Scheduled Maintenance party this year. If you have heard of that party (hosted by a Gold Partner - ENow Software) you’ll know it’s the hottest party of the week – and this year it’s being sponsored by Exchange and Outlook. So, if you want a chance to come and socialize with the engineering team, MVP’s and speakers, go and sign up. We know it will be over-subscribed and not everyone who wants to be there will be able to, but you can’t join if you don’t sign up and we would love to see as many of you there as we can.

See you in Orlando (or LIVE streaming)!

Greg Taylor
Director of Product Marketing
Exchange Server and Online

Deploy Exchange Server 2019 on Windows Server Core

Hurrah! If you have not yet heard: Exchange Server 2019 Public preview was announced earlier, and it is the first version of Exchange that you can install on Server Core!

Now, while that’s great news, if you haven’t worked on Server Core, there may be bit of a learning curve. The purpose of this post is to help you install the Exchange Server 2019 on Server Core in your lab.

We are going to assume that you have:

  1. Installed an Active Directory global catalog domain controller. Exchange Server 2019 will work with writable DCs running Windows 2012 R2 and above. Here’s a link to get you going with Active Directory, in case you have not installed it yet.
  2. Installed Windows Server 2019 (or Windows Server 2016) Server Core operating system.

(In case you need help with Server Core deployment, please follow this link).

Getting started

Once you have installed Server Core and booted it up, you may find yourself staring at this strange, unfamiliar login prompt:

From here on, this command line interface is your friend!

Once you’re logged in, you will get the basic Command prompt window. From here, you can use the start command to launch processes into a new window. For instance, if you type start powershell, PowerShell will be launched into a new window. You can also type start cmd to launch an additional instance of the command interpreter. You can use exit to close any process. Typing taskmgr will launch the graphical based TaskMgr application.

Example:

If you close all command prompt windows and want to open a new one, you can do that from the Task Manager. To launch Task Manager try the CTRL+ESC shortcut, or if you’re logged in via Remote Desktop you may need to use CTRL+ALT+DELETE, click Start Task Manager. Then, , click More Details > File > Run, and then type cmd.exe. (Or Powershell.exe to open a PowerShell command window.) Alternatively, you can sign out and then sign back in.

Prepare the OS for Exchange installation

The following are preliminary tasks you will need to perform to configure the OS for Exchange installation. You can use Sconfig to configure the IP Address, install Windows Updates, enable remote desktop and join the server to AD domain. Alternatively, you can use PowerShell commands to perform each of these tasks, which is useful for scripted installations as well.

Configure IP Address:

Use the Get-NetIPAddress PowerShell command and identify interface index you want to configure the static IP on. Mostly, this should be the one that has Interface Alias Ethernet and AIPA auto assigned DHCP Address.

Sample Get-NetIPAddress output:

Then use the following command to assign a static IP:

New-NetIPAddress -InterfaceIndex 6 -IPAddress 192.168.12.123 -PrefixLength 24 -DefaultGateway 192.168.12.100

If you are going to use a DHCP assigned IP Address, inspect the IP configuration provided.

Configure a DNS Server

Set-DNSClientServerAddress -InterfaceIndex 6 -ServerAddress "192.168.12.121"

Enable Remote Desktop:

cscript C:\Windows\System32\Scregedit.wsf /ar 0

Windows features

Use the following PowerShell command to install the OS component required for Microsoft UCMA 4.0 and the OS component required for Active Directory Preparation.

Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS

Download necessary software

From an admin workstation, download the following software and copy it over to the Server Core we are preparing for the Exchange installation (let’s say you copy the files into a C:\Software folder):

Then login to Server Core and do the following:

Install VC++ 2013 Redistributable

Install UCMA (Microsoft Unified Communications Managed API 4.0)

The UCMA installable is present on the Exchange Server 2019 media itself. Use the following PowerShell command to mount the Exchange Server media:

Mount-DiskImage c:\<FolderPath>\ExchangeServer2019-x64.iso

The UCMA installable is located under the “UCMARedist” folder on the Exchange Server 2019 .ISO. Start the UCMA installation:

.Net 4.7.1

Check the .Net version installed by following this link

If you are not on .Net version 4.7.1 already, use the following command to install the .Net 4.7.1 (not required on Windows Server 2019 Server Core):

C:\<FolderPath>\NDP471-KB4033342-x86-x64-AllOS-ENU.exe /q /log c:\temp\ndp.log

The .Net installation will continue in quiet mode, i.e. no progress bar will be displayed. At the end of successful installation, you will be asked to restart the computer. You can also take a look at the log file to check progress of the installation.

Start Notepad c:\temp\ndp.log

Do not reboot the server just yet; join the computer to an AD domain and then reboot it.

Joining the computer to AD domain

The following command will:

  • Rename the computer to E19Core1
  • Add the computer to domain corp.contoso.com

Add-Computer -DomainName corp.contoso.com -NewName E19Core1 -DomainCredential contoso\administrator

Restart the server

Use the following PowerShell command to restart the computer:

Restart-Computer -Force

Exchange installation

After rebooting the server mount the Exchange .ISO image again using Mount-DiskImage as you did before.

Use the following command to start Exchange Server installation. The PowerShell command will also install the required OS components for Exchange:

.\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

Notepad is available on Server Core, in case you want to open the Exchange Setup log just for review or to troubleshoot any exchange setup issues. Launch it as follows:

start notepad c:\ExchangeSetupLogs\ExchangeSetup.log

Once Exchange is installed, you can launch the Exchange Management Shell using LaunchEMS command from the command line.

Alternatively, you can also use web browser from an admin workstation to access Exchange Admin Center.

Summary

We hope this article will help you to get started with your Exchange Server 2019 deployment on Server Core and help you perform various Exchange admin tasks once you are done!

Here are some more links that you can use to learn more!

Getting started with Server Core

Use the following information to install, configure, and manage the Server Core installation option of Windows Server.

Server Core installation:

Using Server Core:

Bhalchandra Atre

Exchange Server 2019 Public Preview

Update 7/24: We have received some reports that some of started downloads result in files that cannot be opened after the download is completed. We are investigating the problem.

We’re pleased to announce a preview build of Exchange Server 2019 is now available. You can download it here.

We strongly believe Office 365 delivers the best and most cost-effective experience to our customers, but we understand that some customers have reasons to remain on-premises. Exchange Server 2019 is designed to deliver security, performance, and improved administration and management capabilities. These are the attributes our largest on-premises customers tell us they need from Exchange. We also have features end-users will love too of course.

Here are some of the key features in each of these areas:

Security: We’ve included support for installing Exchange Server 2019 onto Windows Server Core. Exchange Server 2019 installed on Windows Server 2019 Core provides the most secure platform for Exchange. You also have the option of installing the Exchange 2019 Preview onto Windows Server 2016 Core or Windows Server 2016/2019 with Desktop Experience, but we have worked hard to make sure running Exchange on Windows Server Core 2019 is the best choice for our code.

Performance: We’ve done work to allow Exchange Server to take advantage of the larger core and memory packed systems our customers buy these days. We’re confident you can be very successful running Exchange Server with up to 48 processor cores and 256GB of RAM.

We’ve re-engineered search using Bing technology to make it even faster and provide better results, and in doing so have made database failovers much faster, and administration easier.  The search indexes are now within the database itself. There are no more separate log files to manage. As the index data is now within the database, normal log shipping includes the database and search data in a single replication and the index is always up to date on all database copies.

At Ignite last year, we told you that Exchange Online had started using Solid State Drives. Yes, SSD’s. Many people were shocked at this.  For years we’ve been telling you to use cheap low-cost storage, and then we switched and started using SSD? What’s up with that Exchange team?

Well, that isn’t exactly what we said, what we said was we were using SSD’s in addition to cheap low-cost spinning disks. Why? Well we’ve pretty much reached the limits of what we can do with cheap storage, read latency in those disks hasn’t really improved yet storage capacity just keeps getting larger. It led us to conclude we needed to re-think our strategy. And we did, and the short version is that we store some of the data from those spinning disks on the SSD, and we use that super-fast device to store key search data, to make logins faster, and message retrieval faster. We still use low-cost storage for storing all of data but intelligently use SSD’s to make the overall user experience better.

We’re adding this tiered storage read/write capability to Exchange Server 2019 but it’s not enabled in the Preview build. We know you will all have lots of questions about this new feature and we will of course have planning and configuration guidance available when we ship, but we will be talking a lot more about these changes at Microsoft Ignite 2018. You are going, aren’t you? We are.

End user experience: One of the most important capabilities in Exchange is calendaring. All large enterprises are heavy calendar users and those organizations rely on calendars to help people get their work done. We’re bringing a few key features such as Do Not Forward and Simplified Calendar Sharing from Office 365 to On-Premises Exchange. We’re sure a lot of end users will be very happy with those features. Administrators get some new calendaring features too, as we’re adding the ability for admins to manage events on user’s calendars and to assign delegate permissions more easily.

One thing to note is that Unified Messaging role will not be available in Exchange Server 2019. Customers who currently connect either a 3rd party PBX or Skype for Business Server to Exchange Server won’t be able to do so with Exchange Server 2019 mailboxes. Those customers considering an upgrade to Exchange Server 2019 should consider migrating to Skype for Business Server 2019 and using Cloud Voicemail, or migrating to Office 365 with Cloud Voicemail. More information on this change will be available prior to launch.

That’s a brief roundup of many of the changes we have baked into Exchange Server 2019.

We plan on launching Exchange Server 2019 later this year, and we’re planning on talking about it a lot more at Microsoft Ignite.

Take a look at the Preview, and we really suggest you install it on Windows Server Core, and Windows Server 2019 Core if you have access to that. We will be publishing a blog post with tips for running Exchange on Server Core in a few days.

But please remember it’s not a production release, so please don’t install into production at all.

We look forward to your feedback, and in case we didn’t say it enough times, we’ll see you at Microsoft Ignite!

The Exchange Team.

Hybrid Configuration Wizard and licensing of your on-premises server used for hybrid

A few years ago, we created a web site that would allow our hybrid customers to obtain what’s generally known as the “hybrid key”. This self-service site would validate your O365 tenant and after a few clicks, give you the key to license your on-premises server used for hybrid purposes. This site is no longer available for use, and we’ve come up with a better way for you to get the key.

We are excited to inform you we are now working on a feature that will allow the Hybrid Configuration Wizard (HCW) to detect and license your designated on-premises “hybrid server”, without having to go to a separate web site or call our support team. We expect this change to be live in HCW by August 7th.

What will the new experience be?

When you choose the “Detect the optimal Exchange server” option, HCW will perform the license check on the server and give you a new “license this server now” option, if the server is currently not licensed. Note: HCW will not let you continue from this point on if this server is not licensed, unless you specify an alternate Exchange server to run Hybrid against (second radio button below):

Selecting the “license this server now” link will prompt you for your online administrator credentials. We realize this is an extra credential prompt at this time, but it is needed to validate and obtain the key (the old key distribution site also required authentication).

HCW will then indicate the progress of applying the server license to your on-premises server:

Next up, you will get a confirmation that the server has been licensed. You will also have an option to copy the product key (and the CMDlet needed to use it) if you wish to do so:

At this time, unless you want to complete the setup of Hybrid in the HCW, you can exit / cancel the wizard. Full completion of the HCW workflow is not needed for this process to be executed; your on-premises server will remain licensed, and you can re-run HCW at a later date / time.

Let us know what you think!

The Exchange Hybrid Team

Issue with July Updates for Windows on an Exchange Server

The Exchange team is aware of issues with the Windows Operating System updates published July 10th, 2018 causing Exchange to not function correctly. The Windows servicing team has advised us that they will be releasing updates to the affected packages. We encourage Exchange customers to delay applying the July 10th updates, including the security updates released on the same date, on to an Exchange server until the updated packages are available.

The Exchange Team

Upcoming changes to Exchange Web Services (EWS) API for Office 365

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: 

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 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