Exchange Server|Office 365

HAFNIUM Highlights the Problem with Removing the Last Exchange Server

Unless you have been living under a rock for the last week, you could not have missed that the Microsoft 365 world has been abuzz with worry after Exchange Server 2010-2019 succumbed to zero-day exploits, believed to being used by a group known as HAFNIUM. These exploits are allowing an attacker to compromise Exchange and forcing IT Pros to stay up all night pushing patches.

Microsoft swiftly made available patches for up-to-date versions of Exchange, along with comprehensive guidance and tooling for discovering whether your environment could be compromised; and followed up quickly with patches for older versions of Exchange that aren’t running supported Cumulative Updates.

These patches are crucial whether you are running Exchange Server to host your mailboxes, or just have a single Exchange Server used for Hybrid recipient management post-migration.

Security experts and Microsoft executives have been quick to rightly point out that if you can move to Exchange Online, then you should do so.

Sponsored Content

Devolutions Remote Desktop Manager

Devolutions RDM centralizes all remote connections on a single platform that is securely shared between users and across the entire team. With support for hundreds of integrated technologies — including multiple protocols and VPNs — along with built-in enterprise-grade password management tools, global and granular-level access controls, and robust mobile apps to complement desktop clients.

If you are running Exchange Server to host your mailboxes today, based on the discussions I’ve had with other IT professionals, it is highly likely that if you could, you would move mailboxes to Exchange Online. It is widely accepted that for most organizations, Exchange Online is the best option. Therefore, I’m not going to labor that point.

Unfortunately, though, every organization that uses Microsoft 365 and uses Azure AD Connect to synchronize their Active Directory must keep an Exchange Server running to manage recipient attributes to be fully supported by Microsoft.

It’s time for Microsoft to get serious about removing the last Exchange Server

The last seven days have shone a light on Exchange, and in particular, the last Exchange Servers that continue to run in many organizations. It’s probably fair to say Microsoft will already be considering how they can finally crack this problem without further delay but if they are not, they should be.

Microsoft documented as early as 2012 that they don’t have a solution for removing the last Exchange Server, and as you can see from the comments on the Exchange Team Blog at the time, customers have been clamoring for a solution since then, if not earlier.

Current Microsoft documentation clearly states this too, explaining that while you run Hybrid Identity, the Exchange Admin Center and Exchange Management Shell (which require Exchange Server) are the only supported tools that can be used to manage recipient attributes synced from the local Active Directory.

Official Microsoft documentation states you must keep an Exchange Server, however great you are with ADSIEdit

For many customers though, removing the last Exchange Server wasn’t a high priority.

Firstly, consider that until recently, Exchange 2010 and above were considered reasonably secure – to such a degree that Microsoft was confident to say if “you operate a secure and well managed Windows/Exchange Server – you have a more secure environment than you think. Adding pre-authentication and layers of networking complexity in front of that buys you very little extra, if anything.”. That was posted back in 2013 (in relation to TMG), and for around seven glorious years, most people agreed with that perspective. In the last year though, we’ve seen several security issues in Exchange, culminating in last week’s advisories.

Secondly, remember that even after moving to Exchange Online, older applications, multi-function-copiers, fax solutions, and more needed to be able to relay SMTP via an unauthenticated (and in many cases unencrypted) connection. Exchange Server remained a great option for taking plain SMTP and then relaying it onward to Exchange Online using a Send Connector secured by TLS.

That is not to say Microsoft has done nothing to attempt to arrive at a solution. At Microsoft Ignite 2017, in breakout session “Thrive as an Enterprise in Exchange Online”, a potential solution was outlined by Microsoft:

Several years ago Microsoft explained a potential solution

As you can see though, the solution isn’t simple. This is for good reasons – just changing the source of authority for mail-related attributes, and leaving the remaining attributes within Active Directory to become stale, creates technical debt for customers and leaves a potential problem brewing for the future.

