In Part 1 I talked about what PowerShell is and showed you how to install and access it on Windows Server 2008.

In Part 2 we went over PowerShell cmdlets and PowerShell providers. I showed you how to execute cmdlets and work with the objects returned and also how to use the different PowerShell providers to work with server resources inaccessible from the FileSystem provider.

In Part 3 we learned how to customize the user interface with the PowerShell profile.

And now that you are familiar with the capabilities of PowerShell, it is time to learn how to really unleash the power of PowerShell with PowerShell scripting.

Today I’ll show you how to take advantage of the script engine to automate the performance of Administrative tasks on the Server.

Understanding PowerShell Scripting

If you followed along with the PowerShell customization exercise that I showed you in the last article, you already know how to create PowerShell scripts. The profile file created in that exercise is actually a PowerShell Script.

In essence, a PowerShell script is simply a text file containing a list of PowerShell commands saved with the file extension .ps1.

For security purposes, script execution is disabled by default. You can set the script execution policy with the Set-ExecutionPolicy cmdlet.

The parameters available for the Set-ExecutionPolicy cmdlet are: -restricted, -unrestricted, -remotesigned and –allsigned. Enter the command: Get-Help Set-ExecutionPolicy –detailed for details on the Set-ExecutionPolicy cmdlet parameters.

In order to exhibit the capabilities of the PowerShell script engine we will go over a sample PowerShell script. The example script was created to display the potential of PowerShell scripting for performing administrative tasks in a server environment.

When the example script is ran, it behaves like a program. It first lists all the printers installed on the server and then prompts you to select one or all of the printers.

Once a printer is selected an additional menu is displayed for operations that can be performed with the printer or printers. When an action is selected, it is performed, then the program begins again at the beginning until you enter ‘exit’ at one of the prompts.

If we examine the script, we can see that it is broken up into three sections. The first section is dedicated to the function definition portion of the script. The second section covers the process of prompting the user. The third section is where the operation chosen is performed on the selected printer.

function cancelPrinterJobs {
	$objPrinter = $args[0]
	$objCancel = $objPrinter.CancelAllJobs()
	if ($objCancel.ReturnValue -eq 0) {
		write-host "Cancelled all jobs on"$objPrinter.Name
	}
	else {
		write-host "Cancel of all jobs on"$objPrinter.Name"failed"
	}
}

function pausePrinter {
	$objPrinter = $args[0]
	$objPause = $objPrinter.Pause()
	if ($objPause.ReturnValue -eq 0) {
		write-host $objPrinter.Name"pause"
	}
	else {
		write-host "Pause of"$objPrinter.Name"failed"
	}
}

function resumePrinter {
	$objPrinter = $args[0]
	$objResume = $objPrinter.Resume()
	if ($objResume.ReturnValue -eq 0) {
		write-host $objPrinter.Name" resumed"
	}
	else {
		write-host "Resume of"$objPrinter.Name"failed"
	}
}

function testPrinter {
	$objPrinter = $args[0]
	$objTest = $objPrinter.PrintTestPage()
	if ($objTest.ReturnValue -eq 0) {
		write-host $objPrinter.Name" printed a test page"
	}
	else {
		write-host $objPrinter.Name" test page failed"
	}
}

function setDefaultPrinter {
	$objPrinter = $args[0]
	$objDefault = $objPrinter.SetDefaultPrinter()
	if ($objDefault.ReturnValue -eq 0) {
		write-host $objPrinter.Name" Set as default."
	}
	else {
		write-host "Failed to set"$objPrinter.Name"as default"
	}
}

function writePrinterInfo {
	$objPrinter = $args[0]
	$strComputerName = $args[1]
	$colPrinters = get-wmiobject -class "Win32_PrinterConfiguration" -namespace "root\CIMV2" -computername $strComputerName

	write-host $objPrinter.Name "Printer Information"
	write-host
	write-host "Name: " $objPrinter.Name
	write-host "Driver Name: " $objPrinter.DriverName
	write-host "Port Name: " $objPrinter.PortName
	write-host "Shared: " $objPrinter.Shared
	write-host "Share Name: " $objPrinter.ShareName
	write-host "Queued: " $objPrinter.Queued
	write-host "Status: " $objPrinter.Status

	foreach ($objPrinter in $colPrinters) {
		if ($objPrinter.Name -eq $strPrinterName) {
			write-host "Driver Version: " $objPrinter.DriverVersion
			write-host "Paper Size: " $objPrinter.PaperSize
			write-host "X Resolution: " $objPrinter.XResolution
			write-host "Y Resolution: " $objPrinter.YResolution
			write-host
			break
		}
	}
}

