Powershell Fundamentals

I’ve had the opportunity this week to take class with Don Jones (blog | twitter), PowerShell guru and author of PowerShell 2.0 TFM (makes me laugh, each and every time). I’m not even going to attempt to try to teach you some of the amazing information Don has spent the last week pouring into my ears (since most of  it spilled on the floor). But, I do want to pass on some high points, gotchas, tips, insights, that Don communicated to us during the class because they might help you pick up on the fundamentals of PowerShell.

That’s the most important lesson I got out of this week, you need the fundamentals to really start to put PowerShell to work. It’s very easy to make the mistake that I did. I went into PowerShell with a programmer’s background. I have built applications with Paradox Application Language (PAL & OPAL), Basic, Visual Basic, Java, and C# and I’ve been working with the VB-Script scripting language for years including work setting up custom rules in Operations Manager. So, I attacked PowerShell like it was just another language. Problem is, PowerShell isn’t completely just another language. It really does have some fundamental differences that you need to be aware of or you will get side-tracked, as I did. Getting side-tracked will not only keep you from properly learning the abilities of PowerShell, but you’ll miss out on major benefits that the proper construction of PowerShell scripts will convey to you.

What constructs? The one key point that I think I was missing was the fundamental importance of the pipe. It’s not simply a neat way to pass information from one function to the next, it’s how you should be doing a lot of the work. I wasn’t, but I will.

Here, largely taken from my notes, so these are not Don’s precise words (all the time), are some things you might want to know (any & all errors are mine and mine alone):

• No one is going to be bleeding from the eyes at the end of the course. Great news since I usually bleed from the ears after drinking from the Itzik Ben Gan firehose of information during his classes.
• Don is convinced that it is Microsoft’s intention to move to a two tier structure of haves & have-nots consisting of the first class citizen of PowerShell users and the second tier citizen that uses only GUI’s. I commented on that at length here.
• Law #1: Thou shalt ask for help. By this he didn’t just mean asking him for help during the class, but learning how to use PowerShell help. He’s right. The more you know how to access the help system, the better.
• Use Consolas instead of the raster font. It really did help.
• If you find yourself messing with text, you’re doing it wrong. Which pretty much invalidates half the scripts I’ve written so far in PowerShell.
• F-7 to get a quick list of commands. Works wonderfully.
• Set up a commandlet of the day calendar. He suggested tossing the Dilbert daily cartoon calendar and setting up a commandlet calendar so that you look at a commandlet in detail each day as a learning tool. I’ll be working on mine.
• If an object binds by PSObject (or psvalue, can’t quite read my notes) it will always only bind by psobject despite what the documentation says. Ok.
• Invoke-Command and remoting are too flipping cool. Parallel execution of the scripts.
• Security is built into the product:
  • script exec is prohibited by default
  • Ps1 is not associated with the shell
  • must provide a path to a script
  • underlying security is not bypassed
• Get a certificate then use and generate nothing but signed scripts. This makes sense and I’ll go to work on it. It’ll change how I post scripts here, but I’ll cope.
• Don’t modify things out of scope. This is actually a fundamental bad behavior. You can modify stuff out of scope, but that doesn’t mean you should.
• PowerShell GUI’s are possible, but if you need a multi-form app, there is a wonderful product called visual studio.
• He had a function he called a “getto breakpoint” he used in v1. I just liked the term.
• If you’re using FOREACH all over the place, you’re doing it wrong. And there go the other half of my scripts….
• If all you’re doing is writing C# code in PowerShell, then use C#.
• While we can do a ton of cool stuff with SQL Server through PowerShell, it’s actually exposed a very stunted set of methods & processes into PowerShell. As a matter of fact, running a query is the one thing it really exposed, which is why I’ve been using SMO so frequently.
• My words, not Don’s, the ISE stinks, get an editor
• Trying out Sapien‘s PrimalScript because of the class… it might replace Idera‘s PowerShellPlus in my tool box. We’ll see.

I’m sure there were better & more important things that I should have picked up, but this is the list of items that stood out. It was a great opportunity to get to learn this from Don and I heartily recommend you track down his classes and attend them. You won’t be sorry.