Forum Discussion
Warning: Provocative post - When is MS going to kill Groups?
I think you have a lot of potential terminology collision going on here that would be best to clarify.
When you're saying Groups, I believe you mean "Outlook Groups" and not "Office 365 Groups". People still confuse these constantly as there has never been good documentation from Microsoft and the shared name is not helping at all.
Office 365 Groups are the membership construct that underpins all the various tools and services in Office 365.
Outlook Groups is the email based communication and collaboration method that attempts to centralize all the tools and services in the Outlook/OWA interface, although not very successfully at this point as you pointed out. These use an Office 365 Group as their membership service to determine who has access.
All three communication methods (Outlook, Teams, and Yammer) use Office 365 Groups as their membership service now. Much of the confusion was created when Office 365 Groups and Outlook Groups were released at the same time and not differentiated at all. This resulted in everyone calling the email based communication method an Office 365 Group, which is not correct.
cfiessinger and Kady Dundas There is still massive confusion about this :)
I doubt MS will ever kill Groups, (most corporations seem loathe to admit they might have made any kind of mistake), but I have a feeling we'll see a name change or two at the very least.
Or company is slowly migrating to O365, and the confusion around when to use Teams vs when to use Groups vs when to use regular SP sites, (remember those?), is causing us no end of problems. To make it worse we are in a hybrid environment, with "almost" everything of a "group" nature being handled by our Service Desk through AD. They create all Distribution Lists and Security Groups, and make sure that all policies and naming conventions get followed.
Now all of that is out the window. We have users creating Groups and Teams willy-nilly. I I have multiple groups with almost the exact same name, and I (as admin) don't have any idea which is the correct one, or what exactly is in that site. At least on my 75 on premises SP servers I can easily log into a SP site and see exactly what is on that site. Not with groups, (or at least any way I have found).
We are now looking at completely restricting the use of Groups and Teams until MS get's this mess sorted out. MS says they use this all through the company, and that's all well and good for them, but for our users it's just a confused mess.
Ted
Exactly to the point.
Collaboration is all good but all these mess is not.
When users are allowed to create Teams, Yammer (O365 Connected Groups), Planner etc.. they also need to be allowed to create O365 Groups. When they are allowed to create Groups they can create Groups from Outlook, and OneDrive too. And all these Groups (no matter where they are created from), each comes with a Mailbox that goes in the AAD GAL, and a SharePoint Site Collection. And there's no easy way to identify who's the owner/admin for those Site Collections. There are ways to find out from AAD but that's way too many steps, not good. Also SharePoint sites' storage comes from a pool of storage allocated for SPO for a tenant and is limited. You have to pay if you go beyond that allocated pool. We don't hear MS talks about this.
There is no need (in my opinion) for users to create O365 Groups on their own from Outlook and OneDrive if users ought to use Teams, Yammer, etc. for collaboration purposes as MS suggests. Creating O365 Group links from Outlook and OneDrive needs to be hidden or disabled by Tenant Admins but they can't right now. Each company should decide whether they would allow their users to create Groups from Outlook and OneDrive. MS needs to figure out how to configure Teams, and Yammer Connected O365 Groups, Planner etc. without needing users to create O365 Groups.
Thanks......
Monir Khan wrote:
Exactly to the point.
Collaboration is all good but all these mess is not.
When users are allowed to create Teams, Yammer (O365 Connected Groups), Planner etc.. they also need to be allowed to create O365 Groups. When they are allowed to create Groups they can create Groups from Outlook, and OneDrive too.
TR: You can mitigate this fact by restricting the people allowed to create groups/teams. I think this is a reasonable thing to do as it avoids the need to scan for unused groups, etc.
And all these Groups (no matter where they are created from), each comes with a Mailbox that goes in the AAD GAL, and a SharePoint Site Collection.
TR: You can hide Groups from the GAL if you want.
And there's no easy way to identify who's the owner/admin for those Site Collections.
Use Get-UnifiedGroup and then Get-UnifiedGroupLinks to find who are the owners of the groups. They are the owners of the site collections. See the report described in https://www.petri.com/identifying-obsolete-office-365-groups-powershell
There are ways to find out from AAD but that's way too many steps, not good. Also SharePoint sites' storage comes from a pool of storage allocated for SPO for a tenant and is limited. You have to pay if you go beyond that allocated pool. We don't hear MS talks about this.
TR: The storage pool is not used if group members don't store files. But if they do, that's goodness because those files are then in the cloud and subject to compliance, etc. The amount Microsoft charges for extra storage is likely less than you'd pay for your own local storage, assuming the same degree of resilience and feature set.
There is no need (in my opinion) for users to create O365 Groups on their own from Outlook and OneDrive if users ought to use Teams, Yammer, etc. for collaboration purposes as MS suggests.
TR: So impose a group creation policy and that will stop users creating groups from Outlook etc. It's your choice.
Creating O365 Group links from Outlook and OneDrive needs to be hidden or disabled by Tenant Admins but they can't right now. Each company should decide whether they would allow their users to create Groups from Outlook and OneDrive. MS needs to figure out how to configure Teams, and Yammer Connected O365 Groups, Planner etc. without needing users to create O365 Groups.
TR: As I said, it's up to each tenant to decide how to create and manage groups. When you buy into a massive multi-tenant service like Office 365, you accept the strengths and weaknesses of the service and cannot dictate a tailored service to meet your own needs, as you can (to some degree) with on-premises systems. So turn off group creation for all, impose a policy, and start managing groups in your own way.
Thanks......
Thank you for the reply and insight..
Please find comments inline in italic....
Exactly to the point.
Collaboration is all good but all these mess is not.
When users are allowed to create Teams, Yammer (O365 Connected Groups), Planner etc.. they also need to be allowed to create O365 Groups. When they are allowed to create Groups they can create Groups from Outlook, and OneDrive too.
TR: You can mitigate this fact by restricting the people allowed to create groups/teams. I think this is a reasonable thing to do as it avoids the need to scan for unused groups, etc.
MK: We do restrict now as to who can create Groups/Teams because of all the mess it creates if we don't do so. This is well managed now. But we prefer not to be this restrictive and want users to create Teams as they need on their own if we can restrict creating Groups from other places. You mentioned below that's doable, we have to see. thanks.
And all these Groups (no matter where they are created from), each comes with a Mailbox that goes in the AAD GAL, and a SharePoint Site Collection.
TR: You can hide Groups from the GAL if you want.
MK: That requires Tenant / EXO admins' involvement. In a large organization with many users that would be tedious tasks for those admins. There should be an easy option for Group Owners to check on/off whether those Groups should be shown in AAD / GAL at the time of Group creation. This is for any organization if they want to allow users to create O365 Groups from other Outlook/OneDrive.
And there's no easy way to identify who's the owner/admin for those Site Collections.
Use Get-UnifiedGroup and then Get-UnifiedGroupLinks to find who are the owners of the groups. They are the owners of the site collections. See the report described in https://www.petri.com/identifying-obsolete-office-365-groups-powershell
MK: Thank you. We have to see if this works for us. Ideally, we want proper Site Collection owner information is displayed in the O365 Admin Center under the Usage Reporting section for SharePoint. For now the owner is displayed as the name of the Group if those sites are created via O365 Groups. This is confusing and can be improved.
Note: if the Site Collection is created via the SharePoint admin center then it shows proper owner.
There are ways to find out from AAD but that's way too many steps, not good. Also SharePoint sites' storage comes from a pool of storage allocated for SPO for a tenant and is limited. You have to pay if you go beyond that allocated pool. We don't hear MS talks about this.
TR: The storage pool is not used if group members don't store files. But if they do, that's goodness because those files are then in the cloud and subject to compliance, etc. The amount Microsoft charges for extra storage is likely less than you'd pay for your own local storage, assuming the same degree of resilience and feature set.
MK: Yes storage is not used if users don't store files but users will store files once they know and there will be many sites for doing so. Data governance / management would be challenging. Agree with compliance.
We recently looked at the storage cost from O365 and that's not cheap as all the additional storage adds up quickly.
There is no need (in my opinion) for users to create O365 Groups on their own from Outlook and OneDrive if users ought to use Teams, Yammer, etc. for collaboration purposes as MS suggests.
TR: So impose a group creation policy and that will stop users creating groups from Outlook etc. It's your choice.
MK: was not sure you could do that, we would certainly look into this. I guess this policy can also be applied to OneDrive.
Creating O365 Group links from Outlook and OneDrive needs to be hidden or disabled by Tenant Admins but they can't right now. Each company should decide whether they would allow their users to create Groups from Outlook and OneDrive. MS needs to figure out how to configure Teams, and Yammer Connected O365 Groups, Planner etc. without needing users to create O365 Groups.
TR: As I said, it's up to each tenant to decide how to create and manage groups. When you buy into a massive multi-tenant service like Office 365, you accept the strengths and weaknesses of the service and cannot dictate a tailored service to meet your own needs, as you can (to some degree) with on-premises systems. So turn off group creation for all, impose a policy, and start managing groups in your own way.
MK: Yes it is and if they can be managed via policy that you mentioned then that's promising. thanks.
Thanks......
Now all of that is out the window. We have users creating Groups and Teams willy-nilly. I I have multiple groups with almost the exact same name, and I (as admin) don't have any idea which is the correct one, or what exactly is in that site.
This is precisely the scenario that I and some other MVPs warned Microsoft would happen when they briefed us about Office 365 Groups in Redmond in November 2014. Those of us who had been down the path of public folders and the uncontrolled sprawl that resulted when users were allowed to create public folders without let or hindrance forecast that the same would occur with Groups. Microsoft's response at the time was that they wanted users to control the creation of groups so that collaboration could flow without administrators or IT departments deciding what should happen. It was complete ill-smelling brown bovine material at the time and it is the same today. No sensible tenant operates without a group creation policy that restricts the right to create groups to a small set of people who might actually understand what they are doing. Yes, this impacts Teams, Planner, Stream, and so on, but it is the only reasonable approach to group management.
I am sincerely sorry that your tenant has gotten into such a mess. I wish that every tenant came complete with a fully-functional group creation policy, but I guess I am less collaborative than Microsoft would like me to be...
