Exchange Team Blog

Released: Hybrid Organization Configuration Transfer V2

We are happy to announce Organization Configuration Transfer (OCT) - V2, which includes updates to OCT-Phase 1 that was launched earlier this year. OCT-V2 further reduces the manual work that admins are required to do once the hybrid setup is complete. OCT-V2 is now available as part of the Hybrid Configuration Wizard (HCW).

What does OCT-V2 include?

OCT-V2 not only copies the organization policy objects from on-premises to Exchange Online (EXO), but also updates the values in EXO with the values from on-premises. Seven additional objects have been added to OCT as part of V2. The list of objects considered in OCT so far are:

OCT (available since June 2018)
  • Active Sync Mailbox Policy
  • Mobile Device Mailbox Policy
  • OWA Mailbox Policy
  • Retention Policy
  • Retention Policy Tag
OCT-V2 (available now)
  • Active Sync Device Access Rule
  • Active Sync Organization Settings
  • Address List
  • DLP Policy
  • Malware Filter Policy
  • Organization Config
  • Policy Tip Config

If object values are updated on-premises after they are moved to EXO, admins can re-run OCT to copy over the updated values from on-premises to EXO. Admins will continue to control the process of keeping the objects in sync but with reduced effort by using OCT.

How is V2 different from the initial version of OCT that was launched in June 2018?

Phase 1 of OCT dealt only with copying objects from on-premises to EXO. However, it did not edit/update the parameters in EXO. As part of V2, if an object with the same name already exists in both on-premises and EXO, admins can now choose to either overwrite the values of the objects in EXO or keep them as is. A rollback script with values of the objects prior to the update in EXO will be available to admins in the log folder.

What are the Exchange Server Versions supported?

The supported versions are Exchange Server 2019, 2016, 2013 and 2010. OCT-V2 requires the latest cumulative update or update roll-up available for the version of Exchange you have installed in the on-premises organization. If you cannot install the latest cumulative update or update roll-up, the immediate previous release is also supported. Older cumulative updates or update roll-ups are not supported.

Kavya Chandra

Announcing support to migrate up to 250K public folders from Exchange On-Premises to Exchange Online

In an earlier post, we announced we were increasing the maximum number of public folders that could be migrated from Exchange Server 2010 to Exchange Online to 250K. We also highlighted in that post that the migration of public folders on Exchange Server 2013 and 2016 were limited to 100K.

We’ve been working hard to remove this limitation and we are very pleased to announce today that we now support migrating up to 250K public folders from Exchange On-Premises 2013/2016/2019 to Exchange Online.

What does all this mean to you?
  • Any Exchange On-Premises customer running Exchange 2010/2013/2016/2019 with up to 250K public folders can now migrate them directly to Exchange Online.

Please do check this link for planning migration of public folders to Exchange Online. The current Exchange Online limits can be viewed here.

We’ve love to hear your feedback and please feel free to ask any questions via the comments section below.

Public folder team

Microsoft Ignite 2018 – The Recap

Microsoft Ignite 2018 ended a few weeks ago, and what a great event it was. It was great to see so many of our customers, partners and friends there – thank you for coming to our sessions, thank you for coming to the booth, thank you for hanging out with us whenever the opportunity arose and thank you for giving us great feedback on what we’re doing. We’re still recovering but we heard you and are focused on doing a better job because of it.

All of the sessions were recorded this year, and so here’s a handy reference to all the sessions in the Exchange and Outlook track, and some others we think you’ll find interesting, so you can refer back here whenever you want to find one.

You will need an account in Tech Community to access them, but that’s something you should have anyway.

So here’s a long list of sessions, in no particular order but grouped by technology as much as possible.

Exchange Outlook Office 365 Podcasts/Broadcasts

It’s possible we missed a session you think we should have included (there were 750 or more after all), if so, add it to the comments section so people can find it. Thanks!

Happy watching!

And see you next year for more of the same. Microsoft Ignite 2019 here we come!

Greg Taylor
Director of Product Marketing
Exchange Server and Online

Exchange Server 2019 Now Available

We’re pleased to announce the final build of Exchange Server 2019 is now available and can be downloaded from the Volume Licensing Service Center.

Exchange Server 2019 is designed to deliver security, performance and improved administration and management capabilities; attributes our largest on-premises customers expect from Exchange.

If you haven’t yet seen the session delivered at Microsoft Ignite 2018 we suggest you watch the video and download the slides here. During that session we talked for the first time about how the code paths between on-premises and online have separated, and the impact to on-premises customers – in short, less code churn and more stability.

Here is a selection of other key features in Exchange Server 2019:

Security: Exchange Server 2019 requires Windows Server 2019. In fact, we recommend installing Exchange Server 2019 onto Windows Server 2019 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 Exchange 2019 onto Windows Server 2019 with Desktop Experience, but we have worked hard to make sure running Exchange on Server Core is the best choice for our code.

We’re aware all media for Windows Server 2019 and Windows Server, version 1809 has been temporarily removed and Microsoft will provide an update when refreshed media is available. Exchange Server 2019 will be fully compatible with version 1809, and the refreshed version.

We also built Exchange Server 2019 to only use TLS 1.2 out of the box, and to remove legacy ciphers and hashing algorithms. To understand how this affects coexistence with earlier versions, please reference our previous series of posts on TLS.

Performance: We’ve done significant work to allow Exchange Server to take advantage of larger core and memory packed systems available in market today. With our improvements, Exchange Server can use 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.

We’re adding dual storage read/write capabilities to Exchange Server 2019 using Solid State Drive (SSD) technology to provide a super-fast cache of key data for improving end user experience. We also talked about this in our Email Search in a Flash! Accelerating Exchange 2019 with SSDs session at Ignite.

We also changed the way database caching works to allocate more memory to active database copies, again improving the end user experience. You can learn more about Dynamic Database Cache from Welcome to Exchange Server 2019! video and slides.

The improvements we have made to Exchange Server 2019 will enable you to scale to a larger number of users per server than ever before, use much larger disks, and see the latency of many client operations being cut in half.

End user experience: We all rely on Exchange for calendaring, and we know large enterprises are heavy calendar users. We are bringing a few key features such as restricting the forwarding of meeting requests and better control over OOF settings to Exchange Server 2019. Administrators get some new calendaring features too, as we’re adding the ability to manage events on user’s calendars and assign delegate permissions more easily.

We are also adding support for routing mail to and from EAI/IDN recipients and hope to add additional capabilities in this area in the future.

The session recording also goes into some of the other features we have plans for, so make sure you watch it to the very end.

As we mentioned in the Preview post in July, the 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.

Our official product documentation is now live, and we’ll be publishing the updated Preferred Architecture documentation soon.

We’re also pleased to also announce there are even more Office Server products releasing today! You can read more about those releases here.

We look forward to your feedback and thank you for your continued support and love of Exchange.

The Exchange Team

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