Window Powershell

What is new in PowerShell V2

Version 2.0 of Windows PowerShell was officially released on October 28, 2009 after much anticipation by the PowerShell community. It introduces a large amount of new features that were not available before. It stays true to its purpose of making system administration easier by adding remoting, debugging tools and other things to the administrator's new shiny toolkit.

Of all the new features in Windows PowerShell version 2.0, the one feature that seems to elicit cheers and get the most attention is the new remote management or remoting feature. PowerShell supports interactive remoting where you connect directly and issue commands, fan-in (1 pc to many) and fan out (many pcs to 1). It allows the administrator to run scripts on one or many remote computers with a single command. Gone are the days of tediously going to different computers and running the same script on each of them one at a time. Gone are the days of taking your preferred script and copying it from machine to machine. Now, all you have to do is establish a session to the other computer or computers you want to run the script on and then issue the commands. From running a single cmdlet to a whole script, it is that simple. PowerShell 2.0 does have to be installed on the computers you are running the scripts on, the originating one and the target ones.

Another new feature sorely lacking from the earlier versions of PowerShell is the ability to run background jobs. This new ability of PowerShell version 2.0 to run background jobs allows you to asynchronously run other jobs or processes in the background while you continue to work on your session. You issue the command for the background job and immediately get the prompt back so that you can continue to work while the background job executes. These background jobs can be run on your local machine or on a remote computer.

Windows PowerShell 2.0 has also included new script debugging capabilities. Included now is the built-in capability to debug your scripts. It allows you to set breakpoints, step through code, monitor variable values, and more. It also allows you to decide what actions to take when the break point is hit. These capabilities give you the tools necessary to debug all your scripts with relative ease.

Another new feature is that of eventing. Eventing is the new capability of PowerShell to handle and react to events. It now includes an infrastructure that not only can listen for system and application events and act based on them. In addition, you can now create your own events which allow you to set up a chain of actions based on what your scripts do.

The new version also comes with a large number of new cmdlets. PowerShell version 2.0 introduces a little over 100 new cmdlets with numerous capabilities. All these cmdlets range from all the new functionalities mentioned earlier to powerful logging tools and mail-sending cmdlets.

PowerShell 2.0 also supports script internalization. This allows PowerShell to display messages in multiple languages. In addition to the regular get-help command and man command at the command line, PowerShell includes online help via a parameter to the get-help command. Using get-help, the command to get help on and then the online parameter opens a browser for you with the command help in Microsoft TechNet. Another new feature is the support of Modules. A module is a package that includes Windows PowerShell commands like cmdlets, providers, aliases, and variables. PowerShell now lets you create these modules and organize your commands so that you can share them with others. PowerShell version 2.0 has also included a lot of advanced functions. These functions behave just like cmdlets but they are fully written in the Windows PowerShell scripting language as opposed to C#.

Another new feature that PowerShell 2.0 has brought is the new Integrated Scripting Environment or ISE. The PowerShell ISE lets you run commands and scripts in an integrated development environment (IDE). It allows you to edit and debug your scripts with many options to figure out what is wrong and where it is going wrong like most graphical interfaces. It makes writing cmdlets easier with multiline editing and line and column numbers. It includes color coding like most graphical interfaces which makes it very easy for the user to write and execute their own commands by immediately showing them if they have made any syntax errors. It has several panes or windows to make it easier to see what is going on. One pane to write your command(s), one to show your scripts, and one to show you the output or results of your commands or scripts. In essence, it makes it really easy to get started with PowerShell by giving the user the tools to create what they want quickly and easily.

Cmdlets

There are hundreds of Cmdlets available in Windows PowerShell, so it is not possible to review all of them here. Cmdlets are small commands that can be called from PowerShell either by themselves or with other commands. To get a list of the available Cmdlets on your system, run get-help * in Windows PowerShell and it will output a list of the available Cmdlets, as well as any aliases setup on your system. Microsoft has created, by default, several dozen aliases so that normal DOS commands will work within PowerShell. As an example, there is no PowerShell command called “dir”; however, there is an alias called “dir,” which points to the Get-ChildItem Cmdlet, so that when you type dir into PowerShell, you get back results that you are looking for. You will also find alias for *nix commands as well, such as the command ls, which is also mapped to the Get-ChildItem Cmdlet.

