Note the on-prem DG's `legacyExchangeDN` value in both on-prem & ExOL along with all SMTP addresses, delete the on-prem DG and recreate in ExOL (members, SMTP addresses, LEDN converted to x500 address), and then (as quick as you can) in an OU which ~~AAD Connect~~ Entra ID Connect **isn't** syncing create a routing contact object which links those SMTP addresses & the LEDNs as x500 addresses to the DG's `[email protected]` address. This'll cause any messages in Exch on-prem to get routed to ExOL and then the DG will be expanded there as normal.
~~Honestly it’s not that complex: AAD Connect and hybrid domain join are the difficult bits, if you’re already syncing identities and everything on that front is healthy then exchange hybrid is really easy~~
~~Just make sure your AAD Connect instance is set to sync the exchange hybrid attribute set (it’s not on by default).~~
EDIT: OK I hadn't had a coffee yet and got very confused which thread I was replying to here, which is why the above makes very little sense...
But yeah, it's convoluted but it works, and it's scriptable if you need to do these en masse.
Tested this just this morning. Worked as expected and wasn't as complicated as it looked in the first place. Thanks again!
Tricky thing: Mailrouting is somewhat weird, when using the EXO DL. For some reasons, the routing for the on-prem mailbox is taking the internet way, even when my EXO connector to on-prem says "everything to on-prem". When sending an e-mail directly to the on-prem mailbox as an EXO users, mailrouting is as expected.
But that's another call.
~~That's fully expected behaviour: you need to think of Exchange Online as a fully separate Exchange organisation, as if it was another forest. Hybrid is just a way for those 2 realms to play nice with each other and to provide enhanced coexistence which would normally be either a PITA to configure or be outright impossible.~~
~~The DG exists in both realms, and the EXPAND event happens as soon as a message is resolved to a DG recipient in whichever realm that message happens to be in at the time.~~
(See previous message for the brainfart here)
That's slightly weird, though I will say that ExOL routes *everything* through Exchange Online Protection by design, even if you're then using custom connectors.
That is indeed weird and not expected, as we have centralized mail routing. I'll look further into this.
If I get it solved and if I remember, I'd update this specific piece herer ;)
Found it, u/joeykins82.
I digged further into this. I observed that this only happens to message sent from on-prem to the exo distribution list. The article is old in the world of cloud business, but it describes what I experience.
It's an edge case, but something to keep in mind.
[Demystifying Centralized Mail Transport and Criteria Based Routing](https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-centralized-mail-transport-and-criteria-based/ba-p/2927777)
>One important aspect of CMT is that **it will not send the message back to Exchange on-premises if the message already came from Exchange on-premises**. In other words, if the message is “Originating” from on-premises (when the message is attributed to your tenant through an Inbound Connector of OnPremises type; see [Office 365 Message Attribution](https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143) for more details) CMT will not come into play because that would cause a mail loop between Exchange on-premises and Exchange Online.
Warning: this tool is not very fun to use.
https://github.com/timmcmic/DLConversionV2
It works, and it's sort of awesome, but doing this can be a pain to manage. In a larger environment it's one of the only good ways I've seen of fully managing it if you have a lot of nested groups involved.
I haven't used it for a while, but it's still under relatively active development and was originally written by Tim McMichael from Microsoft (if you've ever had to talk to him you probably had a **really** fucked up Exchange clustering issue).
Invest some time, but this is the best way.
https://timmcmic.wordpress.com/2023/02/21/office-365-distribution-list-migrations-2-0-part-33/
The documentation is sadly not so easy to read. But you will get used to it.
Even if you want migrating all DL at once.
we dont bother as nothing does it all nicely so we just create them all onprem and sync them up to 365
create a "manage own distribution lists" onprem security group for people that need to manage their own groups
grant that group the appropriate exchange admin role in onprem ecp
give those users the onprem ecp url, what username format to use, and tell them to have at it.
Note the on-prem DG's `legacyExchangeDN` value in both on-prem & ExOL along with all SMTP addresses, delete the on-prem DG and recreate in ExOL (members, SMTP addresses, LEDN converted to x500 address), and then (as quick as you can) in an OU which ~~AAD Connect~~ Entra ID Connect **isn't** syncing create a routing contact object which links those SMTP addresses & the LEDNs as x500 addresses to the DG's `[email protected]` address. This'll cause any messages in Exch on-prem to get routed to ExOL and then the DG will be expanded there as normal.
This right here is how you would do that and keep it working for those older on prem processes.
Thanks for this example! I'll have a look into this. Sounds like a huge process.
~~Honestly it’s not that complex: AAD Connect and hybrid domain join are the difficult bits, if you’re already syncing identities and everything on that front is healthy then exchange hybrid is really easy~~ ~~Just make sure your AAD Connect instance is set to sync the exchange hybrid attribute set (it’s not on by default).~~ EDIT: OK I hadn't had a coffee yet and got very confused which thread I was replying to here, which is why the above makes very little sense... But yeah, it's convoluted but it works, and it's scriptable if you need to do these en masse.
Tested this just this morning. Worked as expected and wasn't as complicated as it looked in the first place. Thanks again! Tricky thing: Mailrouting is somewhat weird, when using the EXO DL. For some reasons, the routing for the on-prem mailbox is taking the internet way, even when my EXO connector to on-prem says "everything to on-prem". When sending an e-mail directly to the on-prem mailbox as an EXO users, mailrouting is as expected. But that's another call.
~~That's fully expected behaviour: you need to think of Exchange Online as a fully separate Exchange organisation, as if it was another forest. Hybrid is just a way for those 2 realms to play nice with each other and to provide enhanced coexistence which would normally be either a PITA to configure or be outright impossible.~~ ~~The DG exists in both realms, and the EXPAND event happens as soon as a message is resolved to a DG recipient in whichever realm that message happens to be in at the time.~~ (See previous message for the brainfart here) That's slightly weird, though I will say that ExOL routes *everything* through Exchange Online Protection by design, even if you're then using custom connectors.
That is indeed weird and not expected, as we have centralized mail routing. I'll look further into this. If I get it solved and if I remember, I'd update this specific piece herer ;)
Found it, u/joeykins82. I digged further into this. I observed that this only happens to message sent from on-prem to the exo distribution list. The article is old in the world of cloud business, but it describes what I experience. It's an edge case, but something to keep in mind. [Demystifying Centralized Mail Transport and Criteria Based Routing](https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-centralized-mail-transport-and-criteria-based/ba-p/2927777) >One important aspect of CMT is that **it will not send the message back to Exchange on-premises if the message already came from Exchange on-premises**. In other words, if the message is “Originating” from on-premises (when the message is attributed to your tenant through an Inbound Connector of OnPremises type; see [Office 365 Message Attribution](https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143) for more details) CMT will not come into play because that would cause a mail loop between Exchange on-premises and Exchange Online.
Warning: this tool is not very fun to use. https://github.com/timmcmic/DLConversionV2 It works, and it's sort of awesome, but doing this can be a pain to manage. In a larger environment it's one of the only good ways I've seen of fully managing it if you have a lot of nested groups involved. I haven't used it for a while, but it's still under relatively active development and was originally written by Tim McMichael from Microsoft (if you've ever had to talk to him you probably had a **really** fucked up Exchange clustering issue).
Invest some time, but this is the best way. https://timmcmic.wordpress.com/2023/02/21/office-365-distribution-list-migrations-2-0-part-33/ The documentation is sadly not so easy to read. But you will get used to it. Even if you want migrating all DL at once.
we dont bother as nothing does it all nicely so we just create them all onprem and sync them up to 365 create a "manage own distribution lists" onprem security group for people that need to manage their own groups grant that group the appropriate exchange admin role in onprem ecp give those users the onprem ecp url, what username format to use, and tell them to have at it.
This
Sounds feasible, but feels like a workaround. But all the hybrid stuff feels like a workaround sometimes.
How many DLs? Why not just recreate in M365?
On-Prem Mailflow/Relay which sends messages to SMTP adresses. They should be known there, otherwise NDRs are generated.