This may not directly align with the scenarios described in the article, but I’m curious to hear Microsoft’s perspective on the following approach.
In a typical environment where all mailboxes have been fully migrated to Exchange Online, classic Hybrid features such as free/busy sharing and mailbox migrations are no longer required. However, the on-premises Exchange server is retained solely for SMTP relay and recipient management, due to the continued use of Azure AD Connect.
To maintain mail flow between the on-prem server and Exchange Online, the environment still relies on the Hybrid Configuration Wizard created connectors which in turn depend on a valid public TLS certificate. This introduces an ongoing operational requirement to renew the certificate annually to avoid mail flow disruption.
Given that Hybrid functionality is no longer needed (except for in my case relay and recipient management), would the following approach be viable and supportable:
1. Configure a new outbound connector on the on-prem Exchange server using domain-com.mail.protection.outlook.com or domain-com.l-v1.mx.microsoft.com as the smart host.
2. Create a new inbound connector in Exchange Online scoped to the public IP of the on-prem Exchange server, allowing relay based on IP authentication. And if you haven't already, then ensure that your Exchange servers Public IP is present in your SPF-record for the domains you need to relay through.
3. Remove the Hybrid Configuration Wizard created connectors both on-premises and in Exchange Online.
In theory, it would allow the server to still relay to Exchange Online and be kept in a supported scenario where the Exchange server can manage mailbox attributes on migrated mailboxes without the use of unsupported methods as ADSIEdit, and not being bound to annually update the certificate on your server as you're now authenticated by IP, thus you'd never have to run the HCW again unless there is a major update where it is needed, and finally you can remove the public TLS certificate from your Exchange server so you don't need to update it on your server and can continue onwards by using the 'Microsoft Exchange' certificate as your default SMTP certificate, if your server don't have services that requires a public TLS cert.