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

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, they can be silenced and ignored 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.