In the previous two posts [1,2], we have used the interactive Windows PowerShell Console or the PowerShell ISE Console Window to execute commands. While this works fine for some ad-hoc processing, the reality will usually be different: you will develop, test and deploy PowerShell Scripts which you can re-use over and over again instead of typing the Commandlet in every time.
To support script creation and maintenance, the Windows PowerShell 2.0 comes with an Integrated Scripting Environment – short: ISE. You can launch it via the Start -> All Applications -> Accessories -> Windows PowerShell menu.
The Windows PowerShell ISE is a simple Script Development Studio. You can:
- manage your script contents – loading, saving, editing the script you are working with,
- execute the script, even in a built-in debug mode,
- access a PowerShell Console to test commands and monitor variables
- launch the PowerShell Console application
Windows PowerShell ISE on Windows Server 2008 R2
If you have started to look into scripting, there is a good chance you are a server operator and want to ease some management tasks. So if you are running a Windows Server 2008 R2 instead of the Windows 7 which I used for my initial examples, you will find that under Start -> All Programs -> Accessories -> Windows PowerShell you will not find the Windows PowerShell ISE.
Windows PowerShell ISE has been implemented as a Feature – and it is not installed by default. You can install it via the Server Manager’s Add Feature or – learning PowerShell – you can install it via the Windows PowerShell Command line:
Import-Module Servermanager Add-WindowsFeature PowerShell-ISE
You will see the system working a little bit, performing the installation. Once done, a summary of the task is displayed:
You now should have the Windows PowerShell ISE available in the Start menu.
Scripting & Security
Scripts can be of any complexity – for today, I just created myself a short one and I did not really pay attention to its usefulness. But it is a few lines of code and I do not want to re-type it every time:
# Execute the Shell Command WHOAMI (returns the
# current user and computer name in the format
# HOSTNAME \ USERNAME
$whoami = whoami
# Execute the Get-Date Commandlet
$today = Get-Date
# Split the $whoami variable into its two parts
$components = $whoami.Split("\")
# Provide some formatted output
"At " + $today + ", the user " + $components[1] +" is working on computer " + $components[0] + "."
You can simply copy & paste the code into your PowerShell ISE environment. Then save it – let’s say to FirstLight-PSS-01.ps1.
If you now try to run the script, you will most likely get an error:
Well, Scripting has always been a terribly dangerous thing – think of all those viruses that used the scripting engine to wreck havoc. Consequently, Microsoft has built in some restrictions to scripting and one of them is that the default settings will not allow you to run scripts.
You can verify the current setting for yourself: type Get-ExecutionPolicy into the to see what the current setting is. Most likely, the current mode is restricted. PowerShell 2.0 knows 6 different settings for the Execution Policy (alphabetically ordered):
- AllSigned: you can run scripts on the system as long as they have been signed by a trusted source. If the script is signed but the source of the signature is unknown, you will be prompted.
- Bypass: does not require script signing and – unlike Unrestricted – there will be no warnings. Not a recommended option!
- RemoteSigned: requires a script that has not been developed on the local computer to be digitally signed. A good option if you do not want to create a local certificate.
- Restricted: this is the default setting after installation. You are allowed to perform individual commands but running entire scripts is forbidden.
- Undefined: clears the currently defined execution policy which will then resume a default value, assuming it is not overwritten by an execution policy of a higher scope.
- Unrestricted: does not require script signing, any script can be run. Will only warn you when a script is directly downloaded from the Internet. Not an advisable option!
If you want to read the built-in help, try Get-Help about_execution_policies to display the detailed definitions for execution policies.
Allowing Scripts to run
If we want to run our previously saved script, we need to set an appropriate execution policy. We can go with RemoteSigned for the moment but I would not recommend this setting for systems used in any production environment. Type Set-ExecutionPolicy RemoteSigned and the system will request permission to change the execution policy which you need to approve.
Try to run the script you have loaded before – with the changed execution policy, the script will run.
Please note, that the change to the execution policy we have made is saved to the system: if you come back to the PowerShell ISE the next time, you will not have to re-set the execution policy. However, that also means that you need to be careful about using all-to-open execution policies for testing: they remain set until explicitly reset!