Mr. Roboto

Polish Your Shell

Learning PowerShell is simple once you understand these basic cmdlets.

With the impending release of Windows 7 and Windows PowerShell version 2.0, it will become more difficult to ignore PowerShell. You shouldn't ignore it. PowerShell is definitely easier to learn than you think.

PowerShell ships with a very robust help system. Every cmdlet -- the basic PowerShell command you'll run -- includes extensive help. You can use either the Get-Help cmdlet or the help command, which accepts wild cards. Both of these options make getting help even easier. Suppose you need to do something with a service but don't know the commands. You can ask for help by typing "help" and what you want help with.

PS C:\> help *service*

You should get a list of cmdlets. Pick Get-Service:

PS C:\> help get-service

PowerShell will display a summary, syntax and notes. But it gets better. Need more information? Ask PowerShell. Try these commands:

PS C:\> help -get-service -detailedPS C:\> help -get-service -full

The -detailed and -full parameters provide increasing levels of detail.

Get-Member
Discovering information about an object is very easy with the Get-Member cmdlet. Pipe any object to Get-Member, and PowerShell will tell you everything it knows about the object:

PS C:\> get-process | get-member

The first thing you'll see is the object type, which in this example is a System.Diagnostics.Process. This is helpful in the event that you need to research the object's properties or methods further. Notice all the properties and methods? Don't worry too much about methods right now, because you'll use cmdlets to manage most things. But the property list is important. When you run a cmdlet, PowerShell presents a default view of the objects in the pipeline. More often than not, more properties exist for you to use than are displayed in this view. Use Get-Member whenever you want to learn what objects are coming out of the end of the pipeline.

Select-Object
The last cmdlet that will help you teach yourself about PowerShell is Select-Object, which has an alias of Select. This cmdlet can be used to return the first or last X number of objects from the pipeline:

PS C:\> dir $env:temp | sort length -descending | Select -first 3

This expression will list all files in the %TEMP% directory -- sorted by size in descending order -- and select the first three objects. Were you expecting size? Pipe a file object to Get-Member to see for yourself:

PS C:\> dir c:\windows\notepad.exe | get-member

There's no size property, but you should have seen length in the command output. Or, if you aren't sure, use Select-Object with its other syntax and select the specific properties you want:

PS C:\> dir $env:temp | select Name,Length

All you need to do is specify a comma-separated list of properties. But it gets better. I often want to know all the properties and their values for an object. This helps me discover how an object is designed. Once I know that information, I can write more effective PowerShell expressions:

PS C:\> get-eventlog -LogName System -Newest 1 | select *

Now I know all the properties for an eventlog object and their corresponding values, which makes it easier to develop more specific PowerShell expressions:

PS C:\> get-eventlog -LogName System | Sort Source | group Source | Sort Count -descending | Select Count,Name

If you run this expression, you'll get a list of all event sources sorted by number of events in descending order. Curious as to how I developed this expression? You can figure it out for yourself with everything I've shown you. Start with the Get-Eventlog cmdlet. Look at help. Pipe an expression to Get-Member or Select-Object. Add the next pipelined part, Sort Source, and repeat.

Learn how to use these basic cmdlets, and you'll be learning PowerShell without realizing it.

About the Author

Jeffery Hicks is a Microsoft MVP in Windows PowerShell, Microsoft Certified Trainer and an IT veteran with over 20 years of experience, much of it spent as an IT consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He works today as an independent author, trainer and consultant. Jeff writes the popular Prof. PowerShell column for MPCMag.com and is a regular contributor to the Petri IT Knowledgebase and 4SysOps. If he isn't writing, then he's most likely recording training videos for companies like TrainSignal or hanging out in the forums at PowerShell.org. Jeff's latest books are Learn PowerShell 3 in a Month of Lunches, Learn PowerShell Toolmaking in a Month of Lunches and PowerShell in Depth: An Administrators Guide. You can keep up with Jeff at his blog http://jdhitsolutions.com/blog, on Twitter at twitter.com/jeffhicks and on Google Plus (http:/gplus.to/JeffHicks)

