I do lots of PowerShell scripting, both inside runbooks and in stand-alone scripts. I have my own little virtual lab with a bunch of VMs and a domain controller that has a group policy assigned to enable the right PowerShell scripting settings on all the domain-joined computers, so I really don’t run into execution policy issues when remoting. However, I always see questions by people who are running into this issue because they live in the real world where computers come with remote scripting disabled by default or where unsigned scripts are not allowed. So rather than have runbooks fail because the right execution policy is not enabled, you should perform a check in your runbook before you do any PowerShell remoting and script running to a remote computer.
Note: if you don't know how to set group policy to enable PowerShell remoting,see this blog post:
Enable and configure Windows PowerShell Remoting using Group PolicySee this page on TechNet for more info on PowerShell execution policy:
http://technet.microsoft.com/en-us/library/dd347628.aspx
So here’s a quick example of testing the ability to run remote scripts on a computer that you can insert into any runbook to head off issues before they occur. You can take this runbook and insert it anywhere in any runbook just by using the Invoke Runbook activity and calling it like you would a function or a method in coding terms. Or, you can just cut and paste the script into a Run .Net Script activity in an existing runbook.
It's really very simple. all you have to do is do an "Invoke-Command", specify the target computer, and the command "Get-ExecutionPolicy". You can then parse the results for whatever execution policy value you're looking for. This simple workflow contains an Initialize Data activity, a Run .NET Script activity, and a Return Data activity.
The Initialize Data activity is there to accept an input parameter of the computer name, which is then used by the Run .Net Script activity (which I renamed Get-ExecutionPolicy to be more like PowerShell). The Return Data activity then passes the execution policy value back up to a parent runbook (if any). The script that’s run is really very simple (I’ve added additional error checking for issues mentioned below):
Now just add a published data property so the value returned in $ExecutionPolicy can be used in the runbook:
If the script succeeds, it will return the execution policy value, which will be one of the following:
- Restricted
- AllSigned
- RemoteSigned
- Unrestricted
- Bypass
- Undefined
This script also catches errors that might occur because of firewall issues. For example, it will trap the following error and cause the object to end with a "failed" status:
Using this workflow, you can be sure that your target computers are correctly configured to accept remote PowerShell commands before you start sending them!