Working on many Google Workspace migrations to Microsoft 365 has taught me that even with the best of intentions, people don’t clean up these attributes left behind and they become a problem at some point in the future.

The other option that Microsoft hasn’t, to my knowledge, proposed is to build-out an on-premises extension to Active Directory for recipient management. Long-time Exchange admins will remember Exchange 2000 and 2003 used an extension for Active Directory Users and Computers to achieve this; however, this required the Recipient Update Service running (or quite often – not running, with frustrating results) to push changes. Tasks, such as updating Email Address Policies would not be possible using an AD object attribute tool, unless it incorporated the complex logic Exchange uses.

Therefore, Microsoft has been correct to look for a good solution rather than a tactical solution.

But, the search for a solution seemed to move further away from the one that appeared to be tantalizingly close in 2017.

By Microsoft Ignite 2020, in the session Exchange – Here, There and Everywhere”, Microsoft was transparent about the situation, explaining that despite best intentions a solution is still somewhere over the horizon, and requires several different teams’ involvement:

“The one piece of news unfortunately is – there really isn’t any news, and I’m sorry to have to say that to you. We genuinely understand that many of our customers – all of our customers, in fact, who’ve moved all their mailboxes to the cloud, but keep the source of authority for AD and identities on premises, they have to keep Exchange around just for recipient management.

We completely understand that’s difficult and expensive to do, and we are doing our utmost to get rid of that.

It’s a complicated problem, though, and there are several different teams involved and there’s some complexities and it’s taking us some time to work through it.

We definitely do have a solution in mind, and we’re working towards it, but I’m hoping that Spring Ignite 2021 we’ll have some more news on that, but for now, we’re committed to solving the problem – I can assure you.”

Last week at Spring Ignite 2021 there was little in the way of news in this area, or indeed any Exchange-related content, however it is likely minds were focused on more pressing issues.

As Microsoft moves past patching exploits, hopefully, engineering efforts will be focused on finally, once and for all, putting a solution together to remove the last Exchange Server that many organizations are still running. After the hectic week caused by HAFNIUM, Microsoft needs to quickly find a pragmatic solution to the last Exchange Server dilemma; the solution doesn’t need to be perfect but any assistance at this point will be warmly welcomed.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (7)

7 responses to “HAFNIUM Highlights the Problem with Removing the Last Exchange Server”

  1. <p>Everything in this post is what needs to be said, i think i could probably find my original comments on those exchange blogs – we still have exchange becuase of this EXACT setup and i can't dump it…and guess who got scanned by HAFNIUM :(</p>

  2. <p>I've moved our small company with 30 mailboxes from on-prem Exchange 2016 to Exchange Online almost 3 years ago.</p><p>I didn't think twice about simply removing the on-prem Exchange afterwards and it seems like I made the right call.</p><p>It may be that someday down the line this decision might come back to bite me in the ass but so far, it has been smooth sailing…for everyone thinking about doing the same, I have yet to find a task which I coulnd't do by simply using ADSIEDIT.</p>

  3. <p>Thank you!! This is a very deep, well-researched, and concisely written post about this issue. </p><p><br></p><p>As you note, ADSI Edit doesn't take into account the complex logic the Exchange management tools have for updates. Using it may be fine in some cases, but it's like editing a SQL table directly rather than via stored procedure–a seemingly single-field update may actually update many things. </p>

  4. <p>I have uninstalled Exchange at several customers after migration to Exchange Online and never had any trouble with it. You can still edit attributes with the Active Directory snap in.</p>

  5. <p>Microsoft has not created an "<span style="color: rgb(34, 34, 34);">extension for Active Directory Users and Computers" but it appears another company has. We are going to review this product. </span></p>

Leave a Reply

Technology Writer for Petri, focused on Microsoft Teams and UC news. 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. As Principal Technology Strategist at Content+Cloud, Steve helps customers plan their digital transformation journey and gets hands on with Microsoft Teams, Exchange and Identity projects.