Back in May 2015, during the Microsoft Ignite convention, there was a session called “Evolving distribution lists with Office 365 Groups” (available online). The session described the integration with Outlook 2016 (no plans exist to back port the technology to Outlook 2013) and then went on to investigate how Microsoft views Office 365 Groups as a better alternative to old-style distribution groups. Distribution groups have been around since the dawn of email; however, this is the first time since the introduction of dynamic distribution lists in Exchange 2003 that Microsoft has improved their distribution models.
A major issue with Office 365 Groups is that they will only live in the cloud. Microsoft is not going to incorporate them into the on-premises version of Exchange. You’ll be able to synchronize Office 365 Groups with on-premises Exchange via AADConnect if you operate a hybrid environment, but you won’t be able to create these groups on-premises.
Office 365 Groups are moving in this direction to create autonomy within the Office 365 "ecosystem" as a single entity that permits access to many different forms of data available within the service. Today, membership of an Office 365 Group allows a user to access a shared mailbox, shared calendar, shared OneNote notebook, and a document library. The signs indicate more resources will be accessible in the future through group membership.
Speaking of which, keeping the content of an eBook about Office 365 requires you to pay a lot of attention to what Microsoft is saying to customers at conferences. A speaker may provide information not included in the book or information that changes the book’s content. In this case, I was interested in how the speaker of the session mentioned earlier in the article, Alfons Staerk, approached the topic of migration from old-style distribution groups to Office 365 Groups.
It looks as if customers will be left to their own devices to migrate distribution groups as they wish. Of course, distribution groups bring their own complexities to the table. The process of how you should deal with nested groups, for example, presents a couple big questions: What do you do with groups that include mail-enabled public folders, mail contacts, and shared mailboxes in their membership as none of these objects are supported in Office 365 Groups? Since Office 365 Groups use their own mechanism to access resources across different parts of the service, what do you do with mail-enabled universal security groups?
Microsoft demonstrated a program called “Hummingbird” that can migrate a distribution group to an Office 365 group, subject to the caveats expressed above. Apparently, the source code of the program will also be available to allow user independence.
The approach taken to migrate a distribution group with a PowerShell script was more interesting. Until recently, the PowerShell support for Office 365 Groups was just plain bad. You couldn’t create a new group or update group membership, both of which seem like fundamental operations. Microsoft has recently implemented a new set of cmdlets to Office 365 tenants that address the problem. These are the *-UnifiedGroup cmdlet set to maintain group objects and the *–UnifiedGroupLinks cmdlet set to maintain group membership. A list of the cmdlets can be found here.
The script shown by Alfons was rudimentary but effective for very simple distribution groups whose membership is solely composed of mailboxes. Everyone loves a challenge, and apparently, Microsoft MVP Tony Redmond decided that it would be a good thing to develop a script about that uses the new cmdlets to work with Office 365 Groups. What he created is a script called ConvertDLtoO365Group.ps1. Mr. Redmond based all the script from information discussed in the second edition of “Office 365 for Exchange Professionals”
"I’m no programmer, but the joy of PowerShell is its ability to put things together bit by bit until something really good is done. PowerShell is like Lego bricks in that respect."
I hacked my way through several versions of Redmond’s script and have made several modifications of my own for various purposes. Mr. Redmond's current version is available in the TechNet gallery for anyone to download (and hopefully improve). The script runs in the context of a PowerShell session that is already connected to Exchange Online and does the following:
- Takes the alias or name of a distribution group as the input parameter.
- Performs some initial checks to see whether the distribution group exists or an Office 365 Group with the same alias exists. And that it’s an object of type MailUniversalDistributionGroup, which is the only type we can convert.
- Checks the members of the input group to strip out those that can’t be added to the target Office 365 Group.
- Checks whether the input group has member join restrictions. If it has (the group is “Closed” or “ApprovalRequired”), the admin is prompted to decide whether they want to create a private Office 365 Group. You can’t currently change the group type, so this is an important decision.
- Tells the admin what’s happening and asks to proceed.
- The new Office 365 Group is created with the New-UnifiedGroup. It uses the same alias as the input distribution group because a new alias is given to that group.
- As many of the properties of the input distribution group as possible are moved to the new Office 365 Group (not all can be because there isn’t a direct 1-to-1 mapping between the two object types). The Set-UnifiedGroup cmdlet is used for this purpose.
- The Office 365 Group is set to auto-subscribe new members so that it mimics the distribution of new content via email as members expect from a distribution group.
- Membership is added to the new Office 365 Group using the Add-UnifiedGroupLinks.
- Group members can be in three sets of links (owners, members, and subscribers). Because the new Office 365 Group is intended to behave like an email distribution group, the members are added to the members and subscriber’s sets.
- The owners/managers of the input distribution group are added as owners of the Office 365 Group.
- The email address of the input distribution group is switched to the new Office 365 Group so that new traffic goes there.
Phew! That’s a lot of processing. There are some known issues. For example, the –AccessType parameter for the New-UnifiedGroup cmdlet doesn’t work at present, so only public groups can be created. This is a known bug and is being fixed by Microsoft. Another issue is that running Add-UnifiedGroupLinks to add mailboxes as subscribers doesn’t work. This bug is also known and a fix will be available shortly.
However, the point is that it’s a PowerShell script and because it’s a script the code is there and available for all to see – and hopefully improve.
I have also come up with another approach to doing these conversions as well, one in which you would prestage your Office 365 groups, add the members and owners, and then slowly transition the Groups at a time that is convenient to you. Expect to see another blog from me soon that will later go over this method in more detail.
A shout out to Mr. Tony Redmond for the countless number of scripts in the TechNet gallery he has provided and kudos to Mr. Alfons Staerk for the awesome presentation he gave at Ignite last year.