Summary of the new feature / enhancement
Today, if PowerShell starts in ConstrainedLanguage, there's no way to tell why did this happen.
The problem is simply manifested as:
Microsoft.PowerShell_profile.ps1: Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator.
There're multiple reasons for why the scripting is restricted and knowing which one exactly is very helpful when troubleshooting the issue.
Proposed technical implementation details (optional)
That'd be great if one could start pwsh in a mode where it would print out the high-level source of the issue (WLDP, AppLocker, cached or not, system or user, file policy enforcement).
The best would be if it could analyze CI policies present on the machine and highlight which one is the culprit (stretch goal.)
Summary of the new feature / enhancement
Today, if PowerShell starts in ConstrainedLanguage, there's no way to tell why did this happen.
The problem is simply manifested as:
There're multiple reasons for why the scripting is restricted and knowing which one exactly is very helpful when troubleshooting the issue.
Proposed technical implementation details (optional)
That'd be great if one could start pwsh in a mode where it would print out the high-level source of the issue (WLDP, AppLocker, cached or not, system or user, file policy enforcement).
The best would be if it could analyze CI policies present on the machine and highlight which one is the culprit (stretch goal.)