PowerShell Cmdlets are small applications, which can be run from the Windows PowerShell interface. PowerShell Cmdlets are loaded within modules, which can be loaded manually by using the Import-Module Cmdlet. These PowerShell Cmdlets can perform all the management functions of the Windows management interface.

Some Cmdlets return data from the system, whereas other Cmdlets make changes to the system. You can combine these in a single command by using the pipe symbol (|) between the commands. For example, you could use a Windows PowerShell command to query the computer for a list of the network shares on the computer, and then change the comment on the network share all within a single command.

The most important Cmdlet that you can send objects to is the Where Cmdlet. This allows you to filter the output from another Cmdlet. As an example, you could use the WmiObject Cmdlet to query the list of network shares from the current computer. In order to return only the administrative shares, you would pipe the output from the WmiObject Cmdlet to the Where Cmdlet looking for names that end in a dollar sign as shown in Figure 7.20.

FIGURE 7.20. Using Windows PowerShell to Query for Hidden Network Shares on the Local Server

However, if you take this same command and change the – like command to – notlike command, it will return any network shares on the server that aren't administrative network shares. When run against our sample domain control, you'll get an output similar to the one shown in Figure 7.21.

FIGURE 7.21. Using Windows PowerShell to Query for Nonhidden Network Shares on the Local Server

Remote Management

With the introduction of Windows PowerShell 2, which was introduced with Windows 7 and Windows Server 2008 R2, you now have the ability to run PowerShell Cmdlets against remote machines. Until this time, Windows PowerShell Cmdlets could only be run against the same machine in which the PowerShell script was run. This is done by adding the – computername parameter to the first command as shown in Figure 7.22.

FIGURE 7.22. Accessing a Remote Computer's Network Shares through PowerShell

Integrated Scripting Environment

The initial version of Windows PowerShell included the shell environment as shown in figures such as Figure 7.22. Windows Server 2008 R2 and Windows 7 introduced the Integrated Scripting Environment, which provides you with a more user-friendly interface as shown as Figure 7.23. The top of the interface allows you to open, save, and run the scripts. The middle window shows any output from the script that you are currently running. The lower part of the window is an immediate run window, which allows you to run commands in a more interactive application like the prior PowerShell V1 application. This lower window includes tab completion of both the command and the parameters for the command.

FIGURE 7.23. Windows PowerShell Interactive Scripting Environment

Hello World

One of the simplest ways to create our script is to create a file called HelloWorld.PS1, then right-click on it and choose Edit. This will open the PowerShell ISE, as shown in Figure 1.10.

FIGURE 1.10. PowerShell ISE

In the top window, right next to the 1, we will want to paste the following code:

Write-Output "Hello World"

That's all there is to it. After saving the file, we can either run our code manually now by opening a PowerShell shell, navigating to it, and then running HelloWorld.PS1, or run it by clicking on the green triangle (10^th from the left) in the toolbar of ISE. In ISE, we will see the output from our script execution in the middle window of the interface. Write-Output is one of the PowerShell cmdlets we discussed earlier in this section, and it contains all the necessary functionality to print our statement. Also notice that, unlike our example in bash, we did not need to use anything like a shebang in order to indicate the interpreter we needed to use. In Windows, this function is handled through the use of the file extension .PS1, which indicates that the script should be handled by PowerShell.

Variables

Variables under PowerShell are, again, very similar to what we might find under bash. By default, variables have no type, meaning that a given variable can contain text or numeric data. Variables are always addressed as $<variable name>, whether assigning data to them or extracting data from them. Let's look at a quick variable example and a new cmdlet:

$processes = Get-Process powershell_ise

$processes

