Table of Contents
Teams Joins SharePoint Online and Microsoft 365 Groups in Connector Retirement
On June 11, I wrote about the retirement of Office Connectors for Microsoft 365 Groups and SharePoint Online and speculated that support for Connectors in Teams wouldn’t last. Well, Microsoft published message center notification MC808160 on 3 July 2024 to announce the retirement of Office Connectors from Teams starting on August 15, 2024. It looks as if the retirement involves some work for Microsoft to do because it’s not due to complete until January 1, 2025.
A note in the Microsoft Developer Blog explains more about why Microsoft is retiring Connectors from Teams. The timeline is:
- Microsoft will block the creation of new connectors on August 15.
- Existing connectors will stop working on October 1, 2024.
Microsoft says that when users with active connectors post to Teams, the connector will include a notice about the impending retirement at the bottom of the message posted to the target channel.
The Future is Workflows
Microsoft says that the Workflows app (Power Automate) is the replacement and where they plan to invest future development resources, It’s hard to argue against the consolidation of “citizen development” around a single platform. Moving from Connectors to workflows is straightforward for “standard” connectors like RSS (Figure 1) or if a replacement template is available in the workflows catalog.
Things get more interesting if you’ve built PowerShell scripts to generate payloads to inject into Teams channels via the incoming webhook connector. The development of the necessary code for a relatively simple example of reporting Microsoft 365 service health in an adaptive card took more hours than I anticipated. One issue that I still haven’t solved is how to run a workflow using a service account or service principal. The implementation in Teams appears to be tied to user accounts for authentication. This is fine when a user is active within the tenant but not so good when people leave.
The Problem with Connectors
The problem with Microsoft retiring Office Connectors for Teams is that tenant administrators have no way of knowing what connectors are installed where. There’s no report in the Teams admin center, so we must resort to PowerShell. Looking through the Graph documentation, we find the List apps in team API, or its Microsoft Graph PowerShell SDK equivalent cmdlet, Get-MgTeamInstalledApp.
The API returns all the apps installed in a team, including the apps preinstalled by Microsoft and those used for connectors (above everything else, Teams is an app composed of apps). However, it’s easy to come up with a list of connector apps and use that list to filter what comes back from Teams.
For instance, I defined an array with entries for SharePoint News, RSS, the incoming webhook, and “Happy Communities” (a customized name for Viva Communities). If you think that another Office connector is in use, add its name to the array.
[array]$TargetApps = "SharePoint News", "RSS", "Incoming Webhook", "Happy Communities"
After populating the array, it’s easy to fetch a list of teams and run through each team to determine if any of these apps are present:
ForEach ($Team in $Teams) {
$TeamName = $Team.DisplayName
Write-Host "Analyzing team: $TeamName"
$Apps = Get-MgTeamInstalledApp -TeamId $Team.id -ExpandProperty TeamsAppDefinition
If ($Apps) {
ForEach ($App in $Apps) {
If ($App.TeamsAppDefinition.DisplayName -in $TargetApps) {
$Report.Add([PSCustomObject]@{
TeamName = $TeamName
AppName = $App.TeamsAppDefinition.DisplayName
Description = $App.TeamsAppDefinition.ShortDescription
AppVersion = $App.TeamsAppDefinition.Version
AppState = $App.TeamsAppDefinition.PublishingState
AppId = $App.TeamsAppDefinition.Id
})
}
}
}
}
Hey Presto! The script generates a list of teams and connectors to check (Figure 2). You can see that the connectors are associated with teams rather than individual channels, so some manual checking of each team is necessary to find which connector is targeted by the connectors.
You can download the full script from GitHub.
More Help Needed from Microsoft
I don’t mind the retirement of Office Connectors for Teams. Once Microsoft started along the path with SharePoint Online and Microsoft 365 Groups, it was always highly unlikely that Office Connectors would remain a Teams-only option. What I do mind is the lack of preparation and assistance that Microsoft gives to customers who might have been using connectors for years. It wouldn’t have taken much for Microsoft to create a list of connectors in teams as described above.
Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.
Having Microsoft.Graph 2.20.0 installed I got this error message when I run your Github script:
Connect-MgGraph : InteractiveBrowserCredential authentication failed: AADSTS650053: The application ‘Microsoft Graph Command Line Tools’ asked for scope ‘TeamsAppInstallation.Read.Group’ that
doesn’t exist on the resource ‘00000003-0000-0000-c000-000000000000’. Contact the app vendor.
If I run it without this scope, there is no error message.
Any ideas?
The permission is right, but it is an application permission and you probably ran the script interactively. When you removed the scope, I bet your interactive session had the Directory.Read.All scope and could therefore use that to read the app info. I updated the script in GitHub.
Fantastic script, thanks! For those of us that use macOS or Linux, however, the final pipe into Out-GridView is unfortunately not available, as it is only available on Windows. You can easily save the output in other ways, but if you want GridView-like functionality, I found that Out-ConsoleGridView is an available alternative that works well as a direct replacement, see https://github.com/PowerShell/ConsoleGuiTools
Thank you. This script is exactly what I needed. It’s a shame Microsoft just doesn’t include easy ways for Admins to find this information without needing MVPs like yourself to spend time making scripts that do what they should make easy to see/find!
Well, if Microsoft didn’t leave gaps for MVPs to fill, what else would we do?
Thanks Tony. Mostly getting webhooks and RSS etc results but also had 1000s of Forms app results in the script results but these aren’t connector based are they? These will just be where the Forms app has been installed/added into a Team? Currently can’t configure or add again the Forms connector as get “Something went wrong” error with bearerToken error.
There’s an array used to determine which apps to look for. Remove Forms from the array or filter the output to remove Forms.
Thanks Tony. Mostly getting webhooks and RSS etc results but also had 1000s of Forms app results in the script results but these aren’t connector based are they? These will just be where the Forms app has been installed/added into a Team? Currently can’t configure or add again the Forms connector as get “Something went wrong” error with bearerToken error.
Thanks for this, really helpful!
Hey Tony – This is helpful. However, you mentioned it being ‘easy’ to filter out non-connectors. I see you are doing this in your code by providing a list of apps to filter on. I’d agree with this if a tenant admin knows the list of connectors in their environment.
In larger environments (especially higher education or things are a little more hectic and less controlled) this becomes more challenging. Is there a known property or something that indicates whether or not something is a ‘connector’ and thus will be retired vs just an app that won’t be impacted? I modified your code to not do the filtering and of course, there’s a ton of things (activity, calling, saved, chat, etc.) that are out of scope of this retirement. However, there are things that may or may not be ‘connectors’, such as third party things like, Jira cloud, which very much may be a connector in this context. Also are there scenarios where an ‘installed’ application may be a connector and share a name with an installed application that isn’t a connector? Hopefully that makes sense; It’d be awesome if there was a better way to ‘hone in’ on applications that are connectors in this context. Any thoughts?
I really don’t have any thoughts because I can’t see the data in other tenants. All I can tell you is what I see in front of me. After that, it’s up to you to figure out what apps exist in teams and which apps are of interest.
The deadline was actually extended. However, the URL of the webhooks must be updated again by December 31, 2024.
If other system administrators are having difficulties locating the affected teams:
I have written a small tool in Golang that uses the Graph API to output the affected teams.
https://github.com/SecNex/teams-webhook-finder
This has helped us enormously, as Microsoft does not offer its own solution for reading the affected channels and teams. We have over 350 teams in our company, which we would otherwise have had to search through manually.
I hope I could help someone here with this.
Independently of my day job, I would like to create an alternative to the native “incoming webhooks”. Maybe someone will benefit from it.
Thanks for your contribution. From a quick read of the code, it seems like it’s much like the idea I implemented in PowerShell: Find all teams, find the apps in each team, if an app is present that seems like it’s the incoming webhook, report.
To anyone else contemplating using code downloaded from the internet. Remember to check the code carefully before running it in production. It’s always best (and safest) to run on a test tenant first.