How can we make Microsoft Teams better?

← Public

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.

194 votes
Sign in
(thinking…)
Sign in with: facebook google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

31 comments

Attach a File
Sign in
(thinking…)
Sign in with: facebook google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
  • Rob Nicholson commented  ·   ·  Flag as inappropriate

    >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.

  • YK commented  ·   ·  Flag as inappropriate

    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

    if($ruleExist)
    {
    Set-NetFirewallRule -DisplayName $firewallRuleName -Profile Any -Action Allow
    }
    else
    {
    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
    }

  • NF commented  ·   ·  Flag as inappropriate

    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?

  • Anonymous commented  ·   ·  Flag as inappropriate

    What the fix for this issue ? Run sccm ps1 script ?
    Be nice to have a real fix from Microsoft.

  • Stefan Schipper commented  ·   ·  Flag as inappropriate

    +1
    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...

  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Jan commented  ·   ·  Flag as inappropriate

    Even though, the following may not comply with someone's security understanding, and the port range may not be 100% accurate, I would like to share this information. Please handle with care:

    You can create two 'Inbound' Port rules:
    1. TCP, Allow Ports 50000-50059
    2. UDP, Allow Ports 3479-3481, 50000-50059

    As a result, the windows firewall will not prompt the user for rule creation anymore.

  • Kazzan commented  ·   ·  Flag as inappropriate

    This should be configurable by MDM or GPO to create these rules in firewall in native Microsoft operating system. Really lowering security says user "do not follow security prompt".

  • Johnnymac1974 commented  ·   ·  Flag as inappropriate

    I am currently working on a 2000+ Win 10 Azure/Intune deployment, and really need a tried & tested non GPO based solution! :( I will get this raised with Microsoft shortly , and will post my findings.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Getting error like
    desktop-bbd2dcf3-b91b-41bf-bf9b-c32d43d4b105
    Error code - Request timeout
    Failed to connect to settings endpoint

    Not able to login Microsoft Teams Desktop App but allowint to login Microsoft Teams web application

  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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, sRuleName

    Set 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
    Next

    End if
    ===============

  • Anonymous commented  ·   ·  Flag as inappropriate

    +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.

  • David commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

← Previous 1

Forum Home

Reference Information for Teams

Public: Desktop

Feedback and Knowledge Base

(thinking…)

More Teams Information