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