How to suppress warning message from script when calling Set-ExecutionPolicy

Question

I am writing a script to prepare our laptops before use. It essentially installs certificates and sets the executionpolicy to AllSigned.

It gets executed by right mouse click and "Run with Powershell". This is a windows 10 standard bypass of executionpolicy and lets the script run on unmodified windows 10 machines (That's what it looks like to me at least). So I can execute my script without the need to change the executionpolicy explicitly.
After the script ran the machine is set up. I just get a warning that I want to suppress.

To do this inside the script I elevate the script to administrator rights with a bypass parameter. This works fine except that I get a warning when setting the AllSigned execution policy. It says that I have a policy defined at a more specific scope.

Note: The command worked and the execution policy is set. It just pops up red and looks like an error. If someone else executes the script I don't want to have questions popping up.

--My question:--
As I know that this behavior is intended I don't want the warning from showing up. How can I suppress the message?

I tried various settings with the switches "WarningAction" and "ErrorAction" but it does not work.

Some Details:
ErrorMessage:

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Bypass. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy". At C:\Users\uwe\Desktop\InstallRootCA\InstallRootCertificate.ps1:46 char:5 + Set-ExecutionPolicy AllSigned -Scope LocalMachine -Force + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

Relevant Code parts from powershell script:

Elevating the script prior to execution:

 if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
     Start-Process PowerShell -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
     exit;
 }

Setting the Executionpolicy at the end of the script:

Set-ExecutionPolicy AllSigned -Scope LocalMachine

I tried all kinds of flags

-Force
-WarningAction Ignore|SilentlyContinue
-ErrorAction same

But still the red warning pops up.

Answer 1

You can put this command into a try catch statement. The catch statement will handle the errors and if it is empty, nothing will happen if Set-ExecutionPolicy throws an error.

try{
    Set-ExecutionPolicy AllSigned -Scope LocalMachine
}
catch {
    #Do Nothing
}

Please test it, let me know if it worked and if it did, please mark the post as the answer :)

Answer 2

Nicicalu's answer is effective; let me add some background information:

What Set-ExecutionPolicy emits in your case is a (statement-)terminating error, which is why it is neither affected by -ErrorAction nor by -WarningAction.

Terminating errors can only be handled via:

• try / catch, as shown in Nicicalu's answer.

• The - rarely used - trap statement

• Confusingly, by setting preference variable $ErrorActionPreference to 'SilentlyContinue'.

  • That is confusing, because the seemingly equivalent -ErrorAction common parameter does not work; that is, -ErrorAction SilentlyContinue or -ErrorAction Ignore have no effect, because -ErrorAction is designed to operate on non-terminating errors only.

For a comprehensive overview of PowerShell's complex error handling, see this GitHub docs issue.

---

Taking a step back: It doesn't make sense for Set-ExecutionPolicy to report an error in this scenario, given that the command still succeeded in principle.

Emitting a warning would be more appropriate, as suggested in GitHub issue #12032.