Array
(
    [post_type] => post
    [posts_per_page] => 6
    [order] => DESC
    [orderby] => date
    [ignore_sticky_posts] => 1
    [post__not_in] => Array
        (
            [0] => 48818
        )

    [category__in] => Array
        (
        )

    [tax_query] => Array
        (
            [relation] => OR
            [0] => Array
                (
                    [taxonomy] => category
                    [field] => slug
                    [terms] => Array
                        (
                            [0] => sharepoint-management
                        )

                    [operator] => IN
                )

        )

)

We are currently working on a SharePoint on-prem to SharePoint Online migration, and you might think that migrating the permissions side of things would be relatively straightforward.

Well… it’s not.

One issue that’s recently popped up is how to simplify permissions management without ending up with multiple overlapping groups that all need maintaining separately.

Specifically, our client wanted to avoid having to manually add and remove users from multiple groups every time somebody joins, changes department or leaves the organisation.

Ideally, they wanted just one group that could:

• grant SharePoint permissions,
• work with Microsoft Teams,
• and potentially act as a distribution list as well.

On the subject of setting up groups with a ‘shared mailbox’, our client was hopeful that their legacy use of Mail-Enabled Security Groups would easily move across to Microsoft 365.

However, after adding a test Mail-Enabled Security Group to Teams, despite appearing to work correctly (Teams displayed a reassuring “Done” message), the new group never actually appeared afterwards.

This article includes our suggestions for tackling issues with migrating groups (and why migration of mail-enabled security groups don’t work for Teams membership management), but first, a bit of background…

Why group migrations from on-prem to Microsoft 365 become complicated

A recurring theme on Reddit and Microsoft forums is administrators trying to simplify permissions as part of their SharePoint migration, only to discover they’ve inherited years of overlapping group structures and inconsistent usage.

One admin summed it up perfectly: “We’re using Microsoft 365 groups heavily, but have a lot of on-prem mail enabled security groups and distribution lists that cause a lot of doubling up and confusion.”

It’s not surprising things don’t work as you’d expect, when you consider that these different group types were originally designed for very different purposes.

In older environments:

• Security Groups were used for permissions,
• Distribution Lists were used for email and
• Mail-Enabled Security Groups combined both.

and later,

• Microsoft 365 Groups arrived with Teams and modern collaboration features.

As a result, if you try to migrate legacy groups to Microsoft 365 you are highly likely to end up with:

• duplicate groups,
• nested groups,
• inconsistent ownership,
• broken inheritance,
• and – as our client did – uncertainty over which group type should be used where.

This uncertainty is further compounded by the fact that admins often discover that some groups work in SharePoint but not Teams, or they appear in one Microsoft 365 portal but not another.

Understanding the different group types (and where to use them)

One of the reasons Microsoft 365 migrations become confusing is that several different types of “group” exist – and at first glance they can appear to do very similar things.

But, in general, the best practice approach for managing user groups is as follows: 

As a general rule, you should use the top 3 groups in the table above in Microsoft 365 as follows:

• Microsoft 365 groups: This is my ‘go to’ recommendation where you need a collaborative workspace.  So, for example, internal teams like Marketing, Sales, Finance etc. that require a chat room (Teams), file storage (SharePoint) and secure access to specific people (permissions). 
• Security Group: These are great for simply granting or restricting access.  A security group has no mailbox or Teams or SharePoint site associated with it.  It’s simply there to group users together for permissions which can then be applied to various SharePoint areas within Microsoft 365.
• Distribution Lists: These are purely email only, and are a great way of grouping users for bulk email purposes, such as Sales Distribution Lists (DL), Marketing DLs, etc.

Why doesn’t a Mail-Enabled Security Group work properly with Teams?

As I mentioned earlier, Mail-Enabled Security Groups (MESGs) are not designed to support modern Microsoft Teams collaboration in the same way as Microsoft 365 Groups, which is why our client is having the issues with the group not appearing. 

The reason comes down to how Teams manages membership.

Teams relies on real-time membership sync to control chat permissions, channel access, meeting participation and compliance controls. Microsoft 365 Groups were specifically designed to provide this capability across multiple Microsoft 365 services.

MESGs work differently: Teams cannot natively monitor and manage ongoing membership changes within a MESG in the same way it does Groups.

The result is that while importing a MESG into a Team may appear to work initially, Teams only imports the members that exist at that point in time. In other words, it’s a static list of users that rather than a dynamically managed membership object and any changes to the MESG are not automatically reflected within the Team.

This is why administrators often encounter situations where the Team appears to have been created successfully, but ongoing membership management does not behave as expected.

So in general, we would recommend you use Microsoft 365 groups for achieving the same effect as a ‘legacy’ MSEG, as they automatically create all of the necessary requirements, including a shared calendar, a SharePoint site, centralised Teams membership management and a shared mailbox.

The practical takeaway

As organisations modernise, overlapping group types, duplicated memberships, inconsistent ownership and growing permission sprawl can quickly become a major operational headache.

Cleaning up your group strategy during SharePoint migration projects can significantly reduce:

• administrative confusion,
• permission inconsistencies,
• Teams integration problems,
• and long-term support and group maintenance overheads.

And, as many administrators are discovering, what initially looks like a “simple” SharePoint migration often becomes a much broader identity and collaboration rationalisation exercise.

So to conclude: In general, Microsoft 365 Groups are now the preferred and most consistently supported model for Teams-connected collaboration workloads.

Traditional Security Groups and Mail-Enabled Security Groups can still play important roles, particularly in hybrid and permissions-focused scenarios, but organisations should not assume every group type will behave consistently across all Microsoft 365 services.