Getting Started With Windows PowerShell

Personas que lo han encontrado til: 58 de 106 Valorar este tema

This is your guide to getting started with Windows PowerShell. Read through these pages to get familiar with Windows PowerShell, and soon youll be driving around like a pro. On This Page Getting Started with Windows PowerShell Starting Windows PowerShell Whoa, Whoa, Wait a Second: What Are Cmdlets? I Have a Couple Questions For You PowerShell is Here to Help Hey, What About Scripts? So Where Do I Go From Here?

Getting Started with Windows PowerShell

A couple years ago one of the Scripting Children got his drivers permit; that same day, the Scripting Dad took his son out for his first driving lesson. As you might expect, the Scripting Son was pretty excited and couldnt wait to get to the parking lot where the lesson would take place. After parking the car, the Scripting Dad and the Scripting Son changed places. The Scripting Son started the car, dutifully checked his mirrors, released the parking brake, and shifted the car into Drive. And then, for a moment or two, he paused before finally stepping on the gas and driving a car for the first time. Why the pause? Thats easy: its one thing to want to drive a car, but its a whole nother thing to actually drive a car. You cant blame the Scripting Son for hesitating a bit; after all, for years hed been riding a bike, and he was able to get pretty much any place he needed to get to. Why change now? Why discard a tried-and-true mode of transportation for something new, something that he might not like, something that might be too hard? Admittedly, cars have some advantages over bikes. But at what cost? The same thing is true when it comes to new technologies designed for system administration. By now most of you have heard of Windows PowerShell, Microsofts new command console and scripting language; many of you have even downloaded and installed PowerShell. (If you havent, see our Downloading Windows PowerShell page for more information.) Like the Scripting Son, however, you might have gotten that far and then paused: after all, its one thing to want a new command console and scripting language, but its a whole nother thing to actually start using that command console and scripting language. Youve been using the GUI, Cmd.exe, and VBScript for years, and youve pretty much been able to carry out any system administration task you needed to carry out. Why change now? Why discard a tried-and-true

mode of system management for something new, something that you might not like, something that might be too hard? Those are all good questions and all valid concerns. And, to be honest, we cant really address them all in this introductory article. However, we will say this: just because you get a drivers license that doesnt mean that you can never ride a bike again. Transportation is not a zerosum proposition: having a drivers license doesnt mean you cant also ride a bike, a bus, or a motorcycle. (Or even - gasp! - walk.) Would you rather ride a bike than drive a car? Thats fine; ride a bike when you want to ride a bike, and drive a car when you want to drive a car. If it turns out that youre happier riding a bike, well, good for you: ride your bike, and drive a car only when you really need to. You should think of Windows PowerShell in the same light. If you learn Windows PowerShell, does that mean you have to stop using the GUI and you have to throw out all your VBScript scripts? Of course not. Many people believe that Windows PowerShell is a replacement for VBScript and other management technologies. Thats not really true; if anything, PowerShell is a complement to VBScript and other management technologies. Over time, some people will decide, Wow, I really like PowerShell; I think Im going to use PowerShell for everything. Thats fine; have fun and let the Scripting Guys know how we can help. Other people are going to think, I dont know. I like some of the things PowerShell has to offer, but Ive got a pretty big investment in VBScript scripts. Id rather stick with VBScript. Well, guess what? Thats also fine. As the saying goes, if it aint broke, dont fix it. If VBScript works for you then keep using VBScript. So then why even bother with Windows PowerShell? There are several reasons. For one, its like having a drivers license: you might never need it, but its good to have, just in case. Its true that, at the moment, PowerShell might not seem like that big of a deal: for the average system administrator pretty much everything you can do with Windows PowerShell you can already do with VBScript. On the other hand, however, there are exceptions: if you want to automate the management of Microsoft Exchange Server 2007 youll need to use PowerShell. As time marches on these exceptions are likely to become the rule: PowerShell will continue to be enhanced and improved upon (version 2.0 is in development right now) while VBScript wont. Admittedly, you might not need PowerShell right now; however that could change in the very near future. So why not go ahead and learn it now, when you can take your time and learn at your pace? That, of course, is the reason for the Windows PowerShell Owners Manual: this is intended to be a gentle and relaxed introduction to Windows PowerShell. Like most owners manuals, well tell you how to put the pedal to the metal and drive your new command console and scripting language; over time, well also explain how to care for and maintain your new command console and scripting language. And dont worry: in addition to standard equipment well cover accessories and customization as well. We know that some of you installed Windows PowerShell and, ever since, have been sitting around thinking, Well, now what? If thats you, well, you can stop fretting: youve come to the right place.

