TFS/RM PowerShell policies


Lets discuss the PowerShell execution policy scenario when we are using Microsoft TFS and/or RM(Release Management).

Before running any PowerShell script, first step is to define an execution policy. How to define it? See below:

First see what is the existing policy in place by running Get-ExecutionPolicy cmdlet. By default, it will be “Restricted” as shown below:

image

Windows PowerShell has four different execution policies:

  • Restricted – No scripts can be run. Windows PowerShell can be used only in interactive mode.

  • AllSigned – Only scripts signed by a trusted publisher can be run.

  • RemoteSigned – Downloaded scripts must be signed by a trusted publisher before they can be run.

  • Unrestricted – No restrictions; all Windows PowerShell scripts can be run.

Now, we have to select one best suited to our Organization. From the above list, most secured option would be “AllSigned”. How to set it? See below:

Run Set-ExecutionPolicy with “AllSigned” argument as shown below: It will set the policy.

image

With this policy (AllSigned) in place, we need to sign all the PowerShell scripts before running them in the target machine.

Now the question arises is that –

  1. What will happen to the PS scripts that TFS/RM generates and runs internally to implement particular task? We cannot sign them as we cannot see them. This is important to answer and understand because TFS and RM, all does all the activities using PS scripts internally.
  2. As well as many times, we writes PS scripts to do some specific task from TFS and RM, do we need to sign them?

To answer the first question, Microsoft says that the execution of the PS generated internally will be unaffected by the policy you set at machine or user account level. They will be executed under “ByPass” policy which will not take your machine’s policy into account. It is possible because the context under which the script will run, will be administrator of that server and MS assumes that since they have written the code themselves, so it is secure and can be executed with bypassing the already set policy. Point to be noted here is that the policy will be bypassed only for that session under which the script is executing and it will not impact the existing policy in any way. One can run and use the existing policy for any other script execution at the same time.

 

To answer the second question, the PS script that user will write and will be passing to the Remote PowerShell task, when that script is executed it will get executed with the ByPass Policy as well. Microsoft assumes that you being developer of the script, will write the secure code and execute the script with proper security. If you want your script to run using the particular policy like in our case “AllSigned”, you can define in your user script (say, at the top line of the script) to run under a different execution policy (For example, Set-ExecutionPolicy AllSigned –Scope Process), then that policy will be used for all the subsequent script invocations, that will get invoked from your main script which you passed in the task instead of the ByPass Policy that we set.

—End of Article—

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s