Teams best practices: Deploy Microsoft Teams and stay in control

Microsoft Regional Director Benjamin Niaulin covers Microsoft Teams best practices to ensure a successful rollout.

Related Reading: Teams governance best practices for IT admins

A powerful addition to Microsoft’s cloud-based productivity suite, Microsoft Teams empowers users to create the tools they need without having to go through IT.

But there’s more to a successful rollout than enabling the app and stepping back. Without a bit of guidance, things can go sideways fast.

Before deploying Teams, there are a few things you need to understand…

Download a copy of my slides.

Microsoft 365 and the modern workplace

You made it through the ultimate Microsoft 365 migration checklist and moved to Microsoft 365. Hurray!

But you can’t just move to Microsoft 365 and expect everything to stay the same. The truth is that employees today are accustomed to working how they want, when they want, with whichever tool works best. With the productivity suite in Microsoft 365, Microsoft has provided technology that enables your organization to benefit from these new ways of work.

To take full advantage of the entire suite of Microsoft 365 productivity tools, you still need to make the transformation to Microsoft’s modern workplace. And Microsoft Teams helps enable that transformation—it’s a product that embraces that change and jumps right into it!

But Microsoft Teams is just one piece of the productivity puzzle. To successfully deploy Teams, the way our IT departments think about and use technology needs to go from classic to modern.

Key characteristics of the modern workplace:

• Modern vs classic user experience
• Intent-driven vs technology-driven
• Cross-product governance
• Product team vs IT team

For more tips on modernizing your overall Microsoft 365 environment, check out the recap and recording of my last webinar, You made the move to Office 365—now what?

What is Microsoft Teams?

First, let’s get something straight.

When I talk about Microsoft Teams, there are two things I mean:

1. Teams the chat tool
2. The brand around Teams that represents a new method of collaborating.

Microsoft Teams is a tool that enables people to chat, make calls, have live meetings, and share docs. But Teams is also a “hub for productivity”—the brand of it, the space where productivity happens.

Teams is a chat room

Try to keep things in perspective.

Ultimately, Teams is a white box where people chat. It’s a space you create for people to have ongoing chats about different intent-driven projects.

Teams is not a place to store files. The files you see stored in the Files tab aren’t stored there because Teams isn’t capable of storing them. It’s showing your team’s files that are stored on your team’s team site in SharePoint. Still with me?

The power of Teams is that you have the chat room, and then you have the tabs at the top that allow you to see things from other parts of Microsoft 365—or outside of your tenant completely!

It’s the tool that allows you to grab content for a specific group of people from whichever tool is better at what it does—then lets you display it right there with your team and colleagues. People don’t have to jump from SharePoint to Outlook to Wiki and back. They stay in the same tool.

Teams vs channels

When you create a team, it sits directly underneath your organization. Within each team, you have channels, which hold conversations, other files, tabs, and connectors.

Teams:

• Collection of people, content, and tools surrounding different projects.

Channels:

• Dedicated sections within a team to keep conversations organized.
• Places where everyone on the team can have open conversations.
• Can be extended with tabs, connectors, and bots.

Teams permissions: owner vs member vs guest

With Teams, it’s important to identify who the team owner is.

That’s because they’re the ones responsible for editing settings and keeping track of membership within their team.

It’s important to ensure that every team has an owner—that way someone is always accountable for the resources they create.

Microsoft Teams and the Microsoft 365 ecosystem

So how does Teams fit into Microsoft 365? Every time you create a new team, there’s a lot that happens in Microsoft 365 behind the scenes.

To really understand and take full advantage of Teams, you need to understand how it interacts with Microsoft’s whole suite of cloud productivity apps and tools.

Good to know:

• When you create a team in Teams, there’s automatic provisioning going on behind-the-scenes as well.
• To go modern, you’re going to have to go flat.

More than a standalone app

Think you’re only deploying Teams? Think again.

When you create a team, on the backend, you also create a Microsoft 365 Group and the associated SharePoint document library and OneNote notebook, along with ties into other Microsoft 365 cloud applications. If you’re not careful, you could wind up with 2,000 SharePoint team sites you had no idea existed (true story).

And if you don’t have SharePoint Online enabled, Teams users won’t always be able to share files within the app. Although if you’re using one-on-one chat, you’re actually using OneDrive for Business, so you’ll need to have that enabled.

Going flat to go modern

Microsoft’s new Microsoft 365—the modern workplace we’ve been talking about—is flat.

There are a few reasons why you’ll need to go flat if you want to go modern:

1. Subsites can’t be modern
2. Microsoft Teams and Microsoft 365 Groups only work with top-level sites
3. Microsoft is rethinking architecture with the introduction of hub sites

Every single Teams chat room comes with a modern SharePoint team site. And remember what I said earlier about Teams? They’re flat under your organization.

Within the Teams app itself, there’s no way to organize your teams in groups that make sense—they’re just listed in your sidebar on the left. Ultimately you want people to love and come back to a tool, so you want them to be able to find things when they need them.

