Address rewrite not working for Calendar items

[bonezAU]

Hi,

We are running a hybrid environment with 3 active directory domains, 3 on-prem Exchange clusters and the majority of our mailboxes in O365.

We have set up a default address rewrite so that emails from everyone across the 3 different legacy domain names appear to come from the new domain name. Emails are sent from O365 back to the on-prem clusters for rewriting. Lets use an example

john@oldcompany1.com

john@oldcompany2.com

john@oldcompany3.com

Address rewrite is set up so all emails from the above addresses are displayed to external recipients as:

john@newcompanyname.com

This works perfectly for all outbound emails, however it does not work with meeting/calendar invites.

For example, my own mailbox has the default alias of @oldcompany1.com, and when I send an email to a recipient outside of our organisation, it shows as coming from @newcompanyname.com, but when I send a meeting/appointment to an external recipient, it shows as coming from @oldcompany1.com.

Has anyone seen this before, if so - do you have any tips on where to start the troubleshooting process?

[#2]

Hi @bonezAU,

I believe that's by design. You can try to use ChooseFrom 365 cloud service to rewrite the From: address of Meetings.

[#3]

Hello bonezAU, I know this is old but I've encounter this exact problem. Have you been able to resolve this?

[#4]

It sounds like you're encountering an issue with how meeting invites are handled in your hybrid setup. While the address rewrite works for regular emails, meeting invites sometimes retain the original domain because of how they are processed differently compared to standard email messages.

A few things you might want to check:

Address Rewrite Configuration: Ensure that your address rewrite rule also covers meeting invitations, as they may require separate handling. It's possible the current rule only applies to regular mail flow and not calendar-related emails.

Hybrid Configuration: Review the hybrid configuration between your on-prem Exchange servers and Office 365. It could be that meetings and calendar items are being routed or processed differently, leading to the original domain being exposed.

Meeting Requests Flow: Since meeting requests might bypass certain rewriting mechanisms, you could explore configuring additional rules or scripts to handle meeting-related emails specifically.

Additionally, if you’re considering migrating your mailboxes entirely to Office 365 to simplify such issues, you might find our Microsoft 365 migration service <a href="https://medhacloud.com/microsoft-365-migration-services/" target="_blank"> helpful.

Has anyone else experienced a similar issue or have any troubleshooting tips?

[#5]

Hello justmsguy, the issue is with MailUser.

For rewrite to work MailUser is created with both smtp addresses, source and destination. If for example calendaring is not opted out from rewrite process response will come from rewritten address, which is fine, if on the other hand calendaring is opted out from rewrite process the response will come from the original address, which is also fine.

The issue is that in any instance Outlook\Teams will add an optional attendee which is selected from the MaiUser - either source smtp or destination smtp, depending whether calendaring is included or excluded from the rewrite service.

Now, to add salt to the wound, we have MTO multitenant configuration, and #EXT users exist from other tenants whose original smtp match the one which is external in MailUser.

To murky the water little more, the meeting request is sent not to the MailUser but to the #EXT user. And yes, we did try to send meeting request to the MaiUser - result is the same.

And here’s where the circus begins, optional attendee is automatically added to any meeting, and response is from optional attendee, it doesn’t come from required attendee, so we end up having two same attendees for the meeting, one is original-required (#EXT) which is idle (unknown), and the other is optional which responded to the meeting request? That's the issue.

I can't figure out why is optional attendee added.

I would understand this in case in which calendaring is not opted out, then rewrite service will try to replace required attendee with rewritten address - which would be rejected so rewrite service would add an optional attendee, or stop processing request.

But in case where calendaring is opted out from the rewrite process there is no reason for optional attendee since rewrite rules do nothing but check and pass the original request.

Any thoughts on how to solve this?
Thanks

[#6]

@bonezAU 

May check on Address Rewrite Agent (ARA) as well as Transport Rules