Top Ten Mistakes of Microsoft Teams Administrators - PART 1

Putting aside the clickbait-y title (which I created, so lay the blame at my feet), there are a number of mistakes I see Microsoft Teams administrators make on a regular basis.

In my previous Solutions Engine blog article "Challenges with Microsoft Teams Administration", I mentioned how when designing the MS-700 exam, myself and a number of MVPs and Microsoft staff discussed/debated what a Microsoft Teams administrator should know.

As with many things, the answer is subjective. It depends on what other roles exist in the team, what other teams exist, what the size of the organisation is, and so on.

Regardless of these, because Microsoft Teams sits on top of, and integrates with so many areas of the Microsoft 365 platform, any administrator worth their weight should at least be aware of the associated areas.

The below list is in no particular order of importance, as my point is that they are all arguably equally important.

Ignoring Security

Security in Microsoft 365 is a number of different things. It includes devices, identity, content, access, etc. So, when considering the security of Microsoft Teams – no areas can be ignored.

It doesn’t make sense to have Conditional Access policies applied restricting access to Microsoft Teams from unmanaged devices or locations, when SharePoint doesn’t follow suit – because we can still get the files.

Admins need to be across all areas of Defender (or whatever it’s called at the time you’re reading this blog post), and how it interacts with areas of the platform that are not Microsoft Teams.

Going too strong in one area of security can cripple functionality within Microsoft Teams, create unnecessary support calls, and in fact drive people towards shadow IT.

Security must be balanced with usability, and cross-platform experiences. It also needs to be documented, trained, reviewed, adjusted, documented, trained, reviewed, adjusted, documented, trained, reviewed, adjusted, documented, trained…

(No, that wasn’t a typo: security is an ongoing effort and responsibility of both admins and users that never ends.)

Ignoring External Users

This one is a can of worms, because many of the apps in Microsoft 365 have different features and controls around external users. Here we have to rely on controls in Azure Active Directory and SharePoint to help us to manage guests, access to shared channels, access to content from file libraries, multi-factor authentication, etc.

In Microsoft Teams alone we have a number of different options:

But that’s just for guests!

Those of us who switch tenants regularly lament the fact that there are chat conversations between guest versions of an external person in our tenant, and their federated version. Why not make this easier and disable chat for guests? Want to chat – go back to your own tenant.

The same applies to private calls, and the ability for guests to edit/delete the messages they send in chats or channel conversations.

We also have a number of other options under meeting settings:

How many times have you been in a meeting where you as an external participant have the ability to mute other people, or even remove participants? Sure, this can be set at a per-meeting level, but why not set it at the organisational level like it was back in the Skype for Business days – when external users were attendees by default?

But be careful not to go too hard on this, as people will work around it. A simple scenario is where admins disable the ability for external users to request screen sharing control. I’ve been on calls where this was in place, and the users asked if we could join a Zoom call instead so they could do it. And unless devices are so locked down that users can’t install or run anything in their own profile – you’ve now lost any logging or visibility into the fact that there was a screen sharing experience.

Organisations need to have business-level policies for these, and the tenant settings to match.

Ignoring SharePoint

Admins need to understand that in order to truly know Microsoft Teams – they need to understand SharePoint. It’s not to say they need to be SharePoint experts – but they need to understand how much SharePoint powers functionality in Microsoft Teams.

Files and Lists – they all live in SharePoint. The permissions of them, and sharing is all governed by SharePoint. This flows into access around private channels, shared channels, and guest access. It also factors into guest expiration policies that may apply, and what type of shared link SharePoint defaults to.

Additionally, admins need to consider metadata, folder structure, and versioning - as these can all become a big mess if not understand by users, support staff, and the admins themselves.

Ignoring Groups

This is a big one. Microsoft 365 Groups come in all shapes and sizes. And by that, can be created in a variety of different ways, and operate in numerous scenarios.

And because Microsoft 365 Groups have so many associated components – how does all of this factor for Microsoft Teams administrators?

