Nesting Groups

[Quentin Finck]

Am I missing something or is it not possible currently to nest O365 groups?

[#2]

It's not, you can "add" the group but its membership is simply expanded instead of adding the actual group.

[#3]

Nesting groups creates all sorts of permissions issues. These don't occur for distribution groups, but they do when a group has a unique identity that can be used for accessing information.

[#4]

That just makes the usefulness of the O365 groups about half as useful as it could be. Instead of just keeping each individual team's group up to date and then nesting it in the department group I now have to duplicate work keeping both groups up to date. 

[#5]

Well, you're entitled to your opinion, but before you make such an assertion you should consider the purpose of the different groups and why those groups exist. A security group is intended to secure resources to a set of accounts. The way that security groups function has not changed much since Windows NT 3.1 in 1993. An Office 365 group is a new entity intended to allow members of the group access to various shared resources belonging to the group across multiple workloads. The two purposes are entirely different. You can't compare one to the other apart from the fact that they are two types of groups.

[#6]

This question comes up very commonly for people who are thinking about migrating from distribution groups where nesting is supported and used extensively. Although the two constructs "Groups", one is used to address sets of people and other mail-enabled recipients (like public folders) while the other can be used in the same manner (but only user accounts) but its more important role is as an access mechanism to resources such as the calendar, notebook, document library, Power BI workspace, and so on. Because Office 365 Groups are used as an access mechanism, nesting becomes a lot more difficult than when you simply have to resolve the address list for a message and figure out how to route the various copies. It might be that nesting is supported in the future, but for now it's not to make things simpler all round. Simplicity is good as complexity invariably leads to support issues etc. etc. etc.

[#7]

Would be nice, permissions aside, to at least be able to have a groups homepage where people can see groups (particularly public ones) automatically organized into a heirarchy based upon a tag used to specify where the group resides. This would require you to allow us to use tags or categorization during group creation. A little metadata please?

[#8]

We use nested AD groups for file security and for email, so I'm not sure what sort of issues you see arising from nesting groups for the purpose of resource allocation and distribution here.  

When you have hundreds or thousands of users to manage, keeping non-hierarchical groups in sync is a real headache.

[#9]

Presumeably the "Dynamic Membership" feature will allow more intelligent Group memberships buy ensuring folks that meet certain conditions based on attributes are always members of specific Groups. Note this requires AAD Premium though. We're toying with some cool stuff in our offerings as well in the near term as we hear this ask from multiple customers.Agree with @Tony Redmond that this needs to be smart though--- no one needs more AD Group nonsense like we know so well...

[#10]

This limitation is kind of crazy, sorry.  There's all these microsoft pointers to get everyone to use Office 365 groups instead of distribution groups, but they are completely two different things.  Why can't we at least forward email out of an office 365 group?  I just think it is another rushed half baked ms feature...

[#11]

Why do you want to forward email out of a group? To where?

It's easy to do this. Just add the address you want to receive the forwarded email as a member and make sure that their address is subscribed to the group... That address then receives a copy of every message sent to the group, which is an effective auto-forward.

[#12]

I'm was mainly just pointing out another feature limitation, that is available in shared mailboxes.  All I wanted to do was to simply add the office 365 group email address to a distribution group.  Can't be done.  So what I had to do was create a contact email address using another domain that we have control over, I set that email to forward back to the office 365 group, then I added the contact email to the distribution group.  This works, but there is no reason we should have to go through this just to accomplish a simple task, other than the fact office 365 groups are still somewhat undeveloped at this time.  

[#13]

You can add an Office 365 Group to a distribution group with PowerShell.

Add-DistributionGroupMember -Id DL -Member O365Group

Just because the GUI doesn't allow something doesn't mean that it cannot be done. This is why I recommend that all Office 365 Admins understand how to use and exploit PowerShell.

Or you could just read Office 365 for IT Pros and learn all the tips we have in that book... ;)

[#14]

I always forget about the eternal battle between gui and command line, but I still prefer gui.  Maybe MS will add it someday.  Thanks for the answer, and I'll read the book too when I can carve some spare time out.  

[#15]

Yeah, people do get pretty focused on GUIs, but as I point out all the time, you might not be satisfied by what engineers design in a system... PowerShell does a great job, if implemented correctly,  of exposing the true potential of software. The cmdlets available for Office 365 Groups are pretty good. Those for Teams are awful https://www.petri.com/powershell-module-teams-critically-flawed. 

[#16]

I understand the limitations once you turn a distribution list into an ACL.  But why would any mail platform provider choose to replace distribution lists altogether--it's crazy.  There are HUNDREDS of valid use cases for nested distribution lists which have nothing to do with security access to anything.  

For example, I'm in a (currently) very small tech company with limited IT needs.  However, one of the FIRST things we needed operationally was nested distribution lists, so that the ops team can easily get notifications from different components of the infrastructure with unique addresses, but without having to add the same people to every address.  You get a new tool, you create a group address for the tool so you can create an account using it and get its notifications, and simply forward it to the existing Ops team.

What's the proposed solution for this scenario?  Just keep using distribution lists or what?  I tell you what I'm NOT doing--buying some ridiculous additional tool just to accomplish what every other mail system on the planet does out of the box as basic functionality.

/mike

[#17]

@Mike Mitchell distribution lists still exist and there's no plans to remove them, but also from your description I don't see why you wouldn't be better using an Office 365 group for your ops team anyway and get all the benefits of collaboration as well as email.

[#18]

Because:

1) I can't forward other distribution lists to a Office 365 group, as per my use case above, which is my whole point. Even if I wanted to use collaboration, that group type wouldn't solve my problem. But, since you brought it up...

2) There are exactly zero Microsoft collaboration tools we're interested in using. In fact, I'm questioning the decision to use Office 365 itself, based on ridiculous feature decisions like this.

[#19 · Accepted solution]

Just use Distribution lists if that's all you want, they are entirely just as available as they have ever been, fully support nesting etc.

Alternatively if you read up, @Tony Redmond explains that you can nest an Office 365 group within a DL via powershell if you absolutely must.

[#20]

Yep, you can definitely add an Office 365 Group to the membership of a DL. The only thing is that you must do this via PowerShell because the GUI doesn’t allow the action. DLs are absolutely supported, very flexible and powerful if used correctly, and there is no need to use Office 365 Groups unless they meet your needs.