If you already have SharePoint established and your infrastructure includes a lot of subsites, those subsites won’t work with Teams. Because Teams can only be added to a top-level site. There is a way to logically restructure—with hub sites—but that happens on the SharePoint side of things.

Check out the recap of my last webinar, You made the move to Office 365—now what? for a more in-depth explanation of how and why you should consider going flat.

Microsoft 365 Groups: the behind-the-scenes player

First, let’s eliminate some confusion: do not ask when you should use Microsoft Teams vs SharePoint vs Microsoft 365 Groups.

That questions doesn’t make sense. They have three totally different purposes. Teams is for chat, SharePoint is for docs, and Microsoft 365 Groups is the behind-the-scenes player.

When a Microsoft 365 Group is created, there are little robots behind the scenes that automatically create a workspace attached to that group—and by extension that team—in the various Microsoft Products.

Microsoft 365 Groups is not a product, nor does it compete with any of the others. It’s just like your Security Groups, but with a provisioning robot and a sense of centralized management.

The true power of Microsoft 365 Groups is that it leverages the power of all the tools in the suite, and brings everything together.

Managing Microsoft Teams

Let’s go ahead and take a look at the Teams admin center. You should be able to see and manage the Teams portion of each Microsoft 365 Group.

Here, you can edit some basic settings. If you go to Teams policies, you can create private channels and things like that. There are some org-wide settings you can see here as well.

But most settings in your Teams admin center are about chatting or voice functions. They only apply to Teams the product (singular). This is not where you’re going to be managing your teams so they scale with your environment.

The secret to successful Teams governance that scales is realizing that a team’s workflows aren’t attached to your Microsoft Teams chat room—they’re all attached to your behind-the-scenes player in Azure AD. They’re attached to an Microsoft 365 Group.

Managing and governing Microsoft 365 Groups

Because it’s so easy for end users to provision new groups accidentally as they learn the ropes in Microsoft 365, many IT admins are wary of enabling self-service features for everyone. They want to avoid the dreaded sprawl.

But an IT-led provisioning model—where users depend on IT to approve each new group creation request—is inefficient and virtually impossible to manage at scale. Not to mention the fact that users frustrated by a lack of control are more likely to turn to shadow IT.

Luckily, you have more than two options to choose from when it comes to managing Microsoft 365 Groups creation.

Instead, you might consider enabling self-service alongside these governance best practices:

• Group creation policy
• Group naming policy
• Identify inactive groups

Group creation policy

Maybe you want to let some users create their own resources in Microsoft 365—for example, power users who have already been trained and are comfortable with Microsoft 365 Groups and Teams.

In this case, you might consider creating a security group containing only those users, and then running a PowerShell script to disable self-service group creation for everyone else. In other words, you might consider implementing a group creation policy.

The ability to set a group creation policy originated as a setting in an OWA mailbox policy, and is still used for OWA and Outlook 2016. But you can now implement a group creation policy as an Azure Active Directory (AAD) settings object.

For step-by-step instructions, check out Manage who can create Microsoft 365 Groups in the official Microsoft docs. Note that to use this method, you’ll need either an Azure AD Premium license or an Azure AD Basic EDU license.

Group naming policy

Which group named “Sales” is actually active? And why is there a group called “pArTy123”?

With a naming policy in place, you can figure out the function of each Microsoft 365 Group fast—ultimately, making it easier to avoid duplicates and archive what you don’t need.

You have two options for setting a group naming policy:

1. Create a distribution group naming policy within Exchange.
2. Create a group naming policy at the Azure AD level.

You might also consider creating an effective naming convention within your organization that relies on end user education and trust.

Set a distribution group naming policy within Exchange

IT admins have had the ability to create a distribution group naming policy since Exchange 2010. The policy is stored in the Exchange organization configuration settings, and is still available today in both on-prem and cloud versions.

With a group naming policy in Exchange you can:

• Specify that a prefix, a suffix, or both be applied to all distribution group names.
• Block certain words from being used in names.

Prefixes and suffixes can be either a string, an attribute, or some combination of the two. They can also contain sequences of multiple attributes or strings.

Common implementations might include the following attributes:

• Department
• Company
• Office
• StateOrProvince
• CountryorRegion
• Title
• CustomAttribute1 to CustomAttribute15

A distribution group naming policy is set either through your Exchange admin center (EAC) or PowerShell. Admins can override to create a group named according to their requirements.

Use the following syntax if using an attribute to create a naming policy: <PrefixAttribute><GroupName><SuffixAttribute>

If using strings to create a policy, use this syntax: string<GroupName>string

So if you wanted to create a naming policy using the string DL_ as the prefix, you would use the following: DL_<GroupName>

For step-by-step instructions on using PowerShell to create a distribution group naming policy, check out the official Microsoft documentation.

Set a group naming policy at the Azure AD level