Note. For better or worse, this particular article can only provide a somewhat-cursory introduction to Windows PowerShell. As time goes by, well drill down deeper and deeper into PowerShell and what you can do with it; if you cant wait till then you might want to take a look at the Scripting Guys five Windows PowerShell webcasts.
Top of page

Starting Windows PowerShell

When you install Windows PowerShell the setup program should also install a Start Menu shortcut for you; in Windows XP and Windows Server 2003 that shortcut can be found by clicking Start, pointing to All Programs, pointing to Windows PowerShell 1.0, and then clicking Windows PowerShell. What if you didnt get a Start Menu shortcut? Well, PowerShell installs, by default, in %windir%\System32\WindowsPowerShell\v1.0 (e.g., C:\Windows\System32\WindowsPowerShell\v1.0). Open that folder, doubleclick PowerShell.exe and have at it. When you do start Windows PowerShell youll see something similar to this:

If youre thinking, Hmmm, that looks a lot like a good old MS-DOS command window, well, theres a reason for that: PowerShell actually leverages the good old MS-DOS command shell. And theres at least one advantage to that. Because youve probably used the old MS-DOS command shell a million times you already have a pretty good idea of how to use PowerShell: you just type in commands and press ENTER. For example, do you need to know your IP address? Then typeipconfig and press ENTER:

PS C:\Scripts> ipconfig Windows IP Configuration

Ethernet adapter Local Area Connection: Media State . . . . . . . . . . . : Media disconnected Ethernet adapter Wireless Network Connection: Connection-specific IP Address. . . . . Subnet Mask . . . . Default Gateway . . DNS . . . . . . Suffix . . . . . . . . . . . . . . . . : : : : fabrikam.com 192.168.120.17 255.255.255.0 192.168.120.1

As the preceding example implies, you can run all your command-line executables from within the PowerShell console; you can even run VBScript scripts and batch files from within the

PowerShell console. Want to run the script C:\Scripts\Test.vbs from within Windows PowerShell? Okey-doke:

PS C:\Scripts> test.vbs Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. This message was generated by Test.vbs.

Note. Interested in learning more about the console itself? Then take a look at the Owners Manual sections on customizing the PowerShell console and onWindows PowerShell shortcut keys. Oh, and dont forget tab expansion.
In addition, a lot of the console commands youve grown to love - like cd and cls, or even Unix commands like ls - have Windows PowerShell equivalents. Although there are some minor exceptions, these commands work exactly the way you would expect them to work. Want to change from the C:\Scripts folder to the C:\Windows folder? Then just use the cd command:

PS C:\scripts> cd c:\windows PS C:\WINDOWS> Or, if you prefer: PS C:\scripts> chdir c:\windows PS C:\WINDOWS>

In general, these console commands are aliases to Windows PowerShell cmdlets. If youd like to see a complete list of available aliases just type the following from the PowerShell command prompt and press ENTER:

Get-Alias

In case youre wondering, PowerShell commands are typically case-insensitive. You could also type this from the command prompt:

get-alias

Or even this:

geT-ALIaS Top of page

Whoa, Whoa, Wait a Second: What Are Cmdlets?

