Professional Windows PowerShell by Andrew Watt

From the Publisher

• MSH is a new command-line shell for Microsoft server products, including the long-awaited Longhorn server, and will eventually ship with all major Microsoft products, making it the must-know technology
• MSH will replace current command lines in new Microsoft products and can be used to write shell scripts similar to those used with Unix and Linux
• Discusses how MSH enables all of the .NET Framework objects to become accessible via scripting, making it a very powerful addition to any developer's or administrator's toolbox
• Readers are guided through all the ins and outs of MSH and learn how to create powerful solutions; run scripts, programs, and commands; customize the MSH environment; handle data; manage files and disks; and script solutions and .NET objects

Product Details

• Table of Contents
• Read a Sample Chapter

Table of Contents

Read a Sample Chapter

Professional Windows PowerShell

John Wiley & Sons

Chapter One

If you are like me, then when you begin to look seriously at an interesting piece of software, you like to get your hands dirty and play with it from the beginning. In this chapter, I show you how to get started using Windows PowerShell, and I'll show you enough of the PowerShell commands to let you begin to find your way around effectively. In the rest of the book, I help you build on that initial knowledge so that you can use PowerShell for a wide range of useful tasks, depending on your requirements.

Windows PowerShell, as you probably already know, is Microsoft's new command shell and scripting language. It provides a command line environment for interactive exploration and administration of computers, and by storing and running Windows PowerShell commands in a script file, you can run scripts to carry out administrative tasks multiple times. Windows PowerShell differs in detail from existing command line environments on the Windows and Unix platforms, although it has similarities to past environments. In Chapter 3, in particular, Iexplain more about the PowerShell approach, although differences from existing command shells and scripting languages will emerge in every chapter.

Once you have had a brief taste of PowerShell, you will need to understand a little of the assumptions and approach that lie behind the design decisions that have made PowerShell the useful tool that it is. In Chapter 2, I step back from using the PowerShell command line and look at the strengths and deficiencies of some existing Microsoft approaches to system management and then, in Chapter 3, take a look at the philosophy and practical thought that lies behind the approach taken in Windows PowerShell.

Installing Windows PowerShell

Windows PowerShell depends on the presence of the .NET Framework 2.0. Before you install PowerShell, you need to be sure that you have the .NET Framework 2.0 installed.

Installing .NET Framework 2.0

At the time of writing, the 32-bit version of the .NET Framework 2.0 runtime is available for downloading from www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en.

If you are using 64-bit Itanium processors, download the .NET Framework 2.0 runtime from www.microsoft.com/downloads/details.aspx?familyid=53C2548B-BEC7-4AB4-8CBE-33E07CFC83A7&displaylang=en. Windows PowerShell is only available on Windows Server 2003 for Itanium processors.

If you are using AMD 64-bit processors, download the runtime from www.microsoft.com/downloads/ info.aspx?na=47&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=F4DD601B-1B88-47A3-BDC1-79AFA79F6FB0&u=details.aspx%3ffamilyid%3dB44A0000-ACF8-4FA1-AFFB-40E78D 0788B00%26displaylang%3den.

If you are unsure whether or not you have .NET Framework 2.0 installed, navigate to C:\Windows\ Microsoft.NET\Framework (if necessary substitute another drive letter if your system drive is not drive C:). In that folder you will find folders that contain the versions of the .NET Framework that are installed on your machine. If you see a folder named v2.0.50727, then you have the .NET Framework 2.0 installed. The .NET Framework 2.0 SDK, which you can download separately, is useful as a source of information on .NET 2.0 classes that you can use with PowerShell.

Figure 1-2 shows the appearance of the Framework folder on a clean install of Windows 2003 Service Pack 1 after the .NET Framework 2.0 runtime has been installed.

You don't need to delete the v1.0.3705 or v1.1.4322 folders. In fact, you are likely to cause problems for applications that need earlier versions of the .NET Framework if you delete those folders. The .NET Framework 2.0 is designed to run side by side with .NET Framework 1.0 and 1.1.

To install the .NET Framework 2.0, follow these steps.

1. Navigate in Windows Explorer to the folder where you downloaded the installer, dotnetfx.exe.

2. Double-click the installer. On the splash screen that opens, click Next.

3. On the EULA screen, accept the license agreement and click Install.

4. The installer then proceeds to install the .NET Framework 2.0, as shown in Figure 1-3.