When Microsoft first released Office 365 Groups in 2014 (now Microsoft 365 groups), using the distribution groups policy was the only option—and it might sound like a good thing to have one policy applied consistently to both distribution groups and Microsoft 365 Groups.

However, configuring settings in Exchange only apply in Exchange—not for other applications like Power BI and stream that create groups but don’t communicate with Exchange. Which is why this past spring Microsoft rolled out a naming policy that applies to all Microsoft 365 applications.

Microsoft’s new naming policy uses settings in the Azure Active Directory policy for Microsoft 365 Groups—meaning all Microsoft 365 applications can access the policy to retrieve the naming controls.

Similar to the distribution group naming policy in Exchange, this group naming policy consists of the following features:

• Prefix-suffix naming policy
• Custom blocked words

It’s worth noting that this method requires an Azure AD Premium P1 license or Azure AD Basic EDU license for each user that is a member of one or more groups (including guests).

Identifying inactive groups

Like any object, a Microsoft 365 Group might become unused over time. And if you’re not careful, those inactive groups can pile up real fast. Keeping your tenant tidy and up-to-date improves usability and keeps potentially sensitive company information secure.

Microsoft currently offers no method to detect which of your groups are going underused. There is, however, a PowerShell script that can do the job for you.

It does this by:

• Checking audit records to establish whether there’s been any SharePoint activity in the group document library within the past 90 days with Search-UnifiedAuditLog; and
• Checking whether any conversations have taken place in the group mailbox in the last year with Get-MailboxFolderStatistics.

An HTML report is generated at the end with statistics like:

• Number of groups scanned
• Number of potentially obsolete groups (based on document library activity)
• Number of potentially obsolete groups (based on conversation activity)
• Number of Teams-enabled groups
• Percentage of Teams-enabled groups

See the full script to create a Microsoft 365 Groups and Teams activity report in the Microsoft TechNet documentation.

Coding not your thing? Consider using a third-party tool to automatically flag inactive Microsoft 365 Groups.

Building compliance into Microsoft 365 Groups

How can you ensure Microsoft 365 Groups are compliant across all the workloads they encompass? Use functionalities delivered through your Security & Compliance Center (SCC) rather than each individual workload.

Microsoft 365 Security & Compliance Center

The Microsoft 365 Security & Compliance Center lets you grant permissions to anyone who performs compliance tasks—like device management, data loss prevention, eDiscovery, retention, etc. These people can only perform tasks you explicitly grand them access to.

The new Microsoft 365 security center and Microsoft 365 compliance center—announced at last year’s Ignite and made generally available this spring—enable you to do the same thing across all of your Microsoft 365 services.

Permissions in the Security & Compliance Center are based on the Role Based Access Control (RBAC) permissions model. So if you’re already familiar with Exchange, you’ll find granting permissions in the Security & Compliance Center to be very similar because they both use the RBAC model.

From the Security & Compliance Center, you can implement:

• Audit log search
• Content search
• Secret groups
• Dynamic groups

Audit

Who created the team named “Contoso”? Who changed the channel settings? And who made Mallory team owner?

Another feature you can access from the Security & Compliance Center is your Audit log. Running an Audit log search allows you to investigate specific activities across Microsoft 365 services.

There’s two ways you can use Audit log search:

• Reactive: Review past events.
• Proactive: Get email notifications for new events.

This feature is turned off by default, but once enabled keeps a running record of the last 90 days.

Content Search in Microsoft 365

Who posted about “Longhorn”? What messages have been posted to the channel called “Secret”? And how can I find all messages from Mallory?

The Content Search eDiscovery tool in your Microsoft 365 compliance center allows you to search for in-place items like email, documents, and instant messaging conversations across your tenant.

You can search for items in these Microsoft 365 services:

• Exchange Online mailboxes and public folders
• SharePoint Online sites and OneDrive for Business accounts
• Skype for Business conversations
• Microsoft Teams
• Microsoft 365 Groups

Running a Content Search shows you the number of content locations as well as an estimated number of search results. You can also see statistics like which content locations have the most items that match your query.

For detailed instructions on how to create a content search, check out the official Microsoft documentation.

Secret groups

Sometimes you need certain things about a Microsoft 365 Group to be kept private.

Sensitive groups can be hidden, from your Global Address List (GAL) and membership. Just make sure to set sensitive groups to private to avoid casual searches for confidential documents. It’s also a good idea for users to mark secret groups as favorites so they’re easily accessible in all clients.

Check out my webinar recording or download my slides for the script.

Dynamic groups

Maybe you need everyone in the marketing department to be a member of one group. But what happens if people leave, or new employees are hired? In that case, try creating a dynamic group.

Dynamic Microsoft 365 Groups are implemented through queries executed against Azure Active Directory. The queries defining group membership can only be created and maintained through your ADD console.

You should also know that you’ll need an ADD Premium license for every account that comes in scope for a query used by a dynamic Microsoft 365 Group.