Help: It Says Run a PowerShell Script

Doctor Scripto

Summary: Ed Wilson, Microsoft Scripting Guy, talks about running a Windows PowerShell script.

Microsoft Scripting Guy, Ed Wilson, is here. Ninety two degrees Fahrenheit and sunny—that is what the weather is supposed to be this Saturday in Jacksonville when Teresa and I will be speaking at the Jacksonville IT Pro Camp.

I can’t think of a better way to spend a sunny day in Jacksonville, Florida than in a building with the air conditioning on high, and talking about the way cool stuff in Windows PowerShell. Well, maybe I could think of one or two other things to do, but certainly, IT Pro Camp is at the top of the list.

Is it a script?

A Windows PowerShell script is not a script until it is saved with a .ps1 file extension. So, if I copy a script directly from anywhere, and paste it into the Windows PowerShell ISE, and I do not save it, it is not a script.

In the following image, I have copied a random script from the Script Center Repository. I pasted it into the Windows PowerShell ISE, but I have not saved it.

I could run the script, modify the script, or whatever I want to do with it. But if the title pane says Untitled*.ps1, it is not actually a script. So regardless of the Windows PowerShell script execution policy, I can run a script here.

Script execution policies

When I first open Windows PowerShell on a client computer running Windows 7 or later, the script execution policy is set to Restricted (actually, this was also the case for Windows PowerShell 1.0). On the server side of the house, beginning with Windows Server 2008 R2, the Windows PowerShell script execution policy was set to Remote Signed, which means that scripts downloaded from a remote location must be signed to run without prompting.

I can see the script execution policy by using the Get-ExecutionPolicy cmdlet:

PS C:\> Get-ExecutionPolicy

Unrestricted

But there is more than one script execution policy. To see the value of all of the script execution policies, I use the Get-ExecutionPolicy cmdlet with the –List parameter. This is shown here:

To change the script execution policy, I use Set-ExecutionPolicy cmdlet. If I want to change the script execution policy for only myself, I can use the –Scope and specify CurrentUser, for example:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

When I run the Set-ExecutionPolicy cmdlet, the following prompt appears:

To bypass this prompt, use the –Force parameter. The command is shown here:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force

Script execution policy via Group Policy settings

If the network administrator sets a Windows PowerShell script execution policy with a Group Policy setting, I cannot change my local script execution policy—even to make it more restrictive.  For example, if the network administrator set the script execution policy to Remote Signed, but I thought it would make more sense to set it to All Signed, I could not do that. This is why it is important to look at the results of Get-ExecutionPolicy –List when troubleshooting script execution in Windows PowerShell.

If no policy is set via Group Policy (these are the Computer Configuration and the User Configuration settings), I can set a script execution policy for all users on a computer (Local Computer Group Policy setting) if I have local admin rights and if I open the Windows PowerShell console with elevated rights.

I normally, do not do that however. Instead, I prefer to set the policy only for the current user (which is me), and I do not have to open the Windows PowerShell console with elevated rights to do that. I can do it in a non-elevated manner. I did this earlier when I set the –Scope for CurrentUser.

If I need to run scripts, and I am running with non-elevated rights, and if a Group Policy setting has not disallowed me from running scripts, I can set my Windows PowerShell script execution policy easily. I just use Set-ExecutionPolicy and apply the appropriate policy to the CurrentUser scope.

Of course, there are lots of caveats to consider, but this will get you up and running quickly.

Windows PowerShell Fundamentals Week will continue tomorrow when I will talk about more cool stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow