• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Blog / Finally, you can remove your last Exchange Server

Finally, you can remove your last Exchange Server

April 21, 2022 by Steve Goodman 16 Comments

Table of Contents

  • A word of warning first
  • What to Expect Removing the Last Hybrid Exchange 2019
  • Microsoft 365’s Evolving Capabilities are Culprit
  • Widening the niche

A word of warning first

With what’s almost a passing mention in the announcements for the latest Exchange Server 2019 “H1” cumulative updates on 04/20/22, there were some significant updates from Microsoft.

Yes, removing the last Exchange Server from a Hybrid environment is now possible.

It is important to note though: You must NOT uninstall it – though you remove it permanently using Microsoft’s instructions, and for many folks, you might need to keep the Exchange Server around for some time longer.

You will find a list of caveats, and a specific process documented in detail by Microsoft. Having been part of the preview program for this new feature, the requirements and steps to remove Exchange all make sense.

Register here for TEC 2022 and gain more essential info around removing the last Exchange Server during a session hosted by Jeff Guillet

What to Expect Removing the Last Hybrid Exchange 2019

If you migrated all your mailboxes to the cloud some time ago, then you’ve probably dreamed about the day when you can finally (perhaps with some ceremony), remove that last Exchange 2019 Server. To be clear, you will be slightly underwhelmed, and that is absolutely fine.

What you can expect: A subset of Exchange recipient management cmdlets targeting AD objects representing cloud recipients and their supporting configuration like domains and email address policies. You’ll also receive instructions and scripts to allow you to gently remove the supporting configuration for the server and various hybrid components – after shutting down the last Exchange Server.

Finally, you can remove your last Exchange Server
Figure 1: An management tools only installation; only this time you get remote recipient management cmdlets!

You will still need to manage recipient configuration on-premises for AD-mastered objects with the same boundaries you’re used to. For example, updating Email Addresses for an on-premises user, and updating mailbox settings such as recipient permissions in Exchange Online.

Finally, you can remove your last Exchange Server
Figure 2: Your new cmdlets for recipient management

You won’t have the ability to change the source of authority for those objects, which is something Microsoft alluded to in the past. You also won’t have the ability to update user attributes cloud-side in Exchange Online with the AD object updated using a mechanism (similar to password change flow or HR-based provisioning from Azure AD to on-premises) which was another method shared by Microsoft as a possibility several years ago.

The solution is focused on the recipient management aspect as well. However, Microsoft isn’t specifically suggesting this is the panacea to solve the “last Exchange Server” problem for all.

Mail Relay remains the elephant in the room and while Microsoft announced that Exchange Server 2019 gets free Hybrid licenses, and that you can deploy Exchange onto Windows Server 2022 – that only applies to the core Mailbox role on a domain-joined server not an Edge Transport Server deployment.

Edge Transport as a standalone SMTP relay has the potential to be a great drop-in replacement placed into a DMZ allowing mail relay from older application servers using Receive Connector rules imported from the last Exchange Hybrid Servers you maintain. For now, at least, you’ll need to keep that last Exchange Server up to date, use a different MTA, or work on configuring your application servers to deliver to Exchange Online.

Microsoft 365’s Evolving Capabilities are Culprit

If you were expecting the perfect solution after all this time, then you shouldn’t have. In the last few years, the reality is that an increased number of organizations are actually removing their dependency on Active Directory. By the time a perfected write-back or change of authority solution arrived, you would most likely be considering going towards cloud-only identities anyway with potentially Azure AD DS being the legacy directory after you move some of those legacy servers into a Landing Zone in Azure.

Without write-back capabilities, a stale set of attributes in AD for customers that don’t have a cloud-first strategy (but extensively use Microsoft 365) is dangerous enough that any advocates for simply cutting the link between an AD attribute for Exchange and the equivalent Azure AD attributes have thankfully not experienced the pain that causes.

Many Google migrations obviously result in buyer’s remorse (and staff mutiny) and when customers come back, the mess made by whoever helped them migrate usually includes switched-off Exchange Servers, and attributes that haven’t been maintained and don’t reflect the current state for mail flow. A great deal of effort needs to be expended on remediation, and for Microsoft to enable its own customers to end in that situation would have been inexcusable.

If you truly don’t want Exchange attributes managed in a local AD, even by a set of Exchange recipient management tools, then – begin thinking about how you remove AD. It’s easily achieved by smaller organizations and regularly achieved by mid-size and smaller enterprise organizations. Any larger than a few thousand employees and yes – there will be enough reliance on commercial off-the-shelf apps that it will be more difficult and a 2–3-year journey. In such orgs, the footprint of running a couple of Exchange Servers in Azure or the datacenter is negligible though; and with the ability to upgrade to Exchange 2019; use Windows Server 2022 and perform in-place OS upgrades in the future too – it’s not a bad situation.

Widening the niche

The solution to removing the last Exchange Server is undoubtably a niche solution, for those that:

  • Have no need for mail relay using Exchange
  • Had only a single server remaining
  • Had thankfully not tried to do it themselves already in an unsupported way, leaving attributes in an unknown state
  • Are quite happy using PowerShell for ongoing management
  • Are small enough to fit the above criteria, competent enough with PowerShell to use that for daily management and have no plans to get rid of AD any time soon.

The first three points are a wide cross-section of businesses – the fourth is an order of magnitude slimmer niche; a niche within a niche, if you will.

