Disable Office 365 Groups Creation


Update: There are new cmdlets available for this task.  This blog is for historical reference only.  A new, updated process is available here (https://blogs.technet.microsoft.com/undocumentedfeatures/2017/04/29/disable-office-365-groups-creation-redux/).

Office 365 Groups are a (somewhat) new feature that act both like a distribution list and a public folder.  The underlying technology is a SharePoint site mailbox.  The problem with a Public Folder is that ... well, it's a public folder. We've honestly been trying to get rid of them since about 4 minutes after we introduced them.  I remember seeing an internal memo that said, "yay! we migrated off the last public folder!"

The problem with a distribution list is that if you get added after the most important message of the year was sent, you'll never know you missed the most important message of the year.  More than likely, you'll still have that guy who does a Reply-All to a distribution list, so won't be totally screwed.

However, some organizations may make the decision that they're not ready for wide-spread consumption of groups (maybe they don't understand how to administer them, haven't devised a governance plan, or just aren't really sure what the best method to drive their usage is).  For that, we can go ahead and disable them.  There are several features that use groups (Exchange Online, PowerBI, Teams, and the new Planner), so you'll want to disable them across the board.

You'll need two things:

Let's say you don't want to fully disable the groups, but want to block end-users from creating them through OWA and want to leave the power of Office 365 Groups up to Global Admins to figure out.

** Update **

I'm going to break out the script lines, since these are new cmdlets and a new way of administering some of the settings.

If you haven't already downloaded the Preview version of the Azure AD module, please follow the above link to get it.  The Get-MsolAllSettingTemplate cmdlet is only available in that module.  Then, connect to Office 365.  You can do so using the following:

Import-Module MSOnline
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
-Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
Connect-MsolService -Credential $UserCredential

"Office 365 Groups" are a new type of object, and the configuration parameters for it are viewed in the Get-MsolAllSettingTemplate cmdlet:

o365-groups1

Digging further into the cmdlet for the Group.Unified object, you can see some more details:

o365-groups2

The parameters that we need to modify are called "EnableGroupsCreation" and "GroupCreationAllowedGroupId." Unfortunately, it's about as clear as mud as to what we need to do here--especially since there's no "Set-MsolAllSettingTemplate" or anything of that nature.

Digging yet deeper, we can see that there are some method and properties vailable if we pull the setting into a variable, the most interesting being "CreateSettingsObject" and "Values."

o365-groups3

On a whim, I decided to see what else I could see in Values:

o365-groups4

Values contains the parameters that we're going to set and type of data they will contain.  GroupCreationAllowedGroupId is a System.Guid, and then EnableGroupCreation is a Boolean (true/false).