In the first section, six functions are defined. Each function performs an action with a printer. The function cmdlet is used to define each function. Immediately after the function cmdlet the function name is supplied, followed by the commands of the function enclosed in curly brackets.

Functions in PowerShell do not support defining the arguments. Instead, functions accept a virtually unlimited number of space-separated objects as arguments. The arguments can be accessed within the function with the $args variable.

When PowerShell executes a script, commands are executed as the script is read rather than loaded to memory and then executed. Therefore, a function must be defined in the script before it is ever called.

It is a good idea to always define all your functions first in a PowerShell script. If a function is called within another function the called function must be defined first.

The first commands of every function are to assign the expected argument to a variable for script readability. All the functions expect a WMI Printer object as the first argument. Only the last function expects a second argument, the computer name.

The first five functions each execute a method of the printer object and assign it to a variable. The return value is checked for successful execution with an “if” statement and if the conditions in the parentheses are met the Write-Host cmdlet in the curly brackets is executed to display a success message.

If the successful condition is not met a failure message is displayed from the command in the curly brackets of the else statement.

After the argument variables are assigned in the final function the Get-WMIObject cmdlet is used to assign the Win32_PrinterConfiguration object to a variable. Then select properties from the supplied Printer object are displayed.

After that the Foreach-Object cmdlet is used to loop through the items of the PrinterConfiguration object then checks if its name matches that of the Printer object supplied to the function. When a match is found select properties from the PrinterConfiguration object are displayed and the loop is exited with the break cmdlet.

cls

$strComputerName = "."
$colPrinters = get-wmiobject -class "Win32_Printer" -namespace "root\CIMV2" -computername $strComputerName | sort-object "Name"