comments powered by Disqus

Reader Comments:

Wed, Sep 16, 2009 June Blender [MSFT]

I'll help you, too. I write the help for PowerShell Core (not Exchange) and I'm responsible for Getting Started and the User Guide. If the help isn't helpful, we should fix it. If you're having trouble with syntax after reading about_Command_Syntax, then I'll rewrite it. I can't control word wrap on the screen, but I do produce all of the pages online in the TechNet library (http://technet.microsoft.com/en-us/library/bb978525.aspx) for updates and easier reading. If you send mail to Marco, he can share it with me. Thanks, JuneB

Tue, Sep 15, 2009 Marco Shaw Canada

Jughead, Email me marco DOT shaw AT gmail DOT com. I'm interested in trying to produce something useful out of these discussions. I'd like to run a few ideas by you... Anyone else feeling like their in the same boat can email me too... Maybe we can work something out together.

Tue, Sep 15, 2009 Jeremy D Pavleck Minneapolis, MN

Agree with most of what's been posted. @Jughead - I'm a system admin too. I love posh, it's made my life so much easier. If you're a sysadmin then you must know your way around VBScript and/or Batch files, right? If so, you know the pure hell it can be to do anything simple with either language. Powershell unlocks it all and makes things so much easier. Most of what you need comes out of the box - and with a few searches on google bam, you're there. And if you don't know any VBScript or Batch, then yeah, it can be intimidating, but then I wouldn't call you a real system administrator, either.

Tue, Sep 15, 2009 David "Makovec" Moravec

Jughead - sorry but I think you are lazy. As Jaykul said - when you install it you HAVE TO see PowerShell documentation as it's in the same Start menu as executable itself. When I started to learn PowerShell those were my first resources and they are pretty good starting point. Saying - "it's not my fault" is easy. Within few minutes on Google you have answer (with a lot of very good resources, incl. free PDF books). It just need willingness to try it and learn. Which does not mean it will be easy but I can promise you that PowerShell saves you a lot of work/time (believe me - my AD has more than 100.000 users)

Tue, Sep 15, 2009 EvilEmuofDoom Boston, MA

Jughead: I've felt some of that frustration and was in a similar situation as you. However, after giving it some time I'm now a huge PowerShell fan. Read my comment at http://jdhitsolutions.com/blog/2009/09/absolute-beginning-powershell/ for more details.

Tue, Sep 15, 2009 JKav

Yikes @Jaykul, I have to be honest I never saw those but then again I guess I didn't look. Early on I did find the technet section that shows how to translate vbscript to powershell (http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/default.mspx) and I was off to the races. I guess I am one to rarely read the manuals so no surprise I never sought out a user guide. I think it was when I learned that Powershell was more than a scripting language is when I realized it was time to adopt it and not resist. The worthless help.... yeah I think I had the same complaint when I first used the man command so many years ago, sure it paged but seemed useless until I slowed down and realized I had to make an effort. Also with the get-help using the -examples parameter made my day when I was first learning how to navigate the command. Just my two cents.

Tue, Sep 15, 2009 Joel "Jaykul" Bennett Rochester

Jughead's being ridiculous. There is a "getting started" document ( http://technet.microsoft.com/en-us/library/aa973757 ) and a "users guide" ( http://technet.microsoft.com/en-us/library/cc196356 ) included with PowerShell (if you use the online versions I linked to, you'll have to use the sidebar navigation)... and *all* of the help which he finds so hard to read is available on Technet in web form starting here: http://technet.microsoft.com/en-us/library/bb978525 which is on the first page of search results for Microsoft Windows PowerShell. If you couldn't find that, you're not putting in enough effort.

Tue, Sep 15, 2009 JKav

