Controlling the creation of Office 365 Groups using an Azure Active Directory policy


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

Update (June 2017): Two things have changed since this blog was written. First, Microsoft has moved from the MSOL cmdlets in the Azure Active Directory PowerShell module V1 to the AzureAD cmdlets in the V2 module. The commands used to manage the policy for Groups depends on which version of the module you use (Microsoft’s version for V2 is here). Second, The fourth edition of the Office 365 for IT Pros eBook is now available. This version includes updated information about the policy to control groups along with lots of other information.

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 1.1.117.0 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.

PSCreateGroup

Viewing the Object Id for an Azure AD group

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

Name                        Value
----                        -----
GroupCreationAllowedGroupId A3c13e4d-7083-4448-9224-287f10f23e10 AllowToAddGuests True
UsageGuidelinesUrl
ClassificationList
EnableGroupCreation         False

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”

“value”: “a3c13e4d-7083-4448-9224-287f10f23e10”

}

{

“name” : “EnabledGroupCreation”

“value”: “false”

}

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

Advertisements

About Tony Redmond ("Thoughts of an Idle Mind")

Exchange MVP, author, and rugby referee
This entry was posted in Cloud, Office 365, Office 365 Groups, Uncategorized and tagged , , , , . Bookmark the permalink.

29 Responses to Controlling the creation of Office 365 Groups using an Azure Active Directory policy

  1. Tony you can easily leverage the following list all settings via powershell:
    Get-MsolAllSettings | ForEach-Object Values

  2. Rob Geoghan says:

    Tony,
    Thanks for posting about this new feature. I followed the steps and it worked like a charm. Hopefully Microsoft makes some further progress on controlling and managing the Office 365 Groups that I’ll turn this off. I feel like you must have done some serious digging on technet to find all this new info that probably no MS first line of support will know about.

  3. Robert Allen says:

    Hi Tony

    I have a problem where someone followed this but did not populate the ID for GreoupCreationAllowedGroupID, so essentially I have an odd problem where i can see the tenant level get-msolallsettings with enablegroupcreation set to false, butgroupcreationallowedid is blank. When I re ran with the ID it tells me there is a conflicting object in the directory. Which is probably the default Azure AD. How Can i reset it so that I can target just the group ?

    Regards,
    Rob

    • Why don’t you update the AAD directory setting object with the pointer to a valid DL/group containing the list of permitted users?

      • Hi Tony,
        I was trying this and it really gave me a hard time. In the end i deleted the setting completely and then added the correct group settings. I tested it this morning and it worked fine.Thanks.

        Rob

      • Brian says:

        So, I had the exact same problem as Robert in that my ID for GroupCreationAllowedGroupID was incorrect and was hitting errors when walking back through the steps. Dmadelung has the elegant solution in the comments below, but for anyone else also taking babysteps, our syntax with some pseudocode for adjusting that specific object was:

        $AllSettings = Get-MsolAllSettings
        $Value = $AllSettings.getSettingsValue()
        $Value[“GroupCreationAllowedGroupID”] = “The GroupID for the correct group”
        Set-MSOLSettings -SettingID “The ObjectID displayed from Get-MSOLAllSettings” -SettingsValue $Value

        Thanks so much Tony for putting up this blog, our users and middle managers are much happier.

    • dmadelung says:

      Here is a script to update the settings directly with a designated group:
      $group = Get-MsolGroup -All | Where-Object {$_.DisplayName -eq “ENTER GROUP DISPLAY NAME HERE”}
      $settings = Get-MsolAllSettings | where-object {$_.displayname -eq “Group.Unified”}
      $singlesettings = Get-MsolSettings -SettingId $settings.ObjectId
      $value = $singlesettings.GetSettingsValue()
      $value[“EnableGroupCreation”] = “false”
      $value[“GroupCreationAllowedGroupId”] = $group.ObjectId
      Set-MsolSettings -SettingId $settings.ObjectId -SettingsValue $value

  4. Shiraz says:

    Hi
    This has worked great

    How do i undo do this chang if need be

  5. shiraz says:

    Hi

    Started Working correctly now, without me making changes !!!

    Maybe Microsoft runds some Poershell DSC that could be causing these intermitten issues

  6. Pingback: Azure AD PowerShell: What the version?!? - Max Fritz

  7. Pingback: Mastering management of Office 365 Groups – sharepointworldblog

  8. Mario C. says:

    Unfortunately, this did not work for me. When I issue the “$Policy = Get-MsolSettingTemplate” line from your commands list, I get an error that “Get-MsolSettingTemplate : The term ‘Get-MsolSettingTemplate’ is not recognized as the name of a cmdlet, function, script file, or operable program…”

  9. Mario C. says:

    I downloaded v. 1.1.166.0 and I got the same error:

    PS C:\Windows\system32> (Get-Item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).Versio
    nInfo.FileVersion
    1.1.166.0
    PS C:\Windows\system32> Connect-MsolService
    PS C:\Windows\system32> $Policy = Get-MsolSettingTemplate –TemplateId 62375ab9-6b52-47ed-826b-58e47e0e304b
    Get-MsolSettingTemplate : The term ‘Get-MsolSettingTemplate’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check
    the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:11
    + $Policy = Get-MsolSettingTemplate –TemplateId 62375ab9-6b52-47ed-826b …
    + ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (Get-MsolSettingTemplate:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

    PS C:\Windows\system32>

    Even when I try the article you referenced, I get an error on the second step:

    PS C:\Windows\system32> Get-MsolAllSettings | ForEach Values
    Get-MsolAllSettings : The term ‘Get-MsolAllSettings’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
    spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:1
    + Get-MsolAllSettings | ForEach Values
    + ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (Get-MsolAllSettings:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

    PS C:\Windows\system32>

    I’m not sure what I’m missing.

    • Can you try this on another PC… just to check? I just started a new PowerShell session on my PC and typed the commands below and all worked. I suspect that you might have some environment issues that I cannot debug from here. The clue is that you don’t have access to the cmdlets…

      PS C:\temp> Connect-MsolService
      PS C:\temp> $Policy = Get-MsolSettingTemplate –TemplateId 62375ab9-6b52-47ed-826b-58e47e0e304b
      PS C:\temp> $policy

      ObjectId DisplayName Description
      ——– ———– ———–
      62375ab9-6b52-47ed-826b-58e47e0e304b Group.Unified …

      • Mario C. says:

        Well, it looks like the 1.1 versions of the AD Module that are still available for download don’t have access to these cmdlets.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s