5. When the installation has completed successfully, you should see a screen similar to Figure 1-4.

6. If you have Internet connectivity, click the Product Support Center link shown in Figure 1-4 to check for any updates.

Once you have installed the .NET Framework 2.0, you can then install Windows PowerShell.

Installing Windows PowerShell

To install Windows PowerShell on a 32-bit system, follow these steps. If you are installing it on a 64-bit system, the installer filename will differ.

1. Double-click the .exe installer file appropriate for the version of Windows PowerShell you want to install. The initial screen of the installation wizard, similar to the one shown in Figure 1-5, is displayed.

2. Click Next.

3. Accept the license agreement and click Next.

4. If you are installing on drive C: on a 32-bit system, the default install location is C:\Windows\System32\windowspowershell\v1.0.

5. When the installation has completed successfully you will see a screen similar to Figure 1-6.

6. Click Finish.

Starting and Stopping PowerShell

Once you have installed Windows PowerShell, you have several options for starting it.

Starting PowerShell

To start PowerShell without using any profile file to customize its behavior, open a command window (On Windows 2003, select Start -> All Programs -> Accessories -> Command Prompt), then type:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile

After a short pause, the Windows PowerShell prompt should appear (see Figure 1-7).

If you are still using a Release Candidate and attempt to start PowerShell by simply typing PowerShell .exe at the command shell prompt, you may see the error message shown in Figure 1-8. To fix that, update to the final release version.

Alternatively, you can start PowerShell by selecting Start -> All Programs -> Windows PowerShell 1.0 -> Windows PowerShell (see Figure 1-9).

Because of security concerns about previous Microsoft scripting technologies, the default setting of Windows PowerShell is that scripting is locked down. Specifically, when Windows PowerShell starts, it does not attempt to run profile files (which are PowerShell scripts) that contain various settings controlling how PowerShell should run. Whichever way you start PowerShell initially, you will probably later want to enable scripts. To do that, you use the set-executionpolicy cmdlet. Type:

set-executionpolicy -ExecutionPolicy "RemoteSigned"

and you will be able to run locally created scripts without signing them. I cover execution policy in more detail in Chapter 10.

There are several additional options for starting PowerShell, and I will briefly describe all of those - after I show you how to stop PowerShell.

Exiting PowerShell

To stop PowerShell, simply type the following at the PowerShell command line:

Exit

and you are returned to the CMD.exe command prompt (assuming that you started PowerShell from the CMD.exe prompt). If you started PowerShell using Start -> All Programs -> Windows PowerShell 1.0 -> Windows PowerShell, the PowerShell window closes.

You can't use "quit" to exit PowerShell. It just causes an error message to be displayed.

Startup Options

You have several options for how you start PowerShell. These are listed and explained in the following table. On the command line, each parameter name is preceded by a minus sign.

To view information about all help options, type:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -Help

or:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -?

or:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe /?

at the command line. Each of those commands will cause the information, part of which is shown in Figure 1-10, to be displayed.

Notice that there are sets of parameters that you can use with PowerShell.exe. You can combine parameters only in the ways shown in Figure 1-10.

The preceding commands give you help on how to start Windows PowerShell. Once you start PowerShell, you also need to know where to find help on individual PowerShell commands. As a first step, you need to be able to find out what commands are available to you.

Individual PowerShell commands are small and granular. As a result, they are called cmdlets (pronounced "commandlets").

Finding Available Commands

In this section, I will show you a few commonly used commands and show you how to explore the PowerShell cmdlets to see what PowerShell commands are available on your system. The get-command cmdlet allows you to explore the commands available to you in Windows PowerShell.

The simplest, but not the most useful, way to use the get-command cmdlet is simply to type:

get-command

at the PowerShell command line. Several screens of command names scroll past when you do this - there are a lot of cmdlets in PowerShell. It's more useful to view the information one screen at a time. You achieve that by typing:

get-command | More

at the PowerShell command line. The result is similar to that shown in Figure 1-11. If you run that command and carefully read the available commands, you will get some idea of the scope of functionality that PowerShell allows you to control and manage.

To view another screen of commands, press the spacebar once. Repeat this to view each additional screen of commands.

PowerShell commands are formed of a verb, followed by a hyphen (or minus sign), followed by a noun. The get-command cmdlet illustrates the structure. The verb "get" is followed by a hyphen, which is followed by a noun "command." PowerShell uses the singular form of the noun, even when, as is often the case, you want to find multiple items that satisfy your requirements. Thus, you might use get-process to get all the processes running on a system, as opposed to get-processes.

