I recently ran into a customer that uses: Distribution Groups (DG), leverage Dynamic Distribution Groups (DDG), have started their move to Exchange Online (EXO), while nesting several DDG's inside of DG's.
There are known work arounds that you should implement if you are in an Exchange hybrid configuration working with DDG's. Since each realm bifurcates the message at transport based on the LDAP query with the Active Directory it is using, you need a contact in the other realm to send the message cross premises for that LDAP service; Active Directory Directory Service (AD DS on premises), or Azure Active Directory (AAD in O365), to compile the list of names that the DDG is to deliver each message.
So far so good, most of you already know this process. Now the interesting part, this customer I worked with nests DDG's inside of DG's. This is fully supported and something customers can organize. In fact, I like the option of nesting groups inside of other groups. This nesting can make many processes within an organization easier to manager. For example: User > Department > Division > All employees. Now I know most people do not leverage this nesting for many reasons, one of which is that you can create a nesting loop (Group A > Group B > Group C > Group A) and that can cause issues. The good news is from an Exchange perspective, the application can detect recipients in loops and has logic built in to handle the situation: harmless recipient loops and broken recipient loops.
Back to this customer, they have a DG, let us call it 'Denver Region' and they have a DDG that queries against a users' office value of 'Denver', which is nested inside of the Denver Region DG. I can see the request for this, as sometimes end users (managers for example) may want to be part of the DG, yet also be part of a their own regional DDG. Hence, they nested the DDG inside of the DG.
Again, so far so good and no problems. Enter Exchange hybrid and the customer maintains both the DG and DDG on premises. Now the issue, the cloud DG has the on premises DDG nested inside, and therefore is not able to bifurcate any messages from within the cloud, so the DDG fails when a user in EXO sends a message, this is by design. Easy enough, create a contact in the DG of the DDG in the cloud. However, the contact must reside on site as the DG is still an onsite DG. Exchange won't allow you to add a contact with the same SMTP address in the organization as the DDG already has that SMTP address. So just create the contact in O365. Again, since the DG onsite is the authoritative source, it removes the contact from the cloud group. Sigh.
You'll have the same issue if you move the onsite DG to EXO and convert the DG to an O365 group to have the write back process update the group on premises. You'll need a contact in EXO, which again, isn't allowed with the same SMTP address as the DDG. Consequently, what are you going to do?
The solution
Here's what we came up with, create a user in AD DS, mailbox enable it on premises, and then forward all messages to the on premises DDG. This allows the onsite DG, with the onsite DDG, and an onsite user, with a different SMTP address than the DDG, to forward all messages to the onsite DDG. When the DG gets synchronized to EXO, the DDG is there, which will fail, but the forwarding user is also there in the group and EXO will send messages to that user, which then forwards the message to the onsite DDG, and thus, allows AD DS to bifurcate the message, send the Exchange LDAP query to AD DS, which then can bifurcate and deliver all messages, even if the content must be sent back up to an EXO mailbox. Easy peasy.
The good news is, it took you longer to read this and understand why you need this additional user, then it is to create the user and set the forwarding settings. I hope this provides a work around that is available for anyone in Exchange Hybrid deployment and needs to work with nested DDG's inside of DG's. Thank you.
Screen shots in Exchange
User: mailbox features
Setting delivery options:
