Once in awhile, we get questions about the best practice for PowerShell’s execution policy when it is included as part of a standard desktop image.

This is one of the main reasons that PowerShell ships with a “Restricted” execution policy. Since you have to explicitly enable or install PowerShell, we’ve frequently been asked why we aren’t more permissive by default. After all, you did just install / enable it! The reason is that separating the execution policy decision from the installation decision gives you a lot more freedom on installing PowerShell. It lets you push PowerShell to your whole enterprise via SMS (or include on a standard image,) and then later selectively configure the Execution Policy via Group Policy or other mechanisms.

When it comes to configuring these systems, the answer to this is largely determined by who will be using PowerShell. Is it primarily the end users, or as a target for logon scripts? The 80% rule is key here. You want to make a well-reasoned decision that applies to as many of your systems as possible, rather than have everybody make an un-informed decision on their own.

If it’s mostly for logon scripts, and you have a certificate you can sign these scripts with:

• Set the execution policy to AllSigned
• Add your signing certificate to the TrustedPublisher store

If scripting is likely to be extremely common (as with Exchange,) or you can’t obtain a code signing certificate, set the execution policy to RemoteSigned.

See here for some more guidance on this: http://www.leeholmes.com/blog/3rdPartiesAndPowerShellExecutionPolicies.aspx

As an brief caveat for logon scripts, some machines are configured to treat UNC paths as the same security zone as the internet (as opposed to the intranet.) This is Internet Explorer’s “Enhanced Security Configuration.” In this case, PowerShell responds the same as the Explorer Shell when it runs scripts from a UNC path: “While scripts from the internet can be useful, this script can potentially harm your computer. Do you want to run ?”

One way to fix this is by adding the source server to Internet Explorer’s Trusted Sites, or changing the “UncAsIntranet” configuration property (http://technet.microsoft.com/en-us/library/bb457150.aspx). This is also covered on page 341 of the (my) PowerShell Cookbook.

As another caveat, it is currently not possible to directly assign a .ps1 script as a logon script, since the architecture that enables this implies that you must be able to double-click on a PowerShell script to run it. We don’t want double-clicking to run a script by default for security reasons, so you can write a VBS script or batch file to call PowerShell with the correct arguments. The team blog goes into a bit more detail on this.