Mr. Hicks not sure you can take credit for letting anyone down. I too saw Powershell and walked away at first. Then I listened to a Podcast with the PS development team and started reading more. Installed it and started playing with it. I have asked a ton of questions and although still a novice I have made it my default command shell and scripting language. There are many PDF documents but I disklike pdf, there are also several Compiled Windows Help files for documentation (i.e. PowerCli help file). I know very little about vmware but I have been able to show our vmware gurus how to use Powershell and the vmware provided ** development partner? ** powershell snapin. As for get-help in the command window, check the parameters that is how I found it useful. Not to promote any specific product but using something like PowerTabs, PrimalScript or Powershell Plus really help as the parameters become available right there.

Tue, Sep 15, 2009 JKav

@Jughead: I agree with part of your post, I felt the same way (hey stop with the .Net I am a Sysadmin not a programmer) but with the help of testing and the huge community of Powershell folks you really need to work with Powershell because it will take your skill set much further. As for the third party support... this has been going on forever but look at what third parties have adopted powershell. How is help useless in a command window? Not criticizing but wanting to help because I am way behind Mr. Hicks in PS skill and I might have an understanding of your complaints/frustrations.

Tue, Sep 15, 2009 Jeffery Hicks

I think the original comment merited even further discussion which you can follow at http://jdhitsolutions.com/blog/2009/09/absolute-beginning-powershell/

Tue, Sep 15, 2009 Jeffery Hicks

I feel like the the PowerShell community has let you down. PowerShell *IS* supposed to be easy to use precisely because of your experience. You are exactly the target. That said, PowerShell does offer extensive documentation in the help files for each cmdlet as well as a user guide in .DOC format. There are a number of freely available graphical PowerShell help utilities that display help in a chm file which might help you. You might consider picking up a copy of Windows PowerShell: TFM or PowerShell in Action by Bruce Payette. I can't help you completely in a comment, but I hope you'll post any problems or questions in the PowerShell forum at ScriptingAnswers.com.

Fri, Sep 11, 2009 Jughead

Your comments regarding how "easy" Powershell is to use (or learn) are just unrealistic. I am not a programmer, I am a system administrator. I haven't the time or inclination to learn to use programming terminology like "class" "method" "object" or "namespace" and don't care to "pipeline" my "cmdlets". And Things.Connected.By.Periods Are.Interesting.And.Useful but hell if I can decipher what they represent. This is a foreign language and there are no interpreters and no foreign language classes. (Even if my employer had funds for training, I don't have the time at my job, what with all the work that's heaped up to do.)

We used to have "programs" that called "subroutines" and "variables" with "values". Some "variables" were "arrays" which could be "indexed". "Subroutines" had "arguments". "Input" and "output" was "opened" "read" or "written" and "closed" or "printed". All of this used to be explained in a logical organized "User Manual".

I can't get Powershell to run (beyond the most simple commands as might appear in the most basic of articles I find on the subject). I asked my Exchange administrator how to delete a mailbox without deleting a user. I got a Powershell "cmdlet". It looked easy enough. I opened a Powershell command window, tried it and got a nonsense error message (it didn't work). There used to be an environment variable called PATH that handled this sort of thing. Somehow I don't think it is that simple any more. I have some example code I downloaded which will help me (supposedly) create and maintain users. I have been unable to get this code to step 1 and read a .csv file. And much of the free code seems to be borrowed from web developers in ".NET" language, but that isn't Powershell at all, is it? And besides, I have to maintain my users in Active Directory, a third-party Novell eDirectory and business applications with their own user databases. Microsoft is providing a tool to "solve" the AD problems, but their development partners don't all do it the Microsoft way, do they?

The "cmdlet" syntax and choosing which "cmdlet" to use baffles me. The "help" is worthless in a command window - what doesn't fit onto a single screen is impossible to use in any practical way - with all of Microsoft's resources, can't they provide a nicely organized manual in Adobe .pdf format containing everything I need to know about Powershell syntax?

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.