We want to define the group that will be allowed to create Office 365 groups (I'm going to choose Global Administrators).  We actually need the ObjectID (remember, the type was "System.Guid") of the Global Admins role to complete this task:

$GlobalAdmins = Get-MsolRole -RoleName "Company Administrator"
$GlobalAdminsObjectID = $GlobalAdmins.ObjectId.ToString()

So, to set those parameters (EnableGroupsCreation and GroupCreationAllowedGroupId), we need to create a new settings variable, and then add the values that we want to set to the variable.

o365-groups5

From there, we'll be able to apply those new settings to the tenant with the New-MsolSettings cmdlet.

o365-groups6

The last setting we'll need to modify is the OWA Mailbox policy.

o365-groups7

Putting it all together:

Import-Module MSOnline
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
-Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
Connect-MsolService -Credential $UserCredential
$GlobalAdmins = Get-MsolRole -RoleName "Company Administrator"
$GlobalAdminsObjectID = $GlobalAdmins.ObjectId.ToString()
$template = Get-MsolAllSettingTemplate | where-object {$_.DisplayName -eq "Group.Unified"}
$setting = $template.CreateSettingsObject()
$setting["EnableGroupCreation"] = "false"
$setting["GroupCreationAllowedGroupId"] = $GlobalAdminsObjectID
New-MsolSettings -SettingsObject $setting
Get-OwaMailboxPolicy | ? { $_.IsDefault -eq $true } | Set-OwaMailboxPolicy -GroupCreationEnabled $false

If you'd like to have a group of users (such as global admins) have access to be able to create Office 365 groups in OWA, you can simply create a new OWA Mailbox Policy with -GroupCreationEnabled set to $true and assign that policy to group creators.

Additionally, here's a little bit of updated info on the support site:

https://support.office.com/en-us/article/Control-who-can-create-Office-365-Groups-4c46c8cb-17d0-44b5-9776-005fced8e618?ui=en-US&rs=en-US&ad=US

http://robsgroupsblog.com/blog/configuring-settings-for-office-365-groups-in-azure-ad

 

Comments (36)

  1. John says:

    Frankly, NO THANKS!

    When you post something like this you need to make sure that you include everything everyone needs to actually use the script! After you download the latest Azure AD PowerShell module, you have to load the module. For this module it's "Import-Module MSOnline" which the download page (your link above) does NOT identify. Then you have to invoke the connection with a Connect-MsolService (also not included in the Azure AD Powershell page, but can be found all over the place as to actually how to use it.)

    The next thing anyone would do is to walk through the script one line at a time, and of course "Get-MsolAllSettingTemplate" isn't part of that Module. That's where I stopped with this out of sheer frustration. What MODULE is this part of? What OTHER Modules will we have to load to run this?

    Part II

    Groups themselves. The default behavior is that ANYONE can create a group named ANYTHING! Of course there is a "blocked words" feature in the Group Naming Policy that you can configure, but you have to think of the names yourself rather than a "check here for removal of common offensive language"

    That means that anyone by default can create a Public group called "TheCEOisa@#$#@$Idiot@companyname.com"

    This is one of the most poorly executed conceptions of a feature I've seen by Microsoft in a long, long time.

    Fix It!

    1. I appreciate your feeback, John. Under prerequisites, I said you need "a connection to Office 365 PowerShell" and the "Preview version of the Azure AD Module" (for which I provided a link). If you have the preview version of the module installed, the Get-MsolAllSettingTemplate is part of that module. Then, per the prerequisites, you can connect to Office 365 via the link I provided (to Connect to Office 365 PowerShell). If you run any of the MSOL commands, you will be prompted to run Connect-MsolService. You'll need to have a connection to the Exchange Online PowerShell endpoint to complete the Set-OwaMailboxPolicy. I didn't necessarily see a need in reiterating the same content over, but I'm happy to provide that as well and will update the steps accordingly.

      1. MG says:

        You've ignored his "Part II" comments, which I would like to reiterate. If it's bad in a corporate environment, think how much worse it is in a school.

        You just can't allow students to create stuff like this, by default, with no easy option to turn it off. Expecting people to find blog posts like this, and type in runes to fix things, is not reasonable.

        I have started this tedious and complicated process and the first thing is:

        Import-Module : Could not load file or assembly 'file:///C:\Windows\system32\WindowsPowerShell\v1.0\Modules\msonline\Microsoft.Online.Administration.
        Automation.PSModule.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded

        So it looks like I'll first be forced to upgrade .net. Hope that doesn't impact on anything else ...

        “But the plans were on display…”
        “On display? I eventually had to go down to the cellar to find them.”
        “That’s the display department.”
        “With a flashlight.”
        “Ah, well, the lights had probably gone.”
        “So had the stairs.”
        “But look, you found the notice, didn’t you?”
        “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

        ― Douglas Adams, The Hitchhiker's Guide to the Galaxy

        1. MG / John,

          Please forgive me as I was wrapped up in updating the blog post with more detailed information and totally forgot to circle back around. As a former corporate IT administrator and executive at a managed service practice, I certainly understand your concerns and pain points, and I'm sorry that you're in this predicament. The best advice I can give you is to voice your concerns over at the Office 365 UserVoice forum (https://office365.uservoice.com/), and, if you are a Premier customer, share your feedback with your account team. If you have further concerns, I'd be happy to work with you offline to try to resolve them. You can contact me at aaron dot guilmette at microsoft dot com.

          1. MG says:

            Thank you for your response Aaron.

            For anyone else tripping over this page, I got this working but it was actually the Windows Management Framework 3.0 I had to install, having been through a .net Framework which may or may not have been necessary after all.

            Also, while I acknowledge that you did say "The Preview version of the Azure AD PowerShell module", I initially installed the GA version on the basis that the GA release notes post-date your blog post, and have an apparently later version number (1.1.160.0 vs 1.1.130.0). So I thought it had gone GA since the blog post. However that GA version doesn't contain the necessary Get-MsolAllSettingTemplate cmdlet so I had to uninstall it, then install the preview version as you said.

            At which point your script seemed to work. Haven't tested yet to make sure it really has the required effect ...

            Thanks again for at least posting this info, and responding to our feedback.

          2. You're welcome. This entire area is sticky for those of us in services to navigate--you're not the first customers I've heard this feedback from.

            The version numbers don't seem to be helpful in this instance; I don't know if there's another way to identify different code branches (preview vs GA).

  2. Hikmer says:

    The focus of this article is about Office 365 Groups, while I understand the frustration of setting up Azure AD Powershell (it Should be far easier) I want to thanks the blog author for doing this. The problem I am encountering is that their is no easy way to test this out unless people use it...then it is somewhat too late. So I am left to only imagine how these products work unless I commit to turning them on is some fashion. My question, the folks that can create groups...must they be a member of these groups? Or can they create them and walk away?

    1. I would recommend provisioning a "trial" tenant--it's free (at least for 30 days), so you can see the features and experiment with them. The way the script is constructed, it should only allow people who are members of the Global Admins group to configure Office 365 groups in most services. You would need to configure an additional OWA Mailbox policy that did had -GroupCreationEnabled $true and assign it to a user who is a member of global admins to provision groups in OWA.

  3. Jammy says:

    Aaron, BIG THANKS For your undocumented features, especially this usefule article.
    I'm following your step and it work perfact.
    But the only question is can we restore to default setting ?

    1. Yes--you can put it back to default.

      I believe this will do it (but haven't tested):

      Import-Module MSOnline
      $UserCredential = Get-Credential
      $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
      -Credential $UserCredential -Authentication Basic -AllowRedirection
      Import-PSSession $Session
      Connect-MsolService -Credential $UserCredential
      $GlobalAdmins = Get-MsolRole -RoleName "Company Administrator"
      $GlobalAdminsObjectID = $GlobalAdmins.ObjectId.ToString()
      $template = Get-MsolAllSettingTemplate | where-object {$_.DisplayName -eq "Group.Unified"}
      $setting = $template.CreateSettingsObject()
      $setting["EnableGroupCreation"] = "true"
      $setting["GroupCreationAllowedGroupId"] = $null
      New-MsolSettings -SettingsObject $setting
      Get-OwaMailboxPolicy | ? { $_.IsDefault -eq $true } | Set-OwaMailboxPolicy -GroupCreationEnabled $true

      1. Rick says:

        I tested this and got an error when trying to re-enable groups in our test Tenant. Still working out how to correctly re-enable groups.

        New-MsolSettings : Error calling CreateSettings:
        Content {
        "error": {
        "code": "Request_BadRequest",
        "message": "A conflicting object with one or more of the specified property values is present in the directory.",
        "innerError": {
        "request-id": "8b1755a6-3a32-4c20-b0ad-8741f0a2c984",
        "date": "2016-10-13T05:05:07"
        }
        }
        }
        ErrorException
        ErrorMessage
        StatusCode BadRequest
        StatusDescription Bad Request
        ResponseStatus Completed
        At line:5 char:1
        + New-MsolSettings –SettingsObject $Setting
        + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo : NotSpecified: (:) [New-MsolSettings], ApiException
        + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.ApiException,Microsoft.Online.Administration.Automation.CreateSettings

        1. Rick says:

          Ok I found out what the problem was trying to undo this. It looks like you can't use New-MsolSettings to update an existing Settings Object.

          Based on the information at https://support.office.com/en-us/article/Manage-Office-365-Group-creation-4c46c8cb-17d0-44b5-9776-005fced8e618 the following worked after about 20 minutes or so of replication time.

          $Setting = Get-MsolAllSettings | Where-Object { $_.DisplayName -eq "Group.Unified" }
          $SettingId = $Setting.ObjectId
          $Value = $Setting.GetSettingsValue()
          $Value["GroupCreationAllowedGroupId"] = $null
          $Value["EnableGroupCreation"] = "true"
          Set-MsolSettings -SettingId $SettingId -SettingsValue $Value

          Hope these new commands go GA soon.

  4. Ben says:

    I had the same problem as MG

    "I initially installed the GA version on the basis that the GA release notes post-date your blog post, and have an apparently later version number (1.1.160.0 vs 1.1.130.0). So I thought it had gone GA since the blog post. However that GA version doesn’t contain the necessary Get-MsolAllSettingTemplate cmdlet so I had to uninstall it, then install the preview version as you said. "

    Posting that here so others find it quicker. Might be worth updating the article to make mention of it, I burnt about 2 hours trying to get this working.

    1. I appreciate your input. However, I do state that it requires the "Preview version" and provide a link to it. I'm sorry if it wasn't clear.

      1. Ben says:

        Not a stab at you, it was just a suggestion in order to help others. This official office article should really be updated to mention the version requirements: https://support.office.com/en-us/article/Use-PowerShell-to-manage-Office-365-Groups-Admin-help-aeb669aa-1770-4537-9de2-a82ac11b0540?ui=en-US&rs=en-US&ad=US. I was reading that before doing some searching and finding your blog post. The point I guess is that its confusing that a preview version would have a version number that is older than the current release version - it's fair for customers to assume that the release version with the higher version number would include all of the functionality of the preview version that precedes it.

  5. Thanks a lot. You saved my life 🙂

  6. Matthew says:

    I've been checking back on this page for updates, and it looks like the powershell version required for these commands is still in preview. Any word on general release?

    I guess I just find it really odd that this capability is advertised as available, but the only method to manage it requires software that's not GA yet. Can you really call something "released" in this case? I guess Microsoft does.

  7. Benoit says:

    Seriously, you need to use a preview which has a lower release number than the GA??
    are you kidding me?

    1. Parkerthon says:

      Worse, the preview with this required cmdlet isn't even available for download anymore????? WTF Microsoft. Thanks for offering us a fix and then removing the module with the cmdlets we need. Fantastic! I really don't understand what is going on the administrative capabilities side of O365. It's like they don't even care anymore. Makes google a whole lot more attractive, that's for sure.

      1. There's a new module available. If you have Windows 10, you can use Install-AzureADPreview to get the module. Check out the updated blog for more information (https://blogs.technet.microsoft.com/undocumentedfeatures/2017/04/29/disable-office-365-groups-creation-redux/).

  8. John says:

    Hate that face that Microsoft force feed us all of these new features, that us admins can't easily disable without going through hell.

    Cr*p like this just makes the shadow IT problem worse!

    Microsoft - if you create a new feature like this, give the admins the ability to easily control / disable it!

    So frustrating!!! Hate Office 365 for this!!!

    1. Chad says:

      I feel the same way, it really is beginning to make me push to get away from Microsoft products.

  9. Bryan Marks says:

    Hey Aaron,
    Does any of the new features recently released cover this? Specifically the ones under Group Settings...

    On the roadmap site it's this feature I was looking at

    Office 365 Groups: creation policy in Azure Active Directory

    We’ve implemented policy in Azure Active Directory that allows administrators to restrict group creation to certain users. This ensures that creation of Office 365 Groups through all endpoints can be given to selected users. The existing Exchange Mailbox policy only applies to creation in Exchange, Outlook, or the Outlook Groups mobile app.
    Feature ID: 31838

    The wording is odd to me under the group settings though

    There's a section that users "Users who can create Office 365 groups"
    This setting only says it applies to the access panel

    Then there's another setting "Users who can manage Office 365 groups"
    Here you can select some and assign a group...but I don't understand the word manage.

    I basically want to create a group that can create and manage Office 365 groups.

  10. Royce Lithgo says:

    It's insane that Microsoft enable this feature by default and now anyone within our organisation can register any alias against our corporate domain. This should be disabled by default and management of this feature needs to be simplified. All new groups should require admin approval.

  11. Wessel says:

    Wrong Forum I know but this is another feature that is forced on users with no regard for their needs, hence the need for this article!

    Both the "Distribution Group" and "Office 365 Group" option in the Exchange admin center, creates an Office 356 Group. Why not leave both options as separate options? Some of us may just want to use distribution groups in the classic way where historic mail is irrelevant and can be regarded as resolved.

    1. Parkerthon says:

      An additional click let's you create a distribution list instead. They are forcing this down everyone's throats right now even though they offer no granular abilities to govern the creation of groups by users. It's all or nothing basically. Nothing like an end user free for all. Can you just imagine how many deprecated groups created by users, and then abandoned, will be floating around like mountains of discarded trash in about a year or two in your environment? I just rolled into a company that had Planner enabled without realizing it created groups on backend. The results are comical. People thinking they're creating To Do lists that are now groups in our GAL. Microsoft needs to create some sort of built in governance if they truly expect the enterprise to embrace this. Did they forget who their biggest customers are?

    2. Yes, you need to select the link to create the older style Distribution List instead (you get a notification that Unified Groups are available when you use New-DistributionGroup from PowerShell, as an aside). Groups are the new "IT" thing, especially for customers coming from Google Apps where they already had a similar concept.

  12. Andy Day says:

    Get-MSOLAllSettingTemplate now needs replacing with Get-AzureADDrirectorySettingTemplate
    $template.createSettingsObject() needs replacing with template.CreateDirectorySetting()
    New-MsolSettings - SettingObect $setting needs replacing with New-AzureADDirectorySetting -DirectorySetting $setting
    You'll also need to connect-AzureAD

    Good 'how-to' just a shame it hasn't been updated to reflect the crazy changes PS developers are making, now having to use another service to manage something which should be available in the admin centre. Lots of wasted time!

    1. Matthew says:

      Thanks for the info, Andy.

      Looks like this STILL requires using a preview version of the Azure Powershell module. Why, Microsoft, why?! Is this EVER going to be actually released to general availability?

      https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-settings-cmdlets

      "The cmdlets are part of the Azure Active Directory PowerShell V2 Module. For more information about this module and for instructions how to download and install the module on your computer, please refer to Azure Active Directory PowerShell Version 2. Please note that since these cmdlets are in public preview right now you will need to install the preview release of the module, which can be found here."

    2. I haven't done this since I posted the blog entry. I'll eventually get back to it, since I think both editions of the cmdlets are available.

    3. Sorry it took me forever to get to. I had a pretty heavy customer load the last few weeks, but I've updated the guidance in a new blog post, since you need yet another new version of the PowerShell module (which is installed a new way) and some updates to the cmdlet syntax.

      https://blogs.technet.microsoft.com/undocumentedfeatures/2017/04/29/disable-office-365-groups-creation-redux/

  13. Luca Fabbri says:

    Aaron, thank you for useful article.
    I have a question: is it possible to allow more than one group ("Global Admins" and custom group of users) to create O365 group ?
    Thank you,
    Luca

    1. Unfortunately, no. The object type is a System.Guid, so you can’t put more than one value there. I’d recommend creating a new group (like a mail-enabled security group) and including all of the people allowed in that group.

Skip to main content