In this case, we are invoking the Get-Process cmdlet in order to get the process information for the ISE application we are using to develop our scripts. Then we are taking the returned data from the cmdlet and storing it in the $processes variable. On the next line, we are echoing out the contents of $processes. If everything was successful, we should see output similar to this:

The return from the cmdlet we echoed contains the information on the handles, nonpaged memory, paged memory, working set, virtual memory, CPU usage, process ID, and process name of the process on which we had requested information. Also notice that the formatted output of the cmdlet survives being stored in a variable and echoed out again.

We can also do local and global variable scoping in PowerShell. We will also talk about functions in PowerShell, as this provides us with a nice demonstration of how to deal with variable scope.

function hello{

$LOCAL:name = "whoever you are"

write-output "hello there "$name

}

$name = $args[0]

Write-output "hello there "$name

hello

write-output "hello there "$name

The first item we find in our script is the function we will use to demonstrate the scope of our variable. Functions in PowerShell are very similar to those we discussed when we went over the same topic in bash. The first line of the function is simply the function tag, the name by which we want to refer to the function, in this case hello, and the opening curly bracket, {, to start the function. On the first line inside the function, we can see the line creating our local variable. This variable, created with the local keyword, will only exist inside the scope of our function, and the function will keep its own copy of the contents, regardless of what we name it. Here, we set the contents of $LOCAL:name to the string whoever you are. On the next line, we echo out a greeting and the contents of the variable, then close up the function with }.

In the main body of the script, we take in an argument from the command line, $args[0], and place the contents of it into $name. Notice that this is the same variable name we used in our function, but without the LOCAL tag to set the variable scope, this implicitly makes the variable global in scope. Next, we echo out our greeting and the contents of $name, run the function, and echo the greeting and variable contents again. We can see from the output in Figure 1.11 that, even though we changed the contents of our local copy of $name in the function, we did not change the contents of the same variable in the main body of the script, due to the difference in variable scopes.

FIGURE 1.11. Differing Variable Scopes

Arguments

We can work with arguments in PowerShell in a very simple fashion. To expand on our process script in order to use an argument, we can do the following:

$processes = Get-Process $args

$processes

In order to run this script, we need to supply an argument containing the name of the process for which we will retrieve the information. In this case, we will use the explorer process as an argument, so we will run ./arguments.ps1 explorer. We should see output similar to Figure 1.12, showing us information for at least a couple of explorer processes.

FIGURE 1.12. Output from explorer.ps1

When we take in an argument in PowerShell, it is stored in an array called $args. We can think of an array as a variable with multiple storage compartments called elements, each of them individually addressable. With an array we can use a single data structure to store multiple pieces of information, adding, changing, or deleting them as we need to, without necessarily affecting any of the data we don't care to change.

In order to address the first element in the array, which holds our first (and only) argument, the name of the process on which we want to retrieve information, we could either refer directly to the first element in the array $args[0], or simply refer to the entire contents of the array with $args. If we wanted to refer to further arguments, we would just need to add a number, such as $args[1], which would refer to the second argument, $args[2] for the third argument, and so on.

If we wanted to modify our code to pull in information on multiple processes, we would change our script to:

$processes = Get-Process $args[0], $args[1]

$processes

Running the script as .\arguments.ps1 explorer winword would then return us information on both processes (likely more than one in the case of explorer).

Control statements

Just as we discussed in the first part of the chapter when we talked about control statements in bash, we can find the same in PowerShell and indeed in almost all high-level programming languages. We will discuss some examples of both conditionals and looping functions in PowerShell in this section.

Conditionals

Conditional statements in PowerShell follow many of the same lines as we might find in any of a number of other languages. We will look at if else statements and switches here.

If else statements are a slight variation on the if statements we can find in most languages. We can add an if statement to our earlier process example to add a little intelligence to it:

$processes = Get-Process

If ($processes –match "winword"){

   write-output "Microsoft Word is running"

}else{

   write-output "Microsoft Word is not running"

}

