With over 44 million active users, Microsoft Teams
Firewall 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?! (This is the madness of the Microsoft Teams firewall prompt).
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 Intune’s 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 to fix the Microsoft Teams firewall madness
Taking a glance at the official documentation (and solution) from Microsoft over at: https://docs.microsoft.com/en-us/microsoftteams/get-clients#sample-powershell-script
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. (Microsoft Teams Firewall problem solved?)
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: https://github.com/mardahl/MyScripts-iphase.dk/blob/master/Update-TeamsFWRules.ps1
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 Intune admin center at https://endpoint.microsoft.com/ and follow along:
- Jump straight to the (1) Devices > (2) Windows > (3) PowerShell scripts blade
- Click on the (4) “Add” button.
- 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“
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.
Thx for sharing. We did a test on 3 users and it seems to work!
I have a question though.
We are about to replace all our laptops and move from Windows 10 to Windows 11, the change will happens during a weekend change.
So when is the best time to deploy the ps1 script to all users?
Now, on the old laptops and Windows 10 or wait until users get the new laptop?
If we deploy now, will it deploy again, when users logon to a new laptop?
The script also needs time deploy, so if we deploy when users get the new laptop, the script is not applied before users start Teams
If you give the user a new machine it will run the script again, so go ahead and deploy it now.
I recommend you get a copy of Scott Duffys Intune book, it explains many things that you should know about policy processing and powershell execution.
jeg stødte på dit script da vi er ramt af den dødirriterende popup fra Windows firewall når Teams starter første gang.
Jeg har fulgt din vejledning og “user status” viser grønt. Dog kan jeg ikke se nogle log filer som du beskriver og heller ingen firewall regler er tilføjet
Hvis du har tildelt Powershell scriptet til et gruppe af brugere og sat det op som vist i mine screenshots, så burde det virke fint (nemt at sige).
I kan kontakte mig via APENTO hvis der er behov for hjælp til Intune.
Is it possible to accomplish this through an InTune Firewall policy yet? I’m able to create such a policy but it doesnt seem to work. The rule shows up in the registry at Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Mdm\FirewallRules instead of Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules which appears to be the location it gets entered when you elevate and allow the Teams prompt.
I’d rather handle this by policy if possible. I can use a powershell script, but how can you ensure that the script runs before Teams is launched? Also, wont assigning a powershell script hang up the ESP? I thought about possibly wrapping the script as a Win32 app, but I have no idea what a successful detection rule would be for that. Any insights here would be greatly appreciated.
In the comments you will se that someone else says it is now possible to do with CSP only. so thats great (I have not confirmed this and have no reason to, I like the script because it does cleanup also).
PowerShell scripts are not tracked by ESP. so that should not be an issue. I suggest you just try it out (which I hope you have already done, I am just not good at looking for comments on year old articles :))
How to get around the 200k file size upload limit for powershell scripts with this nice script? 🙂
I think you have the wrong script? this is well below any upload restrictions.
Would this apply immediately after Autopilot ESP, or would the signed in user have to wait a period of time before it takes effect? If so, would it be worth wrapping it as a Win32 App to apply it as a required App during Autopilot ESP, and would you know the required Detection rule for this please?
It’s been so long, that I don’t really recall how fast it applies after autopilot and ESP. but I don’t expect it to be a problem. but you would have to do your own testing surely. and ESP is a pain sometimes depending on how you have everything set up.
Line 83 is basically your detection script, as it looks for the rules.
I know it’s been a couple of years but this works fine in the Intune Firewall rules now. I just set up an Administrative Template Firewall Rule to Allow %localappdata%\Microsoft\Teams\current\Teams.exe
No more Firewall dialog.
That sounds great, and thanks for sharing.
Unfortunately I can’t confirm this (no time).
But I hope others will chime in over time, so these comments hold more valuable information by the community <3
I am sticking with the script though, as it has versatility and can do cleanup if some other messy teams.exe rules have been put in place somehow.
Can this also be used for other apps that bring up the firewall prompt on first run? Would you just modify line 71 to the apps path, line 85 to the exe of the new app and line 117 to Set-NewAppFWRule ?
Hi Brent, yes it can be used for more things.
You roughly have the right idea, and I hope you are just keeping your suggestion brief as there would be some more to it than just that as you are basically renaming a function, and would need to rename the function and not just the invocation of the function on line 117.
I would guess you could feed the script to ChatGPT and it would allow you to replace the right parts.
I suggest reading up on the cmdlets I am using that are unfamiliar to you and understanding how the script does it’s work. Then it will be very simple to adapt it to many use cases.
We get the firewall popup for 2 other programs. If I wanted to use the same script for those programs would I just update the following?
$progPath = Join-Path -Path $ProfileObj.FullName -ChildPath “AppData\Local\Microsoft\Teams\Current\Teams.exe” to
$progPath = Join-Path -Path $ProfileObj.FullName -ChildPath “c:\program files\mersive\solsticeclient\solsticeclient.exe”
$ruleName = “Teams.exe for user $($ProfileObj.Name)”. to
$ruleName = “solsticeclient.exe for user $($ProfileObj.Name)”
Those suggestion would not be good changes as you are joining two paths together and the second one has to be relative.
The solticeclient.exe file is in an absolute path, so you don’t need a scriptet solution, you just need to create a static firewall rule in Intune. much simpler. I suggest you look at how to create firewall rules in Endpoint Manager Intune.
Script works great so far in the small amount of Intune testing I’ve done; thanks for sharing it and also for the work you put into it. One thing I don’t understand is what’s to prevent the following scenario:
User gets a new device, installs Teams, launches Teams before the PowerShell script has run to create the firewall rules, and when user tries to make a call, screen share, etc., they would get a firewall alert notification anyway because the script hasn’t run yet.
Is there any way to guarantee that wouldn’t happen?
Yeah they could be so eager to jump on a call in Teams and share their screen, that I supposed they could do it before the script runs.
But generally speaking the PowerShell scripts run pretty fast after first user sign-in. I think it as being highly unlikely.
Whatever action they take with the firewall prompt it wont hinder them from doing their job.
And the script will purge the rules that get created when they dismiss the prompt.
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
I have not seen any Windows 11 problems with this.
As with all community scripts, some adjustment is always be required 🙂
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 ?
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.
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.
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.
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?
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 🙂
Sorry im not understanding why you would create the block rule in the first place? Is there some harm that i am not seeing?
I just think that peer2peer connection on a public or private network should be blocked. it can go over the public internet instead. ans I don’t assume anyone is having teams meeting together on a private lan in someones home or at the airport.
The access that Teams is requesting is for the local network, and that is what we are allowing with the firewall rule. so that should only be on the domain in my opinion. you can change it if you like.
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.
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.
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 🙂
Have you a solution when you Disable merging of local Microsoft Defender Firewall rules?
It’s security recommendation Defender ATP
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. 🙂
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.
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.
Just use GPO or a PowerShell script to set the required firewall rule in HKLM registy for %logonuser%
See @ https://microsoftteams.uservoice.com/forums/555103-public/suggestions/33697582-microsoft-teams-windows-firewall-pop-up
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.