do {
	$printerIndex = 0
	write-host
	write-host "Installed Printers"
	write-host
	write-host "0) All Printers"

	foreach ($objPrinter in $colPrinters) {
		$printerIndex = $printerIndex + 1
		write-host $printerIndex") "$objPrinter.Name
	}

	write-host

	$selectedPrinterIndex = read-host "Select the printer(s) you wish to work with or type 'exit' to exit"
	if ($selectedPrinterIndex -eq "exit") {
		break
	}
	$validated = 0
	do {
		if ($selectedPrinterIndex -gt $printerIndex) {
			$selectedPrinterIndex = read-host "Please enter a valid printer number"
		}
		else {	$validated = 1 }
	}
	while ($validated -lt 1)

	write-host
	write-host "Printer Operations"
	write-host
	write-host "0) Display Printer(s) Information"
	write-host "1) Cancel Printer(s) Jobs"
	write-host "2) Pause Printer(s)"
	write-host "3) Resume Printer(s)"
	write-host "4) Test Printer(s)"
	if ($selectedPrinterIndex -gt 0) {
		write-host "5) Set Printer As Default"
	}
	write-host

	$selectedOperationIndex = read-host "Select an action to perform on the printer or type 'exit' to exit"
	if ($selectedOperationIndex -eq "exit") {
		break
	}
	$validated = 0
	do {
		if ($selectedOperationIndex -gt 5) {
			$selectedOperationIndex = read-host "Please enter a valid operation number"
		}
		else {
			if ($selectedPrinterIndex -eq 0) {
				if ($selectedOperationIndex -eq 5) {
					$selectedOperationIndex = read-host "Please enter a valid operation number"
				}
				else {	$validated = 1 }
			}
			else {	$validated = 1 }
		}
	}
	while ($validated -lt 1)

The second section of the script is where execution begins. The program begins by clearing the console with the cls cmdlet. Next a variable is assigned with the computer name.

When a computer name is expected as a cmdlet parameter the dot used will be interpreted as the local machine. The computer name variable is then used when assigning the WMI Win32_Printer object to a variable.

The DoWhile-Object is executed next and is closed at the end of the script with while (1). This tells the program to loop execution until the loop is exited with the break cmdlet.

The next four commands display the printer menu title and first option as 0 for selecting all printers. A variable is then created to keep track of the printer index before the foreach-object cmdlet is used to loop through the Printer objects of the Win32_Printer object. Each time through the loop one is added to the printer index then it is displayed with the name of the current Printer object.

After the loop a blank line is displayed to separate the menu items from the prompt. The prompt is displayed with the Read-Host cmdlet and the input is assigned to a variable to represent the index of the selected printer. The printer index variable is then checked if the value is exit and exits the main program loop if so.

A variable is then assigned the value of 0 to represent the input has not been validated. A Do While loop is set to loop until the validation variable equals 1. Enclosed in the loop is an if object that is used to check if the printer index exceeds the number of printers, if so, If the input is invalid the script prompts again for a valid printer index until a valid input is provided by the user.

The second menu is then displayed. An “if” statement is used to check if the printer index variable is greater than 0 before the operation to set as the default printer is displayed.

The user is then prompted to enter an operation. Validation for the second menu is done using the same logic as the first menus validation. The difference is an “if” statement to check to make sure the operation index supplied is not to set all printers to default.

	if ($selectedPrinterIndex -gt 0) {
		$objPrinter = $colPrinters[$selectedPrinterIndex - 1]
	}

	write-host
	switch ($selectedOperationIndex) {
		0 {
			if ($selectedPrinterIndex -eq 0) {
				foreach ($objPrinter in $colPrinters) {
					writePrinterInfo $objPrinter $strComputerName
				}
			}
			else {	writePrinterInfo $objPrinter $strComputerName }
		}
		1 {
			if ($selectedPrinterIndex -eq 0) {
				foreach ($objPrinter in $colPrinters) {
					cancelPrinterJobs $objPrinter
				}
			}
			else {	cancelPrinterJobs $objPrinter }
		}
		2 {
			if ($selectedPrinterIndex -eq 0) {
				foreach ($objPrinter in $colPrinters) {
					pausePrinter $objPrinter
				}
			}
			else {	pausePrinter $objPrinter }
		}
		3 {
			if ($selectedPrinterIndex -eq 0) {
				foreach ($objPrinter in $colPrinters) {
					resumePrinter $objPrinter
				}
			}
			else {	resumePrinter $objPrinter }
		}
		4 {
			if ($selectedPrinterIndex -eq 0) {
				foreach ($objPrinter in $colPrinters) {
					testPrinter $objPrinter
				}
			}
			else {	testPrinter $objPrinter }
		}
		5 {
			setDefaultPrinter $objPrinter
		}
	}
}
while (1)
cls

The final section of the script handles performing the selected operation with the selected printer or printers. It starts off by assigning the selected printer object to a variable using the selected printer index if the user did not select all printers.

The control of which operation is to be executed is handled by the Switch cmdlet. Within the curly brackets of the Switch cmdlet the commands executed are the commands within the curly brackets of the number in the Switch cmdlet that match the operation index provided by the user.

In all cases but the last, an if statement is used to check if the selected operation is to be performed on all printers. If all printers have been selected a foreach loop is used to pass all the Printer objects to the proper function otherwise only the Printer object of the selected printer is passed to the function.

The fifth case does not check if all printers were selected because the input validation prevents the option from being able to be selected if all printers are selected. After the switch statement the program’s infinite Do While loop is closed off the screen cleared and execution of the script ends.

Now that you are so familiar with how to create dynamic PowerShell scripts, you probably want to know how to execute a script. To demonstrate, go ahead and copy the commands from all three sections of the script example into notepad and save it to ‘C:\PrinterOperations.ps1’. From PowerShell enter the command below to execute the script.

& “C:\PrinterOperations.ps1”

With the command above, variable names and functions used in the script will be destroyed when execution completes. If you wish to have script variables and functions available within PowerShell after the script has finished executing you can use dot-sourcing.

The command below will run the script and when execution completes you will have access to the variables and functions created will still be available.

& . “C:\PrinterOperations.ps1”

I hope that you’ve enjoyed reading my series on Windows PowerShell.

