One of the main features of PowerShell is the ability to execute scripts. But, scripts are not inherently "safe" and since PowerShell has no concept of sandboxing, the execution of scripts are disabled by default. The default way to execute scripts is via the console interpreter.
But, since PowerShell's function is to execute scripts, there has to be a way to enable it in your environment. The way to configure this is with the PowerShell Execution Policy. The execution policy is stored in the registry and there are two handy Cmdlet's to get and set it's values.
Get-ExecutionPolicySet-ExecutionPolicy [-executionPolicy] { | | | }The descriptions for the execution policies are as follows:
Restricted
This is the default execution policy. When this policy is set, script execution is completely disabled. PowerShell can still be used to interactively interpret commands. While this is the default policy, it severely limits the user of PowerShell for automation.
When the execution policy is AllSigned, scripts can be executed, but only if they have been digitally signed. When running a signed script, you will be asked if you trust the signer of the script before it will execute. This is still a secure policy, but it makes script development difficult. This is best suited for environments where scripts are to be deployed rather than created.
RemoteSigned
RemoteSigned means that all scripts that are downloaded from a remote location must be digitally signed before they can be executed. This depends on the application downloading the script to mark it as coming from a remote location. Anything downloaded with Internet Explorer, Outlook, or Outlook Express will be properly marked. This is the minimum recommended execution policy setting and is the best setting for script development.
Unrestricted
When the execution policy is unrestricted, PowerShell will run any and all scripts you give it. It will still prompt the user when it encounters a script that has been downloaded however. This is the least secure setting and is not recommended that you use this setting, but it may be necessary in some developer scenarios where RemoteSigned is too restrictive.
For more information on signing PowerShell scripts, see Scott Hanselman's excellent post on the topic.