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.

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.

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.

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?

There’s an array used to determine which apps to look for. Remove Forms from the array or filter the output to remove Forms.

Well, if Microsoft didn’t leave gaps for MVPs to fill, what else would we do?

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.

If I run it without this scope, there is no error message.

Any ideas?