Now that you’ve finished migrating to Exchange Online, congratulations! Now you can access all your emails from the cloud, and your emails synchronise seamlessly. As a result of the move to Exchange Server, what’s next for you?
The following tasks will need to be performed to remove Exchange Servers from your environment, but you should know that if you run Azure AD Connect, you cannot remove all Exchange Servers from your environment. At least one should be kept around for management purposes.
This article walks through advice on minimising what you need to keep and maintain and planning for the future.
Exchange is necessary for recipient management if you are running Azure AD Connect.
If you intend to run Hybrid Identity after migrating to Exchange Online, Microsoft hasn’t removed the requirement to keep at least one Exchange Server around.
Hybrid Identity is based on the fact that the objects synchronised with Azure Active Directory (Azure AD) originate from your on-premises Active Directory Forest and Domain. Almost all attributes synced to Azure AD from your local AD have to be set and edited locally in Azure AD, which is the directory used by Microsoft 365, including Exchange Online.
In other words, you must create the user account in Active Directory when you create a new user account.
The new Azure AD account gets linked back to the new Azure AD account created when you create the new user account. If the new Azure AD account does not have the required attributes, you won’t be able to use the online tools, such as Exchange Admin Center, to update that account.
Microsoft does not provide support for manually editing Exchange attributes via its Active Directory management tools. You can set Exchange-specific points via Active Directory Users and Computers (via the attribute editor) or ADSIEdit.msc, but management tools are not designed to manage Exchange attributes. For the option of phoning up Microsoft for support, Microsoft clearly states that you must use an Exchange server:
Microsoft’s position is justified for many reasons. A solution is available to remove the last Exchange Server from your organisation; however, as the issue is relatively complex and considers the needs of small, medium, and large companies, providing a one-size-fits-all solution will be difficult.
Many enterprise environments that are regulated don’t allow write-backs or coordinated changes, nor are they feasible for smaller customers. Community suggestions include cutting off sync of Exchange attributes, resulting in stale and outdated data in AD.
Providing a set of PowerShell scripts as a replacement for Exchange Management tools would be too complex to manage for small organisations.
In addition, you can break the last Exchange Server on your own; whatever you do yourself will break when Microsoft provides a solution. According to Microsoft, an update may be required before the solution gets removed.
The last point is that, by and large, either a consultant or IT administrator can’t create a third-party tool or script that effectively replicates Exchange Admin Center or Exchange Management Shell. You should be aware that the Active Directory configuration stores and uses several areas directly related to ongoing recipient management in Exchange Online:
- Manage users’ mailboxes, shared mailboxes, and archives with remote access (managing your Exchange Online mailboxes in AD).
- Manage your mail users.
- Create and manage mail contacts.
- Managing security groups by email.
- Management of distribution groups.
- Supporting remote domains and accepted domains.
- Maintaining email policies.
- Setting up Automatic Discovery Service Connection Points.
Regarding recipient management, Microsoft claims you can examine everything Exchange does, but the action you take is at your own risk. If the risks associated with running Exchange on-premises increase with time, perhaps the Microsoft 365 community of IT pros (and Microsoft MVPs) can review the risks together and provide a solution. Now, though, the time is not yet right.
Exchange Servers will no longer be on site.
The company says they will have a solution for removing the Exchange server – and since Exchange is now acceptable as a cybersecurity target, we encourage you to restrict access and possibly shut down Exchange Servers when not in use.
Hence, if you want, you can use direct delivery to Exchange Online but do not want to take the risk of a compromised firewall for outgoing SMTP; what are your options?
Standard-compliant SMTP relays with a known configuration on Exchange Online are only considered; after all – we are only considering options when they release a way to remove the last Exchange Server.
Using Exchange Servers with the Edge Transport role would be the first option to consider.
In a DMZ, for example, the role gets installed on standalone servers without a local Active Directory domain connection.
There are fewer hardware requirements for Edge Transport, as it does not install HTTPS services. Hybrid deployments can support Edge Servers, but without Exchange, this deployment model would not be applicable. There would be no mailbox servers for EdgeSync, so the Edge Servers would instead have to provide Send and Receive connectors.
There is no clear definition of a hybrid mail flow scenario covering roles in Microsoft’s licensing FAQ. Still, it is of utmost importance that your Microsoft account manager verifies this for you. Otherwise, the Edge Transport role provides the same ability to maintain relay Receive Connectors and a Send Connector onward to Exchange Online using the same skills you have today and fulfils the need to remove Exchange from the corporate network and Active Directory.
First, SMTP functionality found in IIS on Windows Server get used. It’s a configuration that some organisations have used successfully, but long-time administrators of Exchange Server 2000 or 2003 will recognise this as SMTP functionality.
IIS SMTP for mail relay may be considered as a last resort if you want an option, at which point a third-party solution with ongoing support and development might be most appropriate.
Mail servers compatible with Open-Source software, such as Exim, Postfix, and Send mail, are well documented and capable of handling extremely high mail volumes. Mail Transport Agents are often used to power cloud-based mail filtering solutions – but the servers they run on the need to be patched and maintained because they still have vulnerabilities.