To help solve that, stay tuned for my latest open-source script, which I’ll release for Practical 365 readers in the new few weeks for removing the last Exchange server.

Blog, Exchange Online, Exchange Server Edge Transport, Exchange 2019, Hybrid, STMP relay

About Steve Goodman

Chief Editor for Audio and Video Content and Technology Writer for Practical 365, focused on Microsoft 365. A nine-time Microsoft MVP, author of several Exchange Server books and regular conference speaker, including at Microsoft conferences including Ignite, TechEd and Future Decoded.

Steve has worked with Microsoft technology for over 20 years beginning and has been writing about Exchange and the earliest iterations of Office 365 since its inception. Steve helps customers plan their digital transformation journey and gets hands on with Microsoft Teams, Exchange and Identity projects.

Comments

  1. steven says

    May 17, 2022 at 4:36 pm

    Know if there is any dependencies on the Exchange namespaces and the RecipientManagement Snapin once the Exchange Server is retired?

    Would like to just standup an IIS server as a mail relay and repoint DNS but not sure if this would cause any issues with the RecipientManagement Snapin.

    Reply
  2. Djarin says

    May 10, 2022 at 6:59 pm

    What’s pretty amazing is that these tools will not work in PowerShell 7 since, for some reason, they packaged them as a snap-in instead of a module. PowerShell 7 does not support snap-ins.

    I’d like to thank Microsoft for making this more complicated than it needs to be.

    Reply
  3. Eirik Lindem says

    May 9, 2022 at 10:47 am

    Hi.
    As talked about in the comments here it seems like it is possible to install 2019 CU12 managements tools on a server even if you are on Exchange 2016.
    Has anyone done this?
    Does it do any harm to the Exchange 2016 server or is it still operational after doing all the schema updates and installing the management tools?
    Thank for any reply.

    Reply
  4. Marklin says

    May 3, 2022 at 2:25 am

    Posted my q under wrong comment, so feel free to remove the other one.

    Can we use only the commands posted on microsoft doc? It seems the management tool is limited to a few powershell commands.
    I don’t see Add-MailboxPermission in the command list that MS posted on the article.

    Reply
  5. Brian B. says

    April 28, 2022 at 7:47 pm

    We’re fully moved to online mailboxes for several years now, just using HCW for the recipient management and Relay. Looks like we’ll have to spin up a new Exch 2019 with HCW so we can retire the old Exch 2016 with HCW as we are stuck with the requirement for Relay for at least another year (legacy devices and stuff). But knowing we can then move to just a feature install of Exch 2019 on some other server is very welcome news going forward to maintain our recipient management.

    Any items to cleanup once we get the Exch 2019 with HCW up and the process thru the uninstall/decom of Exch 2016?

    Reply
  6. olivier says

    April 26, 2022 at 2:51 pm

    what about brend new AD forest ?
    promote DC, update schema and install tools only, right ?
    i understand there is no need to install exchange

    Reply
    • Steven Goodman says

      April 26, 2022 at 5:27 pm

      Yes, you’ll need to install this, along with the configuration needed to support managing Exchange attributes. Previously in a new forest, you’d install and configure a minimal Hybrid Server

      Reply
  7. Tristan says

    April 24, 2022 at 9:23 am

    Am I right in assuming this functionality is only for Exchange 2019 instance, so we would need to upgrade from 2016 to 2019 to get the feature set to turn off the server?

    Reply
    • Vincent says

      April 26, 2022 at 10:53 am

      Hello,
      Good point Do you get an answer for this ?

      Reply
    • Jeroen says

      April 26, 2022 at 11:31 am

      Indeed a good point. In a hybrid scenario we get a free licenses for the last remaining Exchange 2016 server, but not for an Exchange 2019. If this feature is for 2019 only, how is this to be implemented? Can you simply rollout another 2019 next to the existing 2016 machine and demote the oldest one, then simply shutdown (with the correct procedure) the 2019 machine? What about licensing that machine for the short period of time necessary to shut it down permanently?

      Reply
      • Jeroen says

        April 26, 2022 at 11:43 am

        I will reply to my own comment. It has been answered by MS that an installation op Exchange 2019 is not necessary if you are using Exchange 2016. A simple extend of the schema for Exchange 2019 will be necessary, but a co-existence scenario is not.
        After the schema extend the management tools can simply be installed.

        Answered by Nino Billic on Apr 25 2022 09:13 AM on the MS blog post.

        Reply
        • Eirik Lindem says

          May 2, 2022 at 11:53 am

          Hi.
          This is very interesting, do you know if the Exchange 2016 will still work after doing the installation of the 2019 management tools on a new server.

          Reply
    • Steve Goodman says

      April 26, 2022 at 5:28 pm

      Nino is (of course) right – it’s a schema update; so if you run Exchange 2013 and add the 2019 schema it limits options on installation of 2016 – but apart from that, it’s schema *only*

      Reply
  8. Chris Barrett says

    April 22, 2022 at 2:21 pm

    Wonderful article that sums all this up really well

    Reply
  9. Andy Costello says

    April 22, 2022 at 7:54 am

    Great article Steve

    Reply
    • Steven Goodman says

      April 26, 2022 at 5:29 pm

      Thanks Andy! To think it is several years since we discussed this and hoped that the Exchange Servers installed in the new AD forest would be soon replaced – but at least, now there the option..

      Steve

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland