Migrating Distribution Groups to Office 365, part 5

In the previous installments of this series on migrating distribution groups from Microsoft Exchange on-premises to Exchange Online, I covered these four steps:

Part 1 – Overview of the process I used to migrate my Exchange distribution groups to Office 365.
Part 2 – Exporting your on-premises distro group settings to CSV files.
Part 3 – Importing your group settings from the CSV files to Exchange Online.
Part 4 – Renaming and addressing your online distro groups.

Now, in Part 5, I’ll talk about rebuilding Dynamic Distribution groups online.
This step is much simpler than the others, primarily because I didn’t have enough Dynamic groups to justify putting a lot of time into writing Powershell scripts. I only had about two dozen of them, so it was just easier to create the groups and configure them using the Exchange Admin Center graphical interface. It was tricky in one important respect, though:

Dynamic groups in an on-premises Exchange organization can be based on your Organizational Unit structure. In Office 365, you can’t do that. You’re restricted to these mailbox attributes:

1. State or Province
2. Company
3. Department
4. Custom Attribute (1-15)

The custom attribute fields can be very powerful if you are using a lot of automation for onboarding and account management (I am), but the one field that approximated OU more closely than any other for me was Department. It wasn’t an exact match, so I had to do a little work to make it fit.

Migrating distribution groups to office 365, part 5: Recreating dynamic distribution groups in the cloud.First, I created a regular group with the same name and email address as the old dynamic group. We’ll call it “HR – All Employees”.

Second, I created a dynamic group that included with the relevant department name, in this case “HQ Human Resources”. (You can include multiple department names in a single dynamic group, but, unfortunately, you can’t use an “exclude” statement. Combined with the Custom Attribute fields, that would have made these groups much simpler to configure.) We’ll call this one “HQ Human Resources dynamic group”.

Third, I made “HQ Human Resources dynamic group” a member of the “HR – All Employees” group from step one. You can add multiple dynamic groups to this top level distro group. For example, if you had a separate recruiting department, you could create a dynamic group for the “HQ Recruiting” department and add it to the “HR – All Employees” distro group. Rinse. Repeat.

Fourth, I added any obvious exceptions from the original on-premises OU–people with a department name of “Multi-Site HR Taskforce”, for example, because there are users in multiple OUs with that department name, and we can’t exclude people from the wrong OU–to the “HR – All Employees” group.

Finally, I set an owner on “HR – All Employees” and explained to the owner that he never needs to add anyone with a department name of “HQ Human Resources” to this group. It’s already done for him by the “HQ Human Resources dynamic group”! All he needs to do is add the oddball employees who have some other department name.

I toyed with the idea of hiding the dynamic group from the GAL, but then the regular distro group owner would very likely forget that it existed and add all of those employees to the regular group manually. This wouldn’t hurt anything, but would duplicate effort and defeat the purpose of the dynamic group.

And there you have it. All of my groups have been migrated to the cloud. There was some confusion, but the added benefit of the group management tools available in Office 365 more than made up for the pain.

Leave a Reply

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