How to reconfigure Outlook on MAC to use Modern Authentication
In earlier post on this blog we discussed Microsoft turning off basic authentication and what you...
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.
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.
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.
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:
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.
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.
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.
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!
I'm a Microsoft 365 Apps and Services MVP, with focus on Exchange, Identity, and an affection for PowerShell. I'm is a consultant, publisher of EighTwOne, published author, and speaker.