If your organization, like so many others, had to make a quick transition to Microsoft Teams, you may not have a structured governance policy in place to fight teams sprawl. Tackling sprawl within your organization requires adaptation and adoption, in this insight we will explore several options to assist in the automation and moderation of inactive teams. Building moderation into your workflow can relieve your IT team of the burden of keeping sprawl in check.
In this short recorded talk, Digital Workplace Consultant Mike Dumka shares a few options for managing Teams sprawl, including:
- Microsoft’s Azure Active Directory
- AvePoint’s Cloud Governance
Who this is for
- IT leaders responsible for addressing the management of Microsoft Teams within their organization
- Technical specialists in charge of managing Teams
The following text below is a transcript of the video.
Today I'm going to be talking about how you can avoid sprawl in Teams. So, what is Teams sprawl? Anyone who’s been in the SharePoint game for a while knows exactly what we mean by sprawl. For those of you who are new to managing Microsoft Teams, which also includes SharePoint, sprawl is when you have an excessive amount of unattended or unused teams. This happens when an organization rolls out Microsoft Teams without completely thinking through the complete team lifecycle. If you’ve been following the news, you know that Teams growth is exploding. There are now over one hundred million active Teams users. That’s one hundred million employees creating more and more teams every day. Someone or something must clean up these teams after our employees are done with them. As someone who is experienced in sprawl warfare, there are a couple of problems every organization must solve.
Problems to solve
Employee self-service
The first problem is employee self-service; we absolutely want our employees to create teams when we need them. We want to support the teams open collaboration. To do this we recommend leaving things wide open, but some groups believe that limiting how many people can create teams will solve the problem. The issue with this is that you are just delaying the problem, not fixing it. You don’t fight sprawl when teams are created. You fight sprawl after employees are done with the team.
Accountability
This brings us to problem two, we want our employees to oversee the disposal of their teams when they are done. Make no mistake, this is where organizations win or lose the war with sprawl. Like when we were kids, our parents would give us toys, and would expect us to clean up after ourselves, sometimes we would sometimes we wouldn’t. It’s the same thing with teams, we want to let our employees create and collaborate, and get their jobs done, but we want to make them accountable to clean up after themselves once they’re finished.
What can we do
Now that we know what we must do, lets take a look at some of the options that are available to us:
Option 1: We trust our employees to dispose of their teams once they are finished. If this was in any way possible, you wouldn't be watching this today, so we will strike this from our list.
Option 2: The support team would dispose of the teams once they are finished of them, we don’t recommend this either as it puts too much strain on the support team. It also wastes too much time and money to have a team do something that can be automated. We will be striking this from the list as well.
Option 3: This is the first viable one, we can configure Azure Active Directory to implement a group expiration policy to automate the disposition of teams. The key with this solution is that it supports automation, is provided, and supported by Microsoft. Now while this is a good solution for some, it can’t do everything. If your org has some really gnarly requirements that Microsoft can’t support, we have to move to our last option.
Option 4: Using a third-party solution to implement an expiration policy, again, to automate the disposition of teams. Some of these third-party solutions are great, they expand on everything Microsoft is trying to do and more. They can support organizations that have more complex requirements.
Microsoft Azure
First up Azure Active Directory and their Group Expiration Policy. So here we are within Azure active directory.
Group lifecycle options
As you can see, I’m in the group expiration settings, where you can configure the three main expiry options:
Group lifetime (in days): This is how many days the group can survive without any activity before it expires. It can be as long as you want but has to be at least thirty days.
Then we have the email contact for groups with no owners, this is usually a monitored administrator address supporting MS365. The contact is in place to ensure someone is monitoring the activity of the group if there is no owner. We need to ensure there is a contact, as once the group comes close to expiring, owners will get emailed renewal notifications, this happens 30 days 15 days, and 1 day prior to the group expiry. If the group no longer has an owner, this email contact will get notified as a backup. Not only to ensure that this group stays active, but also allow group members identify a new owner.
Finally we have the option to turn the expiry on or off for all MS365 groups, when on, it can be for all groups, or only selected ones. If it’s for selected groups, this is a manual process that admins must do with each team individually, it cannot be automated in any way.
Benefits
As you can see the group expiration policy within Azure active directory has some great benefits:
- It has strong out of the box functionality which is supported by Microsoft
- You can see it's very easy to configure
- It supports automation which reduces admin overhead
Limitations
In theory these benefits should be a slam dunk to implement in any organization. However, when you dig deeper it’s important to understand there are some limitations.
You can only configure a single expiration policy for all Microsoft 365 workflows that are connected to groups, this means that whatever we configure is not only applied to teams but everything that leverages groups. This could be exchange, Sharepoint, Yammer, Planner, PowerBI and so on.
The policy can only be configured based on a group’s activity, this means that if you have some complex requirements, like your group renewal process, it must be based on when that group was created, or if you must have a group expire after a certain duration, like a project that can only last for a year, this functionality is not going to work for you.
This may not be a big deal, but this functionality requires Azure Active Directory premium licenses. This means, depending on what SKU you have for 365, it could be an additional cost.
For some organizations, they can work within these limitations, but some can’t. They need a bit more flexibility, and then that’s when we have to start looking at third party solutions.
AvePoint Cloud Governance
Now we know that there are a bunch of options out there that can help fight sprawl. Some do a good job of automating, some do a good job of reporting, some do a little bit of everything, but for us, we really love AvePoint and their cloud governance platform. For those that don't know about AvePoint, it is part of a very select group of tier zero Microsoft partners, that means they get access to new Microsoft 365 features and functionality before anyone else.
This helps ensure that AvePoint products are ready to support their customers on day one. When these new features and functionality are released, but when it comes to dealing with sprawl, AvePoint gives us a wide variety of content lifecycle options that just can’t be done using Microsoft’s out of the box tools.
Group lifecycle options
So, just like Azure lets hop into the group lifecycle options for AvePoint, it’s important to know in this context, with Azure you currently only have one option for life cycle management you only have one option, with AvePoint you can have as many as you want.
The deletion of the group/team, this allows deletion of the group or team once the inactivity threshold has been reached or the lease expiration is up. This means that when your group runs out of time, it’s deleted.
Then we have the extension of the group or team lease, this allows the extension of the group or team when the inactivity threshold is reached or when the lease expiration is up. Essentially this allows you to keep your team active, the extension period can be set for as little as one day up to several years.
Then we have the group or team policy change, when enabled it allows the site users to change the policy associated with the team or group, and example of a policy change would be to allow or remove guest users. These changes can be supported by approval workflows if your organization requires that.
Next is the Microsoft 365 group teams site quota change, when enabled it allows you to update the site quota to increase or decrease within a certain storage threshold.
Then we have archiving of the team, this option is only available for Microsoft Teams, by default when a site is archived all files and conversations associated with that site become read only, but site owners can still modify the membership.
With this option this allows us to remove all members or owners, we can configure new accounts as owners while the site is an archive state, or we can come up with a combination of those two options to come up with something custom.
Then finally we can restore an archive team, again, this is only for Microsoft Teams it allows us to restore teams once they’ve been archived. This is something your org may or may not want depending on the workload. This option again, can be supported by approval workflows if your org requires.
Inactivity thresholds and lease management
Now that we have our lifecycle management request types defined, lets move on to defining our inactivity thresholds and our lease management. The first thing you are going to see, is that it is very similar to what is offered by Microsoft out of the box with Azure Active Directory, but it has a few more bells and whistles.
First, we can configure the inactivity threshold to be as little as one day up to several years but then we can configure additional actions or tasks that need to be completed. For example we can either delete or archive the team once the threshold has been reached, also we can backup these actions with the support of approval workflows, if you want an additional layer of oversight.
Then if we move down to the group or team lease management, we can see that this is very similar to what is out of the box with Azure and the expiration policies. We still have all the same options as I said, and the lease can be as little as one day or up to several years, also once a lease expires and or is not renewed, AvePoint can automatically delete or archive the team, again with or without approval workflows. The big difference between these two options, lease management and inactivity threshold, is that one is based on people no longer using it, and lease management is based on a set period.
Why we recommend AvePoint
This AvePoint demonstration was for a single lifecycle management policy, unlike with Azure Active Directory, with AvePoint you can have as many of these policies as you need to support your governance requirements. Also, everything AvePoint Cloud Governance offers can be used to clean up what you currently have, sometimes this is called create and chase, you set up your policies and turn them on. Owners will get a notification letting them know what policies are being applied to their team or group. They are also notified if their team or group is an active or inactive team or group, or if they have a lease that needs to be renewed. AvePoint will even let owners know if their site is going to be archived or deleted if they are not compliant with current policies. Everything is automated and the accountability shifts back to your employees, when it comes to AvePoint, this is just a small sliver of what the product can do, but you can see why we love them so much.
Takeaways
Either way you go, with Azure or AvePoint, there are a couple of points we'd like to leave you with:
- Leave self-service open so anyone can create a team when they need it
- Implement an expiration policy that makes employees accountable for keeping their Teams active, if they stop using them they will automatically be disposed of