In this case, we run the same code we did previously to dump the information on all the running processes. We then set up our if statement to match against the output of Get-Process in order to look for the string winword, which is the process name for Microsoft Word. The –match operator uses a regular expression to search for the string we give it, and is a good choice in this particular instance, as it keeps us from having to parse through the entire process listing manually for the string we want.

Based on whether we get a match or not, we can then determine whether the process is running and provide the appropriate output to the user.

Switch statements function along the same general lines as an if statement, but enable us to configure a more complex set of actions based on the conditions we find. We can make our process checker a bit more capable by using a switch:

$processes = Get-Process

switch -regex ($processes){

   "winword" {write-output "Microsoft Word is running"}

   "explorer" {write-output "Explorer is running"}

   "vlc" {write-output "VLC is running"}

}

Now we can look for multiple processes in one go. Here we used the same cmdlet to dump out the process listing, and instead of being limited by the if statement, we built a more complicated set of conditions using the switch statement. We set up the first line of the switch on line 2 of the script, and configure our matching to use a regular expression (regex) and match against the contents of $processes, the variable where we stored the process listing.

In the body of our switch statement, we set up a series of lines, each for a different potential match. On each line, our very simple regex will check the line for the name of our process. Interestingly, since our variable $processes is holding multiple lines of text, the switch will attempt to match each line in the variable against each case in the switch. This is actually handy, since, as we can see in Figure 1.13, some processes do have more than one instance running.

FIGURE 1.13. Output from the Switch Example

Looping

There are a number of looping structures we can use in PowerShell and we will look at a couple of the more common and useful possibilities here. Looping in PowerShell follows much the same format as looping in most programming languages. One of the simplest looping constructs we can look at is the for loop:

for ($counter=0; $counter -lt 10; $counter++)

{

   $ping = New-Object System.Net.NetworkInformation.Ping

   $ping.Send($args[0])

   Start-Sleep -Second 5

}

We would want to run this script with .\looping.ps1 codingforpentesters.com. Let's have a look at what we did here. First we set up the beginning of our for loop, for ($counter=0; counter –lt 10; $counter++). So, this line initializes $counter with zero. This will be the variable that keeps track of how many times our for loop has executed. Next, we evaluate $counter to make sure it is still less than 10 with –lt. If this is true, we will continue; if not, we will stop right here. Lastly, we increment the value in $counter by 1. Next, we can find the body of our loop enclosed in braces, {}.

Inside the loop we are doing a very nice little bit of .NET work to call the ping function provided there. As PowerShell is a native Microsoft tool, it is fully capable of taking advantage of Microsoft's .NET development framework and all the goodies that come with it. In this particular case, we are instantiating an object to use for ping, running a ping against the host name or IP provided by our first argument, and sleeping for five seconds. After we finish sleeping, we will go back to the top of the loop, repeating this for a total of 10 times through. In the output, we will see the results of our pings display each time we execute the loop.

We can also use another construct called a foreach loop, like so:

$devices = @("codingforpentesters.com","happypacket.net")

foreach ($device in $devices)

{

   write-output "device is " $device

   $ping = New-Object System.Net.NetworkInformation.Ping

   $result = $ping.Send($device)

   $result

}

Here, we are doing things a bit differently. In this case, we want to ping more than one machine with our pinging routine. We would feed this in from the command line in the form of arguments, or we could pull it in from a file, but in this case we will use an array to hold the names of our hosts.

The first line in our script sets up and populates the array. We can see that this is very similar to setting up and populating a variable, with a little additional information to indicate we want it to be an array, in the form of the @. We also need to put parentheses around our list of elements and separate each of them with a comma.

After constructing the array, we set up the foreach loop. Here, we say foreach ($device in $devices). This means that for each item in our array called $devices, we should be doing something on each individual element, which we refer to as $device. We could have used any variable name to hold the contents of each element as we process through them, such as $i or $monkey; it really makes no difference what we call it.

The only other change from our previous pinging routine is to change the target of our ping.send to $device, in order to match our foreach configuration.