How to deal with Dynamic Distribution Groups in an Office 365 Hybrid Scenario

16. November 2017 Technical 0

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):

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:

You can verify the group membership with:

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.

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.


Leave a Reply

Your email address will not be published. Required fields are marked *