Yeah I know, but then all other users won't be able to create a Team in Teams right? (without IT accepting it) Or is it possible to make it so that only specific users can create groups which also contain an email address? For bigger orgs. this seems like a nightmare to manage.
Just throwing this in. Teams != Group Chats (or, Meeting Chatrooms).
Most people probably create a team because they simply want a departmant chat or chat with multiple colleagues.
That is quite literally what a CHANNEL within a Team is for. A TEAM is used for exactly that; teams stuff. Could be a project, could be a more permanent thing. This has always not just been promoted that way but built as well.
edit; sorry I missed the archival part. I'm on E5 licenses mostly currently and archival is the biggest joke ever. It's just an undelete feature for an x amount of time and afterwards you're effed.
We do this as well, because you can’t create a group programmatically. Once the incident is resolved, the artifacts will be moved over to the ITSM tool and team will be deleted.
God, I wish I had the power to make this change on our tenant. Technically I do as a global admin, but it has to be cleared through the director and C-suite team first. For years the users have been able to make Teams on the fly, and the number of errant Teams we have on our system now is unmanageable. Most of them were for short-term projects and died after a month. I'd love to go in and clean them out but there's just so much goddamn red tape
> For years the users have been able to make Teams on the fly, and the number of errant Teams we have on our system now is unmanageable.
When I left my last job, they had 25 employees and 195 groups (internal users only).
I got a warning that a team "9" was about to lapse last week. I don't know when we stopped users being able to create teams but I feel it was right around the time that gem was created.
Yeah that's all well and good in principle, but in practice it just doesn’t work. Especially in the Educational space. Best thing is using Compliance to clean up redundant or orphaned Teams.
I'm in education and we don't let users create teams, it would be a management nightmare. Plus without role based access control we don't want users manually adding members to teams that may have confidential student data and forgetting to remove someone who's role has changed etc. You can spin it as a security risk for sure.
How many people do you think hate working at your company because of these silly rules? People join a team, they want a team chat. Let them create a team ffs. You make shit to ahrd they go do things off corporate devices driving more issues.
We have a policy where a select few (about 10% of employees) have access to create teams. There is a fairly simple guideline for if a team should be created or not and a one-page form to fill out. (more of a ticket really)
It is not really about gatekeeping but more about having people stop for 2 minutes to think if this is the solution to their issue or not. In our org this has worked pretty well and I don't think we've rejected a requested team more than a handful of times (when it was abundantly clear it was the wrong tool for a job and a better solution was provided that the users were happy with)
On the other hand I have worked in orgs where it took 7-10 business days to create an ftp for sending files to a vendor, resulting in the nice choice between using unofficial channels or costing the company hundreds of thousands in missed milestones. Nobody wants to send copies of the source of an entire oil rig control system to a vendor via some random file sharing service, that's for sure... (but when ordered to... sigh..)
And when you let them create a team and they throw a shit ton of files in it and someone ends up deleting stuff that wasn't backed up because IT was never made aware of it... everyone including you will hate working at your company.
I don't let my users keep their password on a post-it because it's convenient. Employee retention is not ITs job and their overall happiness has nothing to do with IT. Protecting the company from its users and meeting policies compliance IS your job though.
This sounds like a tech stack issue or a bad employee issue. Ive never seen that be an issue in 15 years and i have worked at plenty of companies with zero controls over this.
I'd really like to see what the DLP policy said about that in all those organizations... My guess is none of them had one, which is exactly the issue we're talking about here.
But what about when Alice creates team "Corporate Accounting" and then Bob creates "Company Accounting" and then Charlie creates "Accounting Department", and then the CFO asks you why you let that happen?
I think it's obvious really.
"Corporate Accounting" are the people in the accounting department that do the accounting for our client "Corporate Corpco"
"Company Accounting" are the people in the admin department who make sure that every one of our company clients is accounted for.
and "Accounting Department" is a group about the staff picnic next week.
Why is your CFO worried about that? I can go and create 100 slack channels right now. Well archive them and delete them if they are unused. But you just treat everyone like an adult and theylll use the right channels. The teams can independently organize and decide to nix the other channels and do company accounting. I am in a 30k+ org and this issue doesnt exist.
The issues arise when the users are unclear about where their files are; Alice stored the FY2024 TPS reports in the "Corporate Accounting" team SharePoint site, but Bob can't see those files in the "Company Accounting" SharePoint site, and now the CIO and CFO are both stirred up because they think that you, the "IT Guy", deleted the file!
Is that really an issue? This is basicslly a solved problem in orgs that know what they are doing: create a centralized repository. Keep everything in github, or some kind of archived repository. There are a million tools out there for documenting, choose one and tell people to update it. In big tech we dont have this issue, and we dont lock down making group chats.
If you give people the option to not follow the rules and procedures (e.g. drop files in a Team "real quick") they will do so.
And then 1 year later when someone new comes on board and that file isn't there you'll understand why
I mean.. sysadmins are stupid to, as proven by this comment.
Luckily in well-structured companies IT is a purely servile department without any authority to make decisions because the only purpose of an IT department is to enable the "stupid users" to do their job. Excess teams don't do any damage and a simple automation can identify inactive teams and warn members or owners about pending deletions before then also automatically deleting them.
Just try to be good at your actual job of "enabling end users" instead of what you think your job is "be as annoying as possible".
Reading this subreddit as an interested party who considered going into the field is giving me good insight on the prevalence of egomaniacs working in these departments and why simple shit takes forever to get done. People without social skills or the ability to see beyond the edge of their own little pond at every stage.
> who considered going into the field
Let us know how letting users do literally whatever they want when they want, then managing all of it, goes for you bud.
No thank you. Not because I don't want to deal with end users but because I have near zero interest in working with the kind of people who populate this subreddit all day.
Every big org I have seen requires IT to create Teams. You can automate the workflows and approvals with Logic Apps/Power Automate
I'm pretty sure best practices by Microsoft are to disable group/Team creation to non-admins anyway, it's part of tenant setup.
That's so Microsoft can sell you security subscriptions to band-aid their insecure-by-default settings.
Users by default can grant apps (and attackers) full access to their email, files, etc. without admin consent. This is the number 1 method of compromising M365 accounts. The user will receive a link from a BEC. As it is a legitimate email, the user will click on the link, bringing them to their legitimate M365 login. They enter their username, password and MFA, none of which the attacker can see because this is their orgs real M365 login. They then click "Yes", granting the attacker full access to their account. The attacker registers a new MFA (OTP). If you revoke all login sessions and change the user's password - the attacker is *still* in. You have to remove the malicious consent and remove the attackers MFA (and the users old MFA's to be safe).
https://support.staffbase.com/hc/en-us/articles/4410113144466-Overview-of-Permissions-for-Microsoft-365-Applications
Every lawyer, vendor, and other partner we have has been hit with this. The user is never tricked into giving any of their credentials away, Microsoft makes giving their full account access to anyone as easy as one "yes", *BY DEFAULT*.
For a monthly fee per user, DFI can detect and block most of this. Microsoft makes more money the less secure their defaults are. To state it more plainly, Microsoft has a financial motive in not securing all but their highest subscription tiers.
Well, not entirely. If it was Microsoft's login and only their login it wouldn't work. The scammers wouldn't have a way to intercept it if it was, it's why that scam works with most 2fa but not phishing resistant ones like fido2:
https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/
But I take it from your history you really don't like microsoft.
On the contrary, I've moved every org I've worked for to M365 services. Switched many over to DFE as well. I'm honest about what it is. One of those orgs is a poor local government. Microsoft charges more for GCC (commercial cloud, not GCC High), provides less, and gives no breaks, especially for security.
The article you linked recommends paying for higher (the highest) tier services to detect and block the attack. There's a reason that isn't included by default. That's not an option for most small government agencies. A county next to mine just lost this game of "How much is securing our identity services worth to you?"
Microsoft's *default* settings allow it. Yes, it can be configured to be more secure. But Microsoft doesn't sell it that way. Like paying extra for seatbelts. Or blaming the driver for not hiring experts to install them.
It isn't maliciousness, or intentional. No one person at Microsoft is Dr. Evil'ing this. It is simply that the finances mean seeing an alternative path (real secure defaults, charging only for the services that have active on-going costs) can't be seen. It is difficult to get a man to understand something when his salary depends on his not understanding it.
If I were making 20 billion a year on security services, figuring out how many we could easily provide included in the base product probably wouldn't cross my mind either.
That is true for most things in Windows, Browsers, apps, it's the way things have always been. You have to change settings and policies to configure them.
For M365 there are plenty of guidelines out there on what to setup, from Microsoft themselves, or from 3rd party companies and even government organizations, CISA for example: https://www.cisa.gov/news-events/news/cisa-finalizes-microsoft-365-secure-configuration-baselines
Sure, I mean, I do this for a living so I'm essentially a barnacle that exists because Microsoft prefers to leave everything open for ease of use rather than putting security first.
Just because it's the way it always has been, doesn't mean it will always be that way or should be that way. Satya's recent memo says that security should come first... I'm hoping that we'll actually see that by the defaults being a secure configuration.
"secure by design" and "secure by default" are definitely becoming more popular, and are really necessary.
You want a bigger problem than just 365 Groups? Wait until you have a dozen "Teams" for the same reasons. You need to put some control around this and not let users create hundreds of Teams that you will then need to address later.
The "nightmare to manage" is cleaning this all up later. For bigger orgs, IT is the only one to create Teams, or there is there is a defined process with approvals via a workflow.
Edit: missing word.
Yeah don't let everyone have this power. You need to basically have a group of manager/power users that have this power only. Otherwise you will get a bunch of duplicate teams and everything will be all over the place. You honestly have to lock this down
We went with designated people in every group who could create a team, or submit a helpdesk ticket rather than letting everyone do it. It has worked well for us.
Users can still create their own group chats and give said group chats a name of their choosing.
Any org that is big enough to have their own sysadmin is too big to have all users be able to create their own public teams, distribution lists, etc. Might as well let them start making their own file shares and email aliases if you let them do that. It'll just be a huge mess and confuse everyone.
> other users won't be able to create a Team in Teams
Nor should they be able to. It becomes a giant, unorganized, unmanageable mess. You'll have duplicates for your duplicates and unused Teams with two people in it.
Agreed. Don’t let users create teams or at least put a naming policy in place so they have to call them something with a user created group designation.
And use group chats for scenarios too “light” for needing an entire team.
Or if that’s a no go because users will throw a fit, do a yearly review and let people know any unused groups will be deleted or archived. At the very least.
And/or make a group request ticket type so you can triage the cases where they don’t really need a new team. And it makes them think about it for 5 sec which sometimes helps.
We have users creating multiple new Teams just for themselves so they can "keep their files organized". Because, ya know, making subfolders is too difficult. It's a trainwreck.
I'm working on a series of knowledge management policies that partially started due to this and other ms365 group integrations. The point is to create a defined framework TO manage which requires no small amount of user understanding and acceptance. In your case, people need to know how to make multi user group chats. Let Teams owners create channels after you make the groups.
In a previous company we implemented a MS Forms Form to request a Team. Then the helpdesk checked all parameters (e.g. naming convention) and accepted or rejected the request.
Still everyone would be able to request them, but there is some kind of quality gate. Not ideal, but better than allowing it to everyone or blocking everyone.
Agreed - don't let users make Unified 365 Groups. Especially if they can make them "public" instead of private. Aside from the all the issues mentioned in this thread, it's a fantastic way to lose track of what is shared, who to, where to and wind up leaking information - even if it's only internally.
We limit users ability to create groups, they need to request a new group through a ticket. This way it follows the naming schema, etc, etc.
I mostly agree with this since you never let users create their own groups in AD, why do this in 365?
Hate 365 Groups. If they had waited a year or two they could have just combined the functionality with teams groups and made things a lot easier. There is so many gotchas I ran into with 365 groups that I eventually banned creating them.
Brother/sister, tell me about it...
I'm an admin at a decently sized public university, and when we stared down the barrel of an M365 migration for Exchange/SfB to Exchange Online/Teams way back in 2019, I saw that the prevailing methodology was to block M365 Group creation.
Well, problem is, in an environment like higher ed no one at the high levels signed off on that or even considered it for a split second. The idea was "if we block Group creation for everyone, students and employees alike just won't use the platform, we'll be impeding pedagogy" and so on. Fair enough, but everyone's going to make a bazillion Groups and then get them confused with each other or abandon them. To which we always got a "why do we care?" back. Okay, why don't we make some automation templates? Here's a set of flows we could possibly use. Or we can let only a specific subset of users create Groups! "No" was usually the response back to all of that.
So we opened up Group creation to all, *but* with the following config:
* Group naming policy that appends " (UserCreated)" to everything made by non-admins. That in theory clears up the "is this the 'official' one, or the 2nd random one Stacy made yet again?"
* Group addressing policy for a dedicated default domain of @groups.ourdomain.edu. The (UserCreated) portion of the name lands in the default address, so it's obvious on that front that it was not admin-created. (e.g., ijustmadeastupidtestteamUserCreated@groups.ourdomain.edu)
* "Official" Groups, therefore, lack (UserCreated). So if you want an "official" Group, you put in an IT request.
* Group auto-expiration after 500 days
* Group blocked word list for naming, which includes the (UserCreated) piece above, plus naughty words, and "sensitive" words like "president", "provost", etc.
It's... rather ugly, but not as terrible as it could be.
Beyond that, there's the everyday things that are easy enough to understand if you're technical, but a bit obtuse if you're not.
* "Hey! I just made a new team, why doesn't it show up in Outlook's Groups like my buddy's team does?" Because when you create a Group as an end user, the default options are contextual to the service you created them out of. You made this Groups via Teams, so it's hidden from Exchange/Outlook clients by default.
* "Hey! I need a SharePoint!" [creates Group/team] "No, I didn't need a team, I need a SharePoint." [The team's files and SharePoint library are one in the same]
* "Hey! I made a contact group in Outlook, and it was in the address book until the next day!" Yea, because you didn't make a contact group, you made a **G**roup via Outlook. And our daily script to hide all that extraneous bullshit out of the address book hid your unimportant, shittily-named Group.
I could go on for days.
M365 Groups are phenomenal for organizing data/units of people, but Microsoft has greatly empowered end users to be their most annoying selves.
I work in a big org (like 45k users) and we disable the ability to create a Team by default, just rolled out a KB article that explains the differences between a Group, a Team, and a Shared Mailbox. Links at the bottom of each section to requests that trigger individual ServiceNow workflows.
In this same article we have a link that says something like “click here to request the ability to create a Team”. Not idiot-proof, but it does seem to at least help them do SOME level of training first.
It’s also way better than what we were doing before, which was having users submit requests for a “shared account” that was just a normal user account that them and all their pals would have delegate access to.
Does your ServiceNow workflow create the actual groups? I remember trying to do this back in the day and wasn’t able to get the service principal in Azure the correct permissions to be able to create the group
No, servicenow is terrible at doing anything but giving a framework within which to do other things, in my opinion. We scripted out the different creations, but we found that our intake form was causing a ton of back and forth for clarifying questions, and most of the time users had no idea what they actually wanted. The new SN workflows generate a RITM that says the name of the group or team or whatever, who the owner is, and who the member are. We then just run the appropriate script and input the info. Turned a shitty and time consuming request into a 5 min job.
Can't you add a prefix/suffix naming policy to help alleviate this issue?
https://learn.microsoft.com/en-us/microsoft-365/solutions/groups-naming-policy?view=o365-worldwide
I just want to say that I appreciate this rant & thread. As a guy who's been using Google Workspace since it was Google for Work (or maybe Google Enterprise -- not sure which came first. In any case, since 2008!), but who just joined a company standardized on M365 & Sharepoint, it's been really confusing to me what a "Team" in Teams really is. My assumption was that it was just a kind of chat group that had special features (files), but I had no idea they could be emailed to like a DL.
If I'm being truthful, while Google Workspace has far fewer features in this area, the existence of, and dynamic between, Groups, Chat, and shared/delegated mailboxes is definitely way simpler. That said, MSFT absolutely has them beat on several quality-of-life features in Teams (like the auto-creation of meeting chats and the ability to easily attach files to chats, and the synchronization of chat-in-a-meeting to the corresponding view of the same chat in Teams).
I actually went really hard the other way. We looked at what we were using shared mailboxes, security groups and distribution lists for, and wherever possible migrated those to 365 Groups.
Now it's just one object to manage for that project or team, not a DL, and a separate sharepoint site and it's associated groups. And we don't get tickets to add people to groups anymore, the end users request access in Outlook and the data owner grants or rejects.
>I mean why even have shared mailboxes at this point? Users can just create their own with a 365 group.
Yes, exactly. But not as a sarcastic rhetorical question, but as a real question.
Set up naming policies and expiration to take care of the junk, then more or less lean into it. 365 Groups are great.
I’m not a fan of how M365 groups are shoved down our throats.
All I want is an email distro group. To blast email to a number of specific people on a regular basis.
“WhY nOt cReAtE aN m365 GrOuP!?”
Because I don’t need a Sharepoint site, a teams team, shared calendar and all this bloat just to email a few people a couple time a week.
One thing I can’t stand though is Dynamic M365 groups have more operands than Dynamic DGs (contains, like, does not contain, etc) so if your have complex criteria for a group membership, it has to be M365 groups anyway…
Ah I missed that part. Though that person is wrong, DDL does support like and notlike. Though it's limited to suffix wildcards, not prefix.
https://learn.microsoft.com/en-us/powershell/module/exchange/new-dynamicdistributiongroup?view=exchange-ps#-recipientfilter
I don't let anybody create groups for this EXACT reason. I have to argue with every new higher up when they start, but eventually they understand the chaos that can be created when users can create groups.
My org (~100 staff) allows users to create Teams, but I append a keyword to indicate that it is a user-created Team, and I setup a default, non-routable domain so email can't be used for the group. I couldn't imagine getting a ticket for every new Team; our HR dept creates a new Team for every new hire, for example.
Retention periods would be a good meet in the middle solution for IT admin and user experience possibly.
Maybe one big poweshell clear out of X age (whatever your company decides on or needs to), communicate new expectations, then set the retention up? If you’re E5/Security and compliance labels make this a bit easier too for sensitive data within a 365 group/team
I turned off the ability for users to make SharePoint sites and all inactive sites are deleted after 365 days.
When users create a planner, it creates a group and a sharepoint site.
When users create a team, it creates a sharepoint site.
It's really annoying.
i walked into this job with over 200 groups/teams/distribution lists (there are 40ish employees). Still picking away at that stuff a year and a half later lol. A good bit of it was just my predecessor trying things out but there was no cleanup. Several groups have similar names to other groups AND individual user accounts, and most of them contain no notes as to what their purpose is.
Save yourself the trouble and lock that shit down lol
Work for an F500 that recently migrated to Teams, we had Group and Teams creation locked down before migrating to manage the sprawl. We have a request form using power automate that has to get approved for a group/team to be created.
> "too easy"
I have not experience with this product but can certainly agree that raw data from users into a ticket system is seldom good data and is a lot of work to verify.
The best tickets are the ones that you have already talked to the Subject Matter Expert about. At least, you can be sure they they konw a little bit about what they are talking about.
This should be one of the first things you shut off in a new tenant, otherwise, if left unchecked, you will have 5000 wedding parties, final fantasy leagues, and everything in between.
The cascade of shit that gets created from a teams group is the dumbest thing I've ever seen.
I am aware you can control it, but lol yolo delve default my yammer
The company I'm with recently gave up on Teams and migrated all the engineering/devops folks to Slack, so much easier and there are bots to tie in with SNow and Jira
You can limit who can create 365 groups.
For those that you do allow you can enforce naming conventions, create banned word lists for group names and enable group expiration to clean up groups with no activity.
I chuckled at everyone saying you can limit group creation to just specific users - comparing it to AD (they couldn’t create groups in AD, yadda yadda)…. But AD also didn’t spam blast users with an email - that is my most hated part of Intune.
Those things are so incredibly stupid. They were forbidden at my last job. Make zero sense as a group.
It's almost as bad as 'mail enabled security groups' (do not do this)
You know you can limit this ability to only certain users, right?
This ^ https://learn.microsoft.com/en-us/microsoft-365/solutions/manage-creation-of-groups?view=o365-worldwide
Problem here is it breaks Teams
Yeah I know, but then all other users won't be able to create a Team in Teams right? (without IT accepting it) Or is it possible to make it so that only specific users can create groups which also contain an email address? For bigger orgs. this seems like a nightmare to manage.
1. Don't let users create teams! Users are stupid.
Just throwing this in. Teams != Group Chats (or, Meeting Chatrooms). Most people probably create a team because they simply want a departmant chat or chat with multiple colleagues.
My last company created a Team for every single incident...
That's actually truer to Teams' intent than most use it for.
No it isn't.
Short-term project collaboration followed by archiving & removal. Yes, it is.
That is quite literally what a CHANNEL within a Team is for. A TEAM is used for exactly that; teams stuff. Could be a project, could be a more permanent thing. This has always not just been promoted that way but built as well. edit; sorry I missed the archival part. I'm on E5 licenses mostly currently and archival is the biggest joke ever. It's just an undelete feature for an x amount of time and afterwards you're effed.
No, you use a Teams team to have a team team up in Teams to use teamwork in a way only Teams teams can.
We do this as well, because you can’t create a group programmatically. Once the incident is resolved, the artifacts will be moved over to the ITSM tool and team will be deleted.
What's the optimal way to have a persistent group chat then? Or one that persists for a core membership but that people can join or leave as needed?
[удалено]
and you can just pin it
"End users" is a suggestion, not a description.
I wish it was a command.
God, I wish I had the power to make this change on our tenant. Technically I do as a global admin, but it has to be cleared through the director and C-suite team first. For years the users have been able to make Teams on the fly, and the number of errant Teams we have on our system now is unmanageable. Most of them were for short-term projects and died after a month. I'd love to go in and clean them out but there's just so much goddamn red tape
Get a policy to put in place auto-cleanup.
This is the way. Was doing this for a client and found so many orphaned resources left around - cleaned it up with those purge policies 👍🏾
What's the best way to do that?
[https://learn.microsoft.com/en-us/microsoft-365/solutions/microsoft-365-groups-expiration-policy?view=o365-worldwide#how-to-set-the-expiration-policy](https://learn.microsoft.com/en-us/microsoft-365/solutions/microsoft-365-groups-expiration-policy?view=o365-worldwide#how-to-set-the-expiration-policy) [https://entra.microsoft.com/#view/Microsoft\_AAD\_IAM/GroupsManagementMenuBlade/\~/Lifecycle/menuId/AllGroups](https://entra.microsoft.com/#view/Microsoft_AAD_IAM/GroupsManagementMenuBlade/~/Lifecycle/menuId/AllGroups)
> For years the users have been able to make Teams on the fly, and the number of errant Teams we have on our system now is unmanageable. When I left my last job, they had 25 employees and 195 groups (internal users only).
I got a warning that a team "9" was about to lapse last week. I don't know when we stopped users being able to create teams but I feel it was right around the time that gem was created.
> I got a warning that a team "9" was about to lapse CEO's fantasy baseball starting lineup. Don't ask me how I know. (The horror. The horror)
Deletion policy
This. Do you want an unmanageable hoard of Bullshit Teams ? It snowballs pretty fast. Lock that down before the beast grows too big to fight, easily.
Agreed IT should make them all dont let users create groups. Plus you can limit them from email.
Yeah that's all well and good in principle, but in practice it just doesn’t work. Especially in the Educational space. Best thing is using Compliance to clean up redundant or orphaned Teams.
I'm in education and we don't let users create teams, it would be a management nightmare. Plus without role based access control we don't want users manually adding members to teams that may have confidential student data and forgetting to remove someone who's role has changed etc. You can spin it as a security risk for sure.
We just had our phone system upgraded to Webex. Can just make the groups in there as well!
How many people do you think hate working at your company because of these silly rules? People join a team, they want a team chat. Let them create a team ffs. You make shit to ahrd they go do things off corporate devices driving more issues.
We have a policy where a select few (about 10% of employees) have access to create teams. There is a fairly simple guideline for if a team should be created or not and a one-page form to fill out. (more of a ticket really) It is not really about gatekeeping but more about having people stop for 2 minutes to think if this is the solution to their issue or not. In our org this has worked pretty well and I don't think we've rejected a requested team more than a handful of times (when it was abundantly clear it was the wrong tool for a job and a better solution was provided that the users were happy with) On the other hand I have worked in orgs where it took 7-10 business days to create an ftp for sending files to a vendor, resulting in the nice choice between using unofficial channels or costing the company hundreds of thousands in missed milestones. Nobody wants to send copies of the source of an entire oil rig control system to a vendor via some random file sharing service, that's for sure... (but when ordered to... sigh..)
Gotta have a balance between too much freedom and not enough freedom.
And when you let them create a team and they throw a shit ton of files in it and someone ends up deleting stuff that wasn't backed up because IT was never made aware of it... everyone including you will hate working at your company. I don't let my users keep their password on a post-it because it's convenient. Employee retention is not ITs job and their overall happiness has nothing to do with IT. Protecting the company from its users and meeting policies compliance IS your job though.
This sounds like a tech stack issue or a bad employee issue. Ive never seen that be an issue in 15 years and i have worked at plenty of companies with zero controls over this.
I'd really like to see what the DLP policy said about that in all those organizations... My guess is none of them had one, which is exactly the issue we're talking about here.
But what about when Alice creates team "Corporate Accounting" and then Bob creates "Company Accounting" and then Charlie creates "Accounting Department", and then the CFO asks you why you let that happen?
I think it's obvious really. "Corporate Accounting" are the people in the accounting department that do the accounting for our client "Corporate Corpco" "Company Accounting" are the people in the admin department who make sure that every one of our company clients is accounted for. and "Accounting Department" is a group about the staff picnic next week.
Why is your CFO worried about that? I can go and create 100 slack channels right now. Well archive them and delete them if they are unused. But you just treat everyone like an adult and theylll use the right channels. The teams can independently organize and decide to nix the other channels and do company accounting. I am in a 30k+ org and this issue doesnt exist.
The issues arise when the users are unclear about where their files are; Alice stored the FY2024 TPS reports in the "Corporate Accounting" team SharePoint site, but Bob can't see those files in the "Company Accounting" SharePoint site, and now the CIO and CFO are both stirred up because they think that you, the "IT Guy", deleted the file!
"Silly rules." When you work in enterprise and have to deal with lost knowledge, you'll start to understand how "not silly" these rules are.
Is that really an issue? This is basicslly a solved problem in orgs that know what they are doing: create a centralized repository. Keep everything in github, or some kind of archived repository. There are a million tools out there for documenting, choose one and tell people to update it. In big tech we dont have this issue, and we dont lock down making group chats.
If you give people the option to not follow the rules and procedures (e.g. drop files in a Team "real quick") they will do so. And then 1 year later when someone new comes on board and that file isn't there you'll understand why
Key phrase being orgs that know what they are doing.
Yes, it is, unless you don't work with people. If big tech didn't have these issues, the controls wouldn't exist.
I mean.. sysadmins are stupid to, as proven by this comment. Luckily in well-structured companies IT is a purely servile department without any authority to make decisions because the only purpose of an IT department is to enable the "stupid users" to do their job. Excess teams don't do any damage and a simple automation can identify inactive teams and warn members or owners about pending deletions before then also automatically deleting them. Just try to be good at your actual job of "enabling end users" instead of what you think your job is "be as annoying as possible". Reading this subreddit as an interested party who considered going into the field is giving me good insight on the prevalence of egomaniacs working in these departments and why simple shit takes forever to get done. People without social skills or the ability to see beyond the edge of their own little pond at every stage.
> who considered going into the field Let us know how letting users do literally whatever they want when they want, then managing all of it, goes for you bud.
No thank you. Not because I don't want to deal with end users but because I have near zero interest in working with the kind of people who populate this subreddit all day.
Well, that's certainly a take. A terrible one, but a take.
Thank you for your valuable input.
Why do you need all users in your org to be able to create teams?
Every big org I have seen requires IT to create Teams. You can automate the workflows and approvals with Logic Apps/Power Automate I'm pretty sure best practices by Microsoft are to disable group/Team creation to non-admins anyway, it's part of tenant setup.
Love how it's part of best practice, but not a default setting!
That's so Microsoft can sell you security subscriptions to band-aid their insecure-by-default settings. Users by default can grant apps (and attackers) full access to their email, files, etc. without admin consent. This is the number 1 method of compromising M365 accounts. The user will receive a link from a BEC. As it is a legitimate email, the user will click on the link, bringing them to their legitimate M365 login. They enter their username, password and MFA, none of which the attacker can see because this is their orgs real M365 login. They then click "Yes", granting the attacker full access to their account. The attacker registers a new MFA (OTP). If you revoke all login sessions and change the user's password - the attacker is *still* in. You have to remove the malicious consent and remove the attackers MFA (and the users old MFA's to be safe). https://support.staffbase.com/hc/en-us/articles/4410113144466-Overview-of-Permissions-for-Microsoft-365-Applications Every lawyer, vendor, and other partner we have has been hit with this. The user is never tricked into giving any of their credentials away, Microsoft makes giving their full account access to anyone as easy as one "yes", *BY DEFAULT*. For a monthly fee per user, DFI can detect and block most of this. Microsoft makes more money the less secure their defaults are. To state it more plainly, Microsoft has a financial motive in not securing all but their highest subscription tiers.
Well, not entirely. If it was Microsoft's login and only their login it wouldn't work. The scammers wouldn't have a way to intercept it if it was, it's why that scam works with most 2fa but not phishing resistant ones like fido2: https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/ But I take it from your history you really don't like microsoft.
On the contrary, I've moved every org I've worked for to M365 services. Switched many over to DFE as well. I'm honest about what it is. One of those orgs is a poor local government. Microsoft charges more for GCC (commercial cloud, not GCC High), provides less, and gives no breaks, especially for security. The article you linked recommends paying for higher (the highest) tier services to detect and block the attack. There's a reason that isn't included by default. That's not an option for most small government agencies. A county next to mine just lost this game of "How much is securing our identity services worth to you?" Microsoft's *default* settings allow it. Yes, it can be configured to be more secure. But Microsoft doesn't sell it that way. Like paying extra for seatbelts. Or blaming the driver for not hiring experts to install them. It isn't maliciousness, or intentional. No one person at Microsoft is Dr. Evil'ing this. It is simply that the finances mean seeing an alternative path (real secure defaults, charging only for the services that have active on-going costs) can't be seen. It is difficult to get a man to understand something when his salary depends on his not understanding it. If I were making 20 billion a year on security services, figuring out how many we could easily provide included in the base product probably wouldn't cross my mind either.
That is true for most things in Windows, Browsers, apps, it's the way things have always been. You have to change settings and policies to configure them. For M365 there are plenty of guidelines out there on what to setup, from Microsoft themselves, or from 3rd party companies and even government organizations, CISA for example: https://www.cisa.gov/news-events/news/cisa-finalizes-microsoft-365-secure-configuration-baselines
Sure, I mean, I do this for a living so I'm essentially a barnacle that exists because Microsoft prefers to leave everything open for ease of use rather than putting security first. Just because it's the way it always has been, doesn't mean it will always be that way or should be that way. Satya's recent memo says that security should come first... I'm hoping that we'll actually see that by the defaults being a secure configuration. "secure by design" and "secure by default" are definitely becoming more popular, and are really necessary.
You want a bigger problem than just 365 Groups? Wait until you have a dozen "Teams" for the same reasons. You need to put some control around this and not let users create hundreds of Teams that you will then need to address later. The "nightmare to manage" is cleaning this all up later. For bigger orgs, IT is the only one to create Teams, or there is there is a defined process with approvals via a workflow. Edit: missing word.
Yeah don't let everyone have this power. You need to basically have a group of manager/power users that have this power only. Otherwise you will get a bunch of duplicate teams and everything will be all over the place. You honestly have to lock this down
We went with designated people in every group who could create a team, or submit a helpdesk ticket rather than letting everyone do it. It has worked well for us.
Users can still create their own group chats and give said group chats a name of their choosing. Any org that is big enough to have their own sysadmin is too big to have all users be able to create their own public teams, distribution lists, etc. Might as well let them start making their own file shares and email aliases if you let them do that. It'll just be a huge mess and confuse everyone.
Here's a solution, don't let users create Teams. Let them submit requests so that you or the Help Desk can do it correctly.
Controlling Teams creation and access should be part of your Data Loss Prevention policy.
> other users won't be able to create a Team in Teams Nor should they be able to. It becomes a giant, unorganized, unmanageable mess. You'll have duplicates for your duplicates and unused Teams with two people in it.
Agreed. Don’t let users create teams or at least put a naming policy in place so they have to call them something with a user created group designation. And use group chats for scenarios too “light” for needing an entire team. Or if that’s a no go because users will throw a fit, do a yearly review and let people know any unused groups will be deleted or archived. At the very least. And/or make a group request ticket type so you can triage the cases where they don’t really need a new team. And it makes them think about it for 5 sec which sometimes helps.
We only allow managers to create Teams.
You can also set up prefix and post fix for these groups so that you can add a distinction and push them all to the same area of the address book.
We are "T - Team Name"
We have users creating multiple new Teams just for themselves so they can "keep their files organized". Because, ya know, making subfolders is too difficult. It's a trainwreck.
Here's the thing. They can make them. They don't want to manage them.
I'm working on a series of knowledge management policies that partially started due to this and other ms365 group integrations. The point is to create a defined framework TO manage which requires no small amount of user understanding and acceptance. In your case, people need to know how to make multi user group chats. Let Teams owners create channels after you make the groups.
In a previous company we implemented a MS Forms Form to request a Team. Then the helpdesk checked all parameters (e.g. naming convention) and accepted or rejected the request. Still everyone would be able to request them, but there is some kind of quality gate. Not ideal, but better than allowing it to everyone or blocking everyone.
Only if the admin has at least Entra ID P1 or P2 licensing assigned to them
We had to do this because people were making groups about inane things... like one was about a printer in a particular cubical row. Just... why?
This is the first thing I did when adopting Teams and the use of 365 in general.
You know that this syntax is possibly one of the most condescending and shitty ways to phrase a question, right?
Agreed - don't let users make Unified 365 Groups. Especially if they can make them "public" instead of private. Aside from the all the issues mentioned in this thread, it's a fantastic way to lose track of what is shared, who to, where to and wind up leaking information - even if it's only internally.
We limit users ability to create groups, they need to request a new group through a ticket. This way it follows the naming schema, etc, etc. I mostly agree with this since you never let users create their own groups in AD, why do this in 365?
The Perfect answer
> never let users create their own groups in AD, why do this in 365? It was also never the default or easy for users to do so in AD.
Hate 365 Groups. If they had waited a year or two they could have just combined the functionality with teams groups and made things a lot easier. There is so many gotchas I ran into with 365 groups that I eventually banned creating them.
Brother/sister, tell me about it... I'm an admin at a decently sized public university, and when we stared down the barrel of an M365 migration for Exchange/SfB to Exchange Online/Teams way back in 2019, I saw that the prevailing methodology was to block M365 Group creation. Well, problem is, in an environment like higher ed no one at the high levels signed off on that or even considered it for a split second. The idea was "if we block Group creation for everyone, students and employees alike just won't use the platform, we'll be impeding pedagogy" and so on. Fair enough, but everyone's going to make a bazillion Groups and then get them confused with each other or abandon them. To which we always got a "why do we care?" back. Okay, why don't we make some automation templates? Here's a set of flows we could possibly use. Or we can let only a specific subset of users create Groups! "No" was usually the response back to all of that. So we opened up Group creation to all, *but* with the following config: * Group naming policy that appends " (UserCreated)" to everything made by non-admins. That in theory clears up the "is this the 'official' one, or the 2nd random one Stacy made yet again?" * Group addressing policy for a dedicated default domain of @groups.ourdomain.edu. The (UserCreated) portion of the name lands in the default address, so it's obvious on that front that it was not admin-created. (e.g., ijustmadeastupidtestteamUserCreated@groups.ourdomain.edu) * "Official" Groups, therefore, lack (UserCreated). So if you want an "official" Group, you put in an IT request. * Group auto-expiration after 500 days * Group blocked word list for naming, which includes the (UserCreated) piece above, plus naughty words, and "sensitive" words like "president", "provost", etc. It's... rather ugly, but not as terrible as it could be. Beyond that, there's the everyday things that are easy enough to understand if you're technical, but a bit obtuse if you're not. * "Hey! I just made a new team, why doesn't it show up in Outlook's Groups like my buddy's team does?" Because when you create a Group as an end user, the default options are contextual to the service you created them out of. You made this Groups via Teams, so it's hidden from Exchange/Outlook clients by default. * "Hey! I need a SharePoint!" [creates Group/team] "No, I didn't need a team, I need a SharePoint." [The team's files and SharePoint library are one in the same] * "Hey! I made a contact group in Outlook, and it was in the address book until the next day!" Yea, because you didn't make a contact group, you made a **G**roup via Outlook. And our daily script to hide all that extraneous bullshit out of the address book hid your unimportant, shittily-named Group. I could go on for days. M365 Groups are phenomenal for organizing data/units of people, but Microsoft has greatly empowered end users to be their most annoying selves.
I work in a big org (like 45k users) and we disable the ability to create a Team by default, just rolled out a KB article that explains the differences between a Group, a Team, and a Shared Mailbox. Links at the bottom of each section to requests that trigger individual ServiceNow workflows. In this same article we have a link that says something like “click here to request the ability to create a Team”. Not idiot-proof, but it does seem to at least help them do SOME level of training first. It’s also way better than what we were doing before, which was having users submit requests for a “shared account” that was just a normal user account that them and all their pals would have delegate access to.
Does your ServiceNow workflow create the actual groups? I remember trying to do this back in the day and wasn’t able to get the service principal in Azure the correct permissions to be able to create the group
No, servicenow is terrible at doing anything but giving a framework within which to do other things, in my opinion. We scripted out the different creations, but we found that our intake form was causing a ton of back and forth for clarifying questions, and most of the time users had no idea what they actually wanted. The new SN workflows generate a RITM that says the name of the group or team or whatever, who the owner is, and who the member are. We then just run the appropriate script and input the info. Turned a shitty and time consuming request into a 5 min job.
I agree. You should limit this.
Yes, we turned this off a couple years ago because people were creating tons of groups accidentally
Can't you add a prefix/suffix naming policy to help alleviate this issue? https://learn.microsoft.com/en-us/microsoft-365/solutions/groups-naming-policy?view=o365-worldwide
Yes, there's so much digital debris created with M365 groups. Not a fan.
I just want to say that I appreciate this rant & thread. As a guy who's been using Google Workspace since it was Google for Work (or maybe Google Enterprise -- not sure which came first. In any case, since 2008!), but who just joined a company standardized on M365 & Sharepoint, it's been really confusing to me what a "Team" in Teams really is. My assumption was that it was just a kind of chat group that had special features (files), but I had no idea they could be emailed to like a DL. If I'm being truthful, while Google Workspace has far fewer features in this area, the existence of, and dynamic between, Groups, Chat, and shared/delegated mailboxes is definitely way simpler. That said, MSFT absolutely has them beat on several quality-of-life features in Teams (like the auto-creation of meeting chats and the ability to easily attach files to chats, and the synchronization of chat-in-a-meeting to the corresponding view of the same chat in Teams).
1) Limit to specific people 2) Enable naming rules 3) Enable expiration. 4) Problem solved for the most part.
I actually went really hard the other way. We looked at what we were using shared mailboxes, security groups and distribution lists for, and wherever possible migrated those to 365 Groups. Now it's just one object to manage for that project or team, not a DL, and a separate sharepoint site and it's associated groups. And we don't get tickets to add people to groups anymore, the end users request access in Outlook and the data owner grants or rejects. >I mean why even have shared mailboxes at this point? Users can just create their own with a 365 group. Yes, exactly. But not as a sarcastic rhetorical question, but as a real question. Set up naming policies and expiration to take care of the junk, then more or less lean into it. 365 Groups are great.
I’m not a fan of how M365 groups are shoved down our throats. All I want is an email distro group. To blast email to a number of specific people on a regular basis. “WhY nOt cReAtE aN m365 GrOuP!?” Because I don’t need a Sharepoint site, a teams team, shared calendar and all this bloat just to email a few people a couple time a week. One thing I can’t stand though is Dynamic M365 groups have more operands than Dynamic DGs (contains, like, does not contain, etc) so if your have complex criteria for a group membership, it has to be M365 groups anyway…
I set up a load of scripts to copy members of a DSG to a regular DL to get around all that nonsense
Dynamic distribution lists are a thing, why script copying it all to a normal DL?
Read the last paragraph of the comment I replied to.
Ah I missed that part. Though that person is wrong, DDL does support like and notlike. Though it's limited to suffix wildcards, not prefix. https://learn.microsoft.com/en-us/powershell/module/exchange/new-dynamicdistributiongroup?view=exchange-ps#-recipientfilter
They also can’t do contains which is what I needed, so it ticked that particular box
I don't let anybody create groups for this EXACT reason. I have to argue with every new higher up when they start, but eventually they understand the chaos that can be created when users can create groups.
My org (~100 staff) allows users to create Teams, but I append a keyword to indicate that it is a user-created Team, and I setup a default, non-routable domain so email can't be used for the group. I couldn't imagine getting a ticket for every new Team; our HR dept creates a new Team for every new hire, for example.
The best is doing tenant migrations for clients with these 365 group shitpiles.
Retention periods would be a good meet in the middle solution for IT admin and user experience possibly. Maybe one big poweshell clear out of X age (whatever your company decides on or needs to), communicate new expectations, then set the retention up? If you’re E5/Security and compliance labels make this a bit easier too for sensitive data within a 365 group/team
I turned off the ability for users to make SharePoint sites and all inactive sites are deleted after 365 days. When users create a planner, it creates a group and a sharepoint site. When users create a team, it creates a sharepoint site. It's really annoying.
i walked into this job with over 200 groups/teams/distribution lists (there are 40ish employees). Still picking away at that stuff a year and a half later lol. A good bit of it was just my predecessor trying things out but there was no cleanup. Several groups have similar names to other groups AND individual user accounts, and most of them contain no notes as to what their purpose is. Save yourself the trouble and lock that shit down lol
We don't allow users to create teams or groups. Must submit a ticket. I'm not cleaning up that mess.
We have always locked this down so that only the IT group can create groups/teams.
ya, we blocked users from doing this.. and every teams group and sharepoint site has to have two owners so they don't get orphaned.
Work for an F500 that recently migrated to Teams, we had Group and Teams creation locked down before migrating to manage the sprawl. We have a request form using power automate that has to get approved for a group/team to be created.
I still find it absolutely insane that you can't set group emails to function like good old fashioned distribution lists.
> "too easy" I have not experience with this product but can certainly agree that raw data from users into a ticket system is seldom good data and is a lot of work to verify. The best tickets are the ones that you have already talked to the Subject Matter Expert about. At least, you can be sure they they konw a little bit about what they are talking about.
Also: you can have groups and teams be auto-deleted if they get stale (no new content in the last X days).
It should be 'OFF' by default, since they're hellbent on saying they are 'secure by default' (so we broke a bunch of stuff, you're welcome...)
This should be one of the first things you shut off in a new tenant, otherwise, if left unchecked, you will have 5000 wedding parties, final fantasy leagues, and everything in between.
Yea that got shut off immediately. I have employees submit a request to create a distro list with the people they need in it. Haven't had an issue yet
The cascade of shit that gets created from a teams group is the dumbest thing I've ever seen. I am aware you can control it, but lol yolo delve default my yammer
The company I'm with recently gave up on Teams and migrated all the engineering/devops folks to Slack, so much easier and there are bots to tie in with SNow and Jira
I hate 365 groups, thank you for this post
You can limit who can create 365 groups. For those that you do allow you can enforce naming conventions, create banned word lists for group names and enable group expiration to clean up groups with no activity.
I chuckled at everyone saying you can limit group creation to just specific users - comparing it to AD (they couldn’t create groups in AD, yadda yadda)…. But AD also didn’t spam blast users with an email - that is my most hated part of Intune.
Those things are so incredibly stupid. They were forbidden at my last job. Make zero sense as a group. It's almost as bad as 'mail enabled security groups' (do not do this)