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.
Anonymous
shared this idea
18 comments
-
Anonymous
commented
any news on this?
-
Anonymous
commented
Lance,
Did you actually try calling someone on Teams after the deployment via your script? Even with the rule in place, Teams will prompt to make changes to the FW rules, regardless if the rule is already in place or not. -
Lance
commented
What I have done, works great:
Create scheduled task with user logon as trigger, runs as SYSTEM account at highest priveledge, calls the following VBS script with wscript.exe
The script creates a per user rule for any users who log onto the computer, the script first checks to make sure no rule exists and excludes some default accounts.===============
Dim oFSO, oShell, fwPolicy2, RulesObject, sExclude, rule, bExists, sRuleNameSet oFSO = CreateObject("Scripting.FileSystemObject")
Set oShell = CreateObject("WScript.Shell")
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
Set RulesObject = fwPolicy2.Rules' folders to exclude
sExclude="All Users,Default,Default User,Public"' valid fw profile types?
If fwPolicy2.CurrentProfileTypes Then' get users folder and enumerate subfolders
Set fUsers=oFSO.GetFolder("C:\Users")
For Each subFolder In fUsers.SubFolders
' ignore excluded folders
If InStr(LCase(sExclude),LCase(subFolder.Name))=0 Then
' check if fw rule already exists
bExists=False
sRuleName="Teams.exe (" & subFolder.Name & ")"
For Each rule In Rulesobject
if rule.Profiles Then
If LCase(rule.Name)=lcase(sRuleName) Then
bExists=True
Exit For
End If
End If
Next
' create fw rule if not already exists
If Not bExists Then
oShell.Run "Netsh.exe advfirewall firewall add rule name=""" & sRuleName & """ program=""C:\Users\" & subFolder.Name & "\Appdata\Local\Microsoft\Teams\Current\Teams.exe"" dir=in enable=yes action=allow",0,True
End If
End If
NextEnd if
=============== -
Anonymous
commented
+1 to this. We're trying to deploy this to a enterprise environment with 300+ employees. Our initial testing with about 30 employees all had the issue of UAC prompting to making Firewall changes on 1st call on Teams. Subsequent calls did not get the UAC prompt but now have denied firewall rules. Funny thing, Microsoft Teams still works fine with the denied rules in place. This issue is pausing our project as of now there is no work around fix.
-
Harry Styles
commented
We are also seeing this issue. PLEASE GIVE US A FAT INSTALLER!
-
David
commented
This is a major hindrance to staff working on systems outside of IT control such as Guests invited into meetings or contractors working on a remote site joining a meeting and needing to SHARE content which is not possible via the web client.
There isn't a point in having a user mode installer if an Admin ACTION is still prompted after install!!!
This is Skype for business all over again!
Please look at the near frictionless experience of Webex / Zoom for group meetings of users without install privileges.
People joining conferences switch to other other products largely due to setup issues. If you have one participant struggling to connect the whole meeting gets derailed.
-
Lb
commented
I am not sure how this has been allowed to fly under the radar for so long, this is a pretty significant issue and I think installing\running anything from appdata should be discouraged. As others have said we need to have a business version of this that runs from a static path.
-
Anonymous
commented
Any solution found yet? I see Mohit's solution didn't help for some.
-
Steve Wells
commented
A proper system-wide installer of this is required, if the installation requires admin rights that is fine, we need to deploy this to a large number of users via SCCM and have zero push back due to UAC prompts.
-
Ben Giacaman
commented
@Mohit
That is not a solution. Using profile variables such as %userprofile% or %localappdata% is not recognized by the Windows Firewall because it runs as system.
-
Mohit
commented
Here is the solution:
Enable to the following using GPO
Windows Firewall: Allow local program exception :Enable
Windows Firewall: Define Inbound program exception: Enable
value: %userprofile%appdata\local\microsoft\teams\current\teams.exe
Windows Firewall: Prohibit notification : Enablenow create firewall rules :
rule 1:-
name: teams.exe profile: all enable: yes action : allow program: %userprofile%\appdata\local\Microsoft\teams\current\teams.exeRule 2:-
name: team.exe profile: all action: allow program:
%localappdata%\Microsoft\teams\current\teams.execreate a blockrule and disable it
rule 3:(disabled)
teams.exe domain: all action:block %localappdata%\Microsoft\teams\current\teams.exerule 4: disabled
teams.exe domain: all action:block %userprofile%\appdata\local\Microsoft\teams\current\teams.exeRule 5: Outbound Rule
name: teams.exe profile : all action: allow program %localappdata%\Microsoft\teams\current\teams.exePush the policy through GPO and test with the new user.
Regards,
Mohit -
Ben Giacaman
commented
Please fix this! The whole issue is not in the firewall settings. The issue is how Teams is being deployed. The MSI package still installs the actual app in the user's profile. Microsoft needs to give us an enterprise version of Teams so that it can install in %ProgramFiles% like a normal Microsoft product would and then we will be able to add the correct rules in the Firewall. C'mon, Microsoft!
-
Jeff Genovese
commented
I implemented a workaround that seems to suppress the message. Use the following as a Group Policy PowerShell Startup script for the computer account. It won't work as a regular user since they don't have access rights to the firewall settings.
$users = Get-ChildItem c:\users
foreach ($user in $users) {
$path = "c:\users\" + $user.Name + "\appdata\local\Microsoft\Teams\current\teams.exe"if (Test-Path $path) {
$name = "teams.exe " + $user.Name
if (!(Get-NetFirewallRule -DisplayName $name)) {
New-NetfirewallRule -DisplayName $name -Direction Inbound -Profile Domain -Program $path -Action Allow
}
}
} -
Anonymous
commented
Guessing the issue is the Firewall service cant resolve user variables... This is painful since onedrive and teams installs to the user profile.
-
Jonathan Klein-Wiele
commented
Same problem here. Would also appreciate a solution!
-
Chris White
commented
Teams.exe prompts for windows firewall when making calls. Adding rules to windows firewall requires elevation. Therefore creating a user based installer of software that has features which require elevation is pretty bad is it not?
In our environment Windows firewall is managed by group policy. I have tried creating firewall rules to %USERPROFILE%\AppData\Local\Microsoft\Teams\Current\Teams.exe and also to C:\Users\%USERNAME%\AppData\Local\Microsoft\Teams\Current\Teams.exe. Both of these do not appear to work and the prompt saying C:\Users\joebloggs\AppData\Local\Microsoft\Teams\Current\Teams.exe still pops up.
Can we have an installer that installs the product into the propper directory for installed programs C:\Program Files or C:\Program Files (x86). This way we can create firewall rules in our environment that will work and create a more seamless hassle free environment for our users.
I have also tried following the suggestions at this URL (https://docs.microsoft.com/en-us/microsoftteams/get-clients) and it still prompts for firewall.
The problem is people developing the software aren't taking everything into consideration. This product is going to be used in enterprises then it needs to fit with an enterprise model not a consumer model that it seems to be currently alligned towards.
-
Charles Ulrich
commented
This issue is now holding up my rollout to over 3000 users. Please advise.
-
Christian Krüsi
commented
Even adding a firewall roule for %localappdata%\microsoft\teams\current\teams.exe doesn't work. A resolution or at least a workaround would be great. Thanks.