You can use wildcards to focus your search for the relevant command. For example, to find all commands that use the get verb, use the following command:

get-command get-*

or, the slightly tidier:

get-command get-* | More

The argument to the get-command cmdlet uses the * wildcard. The argument get-* finds any command whose name begins with get, a hyphen, and zero or more other characters. As you can see in Figure 1-12, there are many cmdlets that use the get verb.

Other verbs worth looking for include add, format, new, set, and write. To see a complete list of available verbs, type the following command:

get-command | group-object verb

Figure 1-13 shows the results. The preceding command uses a pipeline that consists of two steps. The first uses the get-command cmdlet to create objects representing all available commands. The second step uses the group-object cmdlet to group the results by the verb.

To find the nouns available in your installation of PowerShell, use the following command:

get-command | group-object noun

If you want to sort the nouns alphabetically use the following command:

get-command | group-object noun | sort-object name

You can also use the get-command cmdlet to explore in other ways. For example, suppose that you want to find all cmdlets that you can use to work with processes. The preceding command shows you that process is one of the nouns used in cmdlets. One way to display information about all cmdlets that operate on processes is to use the following command:

get-command *-process

Figure 1-14 shows you that there are only two cmdlets that you can use to work specifically with processes. As you construct pipelines with multiple steps, you have many other cmdlets available for use with process-related information.

You can adapt the preceding command to find cmdlets relevant to other nouns. For example, the command:

get-command *-service

will find all cmdlets that relate to services.

Getting Help

When you're using PowerShell, you need to be able to find out how to use commands that you are already aware of or that you find by using the techniques described in the previous section.

You use the get-help cmdlet to get help information about individual cmdlets. You can use the get- help cmdlet with or without parameters. Using the get-help cmdlet with no parameters displays abbreviated help information.

For example, to get help on the get-process cmdlet type either:

get-help get-process

or:

get-process -?

at the PowerShell command line.

The default behavior of the get-help cmdlet when providing help information about a specific command is to dump all the help text to the screen at once, causing anything that won't fit on one screen to scroll off the screen and out of sight. You may find it more useful to display the help information one screen at a time by using More:

get-help get-process | More

or:

get-process -? | More

You are likely to have the help function available to you. It behaves similarly to the get-help cmdlet, except that the help function displays the help information one screen at a time. To display the help information for the get-process cmdlet one screen at a time, you can type:

help get-process

Since that is a little shorter to type than the get-help syntax, you may find that it's more convenient.

PowerShell displays help information in a way similar to man in Unix. The help for each command or other piece of syntax is structured in the following sections:

Name - The name of the cmdlet Synopsis - A brief text description of the cmdlet Syntax - Demonstrates how the cmdlet can be used Detailed Description - A longer text description of the cmdlet Parameters - Provides detailed information about how to use each parameter Input Type - Specifies the type of the input object(s) Return Type - Specifies the type of the returned object Examples - Examples of how to use the cmdlet Related Links - Names of other cmdlets with related functionality Remarks - Information about using parameters with the cmdlet

For some commands, some sections may contain no help information.

When you use no parameter with the get-help cmdlet, you see the following sections of information:

Name Synopsis Syntax Detailed Description Related Links Remarks

If you use the -detailed parameter, for example:

get-help get-process -detailed

you see the following sections of help information:

Name Synopsis Syntax Detailed Description Parameters Examples Remarks

If you use the -full parameter, for example:

get-help get-process -full

you see the following sections of help information:

Name Synopsis Syntax Detailed Description Parameters Input Type Return Type Notes Examples Related Links

In addition to the built-in help about cmdlets, you can also access help about aspects of the PowerShell scripting language using the get-help cmdlet. If you don't know what help files on the language are available, use the command:

get-help about_* | more

to display them. Figure 1-15 shows one screen of results. This works, since each of these help files begins with about_.

An alternative way to explore the available help files for an install on 32-bit hardware is to open Windows Explorer, navigate to the folder C:\Windows\System32\WindowsPowerShell\v1.0, and look for text files whose name begins with about. If your system drive is not drive C: modify the path accordingly.

(Continues...)

---

Excerpted from Professional Windows PowerShell by Andrew Watt Copyright © 2007 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---