This blog post helps you to proactively disable Teams firewall pop-up with Intune on managed Windows 10 endpoints. But before we get started, let us first understand the complete context.
Table of Contents
Understanding the MS Teams Firewall prompt scenario
You may have end-users complaining about receiving a Windows Defender Firewall prompt when they initiate or receive a call for the 1st time with Microsoft Teams application on their managed Windows 10 devices.
This is really annoying to the end-users and it also hampers the user experience on a freshly provisioned device.
However, you as an intune Administrator, can easily save them from getting this Windows Firewall prompt for MS Teams.
But before we get to how to disable Teams firewall pop-up with Intune, let’s first understand why the prompt appears in the first place.
Let’s get started…
Why end-user gets the “Windows Firewall has blocked some features of this app” prompt
In general, this prompt is presented to end-users when an application wants to act as a server and accept incoming connections. Windows Firewall blocks incoming connections by default.
But the first time it blocks connection attempts to a new application, the end-user gets prompted to choose whether to allow the connection through or not.
Now as can be seen from the snapshot of the firewall prompt, the end-user needs to have local admin privilege on the endpoint to Allow access to this firewall prompt which would then create the required firewall rules.
However, in ideal cases, the end-user account provisioned on the endpoint would be a standard account.
Also, the irony is that even if the end-user clicks on Cancel on this prompt, the required firewall rules get created for Teams.exe, thereby allowing the connection. The same is documented here in the MS document.
Now that we know why the prompt appears, let’s move on to the next section, which is
What firewall rules are needed to be pre-created for Teams to prevent the prompt
This is obviously not the first blog post on this topic and as such, you can find a lot of content available on the internet on this particular topic, and what you will find is, most of those blog posts suggesting to create two inbound rules (one for TCP and one for UDP) with Action type set as Allow for all profiles (Domain, Public, Private) as below.
New-NetFirewallRule -DisplayName "Teams.exe" -Program "%LocalAppData%\Microsoft\Teams\current\Teams.exe" -Profile Domain,Private,Public -Direction Inbound -Protocol TCP -Action Allow -EdgeTraversalPolicy DeferToUser
New-NetFirewallRule -DisplayName "Teams.exe" -Program "%LocalAppData%\Microsoft\Teams\current\Teams.exe" -Profile Domain,Private,Public -Direction Inbound -Protocol UDP -Action Allow -EdgeTraversalPolicy DeferToUser
However, I never managed to get a consistent result with the above.
For me, the config that worked is by creating inbound rules with action type
- Allow for profile type Domain.
- Block for profile type Public and Private.
New-NetFirewallRule -DisplayName "Teams.exe" -Program "%LocalAppData%\Microsoft\Teams\current\Teams.exe" -Profile Domain -Direction Inbound -Action Allow -Protocol Any -EdgeTraversalPolicy Block
New-NetFirewallRule -DisplayName "Teams.exe" -Program "%LocalAppData%\Microsoft\Teams\current\Teams.exe" -Profile Public,Private -Direction Inbound -Action Block -Protocol Any -EdgeTraversalPolicy Block
I would suggest checking either of the methods mentioned above to see what works for you, before doing a production rollout.
Now that we know what Firewall rules are required to prevent this prompt, let’s see how we can get this done using Intune as part of the device provisioning.
How to disable Teams Firewall pop-up with MEM Intune
It’s fairly easy to pre-create the required firewall rules for MS Teams on the managed Windows 10 endpoints via a PowerShell script deployment from Intune.
However, PS script deployments can’t be tracked during device provisioning via Windows ESP.
As such, post device provisioning completes, when the end-user is presented with the Desktop screen and MS teams auto-launches itself, there is no guarantee that the script deployment has been executed on the system.
Considering this situation, if the end-user straightaway proceeds to make a Teams call, the end-user would still end up with the same firewall prompt.
Thus we will be back to square 1 again!
To prevent this from happening (which is also our actual goal for this blog post), I suggest wrapping the PS script as a Win32 app and then deploy it.
What do you get for the additional admin effort of deploying a PS script in the disguise of a Win32?
Deploying a PS script wrapped as Win32, you get the added ability to mark it as a required app in ESP settings, thereby ensuring that the required MS Teams firewall rules are already created before the end-user is presented with the Desktop screen.
Wrap Up
There is already a UserVoice item submitted requesting the MS Teams Product Group to fix this MS Teams firewall prompt by itself.
As such, if you do not want to take the additional steps as explained in this blog, then do vote for the above UserVoice so that the requested item gets attention from Microsoft.
If you liked this blog post, you may also like my other posts on Intune. Give them a read!
That was all for today. Thanks for reading 🙂
It appears that the rules that you shared are cut off on the screen. Additionally on the rules that worked for you it looks like your allow and block lines are both for Domain. Is that correct? Lastly can this be deployed via a Firewall rule in MEM?
When users initiate a call using the Microsoft Teams client for the first time, they might notice a warning with the Windows firewall settings that asks for users to allow communication. Users might be instructed to ignore this message because the call will work, even when the warning is dismissed. Windows Firewall configuration gets altered even when the prompt is dismissed by selecting “Cancel”. Two inbound rules for teams.exe get created with Block action for both TCP and UDP protocols. This is the default behavior.
But in the environment that I was working for, it worked with Allow for Domain profile and Block for Public and Private to suppress that Firewall notification to the end-users.