This
As always, test these updates in a lab first! I recommend checking out this 7-part guide on configuring Exchange in your lab. It doesn’t take much to get one going.
The updates are as follows:

Exchange 2019 Cumulative Update 5 (VLSC)| KB4537677

Exchange 2016 Cumulative Update 16 | KB4537678 | UM Language Pack
So, what’s new in these Cumulative Updates?
In this series of cumulative updates, Microsoft has resolved a number of security and non-security issues. You can read more about those in KBs 4537677 and 4537678.
This series of cumulative updates shipped with a new version of the calculator for Exchange 2019. This new calculator corrects an issue where developing a design around mailbox size or IOPs was not producing the correct number of mailboxes per database.
Cumulative Update 5 also corrects an issue in the Manage-MetaCacheDatabase.ps1 script that ships with Exchange 2019. The script has been corrected to only return solid-state disks that are initialized. It does this by filtering out all disks with no disk number. This issue was first identified in this article.
These Cumulative Updates also fix an issue with how cookies are handled in Google Chome 80 and later. The SameSite cookie issue was first identified in this post.
If you are current on your Exchange updates, then these cumulative updates will not extend the schema. If you are running Exchange 2016 CU6 or earlier, or, Exchange 2019 CU1 or earlier, you will need to perform a schema update.
While these updates do not contain any changes to the schema, you may need to run SETUP /PrepareAD to apply security changes that were introduced in earlier cumulative updates. If you are running Exchange 2016 CU12 or earlier, or, Exchange 2019 CU1 or earlier, you will need to run SETUP /PrepareAD.
If you are running multiple versions of Exchange in coexistence, run SETUP /PrepareAD from the newest version of Exchange. For example, if you have Exchange 2013 and Exchange 2019, run SETUP /PrepareAD from Exchange 2019.
Note: If you are running in a multi-domain environment, you will need to perform SETUP /PrepareDomain in each domain. You do not need to run /PrepareDomain in the domain where you performed /PrepareAD. /PrepareAD also invokes the /PrepareDomain process.
More Awesome News
Data Consistency Scoring
Microsoft has released a new mechanism for mailbox moves to Office 365 called Data Consistency Score. This score grades the likelihood of noticeable data loss during a mailbox move to Office 365. For example, items that were previously marked as bad under the old process could just be the result of corrupt metadata; items that the user would never notice.
This new process takes the guesswork out of how many bad items are acceptable by scoring on a scale of Perfect, Good, Investigate, and Poor. A score of Perfect or Good, will allow the mailbox move to complete. A score of Investigate will require the tenant admin to approve the completion of the move. A score of Poor will require assistance from Microsoft support.
It is possible to override the new Data Consistency Score process by specifying Bad Item Limits or Large Item Limits in your move request or migration batch.
New Exchange Online Admin Center
At Microsoft Ignite the Exchange Team unveiled the new Exchange Admin Center. The new admin center has a similar look to other new M365 dashboards and is much more responsive.
You can try out the new admin center but either navigating to https://admin.exchange.microsoft.com or by navigating to the Recipients tab in the old Exchange Admin Center and clicking Try it now.
In the screenshot below we have navigated to the Mailboxes tab, which is a combination of all User and Shared mailboxes, selected a user and are currently viewing their mailbox permissions.

Faster Exchange Online PowerShell cmdlets
One of the challenges of a large Exchange Online organization is that PowerShell commands can take a very long time to run. To combat this problem the Exchange Team announced a new Exchange Online PowerShell module which ships with all new Exchange cmdlets. Microsoft has determined that in certain instances, these new cmdlets are up to eight times faster than their former counterparts.
To install the new module run PowerShell as an administrator and run the command below. You will be prompted to accept the untrusted repository and a license agreement.
C:\> Install-Module -Name ExchangeOnlineManagement Untrusted repository You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): Y License Acceptance MIT License 2.0 Copyright (c) 2019 Exchange Online Manageability Team Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"). Do you accept the license terms for module 'ExchangeOnlineManagement'. [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): Y
You may receive an error that you need a newer version of PowerShellGet before you can install the Exchange Online Management module. To resolve this, type the following. Once run, restart PowerShell and try to install the Exchange Online Management Module again.
C:\> Install-Module PowerShellGet -Scope AllUsers -Repository PSGallery -Force -AllowClobber
For more information on commands available in the PowerShell V2 module check this link.
Basic Auth on the Office 365 chopping block
Microsoft previously announced that it was blocking basic authentication for Exchange Web Services on October 13th, 2020. This has since extended to POP, IMAP, ActiveSync, and Remote PowerShell. After October 13th, 2020, any application connecting to these services will be required to leverage modern authentication (OAuth 2.0).
For Remote PowerShell, this one is easy. I recommend using the Microsoft Exchange Online PowerShell Module. This module supports both modern-authentication and is a requirement if your admin account has multi-factor authentication enabled (which I hope it does!). I recommend checking out this article for more information on how to use this module. In addition, you may also want to look into the Azure Cloud Shell. Check out the tutorial; Using Exchange Cmdlets in Azure Cloud Shell.
For POP and IMAP, Microsoft recently added OAuth support. However, this still requires your POP or IMAP application to support OAuth. Microsoft will also be releasing a tool to help you identify active POP and IMAP users in Office 365 and what authentication mechanism they are currently using.
The most significant impact of this announcement will be to ActiveSync. ActiveSync is used by countless native mail apps to access their Office 365 mail. I highly recommend migrating your user base to Outlook mobile (for iOS and Android). Outlook Mobile supports both modern authentication and multi-factor authentication. It is worth noting that some native mail apps, such as those included in iOS 11, have added support for modern authentication. However, pushing users to Outlook Mobile, versus upgrading their phones, is the path of least resistance. Not to mention your helpdesk or IT department will only need to support one universal mail client.
To track which devices and applications are signing in with basic authentication you can use the Azure AD Sign-ins dashboard. Microsoft covers this process in this article.
If you are interested in how to block basic authentication on-prem with Exchange 2019, check out this article; Disabling Legacy Authentication in Exchange Server 2019.
Older algorithms on the chopping block
Microsoft previously announced that older algorithms used in the transfer of mail to Exchange Online were being deprecated. This included SSL 3.0, TLS 1.0, and TLS 1.1. At the time of writing, Microsoft has since disabled SSL 3.0.
While Microsoft has no deadline to disable TLS 1.0 for mail transfer, they have announced that if an exploit is found, they will quickly disable the protocol. Microsoft states that approximately 5% of all mail to Office 365 still uses TLS 1.0. Microsoft urges its customers to get to TLS 1.2.
To help identify which devices and applications are still using older TLS protocols, you can access the SMTP Auth Clients report in the Mail Flow Dashboard in the Security and Compliance Center.