If a Team is created on top of an existing SharePoint site (known as “Teamifying”) – will it get all the relevant controls and settings that you would normally include in your provisioning process? No. Can you control the ability for people to Teamify a SharePoint team site? Also no.

For this reason, admins need to be continually reviewing newly created Teams and understanding their source. What about the requirement to target a policy or access to an app to a group? At the core of them, Microsoft 365 Groups are powered by Azure Active Directory, which allows us to use them as container objects for groups of users.

However, by default Microsoft 365 Groups are not security-enabled. So, either that needs to factor into the provisioning process, or admins and support staff need to be aware of this capability, so they don’t necessarily create duplicate security groups in order to meet the objective.

Which leads me to yet another point on this topic… membership. Within Azure Active Directory we can set groups to either have assign or dynamic membership. If we chose the latter path, then no member can ever be added to or removed from the Team – so how can we have a scenario where users of a department are automatically added to a Team, but other people can also be added if required?

One approach to this is to use security groups with dynamic rules for the membership management and policy/app/permission targeting, and leave the Group/Team membership as assigned – but then we need some form of synchronisation to occur between them. Thankfully Power Automate already has a template ready to go for this exact requirement.

And lastly, the mailbox and distribution list functionality of the associated Group. (This is by no means the last point on the topic, but at some point I need to get off my soapbox.) All too often admins and users alike forget that the underlying Group has the capability to be a shared mailbox and calendar, as well as offer distribution list functionality.

So if you need to still receive emails for the Team members – you don’t have to have them appear in the channel just because it has an email address. You can still use the underlying Group just like you normally would with a shared mailbox and/or distribution list. Unfortunately this particularly functionality is all-too-often forgotten about by both users and admins, and duplicate instances get created – leading to further confusion and challenges around membership management.

Ignoring Compliance

Data Loss Prevention, sensitivity labels, and retention policies are just some of the elements admins need to be across.

Retention policies applied to SharePoint sites don’t include those associated with Microsoft 365 Groups, and by extension Teams. For that you need a different retention policy. And what if they don’t match?

Additionally, retention policies for Teams can’t be in the same retention policy as the SharePoint sites previously mentioned. Again, we need to ensure that they somehow meet in the middle and match the organisation’s business policies and regulatory requirements.

The same challenge occurs for sensitivity labels – where we can apply one label on the Team itself, but a different label on the content within it. For example, we can have a sensitivity label that prevents guests from being added to the Group/Team, but a permission level on the SharePoint site that allows for content to be shared with external users anonymously.

How do we capture that? How can we control that?

Perhaps in that instance, we have sensitivity labels that apply to the files themselves – so while they can be shared anonymously, only those with the correct access can actually open them.

Again, we’re drawn into the requirement to understand SharePoint, security, external users, Groups, AND compliance settings in order to make the solution work.

Unfortunately, if IT admins are not across a number of these areas, it can lead to an increase in support tickets, user frustration, and shadow IT.

Now, it’s unrealistic for admins to be across the detail and specifics of all of these, but it’s not unrealistic, nay – it’s a downright requirement that admins at least be aware and have at least a high-level understanding of all of these areas and more, in order to provide a cohesive, compliant, and usable user experience.

And just when you thought we were done here, you’re now left with the knowledge that in Part 2, I’ll cover: devices, usage, lifecycle, integration, and finally – user experience.

Check out Part 2 now!

Exchange Hybrid and Office 365 Monitoring and Reporting

On-premises components, such as AD FS, PTA, and Exchange Hybrid are critical for Office 365 end user experience. In addition, something as trivial as expiring Exchange or AD FS certificates can certainly lead to unexpected outages. By proactively monitoring hybrid components, ENow gives you early warnings where hybrid components are reaching a critical state, or even for an upcoming expiring certificate. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.

Access your free 14-day trial of ENow’s Exchange Hybrid and Office 365 Monitoring and Reporting today!