Forum Discussion
In Azure AD joined PCs, how to prevent Teams from Auto-Launch
"If you want to use the "Prevent Microsoft Teams from starting automatically after installation
Group Policy setting, make sure you first set the Group Policy setting to the value you want
before you run this script."
I will deploy this script anyways and give you an update.
InTune can and does leverage the local group policy engine, meaning that statement is still relevant since you could definitely have InTune deploying group policy to Azure-native clients.
In an InTune context, the script heading's really just saying, "hey, if you've already deployed Teams, make sure you have deployed the policy setting via InTune first, and then deploy me - the script - second."
Cheers,
Lain
- arturorosarioApr 07, 2022Copper ContributorThank you so much for your help and advice. After deploying the script, the results are mixed at best. First, the script shows an 82.6% success rate. Teams still auto-starts most of the time. I'm logging in to shared desktops if that makes a difference.
Cheers,
Arthur- LainRobertsonApr 08, 2022Silver Contributor
Probably the first thing I'd check all the listed requirements in the blue box entitled "Important" as both the policy and the script only work against specific versions and channels of Office.
Deploy Microsoft Teams with Microsoft 365 Apps - Deploy Office | Microsoft Docs
With respect to the failures, I'm not an InTune person meaning I'm not sure if there's some sort of logging available via it, but since the PowerShell script is very basic and runs under the logged on user's identity, if InTune provides you with the user name and computer name it failed, it'd be easy enough to watch/shadow that person and run the script manually from a PowerShell session on their desktop.
There's multiple reasons it could be failing but three that come to mind are:
- The PowerShell execution policy is stopping it from running;
- AppLocker is stopping it;
- PowerShell "constrained" mode is stopping it.
The PowerShell script itself is incredibly basic and given the amount of path testing it does, isn't likely to be throwing any exceptions from not finding a file or registry path, hence the above suggestions.
Very briefly, here's how to check each one.
PowerShell execution policy
As a general guideline, the PowerShell execution policy should be set to "RemoteSigned".
How to check the effective setting for the logged on user
Admin required? No Command Get-ExecutionPolicy How to check the machine configuration
Admin required? No Command Get-ExecutionPolicy -List How to change the machine configuration (no value changing it for only the user)
Admin required? Yes Command Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned -Force AppLocker
In Event Viewer:
- Navigate to "Applications and Services Logs/Microsoft/Windows/AppLocker"
- Have a look under "MSI and Script" for any clues in any errors
If AppLocker is causing issues then you will also find that running the command manually from the desktop as the affected user will also fail, and they will probably get a pop-up saying that policy prevents them from running that command (unless it's been configured to silently fail via policy.)
PowerShell constrained mode
You have to run the following check from the logged in session of the impacted user.
How to check if constrained mode is in effect
Admin required? No Command $ExecutionContext.SessionState.LanguageMode If checking this variable returns FullLanguage then you have nothing to worry about. If you get ConstrainedLanguage then there may be an issue as the script does call some .NET classes explicitly.
You can read more about constrained mode here but what it doesn't tell you is that AppLocker can also play a role in constrained mode detection. I won't bore you with the specifics here - not yet anyway. Maybe if you see ConstrainedLanguage returned we can go down that path.
about Language Modes - PowerShell | Microsoft Docs
For all three cases, the most useful thing you can do to start with is shadow the user and run the script manually on their desktop session. Only if it fails to run would you then check each of the three settings above. And as I say, there's other reasons it could be failing, too. These are just three that came to mind quickly.
Cheers,
Lain