To identify all other SMTP connections to Office 365, including those made via hybrid mail flow to your on-prem Exchange servers, check out the Messages Protected in Transit (by TLS) report. This is also located in the Mail Flow Dashboard in the Security and Compliance Center.

More in Awesome
In other news, the Exchange Team has moved the backend infrastructure for the FindTime app within the Office 365 compliance boundary. All data stored by the FindTime app is now hosted within Office 365.
In a recent article, the Exchange Team announced that the New-MoveRequest cmdlet can no longer be used to move mailboxes between databases in Office 365. Tenant administrators would utilize this command to troubleshoot issues with mailboxes in Office 365. Moving forward, the New-MoveRequest command will only be allowed to onboard or offboard mailboxes to or from Office 365. This change will go into effect on April 15th, 2020.
Microsoft announced a change to recipient limits in Office 365. Recipient limits dictate how many recipients someone can add to a single email message (this includes all recipients added to the To, Cc, and Bcc lines). This limit was previously hardcoded to 500 recipients. Moving forward administrators will be allowed to configure this limit per mailbox, with a value of 1 to 1,000 recipients per message.
Microsoft also provided guidance on how to disable SMBv1 in your Exchange 2013+ environment. SMBv1 is a 30-year protocol and vulnerable to threats such as WannaCry, TrickBot, and, Emotet (you really should not be using it). You can read more about disabling SMBv1 for Exchange in this article.
The final countdown – 209 days left for Exchange 2010
Back in September, the Exchange Team announced that is was extending support for Exchange 2010 by nine months. Exchange 2010 now shares the same end-of-life date as Office 2010 and SharePoint 2010, which is October 13th, 2020.
While this extension allows for a little more breathing room, it does not extend support for Windows Server 2008 R2, which is the underlying operating system for many Exchange 2010 installations. Server 2008 R2 was end-of-life as of January 14th, 2020.
The Exchange Team has provided this extension to allow companies more time to migrate to a newer email platform, such as Office 365, or, Exchange 2016.
Unfortunately, there is no direct path to Exchange 2019 from 2010. If you do plan to stay on-prem, you will need to migrate to either 2013 or 2016 (I’d recommend 2016 as 2013 is now in extended support). From there you can migrate to 2019.
For more information on migrating from Exchange 2010 to 2016, check out this recent blog article from the Exchange Team: Exchange On-Premises Best Practices for Migrations from 2010 to 2016
Further Reading
Here are some articles I thought you might like.
- Using Exchange Cmdlets in Azure Cloud Shell
- Save Time with FindTime
- Secure files in OneDrive Personal Vault
- Add external sender disclaimer in Office 365
- RPC/HTTP & Block Legacy Auth may prevent Outlook reconfiguration after migrating to Exchange Online

So what do you think is coming next? What would you like to see? Drop a comment below or join the conversation on Twitter @SuperTekBoy.
Do you think is sensible and/safe to always run SETUP /PrepareAD from the newest version of Exchange, whenever doing a major CU upgrade. Will it ever do any harm?
I’ve not tried out 2019 yet, but it does provide some fun doing hops from legacy 2007 – 2013 – 2019!
It doesn’t hurt to do it with each CU. The Exchange setup should check to see if any Schema or AD updates need to be made and apply them, provided you have the necessary permissions in AD.
Just completed the upgrade. Everything went smoothly. No issue whatsoever.
Ram