Oh, right; good question. Cmdlets are Windows PowerShell commands, and are roughly equivalent to command-line tools. (Although, in this case, cmdlets are PowerShell-specific; you cant run a PowerShell cmdlet unless you are running Windows PowerShell). Without commandline tools Cmd.exe wouldnt be of much use. Although the console has a few built-in commands (such as cd and cls) most of the heavy lifting (and most of the useful tasks) are carried out by command-line tools such as Ipconfig.exe and Ping.exe. Windows PowerShell works in a similar way: although the shell has a few built-in commands, most of the heavy lifting is performed by cmdlets. In fact, even PowerShell commands like cd are aliases to cmdlets, an alias being nothing more than a nickname for a cmdlet. In this case, for example, cd is just another way to reference the Set-Location cmdlet. Want to switch to the C:\Windows folder? Instead of using the cd alias you could call the Set-Location cmdlet:

PS C:\scripts> Set-Location C:\Windows PS C:\WINDOWS>

Of course, Windows PowerShell includes cmdlets that do things far more interesting than simply switch you from one folder to another. For example, try typing this command and seeing what you get back:

PS C:\WINDOWS> Get-Process

You should get back information similar to this, information about all the processes currently running on your computer:

Handles ------103 264 101 168 143 752 672 139

NPM(K) -----5 7 4 7 5 13 7 6

PM(K) ----1296 4872 3080 5584 3712 11048 2796 1204

WS(K) VM(M) ----- ----3676 32 10244 70 4692 38 6968 54 6640 52 20256 77 6864 68 4544 38

CPU(s) -----0.05 0.84 1.77 0.30 0.30 2.81 18.80 0.70

Id -2964 920 2124 2896 2776 452 1184 2760

ProcessName ----------alg asghost atiptaxx BTStackServer BTTray CcmExec csrss ctfmon

Pretty slick, huh? Maybe youd like to list all the files and folders in C:\Scripts, including anything which happens to live in a subfolder of C:\Scripts. Well, all you had to do was ask:

Get-ChildItem C:\Scripts -recurse

All were doing here is calling the Get-ChildItem cmdlet. You might have noticed that we also passed Get-ChildItem a pair of parameters: C:\Scripts and -recurse. As you probably figured out, C:\Scripts is the name of the folder we want to work with. You might notice, as well, that we didnt enclose the folder path in double quote marks. Thats pretty much always going to be true in PowerShell: theres no need to enclose parameters in quote marks unless that parameter includes blank spaces. For example, suppose you want to list the files and folders found in C:\Documents and Settings\Ken Myer. Because that path includes blank spaces you need to enclose the path name in double quote marks:

Get-ChildItem "C:\Documents and Settings\Ken Myer"

The second parameter in our original command, -recurse, tells the Get-ChildItem to recursively retrieve information from the parent folder; thats just a fancy way of telling Get-ChildItem to retrieve information from all the subfolders of C:\Scripts (as well as sub-subfolders of those subfolders, and so on). Windows PowerShell version 1.0 ships with 129 cmdlets, cmdlets that let you work with files and folders, read from and write to text files, manage event logs, and even instantiate COM and .NET Framework objects. Now thats all well and good, but the Scripting Son didnt really learn how to drive until he got behind the wheel and started driving: reading about something is no substitute for actually doing something. Windows PowerShell is no different: you can read about cmdlets all you want, but you wont get a good feeling for cmdlets and what they can do until you get behind the wheel and actually start using Windows PowerShell. And while the Scripting Guys cant sit in the passengers seat and offer useful advice (like, Slow down! Watch out for the curb! Dont you ever slam on the brakes like that!) we can do the next best thing: we can provide step-by-step guidance that walks you through a typical system administration scenario using Windows PowerShell. If that sounds like fun (and why wouldnt it be?), take a look at our Windows PowerShell virtual lab. Bonus Tip Heres a little time-saving tip for you. When using parameters in conjunction with a cmdlet, you only have to type as much of the parameter name as needed to make that parameter distinct. What does that mean? Well, Get-ChildItem has only one parameter (recurse) that starts with the letter r. That means we can specify the -recurse parameter by using this command:

