Dear Microsoft: In Office 365, Groups are Groups are Groups – Unless They Aren’t

5 minute read

One of the problems with using common English words for things like “groups” or “teams” is that we end up trying to figure out the difference between things with very common names. When Sue Hanley (@susanhanley) and I were building our session Lions and Tigers and Teams, Oh My! – Sorting through the options to connect and collaborate in Office 365 for SPTechCon Austin recently, I realized just how confusing this could be – yet again.

The Problem

On the SharePoint home UI, when I want to create a “group”, I am told I will “Get a team site connected to Office 365 Groups”. So based on that one sentence, I might quite reasonably assume I’m creating a “Team” and a “Group” – which it so happens I am – sort of.

In the Groups UI in the Admin Center, we see these options:

  • Office 365 Group
  • Distribution list
  • Mail-enabled security group
  • Security group

In the Exchange admin center when we start to create a “group”, we’re given these choices:

  • Office 365 Group
  • Distribution group
  • Security group
  • Dynamic distribution group

But don’t fret. When you go to create a “group” in the Azure AD UI, you can create a “group” with Membership type of:

  • Assigned
  • Dynamic Device
  • Dynamic user

We can also check a box to “

Selecting ‘Yes’ will turn on Office 365 features for this group

I can even try to add the “group” – it’s not clear which type of “group” I’ve actually created – to the membership of another “group”. “Group Type” seems to be one of the following:

  • Distribution
  • Security
  • Office
  • Mail enabled security

When I create a Team in Microsoft Teams, there’s not even a clue that I’m also creating an Office 365 Group behind the scenes. Maybe that doesn’t really matter to an end user, but the fact that a “Team” is also a “Group” is another terminology SNAFU.

So What?

Some people might say that as an “IT Pro”, one should always understand all of these terms intrinsically, but I doubt that it’s often the case that this is true. The terms cross different “workloads” in Office 365 and can vary in terminology from their on premises counterparts, especially across server versions. Add to that the fact that many “admins” are the lone SharePoint/Exchange/Office 365/Chief Cook/Bottle Washer in their organization, and there is little hope they will understand the nuances. Heck, I do this stuff for a living and I find it confusing. Sometimes things are hard for no good reason.

Let’s assume we have an organization which is totally sold on the value of Office 365 Groups (note the capitalization of “groups”). If they have been using SharePoint and Exchange either on premises or in Office 365, they probably already have a mix of all the different types of “groups” shown above. When someone in that organization tries to create an Office 365 Group for – say – the Executive Team, it’s highly likely they will get an error like:

Note that “group alias” is not one of the terms used above, nor does the error give even an inkling of how to solve the problem. Not even a worthless “Contact your administrator” as a fine how-do-you-do. So, what is the user likely to do?

Well, I’ll posit that they will create a Group named “Executive Group” or “Executives” or something else spelled a little differently. That Group won’t be linked to any of the previous artifacts and thus will begin the route to more chaos that we had before.

Of course, this is a real use case I’ve run into at an actual client, as is often the case with my beefs. As far as I can tell, there is no way to convert a “Mail-enabled security group” to an “Office 365 group” without some sort of Powershell tomfoolery. That’s just bad. I’ve reached out to my MVP network for help here and I’ll update this post if I’m wrong – and I’d love to be.

This is where the old Microsoft line would have been that it’s a great “partner opportunity” or that there are “$9 spent in consulting for every $1 spent on server products”. Those were always crappy answers, and they were often driven by confusing things just like this. The “avoid a mess” or “clean up the mess” roles fell to partners who were more than happy to lap up the dollars agonized organizations were willing to toss them to fix things.

The new Microsoft doesn’t want to work this way, but in many cases, their own large size and competing teams (small “t”, generic use) still lead us to these sorts of problems.

One of the things we as consultants spend a *lot* of time doing is working with organizations to build a common set of terminology. Sometimes you may hear this called taxonomy or ontology, but the bottom line point is to get everyone to agree to a set of words and phrases that they can use consistently to express the same thing. If I came out of one of those efforts with as many terms as I’ve listed above, I’d consider the effort a failure, especially if several terms meant essentially the same thing.

The Ask

So, Dear Microsoft, please tighten up the terminology as quickly as you can. Next we need to know how to convert each of the old, legacy types of “groups” to an Office 365 Group – without resorting to Powershell. Ideally, we should just be able to click a button on any of the old things to make it a new thing, which would take us through a process (if we need one) to get it done.

Even better, when I try to create that Executive Team Office 365 Group, walk me – as a user – through fixing the issue. In other words, help me solve the problem BEFORE I’ve created the mess, so I don’t need to call a consultant to fix things. (Yes, nose, face, etc., but I think most of us consultants would rather be building valuable functionality than cleaning up messes. If your consultants relish this type of work – beware.)

Make it easy for us to help ourselves. Cut down on those support calls. Stop making your customers hire expensive consultants to clean up messes. Make Office 365 the best it can be.

