Image of the Teams, PowerShell, Windows Defender and PowerShell logos
Home ยป Microsoft Endpoint Manager ยป Intune ยป Modern Management ยป Managing Microsoft Teams Firewall requirements with Intune

Managing Microsoft Teams Firewall requirements with Intune

With over 44 million active users, Microsoft Teams is not going away anytime soon.
It’s rise in popularity also means that old issues arise a new for a lot of tenants that have not fully utilized the Teams client in the past or have just begun the transition to Office 365 ProPlus that includes Teams.

And you might end up hearing something along these lines from your friendly Help Desk staff:

Users keep bugging us about this annoying ‘Windows Security Alert’ that the Windows Firewall throws every time they try to share their screen in Microsoft Teams“.

And you might ask: “Can I use Microsoft Intune to silence this madness?“.


I’m glad you asked – because Microsoft Intune can most certainly help you out!

But it requires a little PowerShell magic, as the built-in Firewall CSP is unable to handle user based path variables.

You see – as far as I can tell, the Microsoft Teams executable, requires an inbound Firewall rule, when it detects that you are on the same domain network as another party in the chat.

Teams will automatically try and create the required rules, but they require admin permissions. Which most users don’t have, so they will dismiss the prompt.

Ironically enough. Dismissing the prompt will actually leave you with two blocking Firewall rules for Teams.exe, which will force the Teams client to connect via other means.
So it was able to create firewall rules anyway?! Go figure…

Things get complicated because the Teams.exe file is usually installed per-user in the users own APPDATA folder (%localappdata%\Microsoft\Teams\current\Teams.exe), so we need to create a Firewall rule for each user on the Windows 10 Device – not doable with the built-in Firewall CSP.

Now on the other hand, if you have deployed the Teams machine-wide installer, you are able to just create a single Firewall rule with Intunes built-in Firewall CSP.

But that’s no fun, so let’s take a look at how you can crack this “per-user” nut with PowerShell and Microsoft Intune!

The script

Taking a glance at the official documentation (and solution) from Microsoft over at:

You can see that it’s a fairly simple solution.

Find all the user profiles currently on the system – check they have Teams installed – add Firewall rule for the found user profile.

Should work. And in most cases it will! But it’s not really that intelligent…

I have taken the liberty of writing you a new script specifically designed for Intune!

Fetch it from my Github repository:

So how is this more intelligent you might ask?

Well this new script has been designed to be deployed as an Intune PowerShell script assigned to a group of users. Which means that it will only run once per user, and it will also be able to tell who is actually signed in to the device. Thus only creating the necessary rules for the signed in user.

As an added bonus – the script also does a cleanup of any existing rules the user might have gotten by dismissing previous Firewall prompts.

Configuring a PowerShell script deployment with Intune

Let’s get you sorted out!

I hope you grabbed the PowerShell script already from GitHub (and have it handy), with the script saved as “Update-TeamsFWRules.ps1“.

Head on over to the Microsoft Endpoint Manager admin center at and follow along:

  • Fill out the basic information with something self explanatory like:
    • Name: “Teams firewall prompt fix”.
    • Description: “Gets rid of help desk calls regarding the Microsoft Teams Windows firewall prompt”.
  • Click “Next“.
  • Leave the “Script settings” as is. And stick to just adding the script through the “Select location” option.
    • Choose the file you previously saved as (1-3) “Update-TeamsFWRules.ps1“.
  • Click “Next“.

You want the script to execute in system context, and specifically NOT the users context, as the user does not hold enough permissions for the script to complete.

  • Assign the script to a group of users (Not devices as that’s not what the script was designed for):
    • Click (1) “+ Select groups to include“.
    • (2) Search for the groups you would like to assign the users to.
    • (3) Click on the group from the search results.
    • Notice that it’s actually in the “Selected items” area.
    • Click (4) “Select“.
  • Click (5) “Next“.
  • Review the summary (1)
  • Click (2) “Add

That’s it!

Now sit back and relax while the Intune backend chews on this new script…


If you followed the above instruction, what could possibly have gone wrong?

Well lots of things I’m sure, as a large testing facility and cool minions is not something I have handy.

That’s why the script has been supplied with comments, so you can figure out what’s going on.

Adding to that, a log file can be found in “%windir%\Temp\log_Update-TeamsFWRules.txt” to help you in tracing the root cause.

If no log file is found, then check Intune to see if the script has actually executed on the system, and recreate the policy if nothing runs within a few hours even after restarting the “Microsoft Intune Management Extension” service.

If the script has run without any errors, a copy is also placed in the users own Temp files “%localappdata%\Temp\log_Update-TeamsFWRules.txt“.

Intune Management Extension is required for Powershell scripts to be executed from Intune, so make sure your device is eligible for this extension.

Remember to only assign this to a group of USERS and DON’T run it in the users own context.


We now have a simple way of deploying Firewall rules that target programs installed in the users profile.

In the future this might come in handy for a bunch of other programs.

I hope you benefit from this solution and do me the honor of following me on Twitter (@michael_mardahl) where I will gladly try and answer your queries regarding Intune and what I blog about in general.


Michael Mardahl

