‘Last Exchange Server’ Scenario Feedback

Simply put, the SMTP relay question remains unresolved. I am aware that we can directly route apps and devices to Exchange Online, but this involves a significant effort. Moreover, many devices lack internet access. The direct relay on port 587 necessitates open firewall ports, and ideally, a static IP address should be configured on the outbound NAT.

While this approach might work for fewer than 10 devices, many of our customers have a much larger number of devices. Consequently, they often choose to keep the last Exchange server operational. Unfortunately, the current options for correctly authenticating emails as ‘Internal’ within the Auth-Headers pose too many security risks.

Thanks for the feedback form: Done!

It's great to have an option to remove the last Exchange Server, but there are a few things that prevent some of my customers of doing this:

- Exchange uninstallation: It would be great to have an option to uninstall the last Exchange Server without removing the Attributes, that are necessary to run Hybrid. It just looks bad, if you have a dead server there, it feels like missing one step.

- SMTP relay: Often we use third party Software for this. If you have MFPs that you don't want to connect with an anonymous connector, there is no other option to it. The third party Software deploys a SMTP server which takes anonymous e-mails and sends them to the GraphAPI, A tool like this, directly from Microsoft, would be awesome

- Powershell Management: A lot of customers don't feel comfortable to create new remote users within Powershell. If there was an option to do this with a small GUI (reduced ECP) it would help so much.

Last One:
Why are you not just changing Entra Connect, to make the AAD the Primary source of users? User, Group, Mailboxcreation, all should move to M365 and synced back to the local AD. Like this you would have your GUI and don't need to care about doing onPrem stuff if you only need it for a few services. The only thing thats complicate would be to move them to the correct Forest and OU, but you could sync or mirror the whole forest to display it within the AAD.

Any of these updates would be high appreciated by my customers 🙂

PeterForster You can stand up another platform for mail relay and have it treated as "internal" mail, still.  It takes some effort, but I have done this for customers with Postfix (I even built an Ansible role to make it easy).  Use certificates and authenticate the traffic that way.

I think the most significant feature that is lost is Email Address Policies.  This is crucial for larger environments to ensure that addresses are set according to a standard and appropriately remediated when a conflict arises.  If there is a service that could be run, or a well-designed PowerShell script that accounts for the same considerations (perhaps even relies on the actual Email Address Policy data stored in Active Directory for its rules), that would be awesome.  Maybe that has been addressed in some other way that I have missed, though.

DustinDortch thanks for your idea. We thought about this too, but: Exchange did this all out of the box. Not every customer is Linux ready and having a very important function (for many customers SMTP relay is one the business critial functions) on a system they cannot manage is not an option for them.

We have customers still running two Exchange servers based on the relay requirement.

But how did you set the correct headers there? The option to mark the inbound connector as "internal" is not one we would like to use as regardless what system will later send with that public IP is marked as internal. This is the security issue we see here.

QuantumQuest - I think a lot of these items don't really show an appreciation for the challenges.

If you're looking to remove the last Exchange Server and you're still maintaining Hybrid Identity, you're not the "average" customer, in that situation.  So, the expectation that you would need to prune AD of the related objects for the server in order to clean it up doesn't seem like a significant concern.  At some point, there has to be a limit to what sort of things require some skills to manage something.  This includes PowerShell or otherwise, as well.  That doesn't mean tools can't be made, but it starts to get to the point of "If you see a need, fill the need".

If you want an ECP and still also need SMTP relay, then not eliminating your last Exchange Server is really the way to go.

The synchronization issue is far more difficult than you're giving credit.  If you're still looking for AD to exist, AD should be the source of truth.  If you notice how synchronization works in the other direction, Entra ID/Azure AD has always been a flat structure for customers.  This is because synchronizing into another structure would require a lot of manual care and feeding... mapping OUs from one side to another, or mapping users specifically.  If that is a concern, manually creating users on the other side might be less concern.  If there are only a few things, changing the permissions to work with Entra ID/Azure AD is also a possibility which allows for the elimination of AD (many times easier said than done).  Universal Print is one of those services available that could assist in that effort.

100% SMTP Relay. Relaying to Office 365 is (1) Just too cumbersome because every device and app might have different capabilities for relay, and (2) why would I allow and continue to manage hundreds of outbound IPs on my firewall to lock down port 25 when I can use a known set of Exchange Server IPs?

You really need to make the whole process for de-comissioning the last exchange server much easier. You have to go through a thousand steps 

DustinDortch 

"If you're looking to remove the last Exchange Server and you're still maintaining Hybrid Identity, you're not the "average" customer, in that situation."
I don't know if thats true. At least from what i've seen, the majority of the customers want's to either get proper access to Teams/SharePoint, or they want to get rid of their Exchange Server. Most of them are very disappointed when all mailboxes are migrated and i say: "Yes we can remove the Exchange server but...". Most of them use 3rd party Software which needs a local AD. Yes, in a perfect world the software would be able to use the Azure AD but thats not always possible. I've migrated around 40 customers to Exchange Online, 2 of them are Azure only, 2 of them have the Exchange Management Tools, around 6 or 7 had no Exchange before, but most of them still have one even if they don't want it.

"If you want an ECP and still also need SMTP relay, then not eliminating your last Exchange Server is really the way to go."
Exchange is way too huge for these two things. There are 3rd party GUI solutions for the Exchange Management Tools, even the 3rd party integration into the AD directly (Easy265Manager). You could even adjust it with ADSI Edit only, but no we should get a full server for this task? I think Microsoft could write a tool for that in 2 weeks which replaces the local ECP standalone. Same thing for Mail relay, the GraphAPI is so good, creating an SMTP Server which accepts unauthenticated SMTP locally from whitelisted IPs and pushing the mails through the GraphAPI should be possible for one of the biggest companys in the world.

I accept your answer regarding the sync back to the AD since this is definitly not so easy. But there is device, group and password writeback, i see no reason why it's not possible to write back a user aswell. This would eliminate the need of a local ECP aswell. When you need to move the user from some sync OU to the destination OU, that would be a manual task which is way faster for some customers.

To finish this: I have no problem on how it is, but a lot of my customers don't like it, and there is 3rd party software which solves all problems. I think Microsoft could copy/buy these within a few months instead of forcing customers to Azure only while not everything is possible there.

SMTP relay is a big one for us.