The Last Exchange Server

In the announcement that was part of the release of the most recent set of Cumulative Updates for Exchange Server 2019 and 2016, Microsoft introduced some changes – features if you will – which were received with enthusiasm. An overview of these changes was given in a recent ENow blog article: “Exchange Cumulative Updates – April 2022”. However, I want take the discussion further and zoom in on one of those features, which also happens to be a popular topic for customers running Exchange Hybrid deployments: The Last Exchange Server.

Up to Exchange 2019 CU12 (2022 H1), customers that migrated to Exchange Online were still required to leave Exchange-related components running on-premises. Even today, with all the information published around this topic, I am surprised this still surprised customers. This Exchange server running on-premises is to be used for managing recipients which have their source of authority in Active Directory, leveraging Active Directory Connect to propagate objects to Azure Active Directory and thus Exchange Online. Also, when there is a need to relay messages from applications or multi-functionals, customers often need to have an Exchange server on-premises to accept these messages, as Exchange is the only supported mail relay product for hybrid deployments.

Recipient Management

But with the release of Exchange 2019 CU12, Microsoft announced it was now officially supported get rid of the last Exchange Server when running Exchange Hybrid by means of updated Exchange Management Tools. When the dust settled after people did their happy dances, and people started reading the article properly and looking into the requirements in detail, it became clear that this removal ONLY applies to scenarios when the Exchange server running on-premises is used for recipient management. This limits possibilities significantly. Most of my recent customers who have Exchange hybrid deployed, have IDM solutions in-place which directly manage Exchange Online objects, or perform this implicitly through Active Directory. When they need an Exchange server on-premises to accomplish this, usually by running scripts in a remote PowerShell session against the local Exchange server, the last Exchange server cannot be removed.

Mail Flow

Then nearly all customers who have Exchange Hybrid deployed, need this to drop off externally, or mail destined for mailboxes that are hosted in Exchange Online. Since Exchange Server is the only supported SMTP gateway for relaying internal messages, so that they are not classified as regular internet mail (anonymous) and thus potentially end up in Junk E-Mail folders. Or worse. Having applications or appliances directly deliver messages to Exchange Online is of course an alternative, but this is not always possible, and also creates a dependency for the application on the internet connection. Life is simpler when applications can just drop messages off locally, with some form of availability guarantee by having multiple Exchange hybrid servers. Then, it is up to Exchange to take care of delivery and deal with disconnects or other delivery issues.

Process

Initial wording on some publications could lead to people thinking uninstalling Exchange Server was the way to remove that last Exchange server. Of course, that is NOT the way to go. When uninstalling the last Exchange server in an organization, you will also remove all Exchange-related attributes from all objects. The article explaining this process makes this clear and emphasizes this more. In summary, what you need to do is:

• Verify all users, shared and public folder mailboxes have been migrated to Exchange Online.
• Make sure you are only using Exchange server to manage recipient information, such as users and distribution groups.
• Your delegation model does not depend on Exchange Role-based Access Control (RBAC).
• You are used to managing recipients without the Exchange Administrative Center (UI), or have 3rd party tools in-place that manage this for you.
• You have no need to have audit records of recipient management.
• You are absolutely sure you do not Exchange Server for other tasks than recipient management.
• When not already done so, point your Autodiscover and MX records to Exchange Online since your Exchange hybrid server will not be answering those requests any longer.

When you made sure this is the way to go, you can proceed with the steps described in the Microsoft article “Manage recipients in Exchange Hybrid environments using Management tools“, most important being shutting down the last Exchange server (instead of uninstalling) after which you need to make some changes to Exchange configuration and clean up Active Directory using the provided CleanupActiveDirectoryEMT.ps1 script from unused configuration elements such as hybrid configuration, system mailboxes and Exchange security groups.

A quick note: if you are currently running an Exchange hybrid deployment using Exchange server 2016 or 2013, and want to use Exchange Server 2019 CU12 management tools for recipient management, a schema upgrade is required for which you can use setup’s PrepareSchema or PrepareAD switches, depending on your environment and topology.

Role-Based Access Control

When managing Exchange server locally using Exchange Admin Center or the Exchange Management Shell, you use Exchange’s Role-Based Access Controls model. This model acts as a layer on top of Active Directory, between the administrator and Active Directory. It defines what tasks the administrator can perform, and when Exchange RBAC configuration approves the cmdlet or parameters used in the task, Exchange performs the operation in its own security context.

After removal of the last Exchange server, there is no Exchange server to talk to and act on behalf of the administrator. Basically, it is the same as managing Exchange’s Edge Servers or those recovery operations after locking yourself out of RBAC, by adding the Exchange PowerShell snap-in, e.g. Add-PSSnapIn Microsoft.Exchange.PowerShell.E2010. Only with Exchange 2019 CU12, the snap-in has a different name, Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.RecipientManagement. You can check the cmdlets available after loading the snap-in using Get-Command:

Exchange 2019 CU12 comes with a script Add-PermissionForEMT.ps1 which will create a security group “Recipient Management EMT” (Exchange Management Tool). Add members to this group that are not member of Domain Admins, but do require recipient management permissions.

Auditing

In Exchange, every administrative operation run through RBAC against Exchange can be logged. These auditing records are normally stored in an arbitration mailbox. Since there is no Exchange server and no RBAC model after removal of the last Exchange server, this also removes the option of built-in auditing tracking and investigation. This means no more searching the Admin Audit Log to see what account changed those attributes or disabled that mailbox. Security While removal of the last Exchange server might require adding complexity to the management side of things, it of course also reduces the attack surface of an organization. Since there is no Exchange server running that answers requests on ports 443 or 25 or performs management tasks through Remote PowerShell sessions, there is less to monitor and protect against. Also, as the server becomes more or less of a management terminal, it also puts less pressure on keeping up to date by deploying Cumulative Updates or Exchange Security Updates. That said, it is still recommended to keep updating and staying current, as Cumulative Updates might still include fixes or changes in way it works or interacts with Active Directory, but less in the way Exchange servers normally expose their services.

Conclusion

While removal of the last Exchange server is a welcome option for a specific set of customers, there are still parts that can be improved. That said, I prefer having this supported option available now for customers that can benefit from it, rather than wait for the solution that has it all but is not ready yet. Also, customers need to be absolutely sure that they want to use this option; for example, should at some point customers want to introduce Exchange on-premises for whatever reason, what are the consequences of having cleaned up Active Directory of part of Exchange configuration, which is something perhaps to explore for another future article.

With email being one of the most mission-critical tools for organizations today, how do you ensure vital business communication stays up and running? How do you demonstrate to senior management that additional resources are needed to meet growing demand or that service levels are being met?

Developed by Exchange architects with direct product input from Exchange MVPs, ENow’s Mailscape makes your job easier by putting everything you need into a single, concise OneLook dashboard, instead of forcing you to use fragmented and complicated tools for monitoring and reporting. Easy to deploy and intuitive to use, get started with Mailscape in minutes rather than days.

ACCESS YOUR FREE 14-DAY TRIAL and combine all key elements for your Exchange monitoring and reporting to keep your messaging infrastructure up and running like a pro!

PRODUCT HIGHLIGHTS

• Consolidated dashboard view of messaging environments health
• Automatically verify external Mail flow, OWA, ActiveSync, Outlook Anywhere
• Mail flow queue monitoring
• DAG configuration and failover monitoring
• Microsoft Security Patch verification
• 200+ built-in, customizable reports, including: Mailbox size, Mail Traffic, Quota, Storage, Distribution Lists, Public Folders, Database size, OWA, Outlook version, permissions, SLA and mobile device reports