PowerShell Intro

Introduction

PowerShell is the most powerful automation tool that Microsoft has to offer, and its both a shell and a scripting language.

Please note that this series is based on PowerShell 3, which ships with Windows 8 and Server 2012. If you are running Windows 7 please download the PowerShell 3 update before you continue.

Meet the Console and the ISE

There are two ways of interacting with PowerShell out of the box, the Console and the Integrated Scripting Environment – also known as the ISE. The ISE has vastly improved from the hideous version that shipped with PowerShell 2 and can be opened by pressing the Win + R keyboard combination to bring up a run box, then typing powershell_ise and pressing enter.

As you can see the ISE sports a split view so that you can rapidly script while still being able to see the result in the lower half of the ISE. The bottom half of the ISE, where the results of your script are printed, can also be used as a REPL prompt – much like command prompt. The v3 ISE finally added support for intellisense in both the script pane as well as the interactive console.

Alternatively, you can interact with PowerShell using the PowerShell Console, which is what I will be using for most of this series. The PowerShell Console behaves much like the command prompt – you simply enter commands and it spits out the results. To open the Windows PowerShell Console, again press the Win + R keyboard combination to open a run box and type powershell then press enter.

REPL prompts like this are awesome for instant gratification: you enter a command and you get results. While the Console doesn’t offer intellisense, it does offer something called tab completion which functions much the same – simply start typing a command and press tab to cycle through possible matches.

Using the Help System

In past versions of PowerShell, help files were included when you installed Windows. This was a good solution for the most part but left us with a significant problem. When the PowerShell help team had to stop working on the help files the PowerShell developers were still busy coding and making changes. This meant that when PowerShell shipped, the help files were incorrect because they didn’t contain the newer changes that had been made to the code. To solve this problem, PowerShell 3 comes with no help files out the box and includes an updatable help system. This means before you do anything you will want to download the latest help files. You can do that by opening a PowerShell Console and running:

Update-Help

Congratulations on running your first PowerShell command! The truth is that the Update-Help command has a lot more options than simply just running it, and to see them we will want to view the help for the command. To view the help for a command you simply pass the name of the command you want help with to the Name parameter of the Get-Help command, for example:

Get-Help –Name Update-Help

You are probably wondering how to interpret all that text anyway, I mean why are there two lots of information under the syntax section and why are there so many brackets all over the place? First things first: the reason there are two blocks of information under the syntax section is because they represent different ways to run the command. These are technically called parameter sets and you can only use one at a time (you can’t mix parameters from different sets). In the above screenshot you can see that the top parameter set has a SourcePath parameter while the bottom doesn’t. The reason being that you would use the top parameter set (the one that includes SourcePath) if you were updating your help files from another machine on your network that had already downloaded them, while you wouldn’t need to specify a source path if you just wanted to grab the latest files from Microsoft.

To answer the second question, there is a certain syntax that help files follow and here it is:

• Square brackets around a parameter name and its type means it is an optional parameter and the command will work just fine without it.
• Square brackets around the parameters name means that the parameters is positional parameter.
• The thing to the right of a parameter in the angled brackets tell you the data type the parameter is expecting.

While you should learn to read the help file syntax, if you are ever unsure about a particular parameter just append –Full to the end of your get help command and scroll down to the parameters section, where it will tell you a bit more about each parameter.

Get-Help –Name Update-Help –Full

The last thing you need to know about the help system is how you can use it to discover commands, which is actually very easy. You see, the PowerShell accepts wildcards almost anywhere, so using them along with the Get-Help command allows you to easily discover commands. For example, I am looking for commands that deal with Windows Services:

Get-Help –Name *service*

Sure, all of this information might not be handy of the bat, but trust me, take the time and learn how to use the help system. It comes in handy all the time, even to advanced scripters who have been doing this for years.

Security

This wouldn’t be a proper introduction without mentioning security. The biggest worry for the PowerShell team is that PowerShell becomes the latest and greatest attack point for script kiddies. They have put a few security measures in place to make sure that this doesn’t happen, so let’s take a look at them.

The most basic form of protection comes from the fact that the PS1 file extension (the extension used to denote a PowerShell script) isn’t registered with a PowerShell host, its actually registered with Notepad. That means if you double click on a file it will open with notepad instead of running.

Secondly, you can’t run scripts from the shell by just typing the script’s name, you have to specify the full path to the script. So if you wanted to run a script on your C drive you would have to type:

C:\runme.ps1

Or if you are already at the root of the C drive you can use the following:

.\runme.ps1

Finally, PowerShell has something called Execution Policies, which stop you from just running any old script. In fact, by default, you can’t run any scripts and need to change your execution policy if you want to be allowed to run them. There are 4 notable Execution Policies:

• Restricted: This is the default configuration in PowerShell. This setting means that no script can run, regardless of its signature. The only thing that can be run in PowerShell with this setting is an individual command.
• AllSigned: This setting does allow scripts to run in PowerShell. The script must have an associated digital signature from a trusted publisher. There will be a prompt before you run the scripts from trusted publishers.
• RemoteSigned: This setting allows scripts to be run, but requires that the script and configuration files that are downloaded from the Internet have an associated digital signature from a trusted publisher. Scripts run from the local computer don’t need to be signed. There are no prompts before running the script.
• Unrestricted: This allows unsigned scripts to run, including all scripts and configuration files downloaded from the Internet. This will include files from Outlook and Messenger. The risk here is running scripts without any signature or security. We recommenced that you never us this setting.

To see what your current Execution Policy is set to, open a PowerShell Console and type:

Get-ExecutionPolicy

For this course and most other circumstances, the RemoteSigned Policy is the best, so go ahead and change your policy using the following.

Note: This will need to be done from an elevated PowerShell Console.

Set-ExecutionPolicy RemoteSigned

That’s all for this time folks, thanks for reading.

 

CRTech.