Microsoft PowerShell comes configured by default on Windows machines to not run unsigned scripts. These are scripts or tidbits from unknown sources that are not digitally signed.

Microsoft PowerShell is configured on hosts by default to only run signed scripts. The PowerShell cmdlet Set-ExecutionPolicy is used to set this to one of four settings:

Setting	Description
`Unrestricted`	No requirements; all scripts allowed
`RemoteSigned`	All local scripts allowed; only signed remote scripts
`AllSigned`	All scripts need to be signed
`Restricted`	No scripts allowed

The typical admin in need of a quick fix will use Set-ExecutionPolicy to set the policy on the local machine to Unrestricted and then perform the administrative task. Sometimes they will remember to set it back to AllSigned as well; sometimes they forget and leave a security hole on the system that can later be exploited for malicious intent.

It is far better to sign your scripts used in the enterprise in a proper manner using a private key infrastructure in your domain. This is accomplished using a PowerShell cmdlet, naturally. The cmdlet is Set-AuthenticodeSignature, which can be used to generate certificates that can then be trusted by the organization in a Group Policy or Local Policy, as the case may be.

A thorough post on the subject written by Ed Wilson (the Scripting Guy on TechNet) is located at http://bit.ly/pkimyscripts.

I highly recommend and advise that some sort of testing and vetting process be followed for your scripting environment and library in production. Part of that process should be a signing/trust mechanism for the scripts. PowerShell, if left wide open, can be abused quite a bit to impact production systems in negative ways or be used as an attack vector for further activities by custom malware.