Microsoft has recently announced that it will be stopping older Exchange versions from sending mail through Exchange Online. This is a significant move that will impact organisations that still use older versions of Exchange.
Exchange Online provides enterprise-grade security and reliability, ensuring that users’ data is always protected.
Microsoft is stopping older Exchange versions from sending mail through Exchange Online to improve the security and reliability of the service. Older versions of Exchange may not have the latest security updates or features, making them more vulnerable to cyber threats. This puts users’ data at risk, which is why Microsoft is taking this step to protect its customers.
Microsoft will be stopping the following versions of Exchange from sending mail through Exchange Online:
Exchange 2010
Exchange 2013
Exchange 2016 without Cumulative Update 23 or later
Exchange 2019 without Cumulative Update 12 or later
Organisations that are still using older versions of Exchange will need to upgrade to a newer version or move to Exchange Online to continue using the service. This may require significant effort and resources, depending on the size of the organization and the complexity of the email system.
However, upgrading to a newer version of Exchange or moving to Exchange Online has several benefits. It provides better security and reliability, ensures that users have access to the latest features, and enables organisations to take advantage of the latest cloud-based technologies.
In addition to upgrading to the latest version of Exchange, organisations should also take other steps to improve their overall security posture. This includes implementing strong password policies, using multi-factor authentication, regularly backing up data, and training employees on how to recognise and report suspicious activity.
I have been recently doing some work for a local council where they require a migration strategy to move away from an ageing on premise Exchange 2010 and 2016 environment. The environment is currently hosted in a secure infrastructure managed by a large 3rd party who have put in place many security functions such as F5 proxies, numerous firewalls to protect the councils data. The main challenge here was to enable mail flow from the EOL services to EOP. One key factor into this solution is that Microsoft specify the following:
We must not place any servers, services, or devices that process or modify SMTP traffic (Filtering / Packet inspection) between the on-premises Exchange servers and Microsoft 365 or Office 365. Secure mail flow between the on-premises Exchange organisation and Microsoft 365 or Office 365 depends on information contained in messages sent between the organisations. Firewalls that allow SMTP traffic on TCP port 25 through without modification are supported. If a server, service, or device processes a message sent between your on-premises Exchange organisation and Microsoft 365 or Office 365, this information is removed. If this happens, the message will no longer be considered internal to the organisation and will be subject to anti-spam filtering, transport and journal rules, and other policies that may not apply to it.
With the above in mind we had to implement a solution that would not impact current mail flow and provide a solution to connect the EOP to EOL for just hybrid mail flow. To do this we implemented a Microsoft Exchange 2016 Edge Transport Server in the parimeter network and NAT the SMTP traffic through the firewall to the Exchange Mailbox Server in the internal network. The following explains the configuration to get this to work:
Exchange Edge Transport Network Diagram
Network ports required for mail flow with Edge Transport Server
Inbound mail – Edge Transport server to internal Exchange organization
25/TCP (SMTP)
Edge Transport server
Mailbox servers in the subscribed Active Directory site
Outbound mail – Internal Exchange organization to Edge Transport server
25/TCP (SMTP)
Mailbox servers in the subscribed Active Directory site
Edge Transport server
Outbound mail – Edge Transport server to internet
25/TCP (SMTP)
Edge Transport server
Internet (any)
EdgeSync synchronization
50636/TCP (secure LDAP)
Mailbox servers in the subscribed Active Directory site that participate in EdgeSync synchronization
Edge Transport servers
DNS for name resolution of the next mail hop*
53/UDP,53/TCP (DNS)
Edge Transport server
DNS server
Mail flow with Edge Transport Server
The following process describes the path messages take between an on-premises organisation and Exchange Online when the Edge Transport server is deployed.
Messages from the on-premises organisation to recipients in the Exchange Online organization are sent from the internal Exchange server:
Messages from the on-premises organisation to recipients in the Exchange Online organisation are sent from a mailbox on an internal Exchange server.
The Exchange server sends the message to an Edge Transport server running a supported version and release of Exchange.
The Edge Transport server sends the message to EOP.
EOP delivers the message to the Exchange Online organization.
Messages sent from the Exchange Online organisation to recipients in the on-premises organisation follow the reverse route.
Build Exchange Edge Transport Server
Rather than me mapping out the steps for deploying the Transport Server role, the following video goes into great detail as to how you deploy it.
Install Pre Reqs
.NET Framework 4.7.1
Visual C++ Redistributable Package for Visual Studio 2012
Install-WindowsFeature ADLDS
Add DNS Suffix to the Hostname of server
Manually add the DNS record of the non domaines joined server used for Edge
Export Exchange Certificate from Exisiting
ConfigureEdge Subscription
Like the previous video, this one goes in to great detail as to how to configure the Edge Synchronisation and tests to ensure that the syncs are working as they should.
Publish Exchange SMTP Externally
Modify External DNS record for Exchange 2016
A Record: edge.domain.name to reference new Perimeter network External IP
Microsoft have released the new Exchange Online PowerShell module today, This module supports modern authentication and includes faster alternatives to common cmdlets.
The Exchange Online PowerShell V2 module contains a small set of new cmdlets that are optimised for bulk data retrieval scenarios. Until you create a session to connect to your Exchange Online organisation, you’ll only see these new cmdlets in the module. After you connect to your Exchange Online organisation, you’ll see all of the older remote PowerShell cmdlets.
The EXO V2 module uses Modern authentication for all cmdlets. You can’t use Basic authentication in the EXO V2 module.
The new cmdlets in the EXO V2 module are meant to replace their older, less efficient equivalents. However, the original cmdlets are still available in the EXO V2 module for backwards compatibility after you create a session to connect to your Exchange Online organisation.
The new cmdlets in the EXO V2 module are listed in the following table:
Windows PowerShell needs to be configured to run scripts, and by default, it isn’t. To require all PowerShell scripts that you download from the internet are signed by a trusted publisher, run the following command in an elevated Windows PowerShell window: Set-ExecutionPolicy RemoteSigned Notes:
You need to configure this setting only once on your computer. Read more about execution policies here.
If you don’t do this step, you’ll receive the following error when you try to connect:Files cannot be loaded because running scripts is disabled on this system. Provide a valid certificate with which to sign the files.
Close and re-open the elevated Windows PowerShell window to get the changes from the previous steps.
Run the following command from an elevated Windows PowerShell window: Install-Module -Name ExchangeOnlineManagement Enter Y to accept the license agreement.
Update the EXO V2 module
If the EXO V2 module is already installed on your computer, you can run the following commands to see the version that’s currently installed and update it to the latest version.
To see the version of the EXO V2 module that’s currently installed, run the following commands: Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement
Run the following command to update the EXO V2 module to latest version that’s available in the PowerShell Gallery: Update-Module -Name ExchangeOnlineManagement Enter Y to accept the license agreement.Note: If you receive the following error related to the PowerShellGet module, see Step 1 in the previous Install the EXO V2 module section to update the PowerShellGet module to the latest version.The specified module ‘ExchangeOnlineManagement’ with PowerShellGetFormatVersion ‘<version>’ is not supported by the current version of PowerShellGet. Get the latest version of the PowerShellGet module to install this module, ‘ExchangeOnlineManagement’.If you need to update the PowerShellGet module, be sure to close and re-open the Windows PowerShell window before you attempt to update the ExchangeOnlineManagement module.
To confirm that the update was successful, run the following commands:Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement
You can download the PowerShell command-lets today from:
Malcolm Plested IT Blogs 