@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:
- 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
