Introduction to Windows PowerShell

1 2 3 4 5 6 7 8 9 10 11 12 Page 12
Page 12 of 12

Script Execution Policy

As initially installed, PowerShell is set up so that it can be used interactively at the command prompt but will not run scripts. This does make sense. The majority of Windows users will never touch PowerShell, and nobody knows what future bug might be discovered that would let hackers silently send them malicious PowerShell scripts via Internet Explorer, Adobe Acrobat, YouTube, or who knows what. Better to be safe than sorry.

Power users just have to change the default script execution policy from Restricted to, as I recommend, RemoteSigned. Table 2 lists the possible policy settings.

Table 2  PowerShell Script Execution Policy Settings

Setting

Description

Restricted

This is the default setting. No PowerShell scripts will run at all, under any circumstances.

AllSigned

Only digitally signed scripts (including profile scripts, which I describe in the next section) will run; in addition, you are prompted to grant permission to run scripts signed by the specific certificate used.

RemoteSigned

Scripts (and profiles) that have been written locally will run.

Scripts that have been downloaded from the Internet will not run unless they are signed and you have approved the signing certificate.

Unrestricted

All scripts will run, but you are warned about scripts that have been downloaded and must approve them before they’ll run.

Bypass

Any script will run, regardless of its origin. This is a potentially very risky setting and should be used only in very specific circumstances, where some other security system is in place to prevent rogue scripts from running without your permission.

(Undefined)

If no policy setting is in place, PowerShell treats the setting as Restricted and no script will run.

I recommend the RemoteSigned setting. Scripts you write and store on your computer or retrieve across your local area network will run without any problem, but scripts that arrive via programs with Internet connectivity won’t run unless they have a digital signature and you’ve confirmed that you trust the person or company that signed the script. This is a good security compromise.

To change the setting, open a privileged PowerShell window as described in the previous section. Then, type the command

set-executionpolicy remotesigned

You will have to confirm that you want to make this change by typing y and Enter. (You can disable that prompt by adding -force to the command line.)

Now, you can run PowerShell scripts and profiles. .

There are few things you should know about this security setting:

  • If your computer is part of a corporate domain network, this setting is probably under the control of your network manager via Group Policy. Type get-executionpolicy to see what your current setting is. You might not able to change it yourself.

  • If you are forced into, or choose, the AllSigned policy setting, you’ll have to digitally sign any script you want to run. It’s a cumbersome process, but it’s not too bad after you get used to it.
  • You might recall that files downloaded from the Internet are marked as “potentially risky” through information stored in a separate data stream associated with the downloaded file. To remove this marker from a downloaded script that you are certain is safe, use Windows Explorer to open the file’s properties dialog box and click Unblock. It will now be considered a local file and will run under the RemoteSigned execution policy.

Finally, remember that if you have a local area network (LAN) but not a Windows domain network, and the scripting execution policy isn’t set by Group Policy, you’ll have to change this setting on every computer on your network that you want to manage using PowerShell.

PowerShell Profiles

As I showed in the previous sections, you can customize the PowerShell environment to suit your preferences by adding custom aliases, adding directories to the path, and so on. It would be a pain to have to retype these commands every time you started PowerShell—and you don’t have to if you set up a PowerShell profile, which is a script of commands that PowerShell runs every time you start a new instance. You might want to put commands of this sort in a profile script:

new-alias -name “n” -val<br> “notepad” -descr “Edit a file with Notepad”<br> $env:path += “c:\PSscripts”

so that your favorite, custom aliases will be available every time you use PowerShell.

Here’s the skinny: Whenever you start Windows PowerShell in any of its various flavors (the regular command-line PowerShell, the GUI PowerShell ISE, or a PowerShell variant that’s embedded inside another application), it looks for profile scripts in the following two locations, in this order:

%windir%\system32\WindowsPowerShell\v1.0

where %windir% is the folder in which Windows is installed, usually c:\windows, and

%userprofile%\[My] Documents\WindowsPowerShell

where %userprofile% is your account’s profile folder, usually c:\Users\username on Windows 7 and Vista and c:\Documents and Settings\username on Windows XP.

Within these two folders, the different flavors of Windows PowerShell look for different profile filenames. Every PowerShell variant looks first for a script named profile.ps1 and runs it if it’s found. The command-line PowerShell then looks for a profile script named Microsoft.Powershell_profile.ps1 and executes that one if it’s found. The GUI PowerShell ISE program, on the other hand, looks first for profile.ps1 and then Microsoft.PowerShellISE_profile.ps1.

Profile scripts in the %windir% folder affect all users on the computer, while profile scripts in your %userprofile% location affect only shells that you use. So, you can decide to make some customizations available to everyone and make some just for yourself by setting up separate profile scripts. Likewise, you adjust every PowerShell variant by putting commands in profile.ps1, or you can season the different PowerShells to taste by putting commands in the version-specific files.

PowerShell executes each of the scripts it finds, so the environment you end up with is the result of the cumulative changes made by all the script(s) that you’ve set up.

Creating a PowerShell Profile - PowerShell has a predefined variable named $profile that points to the version-specific profile file in your %userprofile% folder. For example, in my command-line PowerShell, $profile has the value “c:\Users\bknittel\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1”.

So, you can instantly create a PowerShell profile by typing the command notepad $profile. Notepad will ask whether you want to create a new file. Click Yes, and you’re ready to go.

To create a profile for all users in folder %windir%\system32\WindowsPowerShell\v1.0 on Windows 7 or Vista, remember that you’ll need to use an elevated Command Prompt or PowerShell instance. This folder name is stored in variable $PSHOME, so from PowerShell you can use the command notepad $pshome\profile.ps1 or notepad $pshome\Microsoft.PowerShell_profile.ps1 to create or edit the file.

However, and this is a big however, profile scripts are still scripts and PowerShell will only run profile scripts that meet the security guidelines I described in the previous section. Remember that the default execution policy is Restricted, so profile scripts won’t run at all (unless you’re on a Windows domain network and your network manager has enabled script execution).

To take advantage of the profile feature to customize your PowerShell environment, you will need to change the execution policy and possibly digitally sign your scripts. The previous section tells you how to do this.

This article is excerpted from the book Windows 7 and Vista Guide to Scripting, Automation, and Command Line Tools, copyright Pearson Education, all rights reserved. Reprinted with permission.

Copyright © 2010 IDG Communications, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 Page 12
Page 12 of 12
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon