Simply finding the right objects and then updating their properties or implementing changes can be a cumbersome process. Many Microsoft systems engineers have developed their own shortcuts and conventions over the years for dealing with the administration of complex Active Directory structures. One tool that has been lacking, however, is the ability to write powerful scripts to manage Active Directory.

The good news is that the arrival of Windows Server 2008 R2 with PowerShell 2.0 and the Active Directory Module changes all of that for the better.

Powershell 2.0 and Active Directory Module

Of the many new features in Windows Server 2008 R2, PowerShell 2.0 is one that may finally be coming into its own. One of the key new features in PowerShell 2.0 is the addition of modules. Modules differ from PowerShell 1.0 snap-ins in that they are self-contained and do not require registration or installation. Rather, modules are imported into the shell via the Import-Module command. Modules can also be offloaded when they are no longer needed.

To use the Active Directory Module, there needs to be at least on Windows Server 2008 R2 Domain Controller running Active Directory Web Services (ADWS) in the domain. As an alternative, the Active Directory Management Gateway Service can be installed on Windows Server 2003 SP2 servers and Windows Server 2008 (non-R2) servers with or without SP2 installed.

For the most powerful configuration of PowerShell 2.0 with the Active Directory Module, you will want to be able to do your scripting remotely from your own computer, or other workstation. This does require Windows 7 in order to install the Remote Server Administration Tools (RSAT).

The Active Directory Module provides a powerful way to manage AD structures even across domains. Part of the AD Module is the PSDrive Provider which allows you to map to an Active Directory domain using whatever credentials are required via the New-PSDrive cmdlet. Users are connected to their current domain by default. The mapped rights persist for the entire shell session, even if it requires using different login credentials for several different AD domains.

Active Directory Scripts In PowerShell 2.0

There are many different commands included in the Active Directory Module. One count places the total number of new commands at 82. The most commonly used commands, however, are those that match up with the most common Windows Server Administrator tasks. The naming convention for Active Directory cmdlets dictates that each cmdlet start with “AD” in order to help separate the Active Directory versions from similar PowerShell cmdlets available in the base PowerShell.

Thanks to this naming convention, obtaining a list of all the Active Directory Module cmdlets can be done by running the Help *-AD* command.

The most difficult part of getting up to speed with Active Directory management via PowerShell 2.0 is mastering all of the parameters available for each cmdlet. In an effort to allow virtually any function that can be performed manually to be scripted, Microsoft had to provide a working parameter for pretty much every setting, checkbox, and field that there is in the GUI. That means that some commands have a mind boggling array of available options. Fortunately, only a small subset of any cmdlet’s parameters are mandatory in order to run the desired command.

As with any new programming language, the key is to focus in the beginning on the basics and most frequently used options and build mastery as you go along. While it may seem daunting at first, one will quickly find that using built-in cmdlets specifically designed for their purpose ends up being much easier to both code and manage than mastering all of the work-arounds and band-aids currently required to perform the same tasks.

Common Active Directory Cmdlets for PowerShell

The most common administrative tasks within Active Directory are those that relate to creating, finding, and changing objects and users. Not surprisingly, these cmdlets make a great place to start learning and using PowerShell 2.0 to manage Active Directory.

Commonly used PowerShell AD cmdlets include:

• New-ADUser
• New-ADGroup
• New-ADComputer
• New-ADOrganization
• New-ADServiceAccount
• Unlock-ADAccount
• Enable-ADAccount
• Disable-ADAccount
• Get-ADUser
• Add-ADGroupMember
• Get-ADGroupMember
• Get-ADForest
• Get-ADDomain
• Get-ADDomainController

Of course, the real power from scripting comes not from typing in a bunch of esoteric computer commands instead of clicking mouse buttons, but from the ability to save useful scripts and use them over and over again. To this end, Active Directory cmdlets support piping information into the cmdlets. For example, to create a couple dozen new users, the administrator could take the Excel Spreadsheet supplied from Human Resources, export it as a CSV file and then pipe the resulting data to the New-ADUser command: Import-CSV c:\neweuserdata\april-new-employees.csv | New-ADUser and let the script take care of all the basic data entry.

Using parts of the same file, the admin can go back through and using the appropriate cmdlets add users to their respective groups and domains and even apply additional group policies to the new users.

Of course, easy, but highly repetitive tasks can be automated as well. Imagine picking up the phone with a call from a panicked user who has locked himself out of his account (again). A tiny shortcut launched directly with minimal typing and clicking requiring nothing more than the user’s login name quickly firing off and unlocking or even re-enabling the account, all without ever having to leave the screen you were already working on when the phone rang.

PowerShell Resources

Even though the Active Directory Module is new with PowerShell 2.0 there are already some great references available for Microsoft server administrators. Check out Jonathan Medd’s Active Directory PowerShell Quick Reference Guide for help getting up to speed and remembering lesser used commands. Microsoft has a general PowerShell Quick Reference guide as well. For those of you lamenting the hours spent mastering VBScripting, check out the VBScript to Windows PowerShell Conversion Guide.

Learning new technology and skills is never easy, but the truth — if we are willing to admit it — is that as high-tech computer administrators, we quickly grow bored with doing the same things over and over again. Not only does PowerShell 2.0 and the Active Directory Module provide some new material for the skills menu, it also provides a way to eliminate far more tedious, repetitive tasks than ever before.

Related posts:

• PowerShell 2.0: Server 2008 R2 Top New Management Feature
• Take Command of Server 2008 with Windows PowerShell – Part 1
• Don’t be Afraid of PowerShell

PowerShell is Microsoft’s newish extensible scripting language and corresponding command line shell. PowerShell was specifically made for IT professionals to achieve greater productivity and control system administration more easily. 

What PowerShell Can Help You Do

The thing is, PowerShell can do pretty much anything except walk your dog for you. You can even check the date and time if you really wanted to. I guess you could stop using the command line all together and do all your cmd tasks from within the PowerShell shell.

However, the real fun comes in when you can use PowerShell to make your sysadmin life easier. Here are a few random examples:

• Inventory your servers like what each has, the free memory, what service pack it is running, and so on.
• Add multiple users at once to your AD and then give them all a mailbox in Exchange.
• Back up and sync certain files then email yourself a corresponding log file…every night.
• Test out those scary commands before committing to them using the Whatif feature.
• And maybe the most compelling thing: You know how in Server 2008 R2 you can recover an AD object from the recycle bin after you have – oops – deleted it? Well you won’t find that option anywhere in the GUI. You need PowerShell to do it. If that isn’t a reason to give PowerShell a try then I don’t know what is!

For the Newbies

Good News! You don’t need any prior programming experience to use PowerShell — it is that intuitive. But, just so we are on the same page here is a short vocab lesson:

• Shell – What you the user actually interacts with. Either a command line or a GUI (graphical user interface).
• Extensible – The ability of a system to grow and change as needed.
• Scripting Language – Well, there are numerous debates going on all over creation about the difference between a programming language and a scripting language. You don’t really need to understand the specifics to understand that PowerShell is a language that you use to do administrative tasks. Who cares whether it is interpreted or compiled?
• cmdlets – Pronounced command-lets. Cmdlets are simple tools that can be used separately, but their power is realized when you combine these simple tools to perform complex tasks. Microsoft provides buckets of built-in cmdlets  but you can write your own if you see fit.

For the People with Programming or Unix Experience

Not surprisingly PowerShell has all the comforts of home: man pages, aliases, wildcards, and pipelines; if statements, recursion, and loops.

If you have worked with VB or WHS then you should be able to make the translation pretty easily. There is even help for translating your existing VB scripts to PowerShell.

PowerShell Resources to Get You Started

1. Take Command of Server 2008 with PowerShell — a short series of articles that provide a good introduction to PowerShell
2. PowerShell FAQ provided by Microsoft
3. Professor PowerShell Jeff Hick’s educational column on MCPmag.com
4. Windows PowerShell Owners Manual a free guide to getting started with PowerShell
5. Scripting with Windows PowerShell a list of resources for sysadmins interested in learning about PowerShell
6. Windows PowerShell Blog with information about the latest advancements in PowerShell
7. Windows PowerShell Cookbook providing you with recipes to do specific tasks with PowerShell.
8. Windows PowerShell 2.0 will teach you just about everything you ever wanted to know about PowerShell (and more)

 Good luck!

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 1
• Active Directory PowerShell Scripts Management Tool For Admins
• Take Command of Server 2008 with Windows PowerShell – Part 2

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