Keep in mind that there are many additional resources and a number of informative references available on this topic. The owner’s manual, articles, and many useful scripting examples are available at Microsoft TechNet’s Script Center.

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 2
• Take Command of Server 2008 with Windows PowerShell – Part 3
• Take Command of Server 2008 with Windows PowerShell – Part 1

You’ve made it this far, so I’m assuming you enjoyed part one, where I showed you how to install and access PowerShell, and part two, where I explained PowerShell Cmdlets and PowerShell Providers.

If you missed those two articles, I would suggest reading them first — just to make sure you’ve got all the basics. Now let’s get started with an exercise in customizing your Windows PowerShell.

Customizing Windows PowerShell

Windows PowerShell starts with the same look and feel of the Command Prompt, by default. Let’s make our first exercise of PowerShell power be to customize the PowerShell console.

The steps below will walk you through customizing the console options then saving those settings to be used every time PowerShell is launched.

1. Open Windows PowerShell

2. Create a variable to the PowerShell RawUI object with the command below:

$psui = (get-host).UI.RawUI

3. Use the $psui variable to change the background and text colors with the commands below:

$psui.WindowTitle = “PowerShell PowerStation”
$psui.BackGroundColor = “Blue”
$psui.ForeGroundColor = “Yellow”

Note: The PowerShell console supports 16 colors. They are; Black, White, Blue, Cyan, Gray, Green, Magenta, Red, Yellow, DarkBlue, DarkCyan, DarkGray, DarkGreen, DarkMagenta, DarkRed and DarkYellow.

4. Use the cls command to clear the console and fill the console with the background color specified

5. View the other properties available to the object by entering $psui

Note: If you wish to change RawUI objects with multiple properties such as the BufferSize property you must assign the property to another variable to modify the object’s properties like the example below:

$psbs = $psui.BufferSize
$psbs.Height = 3000
$psbs.Width = 120

6. Decide on how you want to customize the PowerShell console with the properties available

7. Open your PowerShell Profile with notepad with the command below:

notepad $profile

8. Assuming that you are running Server 2008 and this is the first time creating a PowerShell profile, Notepad should display an error that the file was not found.

Click Ok to close the error and return to PowerShell to rectify the problem.

9. Try using the command below to create the profile file:

create-item $profile –type “file”

10. The previous command attempts to create the profile file under your ‘Documuents\Windows PowerShell’ directory, but with no Windows PowerShell directory, no file was created

11. Use some PowerShell power to create the directory then the profile file by entering the commands below:

new-item $profile.SubString(0, $profile.LastIndexOfAny(“\\”))
create-item $profile –type “file”

Note: If you have any experience with the .NET framework the first command of this step should look familiar. It utilizes the methods of the string object to parse the profile path out of the profile variable.

12. Open the newly created file by entering notepad $profile again

13. Enter the property changes as you would in PowerShell into the profile file. Below is an example of the contents of a profile file with the same setting examples in these steps:

$psui = (get-host).UI.RawUI
$psbs = $psui.BufferSize
$psui.WindowTitle = “PowerShell PowerStation”
$psui.BackGroundColor = “Blue”
$psui.ForeGroundColor = “Yellow”
$psbs.Height = 3000
$psbs.Width = 120
cls

14. Click File | Save to save the changes to the profile

If script execution is enabled, when you launch PowerShell it will automatically start with the configuration set in the profile file. If not enabled, proceed to the next section for information on enabling it.

This example only covers customizing the PowerShell console window. Keep in mind that any variables or functions you define in the profile file will be automatically available for use when you launch PowerShell.

This is it for today! Next week we’ll go into PowerShell scripting — so don’t miss the last article of taking command of Server 2008 with Windows PowerShell. See you next week!

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 2
• Take Command of Server 2008 with Windows PowerShell – Part 1
• Take Command of Server 2008 with Windows PowerShell – Part 4

Welcome back! Today we’re learning about PowerShell Cmdlets and PowerShell Providers.

If you missed the first part of this short series, make sure to take a look at it when you get a chance.

Take Command of Server 2008 with Windows PowerShell – Part 1 will provide you with a good introduction to PowerShell and show you the steps to installing and accessing PowerShell on your Server 2008.

Now let’s get started with Cmdlets, the essence of Windows PowerShell.

Understanding PowerShell Cmdlets

