Limit Org Wide Teams to actual users with licenses
When we create an Org-Wide team it adds every "user" account in our entire Active Directory into the team. Thsi includes service accounts, exchange heal mailboxes, and all kinds of things that aren't actual people. There needs to be an option so that we can choose to only invite actual users. If it can point to an OU, we can specify our "employees" out to rule out all the non-users. If it's limited to AD Online, then it could only add people who have an actual Office 365 license attached to their account. Every time we create a service account, it gets added to the team and we have to go remove it which makes the General channel useless since it's full of spam.
Hey I saw where if you block the user from signing in then it will take them off the list.
Second this, its absolutely useless to fill these teams up with unlicensed service accounts! Let us choose an OU or choose Licensed Users at least.
Useless as it is! Adding all users with licenses should be an option at least
Completely useless option unless you can choose users only, why has this basic requirement not been implemented?
Roland Minshall commented
I would also like to be able to exclude users that are hidden from the GAL so that their email addresses are not exposed
We have an organization that has fewer than 5000 users but greater than 5000 if you count entire AD "users." This makes it impossible to use org-wide Teams. Please increase the 5000 limit AND allow an option to omit these "non-users."
We have exact the same problem. It does absolutely not make sense to add all users even those who don't have a Microsoft Teams license to an org-wide team. This feature is not usable for us how it was implemented by MS currently. We deleted org-wide Teams again.
I am having this same problem and am told org-wide is functioning as designed. The larger an organization, the more the need for exceptions to org-wide. I have tried manually removing accounts, but O365 puts them back in at a later date. I have opened a case (ticket 13951955) on this, but was told to leave feedback here in UserVoice.