This text is an extract from Chapter 9 from the eBook “Office 365 for IT Pros”. This is an example of how we incorporate new events quickly into the publishing process and make new content available to readers. In this case, the General Availability of Office 365 Planner (announced by Microsoft on June 6 and covered in Chapter 10) served as a catalyst for the change in how policies control the creation of Office 365 Groups. We were able to test, assess, and document within a day and release new files to customers of ExchangeServerPro.com. For more information about Office 365 for IT Pros, see ExchangeServerPro.com (for PDF and EPUB versions and some bonus material) or Amazon (for the Kindle version).
Implementing a policy to control the creation of new Office 365 Groups
In November 2014, OWA was the first client to support Office 365 Groups. It was therefore logical that the developers chose to add a new setting to OWA mailbox policies to limit the creation of new groups. When a user attempts to create a new group, the setting (GroupCreationEnabled) contained in the OWA mailbox policy assigned to the user’s mailbox is checked. If the setting is $True, creation is allowed. Conversely, if the setting is $False, creation is blocked. Remember that a tenant can have several OWA mailbox policies active at any time, so it is quite normal to have an OWA mailbox policy that allows all options, including group creation, and others that are more restricted. OWA mailbox policies are applied to mailboxes by editing their properties through the EAC or by running the Set-CASMailbox cmdlet.
The downside of using an OWA mailbox policy is that it is a method specific to Exchange Online, where it is used to control the options available to users in the OWA client. As time went by and integrations with Office 365 Groups appeared that had no relationship with Exchange, the fact that OWA mailbox policies exist was ignored and any user was able to create new groups through these integrations. This is true for Power BI, Dynamics CRM, and Office 365 Planner, and when new groups are created with PowerShell.
Clearly, a new answer was required. The General Availability of Office 365 Planner on June 6, 2016 provided the opportunity to change the control mechanism to a policy stored in Azure Active Directory. The advantage of this approach is that Azure Active Directory provides a central point that all Office 365 applications can check. After a suitable policy is created, control over the creation of new Office 365 Groups is consistent everywhere. That is, once applications have been upgraded to use the new approach.
Follow these steps to create and implement a suitable Azure Active Directory policy to control group creation.
Create a group containing the set of authorized users: Azure Active Directory needs to be provided with a set of users who are allowed to create new Office 365 Groups. To define the set, you create a new group using the Office 365 Admin Center, PowerShell, or the Azure Active Directory console. The group can be a distribution group or an Office 365 Group.
Add the set of authorized users to the new group: You can add as many or as few users as you want. Because Office 365 Groups only exist in the cloud, the users who create Office 365 Groups should have cloud accounts. You can’t add a group to this group as only individual accounts are accepted. Users who hold certain administration roles for the tenant do not have to be added to the set of authorized users as the role automatically allows them to create new Office 365 Groups. These roles are:
- Company Administrator
- User Account Administrator
- Mailbox Administrator
- Partner Tier1 Support
- Partner Tier2 Support
- Directory Writers
Prepare to edit the Azure Active Directory policy: The policy that controls group creation is also referred to as a directory settings object. As the default mode of operation allows any user to create a new Office 365 Group, the intention behind the new policy is to disable the ability of users to create groups by limiting creation to a set of users defined in a specific group. Because no UI exists for this purpose, you have to create the policy and populate its settings using PowerShell. Version 188.8.131.52 or later of the Microsoft Azure Active Directory Module for PowerShell (or later) contains the required cmdlets. As per the release history, this is a preview version of the module. To check what version you have, run the following command:
[PS] C:\> (Get-Item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\ Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion
Next, you need to retrieve the object identifier (ObjectID) for the group that contains the set of authorized users. The PowerShell module for Azure Active Directory uses GUIDs to identify directory objects instead of display names. You can run the Get-MsolGroup cmdlet to access the object identifier for the group, but it’s easier to retrieve the information using the Azure Active Directory console to view the properties of the group (see screenshot). The object identifier is the last field shown for the group properties. Note the Copy icon to the right of the object identifier. Click this to copy the value of the object identifier to your clipboard.
Use PowerShell to update the Azure Active Directory policy: Open a PowerShell session and execute the commands shown below. The commands identify the template that you want to use to create the new directory settings object that will govern group creation for the tenant, and then identify the group containing the set of users who are allowed to create new Office 365 Groups. The object identifier for the template you’re updating is consistent across all tenants. You can see that the object identifier supplied to update the template is the one copied from the group properties as shown in the screen shot.
[PS] C:\> Connect-MsolService
[PS] C:\> $Policy = Get-MsolSettingTemplate –TemplateId 62375ab9-6b52-47ed-826b-58e47e0e304b
[PS] C:\> $Setting = $Policy.CreateSettingsObject()
[PS] C:\> $Setting[“EnableGroupCreation”] = “false”
[PS] C:\> $Setting[“GroupCreationAllowedGroupId”] = "a3c13e4d-7083-4448-9224-287f10f23e10"
[PS] C:\> New-MsolSettings –SettingsObject $Setting
Once the commands complete, a new directory settings object exists that contains the values needed to control group creation. Any application that can access Azure Active Directory is able to check the settings and take the appropriate action to allow or deny a user the option to create a new Office 365 Group. To verify that the change is effective, run the following command:
[PS] C:\> Get-MsolAllSettings | ForEach Values
Alternatively, you can use the Microsoft Graph Explorer to check the settings. Log in using your tenant account and enter https://graph.microsoft.com/beta/settings into the navigation bar and “beta” into the drop-down option list on the right-hand side. You should then see a set of settings data returned, including the values for the Object Id of the group containing the set of users who are allowed to create new Office 365 Groups and the setting that blocks general creation.
“name” : “GroupCreationAllowedGroupId”
“name” : “EnabledGroupCreation”
Test that the new policy works: A user who is included in the authorized user group should be able to create new Office 365 Groups from the integrated applications (Planner, Dynamics CRM, and Power BI), and the Outlook Groups mobile app. A user who is not included should see an error message if they attempt to create a new group (something like “The group couldn’t be created. Your admin hasn’t given you permission to create a new group”).
It will take a little time for all of the applications and clients to fully support the new method and provide the necessary UI and that time will differ from tenant to tenant depending on the release cadence they follow. In particular, the MSI version of the Outlook 2016 desktop client will take time to be updated and then deployed to client desktops. However, the old OWA mailbox policy method continues to work for OWA and Outlook until superseded by the new method.
Follow Tony @12Knocksinna