How to deal with Dynamic Distribution Groups in an Office 365 Hybrid Scenario
Dynamic Distribution Groups are not directly “migratable” to Office 365. (Yes, I just made that word up, but now it is a real word–that’s how words are made). In a hybrid scenario, where you have Azure AD Connect synchronizing your Active Directory objects for single-sign on with Office 365, Dynamic Distro Groups simply will not sync.
They don’t sync because they aren’t really the same type of object as a normal distro group. What they are essentially, is a stored query. In other words, members of the group are determined via a query that is run at the time the email is sent to the group. So for example there are some criteria that need to be met (e.g. recipients are located in the “Human Resources” OU). If you meet the criteria at the time an email is sent to that “group,” then you will get a copy of the message. The problem is, Azure AD is not the same as your on-premises AD, and there may be elements of the Directory that do not correspond 1-1, so some queries wouldn’t really be able to execute in the same way.
Therefore, if you want to keep your Dynamic Groups, then you have to keep them on-premises. Your other options are to manually re-create them in the cloud. Or another alternative is, convert them to normal distribution groups and then synchronize them that way. But, if you’re keeping Dynamic Distribution Groups on-premises, how do we get mail delivered to them, once we migrate mailboxes to Office 365? Remember: Azure AD is not aware of these objects, so how can we ensure mail delivery still happens? Like this.
Step 1. Ensure you have cross-premises mail flow enabled
If you have a full hybrid environment, this should already be the case. Just make sure you can send mail from an on-premises mailbox and receive it in the cloud, and vice-versa. If not, re-run the Hybrid Configuration Wizard again, and also check the setting for your email domain name in mailflow > accepted domains from the Office 365 EAC. Switch it from Authoritative to Internal Relay.
With the Internal Relay option, if Office 365 doesn’t know what to do with a message, it will forward the message back down to your on-premises server.
Step 2. Create contact objects in Office 365 that correspond to the groups
Office 365 needs to have a contact object that matches the on-premises dynamic group. This is very easy. Just make sure that you use the same Display Name, alias and email address for the contact as you have already for the on-premises group. Go to recipients > contacts, and create a new contact.
Step 3. Ensure that the on-premises group is able to send to all recipient types
Sometimes these groups are created with the option to allow sending only to users with Exchange mailboxes, rather than external users or contacts. Since these users are no longer on your Exchange server (if they have been migrated to Office 365), then you need to ensure the group can contain recipients of different types. The easiest way to do this is to just select All recipient types.
And that’s basically it. When mail is sent from a cloud-based mailbox, it will check the GAL and find this contact. Since the mailbox or group does not exist in Office 365, it will assume that the on-premises server has the right object, since it is authoritative for the domain. When the message is delivered on-premises, the query will execute as usual against the local AD. The local Exchange server will then send messages out to the right recipients (which can be on-premises or in the cloud).
How to convert dynamic groups to normal distribution groups
If you’d rather just not deal with dynamic groups and cross-premises mail flow (since this does leave a dependency in place–the on-premises Exchange server must be online for dynamic groups to function, which isn’t ideal in many small business situations), then you can also just convert your dynamic groups to normal ones. For this, we require a bit of PowerShell magic.
First, create a variable to store the members of the dynamic group. (Replace the group name as needed):
$DynGroup = Get-DynamicDistributionGroup "Human Resources" $DynGroupMembers = Get-Recipient -RecipientPreviewFilter $DynGroup.RecipientFilter
You can run that Get-Recipient piece to see the members yourself, if you like, also. But that group membership is now stored in the variable DynGroupMembers. Next, create a brand new distribution group with a temporary name, and then add the members to that group, like this:
New-DistributionGroup HRTempGroup $DynGroupMembers | foreach {Add-DistributionGroupMember HRTempGroup –Member $_.Name}
You can verify the group membership with:
Get-DistributionGroupMember HRTempGroup
One more step that is applicable to some environments, if you have any legacy X500 addresses associated with these dynamic groups, you might need to bring that over and apply it to the new group as well.
Get-DynamicDistributionGroup "Human Resources" | fl LegacyExchangeDN
If this returns a result it will need to be added as an alias to the new group, after the old one is deleted. Since you’ll be deleting the group, you can’t really have this command in a variable for later use, so just copy / paste it into notepad for easiest access later (probably some other PowerShell wizard out there can do better than me here).
Last step is, just delete the dynamic group and rename the new one to whatever the old one was, and you’re all set. When Azure AD Connect runs its next sync cycle (or you run a manual sync) these objects should show up in Exchange Online.
Comments (32)
Thanks for the how-to. The problem with regular groups is not being able to prevent users from expanding the group in Outlook to view members.
I guess the only way to truly prevent this, without registry modifications, is to keep the Dynamic group on-prem ?
That is one way to do it, you can also try re-creating the group manually in Office 365 via PowerShell. Here is an example from BitTitan.
Thanks for the well written explanation.
Great work-around, and your steps are working for our two dynamic groups–but not entirely.
Our scenario is complicated by the fact that we have a standard distribution group that has two dynamic groups as its only members. Because the “parent” group is sync’d to the cloud, it behaves as if it has zero members, so mail sent to it from a cloud mailbox goes nowhere. We created the cloud contacts for the two dynamic groups, and confirmed that mail sent directly to them from a cloud mailbox is now delivering successfully, but trying to add the contacts to the parent distribution group fails because the group is sync’d from the on-premises server.
Any suggestions on how this might be addressed?
Interesting problem. I thought I may have read about another situation like this at some point online, but I can’t remember where that was. I wonder though if it would be as simple and excluding that standard group from syncing? Like in an OU that does not sync? That might free you up to create a new group in the cloud by the same name… But there may be a more creative solution than that, too. Let us know what you come up with!
Your parent group which I am guessing is a static distro is probably sync from on premise to ExO via AADC. If you look at it on-prem, you see the dynamic groups as members. If you look at it in ExO it is empty b/c the two dynamic groups don’t exist in ExO. Because the dynamic groups don’t synch via AADC, They “disappear” in the ExO. This causes a cascading impact. Ultimately, you have to delete your groups on-prem and recreate them in ExO if you want mail to flow correctly. If you are in Hybrid mode and don’t plan to ever exit, you can create a contact in ExO for you parent group. Then any mailboxes in ExO who email that static group will send to the contact, which will send to the group on prem where it get’s expanded and sent back to ExO. Most people don’t want to stay in Hybrid perpetually, so this isn’t really a great option. I’ve run into this more than once.
For long-term (getting off on-prem dependency), yes you should delete object on-prem and re-create
Alex–
Thanks much for your response. The solution (for us) occurred to me right after I posted. I deleted the standard distribution group and recreated it as a dynamic group, using filtering criteria specific to the two dynamic group members (used a CustomAttribute field). Then it was just a matter of repeating your solution of creating a cloud contact to “stand in” for the new dynamic group. We had to wait for our Outlook clients to update their address books with the change (forcing it isn’t always successful), but after that it’s working fine.
Thanks again for your help.
Dimarc67
Hi Alex,
If I created dynamic group on O365 side – which steps need to be done to have chance to expand the group members in Outlook? Many thanks. Tom
Just a question. What if the dynamic group was created in O365. Can we do the same by creating a mail contact in on-prem?
yep; another option is to switch the accepted domain to internal relay, then if Exchange cannot find the object it will relay it to the authoritative server (at 365)
Hi Alex,
I tried this and it seems to be working fine but only for users on Exchange Online. Users who are still on prem and are included in the Dynamic distribution group via an extensionattribute don’t receive the mails. I checked the dynamicdistributiongroup members with get-reciptient and all users who should be in there are. the extensionattributes are well synced to EO.
I must be missing something but I can’t seem to figure out what it is.
Can you see the same recipients in Exchange Online and on-premises, or do the lists diverge in any way?
Great explanation, you’re a savior! Just one question: we want to have external users in these on prem dynamic groups with external email addresses. They do not have a mailbox in our domain, neither cloud nor on-prem. Their proxyAddress attribute in AD cannot be filled and is empty (weird internal reason), we can only fill the mail and targetAddress attribute for those with the external email address. Will this be enough to get mails sent to them externally from the group?
Thank you!
Good question–I assume yes that would be adequate–the query happens on-prem and if the query can return a value for where to send mail then it should work. Let us know what you find out!
Great post, thanks. A couple of questions:
1) Why do you need to create the contact in 365, if you are also setting the domain to internal relay? Wont it automatically forward emails down to onprem without the contact in place?
2)In the scenario you already have the onprem domain set as Internal Relay (as per full hybrid wizard) so that any emails sent to a cloud-only resource will be forwarded up to 365, but also need to get 365 emails routing back down to onprem dynamic groups as per your post, will it result in issues configuring the O365 domain to be internal relay as well? Or is it ok both sides are internal relay? I imagine you need to make at least one authoritative. My guess is you are best to re-create the dynamic group in 365 and keep the 365 domain as authoritative – but keen to hear your thoughts.
Yes, with Azure AD Premium P1 you can get dynamic groups and just recreate them in the cloud–that would be even better.
Thanks Alex, any idea on Q #1? Cheers
In theory that should work, however I have found that the contact method is advisable. I am pretty sure I tried without and it wasn’t successful, but it has been a long while since I dealt with this issue.
Hi Alex
Is it possible to create a dynamic distribution groups according to user O365 licence type?
In Azure AD to create a dynamic group requires Azure AD Premium P1. However in Exchange Online I do not believe this is a requirement, to create a simple ditro list.
Hi,
I am facing an issue regarding Dynamic Distribution Group in Exchange 2013 based Hybrid environment – during my research i reached out to this link.
so i thought to reach out to you, may be if you can help – well, my scenario is that my migrated users of Office 365 can’t send email to Dynamic Distribution Group (DDG).
I have created a contact in Office 365 as per your article so that users’ can select On-Premises Dynamic Distribution Group and then email can be routed to On-Premises DDG as suggested in your article. After doing this, as soon as any user from Exchange Online send email to DDG group by selecting contact from address book – Exchange Online users get this error:
“Your message to [email protected] could not be delivered.
DDG1 wasn’t found at abc.com”
Please note that Exchange Online (EXO) users were getting the same error – when i hadn’t created the mail contact – so even after following all three steps as per your article. EXO users still getting the same error.
Please also note that in On-Premises there is SMTP device where MX is pointed currently but normail email flow is fine. Please suggest, how to fix this problem.
Thanks.
And you have verified that mailflow works between orgs, and that the accepted domain has been flipped from authoritative to internal relay? Remember that you also have the option of re-building your dynamic groups in the cloud, too.
Hi Alex,
Yes, domain is marked as Internal relay. Well, we don’t want to rebuild Dynamic groups as we still have many users to be moved to EXO. Any other idea please? Thanks.
Call MSFT support.
How you can create a contact with the same external email address, it will just error and tell you it already exists.
The dynamic group must not be in scope of sync, you create the object in the cloud, not on-prem, and it should have no problem.
looks like EXO can now handle dynamic distribution lists…
https://docs.microsoft.com/de-de/exchange/recipients-in-exchange-online/manage-dynamic-distribution-groups/manage-dynamic-distribution-groups
Correct, it can. There are certain dynamic groups on-prem that cannot be “re-created” in the cloud however, for example if you have a group that is composed of mail users who belong to a specific OU (there is no such thing as an ‘OU’ in the cloud).
We have been creating DDG on premise and they seem to sync but show as a mail contact in o365. Maybe azure ad sync started doing that at some point but we are sure we never manually created a contact.
Thank you – this fixed an issue with some new Dynamic distribution groups we created that weren’t receiving external emails. These Dynamic Groups are created on-prem using PowerShell scripts – is there a way to complete the O365 contact creation outlined in Step 2 using PowerShell as well? I’d love to just include this step in the PS script if possible, rather than manually adding the O365 contacts after the fact.
I wish our contractor had given us other options in 2017. We have external email going to a 3rd party MX, which relays to hybrid, which handles 400+ DDGs split among 100 remote offices, which relays directly to all mailboxes in O365. All primary addresses related to the DDGs are setup as O365 contacts, which causes messages to be relayed to the internet and back into the hybrid, instead of going direct to hybrid. Perhaps pointing the MX directly to M365 and letting the cross-flow email handle the DDG expansion would smooth out our phishing false positives generated in Defender for O365 also.