Get-ChildItem C:\Scripts -r

Pretend, for a moment, that Get-ChildItem has another parameter that starts with the letter r; lets call this hypothetical parameter -readonly. In that case we can specify the -recurse parameter by using this command:

Get-ChildItem C:\Scripts -rec

Why did we have to type -rec? Thats easy: we had to type three letters before we could differentiate -recurse and -readonly: -recurse -readonly

Still too much typing for you? Well, if you use the gci alias (which, needless to say, is the alias for Get-ChildItem) you can retrieve a recursive list of all the files and folders in C:\Scripts by doing no more typing than this:

gci C:\Scripts -r

Cool. Top of page

I Have a Couple Questions For You

Yes, we know: youd like to know what other cmdlets are available to you and youd like to know what you can do with all those cmdlets. To tell you the truth, we wont be able to answer those questions in this article. However, we can point you to readily-available resources that will help you answer these questions for yourself. To begin with, Windows PowerShell is a pretty chatty and out-going technology: all you have to do is ask and PowerShell will be happy to tell you all about itself. For example, remember the Get-Alias cmdlet, which returned a list of all the PowerShell aliases available to you? Well, theres a similar cmdlet - Get-Command - that returns a list of all the PowerShell cmdlets available to you. Heres a partial look at what happens when you run Get-Command:

