Many companies treat the ExecutionPolicy as a security boundary, which is probably the biggest mistake we can see very frequently and continuously. Dozens of enterprise customers have tried it with this simple approach, and are still applying this approach in production. The ExecutionPolicy defines how scripts can be executed from a machine. The following execution policies are available:

Each pillar defines a specific rule, and the size of the pillar correlates with its restrictiveness for the execution of PowerShell. The definitions of each setting is as follows:

• Restricted: No execution of policy scripts allowed
• AllSigned: Scripts signed by a trusted publisher are allowed to execute
• RemoteSigned: Scripts signed by a trusted publisher and locally created scripts are allowed to execute
• Unrestricted: All scripts can be executed, but with scripts downloaded from the internet, you will be prompted for permission
• Bypass: All scripts can be executed without warning prompts
• Undefined: Not specified

The default configuration on client SKUs is Restricted and on server SKUs is RemoteSigned which prevents script execution in the first place. For an enterprise environment, it is strongly recommended to choose between Restricted, AllSigned, and/or RemoteSigned.

In addition, there is also a defined precedence order that is followed on the machine. The highest policy from this precedence order will override the lower ones:

There are two cmdlets for this use case that you should know about, Get-ExecutionPolicy and Set-ExecutionPolicy:

#Retrieve the ExecutionPolicy
Get-ExecutionPolicy

#Define it to Bypass
Set-ExecutionPolicy -ExecutionPolicy Bypass -Force

#Define it to Restricted
Set-ExecutionPolicy -ExecutionPolicy Restricted -Force

#Retrieve the Execution policies as list
Get-ExecutionPolicy -List | Format-Table -AutoSize

#execute a demo script
.MyScript.ps1

To modify the ExecutionPolicy with Set-SetExecutionPolicy, you need to have elevated rights, as it will try to write to the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell[...]. Otherwise, you will get the following error returned:

Set-ExecutionPolicy : Access to the registry key 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell' is denied. To change the execution policy for the default (LocalMachine) scope,
start Windows PowerShell with the "Run as administrator" option. To change the execution policy for the current user, run "Set-ExecutionPolicy -Scope CurrentUser".
At line:1 char:1
+ Set-ExecutionPolicy -ExecutionPolicy Restricted -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], UnauthorizedAccessException
 + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

With the additional -List flag, on retrieving the policies with Get-Executionpolicy, you will get a hashtable returned with the precedence order and its defined policies:

But here comes now the turning point for the ExecutionPolicy. This policy controls the execution of scripts. As you have seen in the preceding example, dot-sourcing with .MyScript.ps1 or pressing F5 would result in executing the file as a script. The default restriction type would result in the following error:

.ExecutionPolicy_Bypass.ps1 : File C:	empMyScript.ps1 cannot be loaded because
running scripts is disabled on this system. For more information, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .ExecutionPolicy_Bypass.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : SecurityError: (:) [], PSSecurityException
 + FullyQualifiedErrorId : UnauthorizedAccess

Unfortunately, there are also other ways to execute PowerShell code. Executing PowerShell code as a command and not as a whole script results in an ineffective ExecutionPolicy.