Taking advantage of the power of PowerShell is done with the use of cmdlets. The cmdlets are powered by a set of .NET objects and methods developed with server and network administrative purposes in mind.

An example of a cmdlet is Get-ChildItem, which is used for listing the contents of an object. That’s right, object.

Any output created within PowerShell is output in the form of an object as opposed to text. An object is an item that can contain multiple properties and/or methods, which can return more objects.

If no action is performed on an object, PowerShell outputs the object details in text form. Actions can be performed on an object returned by a cmdlet by pipelining another command with the pipe character between commands.

The command below lists the contents of the current object (directory) sorted by name in descending order.

get-childitem | sort-object “Name” –descending

In the above example, the Sort-Object cmdlet is used on the return object of the Get-ChildItem cmdlet to sort by the Name property. Tacked onto the end of the command are the property and descending parameters.

The actions performed by cmdlets are determined by the parameters supplied to the cmdlet. Alternatively you could have supplied the –property parameter flag before “Name”, but because that is the cmdlet’s default parameter, that is not necessary.

Aside from the cmdlet specific parameters, you can also use common parameters with cmdlets to be handled by the PowerShell engine itself.

Not all cmdlets support all the common parameters; most of them usually work though. The common PowerShell parameters are defined below:

• -confirm – Prompts the user for confirmation before executing a command.
• -debug – Tells the cmdlet to provide debugging information.
• -ErrorAction – Allows the cmdlet to; continue, stop, silently continue or inquire when an error occurs.
• -ErrorVariable – Tells the cmdlet to assign error information to the variable specified.
• -OutBuffer – Tells the cmdlet to hold a certain number of objects before calling a pipelined cmdlet.
• -OutVariable – Tells the cmdlet to assign output to the variable specified.
• -verbose – Tells the cmdlet to provide more detail.
• -whatif – Tells the result of executing the command without executing it.

If you have been working along, you probably noticed that the output from the Get-ChildItem cmdlet looks a lot like what you would expect to see by entering dir. This is no coincidence.

When you enter dir you are actually entering the alias assigned to the Get-ChildItem cmdlet. Cmdlets come with pre-assigned aliases and can also have custom defined aliases.

Cmdlet aliases can be listed with the Get-Alias and set with the Set-Alias cmdlets.

Should you ever have the need to find out more information on a cmdlet you can use the Get-Help cmdlet. The Get-Help cmdlet itself has parameters such as –detailed and –full for determining the amount of help shown.

If you ever have trouble remembering the name of a cmdlet you can use the Get-Command cmdlet. Entering Get-Command by itself lists all the PowerShell cmdlets. You can also supply part of a cmdlet name to narrow down the results like in the example below:

get-command get-

Executing the above command lists all the cmdlets that begin with ‘get-‘. The Get-Help and Get-Command cmdlets should prove very useful for helping you to get familiar with the capabilities and usage of PowerShell.

Understanding PowerShell Providers

By default, when PowerShell is launched, you will start with your profile folder as your working directory. Access to this directory is available to you courtesy of the FileSystem provider.

PowerShell providers take the form of logical drives that provide access to data stored within the drives in a fashion that can be navigated and manipulated using the PowerShell cmdlets.

PowerShell comes packaged with seven default providers. You can list the available providers and their respective drives with the Get-PSProvider cmdlet. Additional providers can be installed with the New-PSDrive cmdlet.

The default PowerShell providers are explained below:

• Alias – Provides access to the aliases assigned to cmdlets.
• Certificate – Provides the ability to sign and work with scripts.
• Environment – Provides access to the Windows Environment variables that hold information on configuration and special folders.
• FileSystem – Provides access to the files and folders available on your local drives.
• Function – Provides access to the functions defined in PowerShell.
• Registry – Provides access to the Windows registry.
• Variable – Provides access to the variables assigned in PowerShell.

You can gain access to the different PowerShell providers by using the Set-Location cmdlet. The command below will change the working directory to the Variable provider.

set-location variable:

From the Variable provider you can list all the variables assigned in the console and their respective values with the Get-ChildItem cmdlet. You can also create new variables using the New-Item cmdlet or remove them with the Remove-Item cmdlet amongst other things.

It’s important to note that the Variable provider is not the only place you can work with variables. Variables can be assigned or used anywhere you go with PowerShell.

