Microsoft Teams Windows Firewall pop up
Issue : Microsoft Teams client is showing prompt “Windows Firewall has blocked some features of this app” even after adding Windows Firewall Rules. Issue is explained in the article https://docs.microsoft.com/en-us/microsoftteams/get-clients but no resolution.
Martin Skovmand commented
Would be awesome if it would respect the use of %localappdata%, in order to support adding the firewall rule with a GPO.
Rick Smith commented
I don't understand why MS teams cannot just comply with GPO Firewall settings like we can do with Skype. Why do we need to run a PS1 script at logon to keep adding firewall entries for every user that does not have admin rights.
ce problème décourage certains d'utiliser ce produit.
Paulo Venancio commented
Dear Support, I confirm this problem is a little bit annoying, as users are resqueting our Support about this message... In order to go forward we are planning to communicate to user to not consider this message and just click "Cancel",
BUT, can you confirm that doing that there not impact on TEAMS APP Behavior ???
because, clicking "cancel" it will create a "Block" rule in firewall, so my concern is if Teams is going to continue work normally ?
Any update on the solution or do we need to stick to workaround for the schedule task.
I am not in favor of running a schedule task just for this it will impact the login performance of the machine with no reason
MS can you please do something about this
Having various problems for one of our clients with Skype for Business Web App for the same reason!
Roger Lundqvist commented
+1! In my organization they are about to activate Teams for 55 000 users ...
Users are domain users without admin rights, so they will get this prompt.
What was misleading for me was the fact that Microsoft official article is telling that you can press the Cancel and ingnore this warning, but when you go to check the windows firewall you will see 2 Block rules for the teams.exe. This makes you think that the MS Teams will be blocked from that moment on, but it is not.
Received this message from a new laptop deployed one week ago. The first Teams call yielded the attached screen. ESC cleared the message and allowed call to proceed. Subsequent Teams call with .PPT presentation completed successfully. Still looks to be an issue.
This warrants and urgent fix. We are forced to switch from S4B to Teams by MS
We are seeing the same issue as OP. Currently just instructing users to hit cancel on the prompt. Would be nice not to have this stumbling block built into the product!
Service Desk commented
We need a solution NOW!!!!!
Rob Nicholson commented
Slightly different wish but in the same ballpark. It's good that the Teams client doesn't need admin rights to install but if the user doesn't have admin rights, would it be possible to not do whatever triggers the firewall prompt (https://i.imgur.com/Bt0qpip.png) because the user then gets https://i.imgur.com/UpaFp9y.png is they click "Allow access"
Rob Nicholson commented
>The underlying problem is that Teams is getting installed in the users profile. Why are you doing this Microsoft: simple so that users can install the full client without requiring admin rights. Many companies block admin rights locally for security reasons, e.g. nearly every pharma client we work with. At least with installing in the user's profile, they can have the rich client. Although I would imagine many a sysadmin doesn't like this - Chrome does the same.
I'm using a PS script found online. This script works but when I create a scheduled task to have it run upon user login the firewall rules gets added under the administrator profile and not the user who is logging in. I am assuming because the task is running with elevated permissions? Any suggestions?
Below is the argument in Task Scheduler:
-Executionpolicy bypass -file "C:\Teams PS1 Task\Untitled1.ps1" -parameter 'value'
Below is the PS script to add the FW rules:
$TeamsDir = $env:LOCALAPPDATA + '\Microsoft\Teams\current\teams.exe'
$firewallRuleName = 'teams.exe'
$ruleExist = Get-NetFirewallRule -DisplayName $firewallRuleName -ErrorAction SilentlyContinue
Set-NetFirewallRule -DisplayName $firewallRuleName -Profile Any -Action Allow
New-NetfirewallRule -DisplayName $firewallRuleName -Direction Inbound -Protocol TCP -Profile Any -Program $TeamsDir -Action Allow
New-NetfirewallRule -DisplayName $firewallRuleName -Direction Inbound -Protocol UDP -Profile Any -Program $TeamsDir -Action Allow
I'm using the script provided in the link above, but like everyone else, not thrilled with having to use a workaround.
I think we would all appreciate if Microsoft did one of two things.
1. Release a proper version of Teams we can deploy across the enterprise. FYI, the base installation of teams is 300MB. For everyone that has shared computers, that's subpar, and not something you'd equate with Enterprise grade software.
2. Release a statement indicating they're not changing the installation method, include an explanation on the new delivery method, and a better solution for the firewall nonsense.
Two simple options, they just need to pick one. This UserVoice post is nearing the one year mark. If Microsoft wants UserVoice to be the channel we use for these issues, maybe someone from the Teams team could participate in the thread?
What the fix for this issue ? Run sccm ps1 script ?
Be nice to have a real fix from Microsoft.
Stefan Schipper commented
The underlying problem is that Teams is getting installed in the users profile. Why are you doing this Microsoft? How should we explain this design issue to our customers? You should know much better...
Same problem here. Tryed adding teams.exe to GPO or runing a powershell or vbs to add it in the computer firewall, nothing is working.
This need to be fixed.
John McAdam commented
UPDATE | After now raising the issue with both Intune & Teams support, they have essentially said they know it’s a problem, and will put in on the list of improvements. It’s a really poor response if you ask me :( They have though said they would escalate the issue within, to try to fact track fixing the problem.