In Azure AD joined PCs, how to prevent Teams from Auto-Launch

Occasional Contributor

Need to prevent Teams from auto-launching on my Azure AD joined PCs.

7 Replies

@arturorosario 

 

Have a read of this article:

Deploy Microsoft Teams with Microsoft 365 Apps - Deploy Office | Microsoft Docs

 

If your clients are native Azure-joined then you'd be looking to use an MDM like InTune to deliver any policy settings.

 

If your clients are hybrid-joined, you can leverage Active Directory group policy.

 

Cheers,

Lain

Hi Lain,

I did use Intune's "Prevent Microsoft Teams from starting automatically after installation (User)"
but sadly it does not work for me. I have deployed it to ALL DEVICES and ALL USERS.

@arturorosario 

 

Yeah, fair enough.

 

Did you read the "tip" in the green box?

 

If you are deploying the policy setting after Teams has already been used by the user, it won't work just by deploying the setting on its own. You need to include the script linked inside that green "tip" box.

 

That script needs to be run per user, not just once per machine.

 

Pretty clunky solution in my opinion, but this is how things are these days.

 

Cheers,

Lain

I may be overthinking this but, the script you mentioned has a Group Policy aspect that would not pertain to us because we are Azure joined PCs. Please see below,

"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.
Yeah, it may seem that way but if you're running Windows Enterprise or Education (which is effectively almost just a different SKU of Enterprise) then group policy is still highly relevant - even on Azure-only joined computers (since the group policy engine is part of the Windows client, not an exclusive component of something like on-prem Active Directory.)

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
Thank 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

@arturorosario 

 

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:

 

  1. The PowerShell execution policy is stopping it from running;
  2. AppLocker is stopping it;
  3. 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
CommandGet-ExecutionPolicy

 

How to check the machine configuration

Admin required?No
CommandGet-ExecutionPolicy -List

 

How to change the machine configuration (no value changing it for only the user)

Admin required?Yes
CommandSet-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned -Force

 

AppLocker

In Event Viewer:

 

  1. Navigate to "Applications and Services Logs/Microsoft/Windows/AppLocker"
  2. 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