Variables are identified in the PowerShell console with the dollar sign. Executing the command below will assign a value to a variable.

$variable = “I’m a variable”

To display the newly assigned variable, execute the command below.

$variable

Providers give great potential for expanding the capabilities of PowerShell. They provide access for working with many resources on the server.

The PowerShell provider system has removed the restriction of working solely with the server’s file system within the command shell environment.

We’re done for today, but don’t forget to come back next week for more on taking command of Server 2008 with Windows PowerShell!

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 1
• Take Command of Server 2008 with Windows PowerShell – Part 4
• Take Command of Server 2008 with Windows PowerShell – Part 3

The command shell evolved from direct entry into Windows underlying DOS environment to an emulated DOS Environment in later Windows versions.

All the while the command shell has made strides to maintain backward compatibility with the original DOS environment, however, little has been done to expand upon the capabilities of the command shell.

Utilizing the power of the .NET Framework, Microsoft has released a brand new command shell environment aptly titled Windows PowerShell.

Introducing: Windows PowerShell

Like its predecessors, Windows PowerShell supports all the previous command shell commands such as “cd” to change directories, and “dir” to list directory contents, and converting your old batch files to PowerShell scripts is virtually effortless.

But don’t be fooled by the fact that PowerShell can execute old commands and batch files. PowerShell is run by a brand new command set consisting of some 120 cmdlets.

Cmdlets make themselves useful within each of the PowerShell providers. Providers are objects that store their data in a structure navigable like the Windows File and directory system.

In fact, the default PowerShell provider is the FileSystem provider, which gives access to the files and folders stored on the system drives.

PowerShell’s automation and time saving capabilities become apparent when you take advantage of three key features.

• Pipelining command objects together
• Multiple commands separated by semicolons on a single line
• Powerful and flexible scripting engine

With all that, PowerShell not only acts as a replacement to the standard Windows Command Prompt, in many ways its usefulness as an administrative scripting engine exceeds that of VB Script. PowerShell scripting can accomplish virtually everything VB Script can and do it with greater efficiency in several areas.

Installing Windows PowerShell

Now that you have heard of this new tool, you are probably wondering how to get your hands on all that power?

Like most of Windows Server 2008’s useful features, Windows PowerShell is not installed as a default Windows Component. This is mostly because Windows PowerShell is dependent on .NET Framework 2.0 or higher being installed.

Assuming your installation of Server 2008 meets these requirements, PowerShell can be installed by following the steps below:

1. Open the Server Manager from Start | Control Panel | Administrative Tools | Server Manager
2. From the Server Manager Click Features then click Add Features
3. Check the box labeled Windows PowerShell and click the Next button
4. Click the Install button to confirm installation and wait
5. When the installation is complete, click the Close button to exit the Add Features Wizard

Accessing Windows PowerShell

With PowerShell now pleasantly residing on your server, all that is necessary to bring the power to your fingertips is launching it.

Like many Windows features, PowerShell can be accessed more ways than one. Below are the basic methods for accessing PowerShell.

• Start | Run | PowerShell.exe
• Start | All Programs | Windows PowerShell 1.0 | Windows PowerShell
• From the standard Command Prompt by entering PowerShell.exe

If you prefer, you could also copy the PowerShell shortcut from the start menu to the desktop or quick launch tool bar for easier access.

But Wait! There’s More …

That’s all for today, but don’t worry, in the next few weeks, you will have the opportunity to get fully acquainted with Windows PowerShell through a series of articles, this one being the first.

The main goal of this series is to show you the capabilities and proper usage of Windows PowerShell. So that after reading all the articles you will be familiar with the following:

• Installing and Accessing Windows PowerShell on Windows Server 2008.
• Launching the PowerShell command console.
• Executing cmdlets and working with the objects returned.
• Using the different PowerShell providers to work with server resources inaccessible from the FileSystem provider.
• Using variables to store and reuse objects in PowerShell.
• Customizing the user interface of PowerShell with the PowerShell profile.
• Taking advantage of the script engine to automate the performance of Administrative tasks on the Server.

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 2
• Take Command of Server 2008 with Windows PowerShell – Part 3
• Take Command of Server 2008 with Windows PowerShell – Part 4