In this post of the Office 365 Groups for Admins series we will take a look at how you as an admin and your end-user can create Office 365 Groups. The option to allow end-users to create Unified Groups or not are determined by the Mailbox Policy, as described in a previous post.
End-user creation of Office 365 Groups
End-users have two ways of creating new Groups; either use the Office 365 web interface or using Outlook 2016 (works on the PC edition, not sure about Office on Macintosh). This is option is by default available for ANYONE within your organization, there is no granularity at all, there is no approval or anything.
In the web interface there are several entry points to Groups, most of them have a "plus" icon that allows the end-user to start the new Groups wizard and create a Group.
Unfortunately this "plus" icon is present even if Groups creation is disabled. The end-user will not notice that he/she is prohibited to do it until they actually create the Group and are met with an access denied. Bad UX design Microsoft…
In Outlook 2016, the end-user right clicks on the Groups heading in the right hand pane and choose "New Group". A similar wizard as the web interface is shown and the user can create a Group.
The Office client team got it. If Groups creation is disabled, the New Group option is actually greyed out…
Creating Groups using PowerShell
Administrators can create Groups using PowerShell. It is an simple operation and might at this point in time actually be the best option for you to create Groups. It allows you to have
full more control over the creation and the Group properties.
To create a Group all you need to do is to establish a remote session to Exchange Online and then use the New-UnifiedGroup cmdlet. One might think that issuing a get-help command on that cmdlet would show some information on how to use it - not really the truth (on a side note the help information might tell us where the product group are heading).
# Connect to EXO $creds = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange ` -ConnectionUri https://outlook.office365.com/powershell-liveid/ ` -Credential $creds -Authentication Basic -AllowRedirection Import-PSSession $Session New-UnifiedGroup ` -DisplayName "Group: Project X" ` -Alias "unifiedgroup-project-x" ` -EmailAddresses "firstname.lastname@example.org" ` -AccessType Private Remove-PSSession $session
This is basically what you can do with this cmdlet:
- DisplayName: the display name of the group. This cmdlet does not take the Group Naming Policies into account so you can and should use a proper naming standard here.
- Alias: the Exchange alias. Using this property is the only way to control the Alias of the group
- EmailAddresses: The e-mail address of the Group. This does NOT have to be the default domain, as used when created from the UI. You can use a separate or dedicated domain for this
- AccessType: This can have the value of Public or Private.
Note: the Name property, in Exchange, for any Group created using the UI or PowerShell will be suffixed with "_<10 digit hex numer>". Creating a Group using the Office 365 Unified API's does not append this…
Once this command is invoked it will return fairly quickly and you can access the Exchange part of the Group. Things like Files will take another couple of minutes, it's SharePoint you know…
Once we've created a Group we can further configure it, but we'll take a look at that in the next post in the series.
Creating Groups using the Office 365 Unified API
We have a third way of creating Groups and that is through the Office 365 Unified API's. I will get back to this in a later post when we talk about this API specifically.
After reading this post and the other posts in the series, you should no longer be afraid of Office 365 Groups. You can enable it for everyone to create Groups as they want, and you can do the cleaning afterwards. Or you can put the Group creation into the hands of your Exchange or Office 365 Admins and let them create the Groups using a PowerShell script. Create a SharePoint list (an InfoPath form?), an approval Workflow and just automate it? Just as we have to do with SharePoint sites, anyways…
The experience, for everyone, will be way better than the default one.