PS C:\scripts> Get-Command CommandType Name n -------------Cmdlet Add-Content nt [-Path] <String[]> [-Value] <Object[... Cmdlet Add-History ry [[-InputObject] <PSObject[]>] [-Pass... Definitio --------Add-Conte Add-Histo

Cmdlet Add-Member r [-MemberType] <PSMemberTypes> [-Name]... Cmdlet Add-PSSnapin pin [-Name] <String[]> [-PassThru] [-Ve... Cmdlet Clear-Content tent [-Path] <String[]> [-Filter <Strin... Cmdlet Clear-Item m [-Path] <String[]> [-Force] [-Filter ... Cmdlet Clear-ItemProperty mProperty [-Path] <String[]> [-Name] <S...

Add-Membe Add-PSSna Clear-Con Clear-Ite Clear-Ite

A Quick Detour What do the three dots () at the end of each line mean? They mean that there is additional information about each cmdlet; however, that information wouldnt all fit on the screen. Is there a way to make it all fit on the screen? Sure; all you have to do is display the information in list view rather than table view:

PS C:\scripts> Get-Command | Format-List

In turn, youll get back complete information for each cmdlet:

Name : Add-Content CommandType : Cmdlet Definition : Add-Content [-Path] <String[]> [-Value] <Object[]> [-PassT hru] [-Filter <String>] [-Include <String[ ]>] [-Exclude <String[]>] [-Force] [-Credential <PSCredent ial>] [-Verbose] [-Debug] [-ErrorAction <A ctionPreference>] [-ErrorVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>] [-WhatIf] [ -Confirm] [-Encoding <FileSystemCmdletProviderEncoding>] Add-Content [-LiteralPath] <String[]> [-Value] <Object[]> [-PassThru] [-Filter <String>] [-Include < String[]>] [-Exclude <String[]>] [-Force] [-Credential <PS Credential>] [-Verbose] [-Debug] [-ErrorAc tion <ActionPreference>] [-ErrorVariable <String>] [-OutVa riable <String>] [-OutBuffer <Int32>] [-Wh atIf] [-Confirm] [-Encoding <FileSystemCmdletProviderEncod ing>] Path : AssemblyInfo : DLL : C:\WINDOWS\assembly\GAC_MSIL\Microsoft.PowerShell.Commands .Management\1.0.0.0__31bf3856ad364e35\Micr osoft.PowerShell.Commands.Management.dll HelpFile : Microsoft.PowerShell.Commands.Management.dll-Help.xml ParameterSets : {Path, LiteralPath} ImplementingType : Microsoft.PowerShell.Commands.AddContentCommand Verb : Add Noun : Content

How did we manage to do that? Well, as it turns out, Format-List is a cmdlet that takes information passed to it and then outputs that information in list view (that is, property values are displayed on separate lines rather than as columns in a table). But whats that weird symbol | - in the middle of the command? Well, that weird symbol is the pipe separator, and it indicates that we want to pipe the information returned by Get-Command and hand it over to FormatList for additional processing. You say that makes no sense to you whatsoever? Thats all right; thats why this manual includes a chapter on pipelines and piping. Now, Back to Our Regularly-Scheduled Article Get-Command is pretty useful: after all, it gives you a definitive list of the cmdlets that are available to you. However, it doesnt tell you how to use those cmdlets. For that, you need to access PowerShells built-in help system. Top of page

PowerShell is Here to Help

One of the really nice features of Windows PowerShell is the fact that it includes a very extensive help system, which just happens to be incorporated right into the shell itself. Once you know the name of a cmdlet, you can get additional information on that cmdlet (and how to use it) by calling the Get-Help cmdlet:

Get-Help Format-List

Wait, wait: dont type that in yet. Like we said, PowerShell has a very extensive help system; however, it also has a somewhat complicated help system. Typing Get-Help Format-List will, indeed, show you additional information about the Format-List cmdlet; however, that information will consist largely of a syntax diagram and a brief description of the cmdlet. For more extension information, including example commands and a detailed description of allowed parameters, you need to tack on the -full parameter, like so:

Get-Help Format-List -full

Or, if youre interested only in the example, tack on the -examples parameter:

Get-Help Format-List -examples

Wait, wait: dont type those commands in yet, either. The actual help topics found in PowerShell are very, very good; however, PowerShells help engine leaves a little something to be desired. For example, when you open a help topic using Get-Help, PowerShell displays the entire topic and then leaves the cursor at the very end of the topic. To actually read the information from

start to finish you have to scroll up and find the first line. You can work around that problem (sort of) by piping the results of Get-Help to the more command, which enables you to display information one page (screen) at a time:

Get-Help Format-List -full | more

That helps, although you can only page your way forward; you cant go backwards. (Try it and youll see what we mean.) The other issue is a little harder to work around: for better or worse (mostly for worse) PowerShells help engine doesnt do a very good job of respecting word breaks at the end of a line. For example:

DETAILED DESCRIPTION The Get-Process cmdlet retrieves a process object for each process. Witho ut parameters, "Get-Process" gets all of t he processes on the computer, as though you typed "Get-Process *". You ca n also identify a particular process by pr ocess name or process ID (PID), or pass a process object through the pipe line to Get-Process. For Get-Process, the default method is by process name. For Stop-Process, the default method i s by process ID.

Take a look at the first line under Detailed Description. As you can see, the word the doesnt quite fit on the line. However, instead moving the entire word to the next line, PowerShell went ahead and printed the t at the end of line 1, then printed the rest of the word (he) at the beginning of line 2. Does that make the help a little hard to read? You might say that. So is there a workaround for this word-wrap issue? Not as far as we know. Which is why the Scripting Guys put together the Windows PowerShell graphical help file. This is the same help you get in Windows PowerShell (plus, just for the heck of it, a copy of our VBScript to Windows PowerShell Conversion Guide). However, weve taken that help and wrapped it up in a regular old .chm file; that makes it a little easier to read, and gives you full-text search capability as well. You can even access this Help from the command prompt, simply by typing a command similar to this:

Get-GUIHelp Format-List

And no need for parameters like -full or -examples. With the graphical help file you always get all the information available for a topic. But you know what? Youre right. Help is incredibly useful, provided that you already know what it is you want to do. (For example, you know you want to use Get-ChildItem to list all the files and folders found in C:\Scripts, you just cant remember which parameter enables you to

recursively search for these files.) But what if you have no idea what you can even do with Windows PowerShell in the first place? Are you just supposed to read the help file from start to finish? Well, you can if you want to. Alternatively, you might want to take a look at the Script Centers Task-Based Introduction to Windows PowerShell. Here youll find scores of taskbased articles, with titles like Save Data to a Text File and Copy Files or Folders. One thing you might want to do is browse through those articles and then look in the help file for more detailed information on the cmdlets used to carry out those tasks.

Note. And yes, the graphical help file includes links to corresponding articles in the Task-Based Introduction. For example, if youre viewing information about the Set-Content cmdlet in the graphical help file youll see a link to the article Save Data to a Text File.
Top of page

Hey, What About Scripts?

You dont think wed forget about scripts and scripting, do you? (They dont call us the Scripting Guys for nothing.) Windows PowerShell provides a very cool and very powerful environment for writing and running scripts; however, actually getting scripts to run under PowerShell can be a little tricky, at least at first. Therefore, this Owners Manual includes a separate article on running scripts in Windows PowerShell. Well leave most of the scripting-related information to that article; well also recommend you take a look at our PowerShell scripting webcast if youre eager to try your hand at writing Windows PowerShell scripts. In this article well simply note that PowerShell scripts can be written using any text editor; Notepad, for example, has everything you need in order to write a Windows PowerShell script. Just make sure you save the file as a plain text file and that you give the thing a.ps1 file extension; thats all you have to do.

Note. OK, there might be a little more: you actually have to write some script code. Yet another reason to take a look at the PowerShell scripting webcast.

Heres another cool thing about PowerShell. Throughout this article weve referred to PowerShell as being a command console and scripting language. Theres a good reason for that: you can run PowerShell commands from the command prompt or you can save those commands as .ps1 files and run them as scripts. Even cooler, these commands can be (and usually are) identical: the commands you type at the command prompt can be used as-is in scripts, and vice-versa. For example, consider this simple two-line PowerShell script:

$a = Get-ChildItem C:\Scripts

$a

In the first line, this script uses Get-ChildItem to retrieve a collection of all the files and folders stored in C:\Scripts; that collection is stored in the variable $a. In the second line, the script simply displays the value of $a. Not all that exciting, is it? Thats hard to argue with. However, what is exciting is this: you can either save these two commands as a .ps1 file and then run those commands as a script, or you can type the commands at the command prompt, one after another. What happens if you type the commands at the command prompt? You got: the first command retrieves a collection of all the files and folders stored in C:\Scripts and stores that information in a variable named $a; the second command echoes back the value of $a. Work from the command prompt or write a script? In a certain sense, it doesnt really matter. Needless to say, well have more - much more - about scripts and script writing in future updates to the Owners Manual. Top of page

So Where Do I Go From Here?

Wed suggest two things. First, take a look at the PowerShell Week webcasts, five presentations introducing Windows PowerShell. Those webcasts include: And Now for Something Completely Different: Introducing Windows PowerShell One Cmdlet, Two Cmdlet, Three Cmdlet, Four: An Introduction to Windows PowerShell Commands Object, Objects Everywhere: Working with Objects in Windows PowerShell New Kid on the Scriptblock: Writing Scripts with Windows PowerShell Amazing But True: Thing You Never Dreamt You Could Do with Windows PowerShell

Second, kick the metaphorical PowerShell tires by trying out the virtual lab. Its always better to try something hands-on rather than read about it. (Which, you might have noticed, we didnt bother to tell you until youd finished reading this big, long article.) And keep visiting the Script Centers PowerShell section. Well be adding more and more content to this section, including more installments to the Owners Manual.