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

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

How to check the machine configuration

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

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

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