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 4 (VLSC)| KB4522149
Exchange 2016 Cumulative Update 15 | KB4522150 | UM Language Pack
Exchange 2010 support extended
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 will still go end of life on 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
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 4522149 and 4522150.
Most notably this fixes an issue I had run into myself in both Exchange 2016 CU13 and CU14. The issue was after running the Hybrid Configuration Wizard you could no longer modify the Outbound to Office 365 send connector if your source servers were Edge Transport servers.
Attempting any modifications to the send connector would result in the errors: Error 0x5 (Access is denied) from cli_GetCertificate or Error 0x6ba (The RPC server is unavailable) from cli_GetCertificate. This error was caused because the Exchange organization was attempting to access the certificates on the Edge Transport servers. I can confirm CU15 resolved this error for me.
Note: Error 0x5 (Access is denied) from cli_GetCertificate was also reported in Exchange 2019 CU2 and CU3. It has been resolved in CU4.
This set of cumulative updates now requires .NET Framework 4.8. More info on that installer can be found at this link.
If you are current on your Exchange updates, then these cumulative updates will not extend the schema. If you are running Exchange 2013 CU6 or earlier, 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 the February and June 2019 updates. If you ran /PrepareAD after installing the June updates, then you do not need to run /PrepareAD again.
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 CU2.
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
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.
C:\> Update-Module -Name PowerShellGet
For more information on commands available in the PowerShell V2 module check this link.
More file types to be blocked by default
Microsoft announced towards the end of September that it will be adding additional file types to the blocked file extension list in Exchange Online. The only exception is if an organization had one of those file types previously in an allowed list.
The file extensions to be added to the block list include:
|PowerShell||“.ps1”, “.ps1xml”, “.ps2”, “.ps2xml”, “.psc1”, “.psc2”, “.psd1”, “.psdm1”, “.cdxml”, “.pssc”|
|Python||“.py”, “.pyc”, “.pyo”, “.pyw”, “.pyz”, “.pyzw”|
|Digital Certificates||“.cer”, “.crt”, “.der”|
|Other||“.wsb”, “.udl”, “.appref-ms”, “.appcontent-ms”, “.settingcontent-ms”, “.cnt”, “.hpj”, “.website”, “.webpnp”, “.mcf”, “.printerexport”, “.pl”, “.theme”, “.vbp”, “.xbap”, “.xll”, “.xnk”, “.msu”, “.diagcab”, “.grp”|
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. In a recent blog post, the Exchange Team announced it was extending this block 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 will soon be adding OAuth support. This means your POP or IMAP application will need 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.
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.
In February 2020, Unified Messaging in Exchange Online will be retired. With the removal of Unified Messaging in Exchange 2019, this marks the end of Unified Messaging in the Exchange product line.
Customers leveraging Exchange Online Unified Messaging for either Skype for Business 2015 or Lync 2013 were automatically transitioned to Cloud Voicemail earlier in the year. Organizations on Lync 2010 were not transitioned. Anyone on Lync 2010 will either need to migrate to Skype for Business (to continue to use the cloud for voicemail) or find another voicemail solution.
Customers leveraging Exchange Online Auto-Attendant will need to manually transition attendants and phone numbers to Cloud Auto-Attendant before February 2020.
The main benefit of this change is that it folds all products–Skype for Business on-premises, Skype for Business Online, and Teams–into the same voicemail and phone system. This allows Microsoft to focus all development and support onto a single product.
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.
Ram Lan says
Hi – I just updated the server to CU4 on 22nd Dec 2019. Just a note – was having issue with ECP after the upgrade. Was not able to login to ECP through IE or Chrome.
I was able to resolve the issue after, I installed this update KB4533094 and restarted the server.
Compiler Error Message: CS0433: The type ‘ASP.adminfeedback_ascx’ exists in both ‘c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ecp\67f1ad38\e5546d0a\App_Web_sru5d10r.dll’ and ‘c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ecp\67f1ad38\e5546d0a\App_Web_c0kfwzvq.dll’
Gareth Gudger says
Thanks for the heads up Ram. 🙂