David’s Technical Musings

Each time you start up PowerShell, your session is set to an initial state.  Any changes you made in previous PowerShell sessions (with a few exceptions) are not remembered.  You could put all your configuration changes (e.g. alias definitions, new drives, function definitions, etc.) in a script and execute it as the first thing you do.  However, in order to execute a script, you will need to change the execution policy.

Execution Policy

The execution policy determines whether scripts are allowed to run and, if they can, whether they must be digitally signed.  It also determines whether configuration files can be loaded.

Since the power of PowerShell can be used for malicious purposes, the default setting for the execution policy is Restricted, which means no scripts or configuration files can be run or loaded.  The execution policy can be retrieved using the Get-ExecutionPolicy cmdlet and can be set using the Set-ExecutionPolicy cmdlet.  The following values are valid for the execution policy:

This article won’t discuss script signing, but there are help topics describing how to sign a script or configuration file.

Probably the most useful value for the execution policy for those who develop scripts and software is RemoteSigned.  This allows you to develop scripts and execute them from your local disk or from a share on a share without having to resort to signing the script every time you make a change to it.  This provides similar functionality to a Windows command prompt window with some added security for scripts downloaded from the Internet.

Scripts

PowerShell scripts are files with a .ps1 extension and can contain any statement that can be entered at the command line.  To execute a script you must specify a path with the name.  To execute a script in the current directory, type the directory name or use a dot:

.\testscript.ps1

PowerShell supports language constructs for looping, conditions, flow-control, and variable assignment, allowing you to create scripts from the simplest to the very complex.

Profiles

Creating scripts is a necessity for most people who work in a command shell, but having to recreate your environment every time you start one up can be a real hassle.  Even having to manually execute a script is not very convenient.  PowerShell supports the concept of a profile, which is a script file that is automatically loaded.  PowerShell supports four different profiles, each one loaded in the order listed below.  This allows a more specific profile to override settings defined in a less specific profile.

1. %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 - All users and all shells.
2. %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 - All users, but only to the Microsoft.PowerShell shell.
3. %UserProfile%\My Documents\WindowsPowerShell\profile.ps1 (XP), %UserProfile%\Documents\WindowsPowerShell\profile.ps1 (Vista) - Only the current user but affects all shells.
4. %UserProfile%\My Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 (XP), %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 (Vista) - Only the current user and the Microsoft.PowerShell shell.

The location of the user-specific shell-specific profile is stored in the $profile variable.  To determine if the user profile has been created, type:

Test-Path $profile

At this point you can at least start configuring how you want the shell to behave with aliases, variables, and functions.  Articles for these topics have been or will be added to this series.