Michael works as a Microsoft Certified Cloud Architect with APENTO in Denmark. He specializes in customer journeys from classic Infrastructure to Cloud consumption with a strong focus on security. And has been working in the IT industry for more than 20 years, where he started as a Network Administrator in the logistics industry. He has gained experience through a broad range of IT projects throughout the years and was very early to embrace and share his cloud technology passion. When not at work, Michael enjoys the value of spending time with family and friends and BLOG's passionately about Microsoft cloud technology whenever he has time to spare - this has earned him the title of Microsoft Most Valuable Professional (MVP) in the Enterprise Mobility category.


  • Hi Michael,
    we had an error copying the log file, where the path “C:\Windows” could not be found. However, the file was written to this path and the firewall rules were also set correctly.
    The user has already updated his client to Windows 11. Are there any known problems related to Windows 11 and the script?
    Thank you for your feedback

    Best regards,

    • I have not seen any Windows 11 problems with this.
      As with all community scripts, some adjustment is always be required ๐Ÿ™‚

  • Hi Michael,

    We use Intune in a hybrid environment.

    MS Teams starts automatically when a user logs in to a system triggering the block rule, the script applies later and then the block rule already exists so it cancels out the script..

    any thoughts ?


    • Hi Frank,

      That should be no problem if you have the “force” option set as $true in the script. then it will override the block rule.
      If it is a language mismatch, then you could amend the script to remove rules that you know are blocking. before it adds the allow rule.

  • Hi Michael,

    Excellent work, and thank you! I ran the script as instructed, but since we are mostly remote, I logged in via RDP as the user in the test group and the Script ran successfully but for some reason it detected the local administrator account as the logged in user and set the rules for the local administrator account and not the user in the test Azure AD group. Any suggestions on how to mitigate this? Currently we are a Hybrid Environment.

    • Hi Samy.

      Thanks ๐Ÿ™‚

      If you logged in via RDP then the user session is not detected correctly.
      The Script was not designed for that scenario unfortunately.
      It is designed to be used with remote management tools like Intune or ConfigMgr. even just a classic GPO would work.

      • Thank Michael,

        I am trying to deploy the script using Intune since we have a Hybrid environment with some Remote Users. Any ideas what can be adjusted to have it ran from a user’s RDP session?

      • Hi Samy,

        You would be looking at detecting the users session id and such.
        I think for RDP servers the Microsoft official script might just be the way to go.

  • Why do you create a blocking rule for Public and Private contexts? If a user works from home and does not connect via VPN, or goes to a hotel, would they be blocked?

    • Hi David. The feature will still work, as Teams will then use a service endpoint with Microsoft to relay screen sharing, instead of using the LAN. try it out ๐Ÿ™‚

  • Hi,

    Thanks for the script!

    When i add it to Intune, the same way you did, and assign it to a Test-group of 1 user ( no computers) it gives status FAILED on 1 computer in “Device status”.

    No error message and i dont see the local log file.

    Any idea’s how i can solve this?

    • I would just try and start over. sometimes these things can just go wrong on the backend and need to be redone. You might also have some Group Policy settings that are preventing local firewall changes.

  • Hey Michael,

    thx for this awesome Script, works like a charm! One question about the block rule for private and publik networks. Does teams work like it should or are there any problems when this rule is set? Most of our users are working from home at the moment where the networks are marked as public networks.

    • Hi Henry,

      It should be fine as it seems this firewall port rule just optimizes the sharing experience on local area networks.

  • Testing this out right now and have high hopes!

    I was wondering what happens if the Teams app has not been “installed” to the user profile yet and the script runs? Does there need to be a delay to wait for Teams to show up?

    • It should just add the firewall rule and not care about Teams per se.. but I have yet to test if the firewall won’t accept a path that does not exist.
      But I see no reason why it would not just work ๐Ÿ™‚

  • HI

    Have you a solution when you Disable merging of local Microsoft Defender Firewall rules?
    It’s security recommendation Defender ATP


    • Hi Jean-Yves
      As this is a user-specific firewall rule, disabling the merging of local and GPO firewall rules would break it.
      If you want to manage this via GPO, you will need to write a GPO based firewall rule for every user in your organization.
      You could script that, but I will not do it, as I am focused on moving away from On-Prem GPO controlled devices.

      Feel free to reply with a solution if you come up with one. ๐Ÿ™‚

  • Hi,

    Loving this. Just a suggestion though, but might be worth changing:

    Gwmi -Class Win32_ComputerSystem | select username -ExpandProperty username


    Get-CimInstance -Class Win32_ComputerSystem | select username -ExpandProperty username

    It’s just that PowerShell 7 I note that Gwmi has been depreciated.



    • Thank you, Steve.
      Good feedback.
      You are welcome to do a pull request on the REPO and become a contributor ๐Ÿ™‚

  • Nevermind, it’s because I was logged via RDP, in which case it doesn’t populate that property.

  • Does Intune populate user logged in information in the Win32_ComputerSystem class?

    None of that exists on my Windows 10 which is not enrolled in Intune so not sure how your script can work.

    • Hi Rkast,
      Thanks for your suggestion. I am sure someone will find it useful.
      I know that there are many different ways to get to the goal, but in my case I wanted something that could also mitigate the situation after a user had dismissed the firewall prompt.
      Because Teams creates blocking firewall rules, adding an allow rule afterwards would not change the fact that block rules outweigh allow rules.



Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories use cookies to ensure that we give you the best experience on our website.