Post 999! Sadly, I may have just used up my allotment of quote characters for any future posts.



  1. Can’t argue with a single word of that. MS have ALWAYS seemed to have multiple teams working on different areas of products with no lines of communication between them seemingly. Until they fix that, this kind of thing will keep happening.

  2. So true! Very confusing but I assume they will merge some of the “groups” and provide us a clearer picture.
    About the partner opportunities, I’ve just read about tyGraph for Groups which should be able to put a governance control on Groups. Signep up to test it

  3. Long comment, sorry. I have been working on this problem for the past 5 years and hardly know how to begin my response here – but I’m happy to see that you guys share my view on the current situation. I’ll try to explain a bit how we see the problem and what we in Microsoft are trying to do to address it.

    The problem started way back when someone figured out that you could re-use the members property of a distribution list to provide access to resources. Here’s the real dilemma:
    When a developer creates a features where any aspect of its functionality to manage as scale without using a groups construct of some sort, they can either chose to re-use an existing construct or create a new one. This happens everywhere where people build applications to manage users, everyone wants to group users to have a scalable experience. (This is also true for other object types, but let’s keep this simple for now).
    The core engineering issue is that 1) as an owner of a group type you want to expose the group’s members list so that your features can use it, 2) your groups will be used more and better if you build a (expensive) rich groups management system with many intricate features (think about how many settings a Distribution Groups supports), and 3) apparently it is beneficial for you that many users use you groups. This is especially true for groups that are a little more than just “an identifiable list of members” but also support some additional implicit functionality, like a DL that also support the function “Can send email to it”.
    The problem is this: If developer has invested heavily in a rich groups management system AND has decorated his groups concept with many implicit functions then it is not easy to re-use the members list of that group concept in other features, since a group created in the rich context of the “founding feature” will likely carry with it functionality that may be essential for the founding feature but useless or even unwanted for the new feature you’re building (think about the situation where al your security groups where mail enabled – you probably don’t want that).
    If you, as a developer, cannot persuade the founding team to make their groups model configurable so you can switch off feature you do not want then you will quickly decide to implement your own group concept, totally tailored to your own needs and with the groups management features you want.
    This has happened many time, not only within Microsoft (though admittedly Microsoft’s groups features have highest aggregate member count in the world), this seems to be a very common engineering practice. The result is that we’re living in a world where there are many group concepts and it not always easy to determine what features they support or enable (tracking which user has access to what based on group membership is a notoriously highly-wanted-and-extremely-expensive feature). And there aren’t many drivers on the individual feature team level that would encourage them to create a joint approach.
    I think the Unified Groups concept is different in this aspect – it DOES make an attempt to offer a rich yet configurable and generically supported open groups concept within all of Microsoft features. The basics are that these is one place to create these groups (which happens to be Azure AD) and all features that desire to use a unified group can decorate these groups with their own attributes and functions – e.g. if you create a unified group in Azure AD, from whatever context, all of the “subscribed” features are notified and can take their own actions based on the group creation event – so Exchange Online will create a mailbox and SharePoint will create a team site. This approach at least offers to developers an option to join a rich and vibrant ecosystem of groups features, which easily allows the developer to add their own functionality (of which other teams can potentially take advantage if they have a similar requirement).
    This unified approach is new (as in: a couple of years old) and heavily backed by our top management, because they see this as a great example of the “One Microsoft” vision coming to life, so you can expect to see many workloads within Microsoft already implementing or soon moving to this model – like Yammer, Planner, Teams, Visual Studio, SharePoint, Intune and many more.
    You may also not find all of the configurability in your groups that you require, e.g. you cannot create a group which does support Teams and Visual Studio but not Exchange Online, and hence all unified groups are decorated with a mail box (which is often undesired), but the teams are working hard to make improvements to the model – and comments like your are essential to help us prioritize the work we’re planning on the unified groups model.

    I’ll gladly tell you more about the model if you’re interested, or answer any other questions about how groups are managed within Microsoft – just ping me on

    Thanks for reading this,


    • @Rob:

      Thanks a lot for the long comment! I’m well-aware this isn’t an easy thing to sort through. There’s a LOT of historical baggage here of all sorts.

      To me the big key is to work to get the engineering to match the marketing. Ever had that problem? ;-) Having worked in several organizations with that split, I know that’s a hard thing.

      Office 365 Groups as a construct is clearly the way forward. We’re “crossing the chasm” on this right now, and many of the things I point out above are symptoms of this. What I would hate to see is that people become frustrated being in the chasm and abandon the trip. That’s a serious concern.


    • @Rob:

      p.s. Do you have a suggestion for the specific issue I pointed out above? To whit: “converting” a “Mail-enabled security group” to an “Office 365 group”? I’m loathe to delete the “Mail-enabled security group” so that I can use the alias to create an “Office 365 group”, as it may be used for any number of other things in the organization – for which no current employee may actually know the full details. If I create a new Office 365 Group with a slightly different name, we’ll have a potential schism in “conversations”, as the old “group” and the new “group” will have different aliases.


      • Hi Marc – complicated matter :)

        In order to fully support the proposed conversion without loosing functionality, we need to take care of several things:

        We need to enable Office 365 groups to be used as a security principal in all current scenarios. This is problematic for on prem resources as Office 365 membership isn’t part of a claim in a token that you can use on premises right now, and is not (yet fully) implemented for cloud based resources.
        We need to implement features in Office 365 groups that exist with mail enabled security groups today, such as nesting.
        In the conversion we need to ensure continuity – if you’re a member a group today you need to have uninterrupted access to the resources for which the access is managed through the mail enabled security group
        You’d probably want to have the capability to switch off certain features of an Office 365 group, such as a calendar or a SharePoint site

        We’re currently investigating this area to figure out the best approach here. Until then, converting a mail enabled security group to an Office 365 group cannot happen without loss of some functionality.

        Happy to discuss in more detail.


  4. Hi Mark – Great Article – why do Microsoft / We need three different types of teams ? Is this just a case of Microsoft Infighting ? Surely Microsoft would be better to take the best of each of the different variations of teams and then make them into a single Teams entity which we can all use !



Have a thought or opinion?