I’ve written this up on the new website for our Rochester PowerShell group and on the old blog, and on UGSS Facebook and Twitter … and now that there’s only two days left, it’s time to mention it again, on my blog

This Wednesday, January 20, 2010 – 6:00pm

It’s a new year, and a new opportunity to get started with PowerShell. With the new year, we’re going to put a renewed focus on trying to make our meetings valuable to everyone. With that in mind, the first Rochester meeting of the upstate New York PowerShell users group in 2010 will feature two separate presentations:

Getting Started: The PowerShell Pipeline (100 Level)

• Different types of commands in PowerShell
• Variable assignment and Pipeline arguments
• Understanding the Pipe
• Why PowerShell’s pipeline is different

• Exploiting pipelines for fun and profit

Creating PowerShell script Modules (300 Level)

• Turning your script or function into a module
• What makes a function an “advanced function”
• Providing in-line help for functions
• Controlling what functions and variables your module exports

• Why you should use Module Metadata files

Everyone is welcome, from beginners to pros! Bring a friend and introduce them to PowerShell. As always, our meeting will be at New Horizons’ in Henrietta, 50 Methodist Hill Drive, Suite 50.

In order to keep things on time, we’ll be starting our presentations at 6:30 exactly, after a short pizza, wings, and networking time starting at 6pm. We only ask that if you can come early for the food you let us know ahead of time and come ready to pitch in a few dollars to help cover the cost.

PS: There will be swag. We have several books, an Arc Mouse, and copies of Windows 7 and Office 2007 to give away…

Once you’ve got your PowerShell all installed and have set up your first profile to auto-load … you’re going to want some scripts (well, maybe you’ll want to learn more about how to use PowerShell, but go with me on this)!

One of the best places to look for scripts is the PowerShell Code Repository, and although you can browse and search on the website, you can also do it using the PoshCode module (or the version 1 compatible script). These scripts include a Get-PoshCode cmdlet which you can use with search terms to get a list of scripts and cmdlets back, or with numeric IDs to download scripts (you’ll see what I mean later on, for now, go ahead and grab the appropriate version of that script).

I’m going to assume you put it into your AutoModules folder. If you grabbed the module, it should be saved to WindowsPowerShell\AutoModules\PoshCode\PoshCode.psm1 otherwise, to WindowsPowerShell\AutoModules\PoshCode.ps1 … but you may have run into a minor problem if you load the .ps1 version ). Both the module and the script are signed, but they are signed by my self-issued code signing certificate which your computer almost certainly doesn’t trust… You can use the signature to verify that the file hasn’t been modified since I signed it, but that’s about all (and even that’s a bit of a trick). To actually use the script (module), you’ll need to sign the script yourself (see the steps and how to get a certificate in part 2).

If you’re on CTP2, this would be a good time to get my Authenticode script module to help with signing, and to learn a little about those PoshCode cmdlets …

Using PoshCode to get a module.

Create a folder in your AutoModules folder named “Authenticode” ... and then inside it, try running Get-PoshCode Authenticode … You should get a list of 3 or more versions of my script, entitled “Get/Set Signature (CTP2)”. You want the latest version, so pick the one with the biggest number for the ID, and run Get-PoshCode 464. That should download it and save it. You’ll be able to load it using Add-Module (since Add-Module in the current CTP doesn’t care about code-signing), but first you need to create a settings file (it will tell you how, if you try to load it without setting it). change the CertificateThumbprint that’s set in the first line of code in that script — set it to the thumbprint of your personal code-signing cert (which you’ve hopefully imported into your certificate store).

Now you’ll be able to sign without specifying the certificate each time, and you’ll be able to pipe files in too, so you could, for instance, sign all the script files in a whole folder tree like:

So, here’s what I do.

First of all, I don’t actually put .ps1 scripts into the AutoModules folder, I have a separate AutoScripts folder, and I dot-source scripts from there, as well as loading ps1xml format files from it. I also specifically use a series of scripts there: Aliases.ps1, Variables.ps1, and EyeCandy.ps1. I assume that the functions of the first two are obvious, the last one is a modified version of the PSCX prompt and MOTD script to modify my prompt and startup message.

On top of the PoshCode script module and the Authenticode script module I mentioned earlier, which I use for signing and resigning, and the new CTP2 version of the PowerTab script module, I also use a source build of the upcoming PSCX 1.2 release (which needs a bunch of scripts to be useful, so I just renamed their 3-line profile.ps1 to PSCX.psm1 and stuffed the whole build with all it’s sub-folders into my WindowsPowerShell\AutoModules\PSCX). I also preload my PoshHttp module for downloading files from the web, and I a couple of functions (ellipsis and Get-PerformanceHistory).

Almost everything else I use I write into scripts (I even use the in-line cmdlet syntax to get full-power parameter parsing in a script file) which I put in directories by category inside my main WindowsPowerShell\Scripts directory (in my profile directory, and add to my path so that I can just run a script named “Get-GUID.ps1” by typing Get-GUID on the command-line.

Here’s the profile script off my laptop as an example — I basically use the same profile on all my PCs, and make changes to the “Variables” scripts on each PC to differentiate them. In fact, I have a sub-directory of my “WindowsPowerShell\Scripts” called “Work” which I even keep around at home (although I practically never use those scripts at home — they’re mostly for resetting servers and doing db queries, and only work from home when my VPN connection is up). Let me know if you have any questions.

Incidentally, I use “RemoteSigned for my Execution Policy — I wish there were a way to require signing for just my profile, because then this system would basically protect me from tampering with my auto-run scripts. However, I’m actually comfortable not worrying about it any more than I worry about viruses replacing the executable for Notepad++ on my thumbdrive or something — I do realize that this profile script could be simplified a lot if I replaced the signature checking with just using the “AllSigned” policy … but there’s two major problems with that:

1. I’m a PowerShell-ed developer — I spend a lot of time editing scripts and running them, and re-signing scripts that I’m working on (even though it’s just a matter of typing “sign” before I run a script) becomes an annoyance, such that if I were working in that environment, I’d inevitably have a “Sign-and-Run” script, which would really make me less secure, rather than more — for the average user, I do think that if you’re not writing scripts yourself on a daily basis, you should consider using AllSigned.

1. PowerShell 2 CTP2 doesn’t check signatures on modules, so even if I have it set to all-signed, it will load script modules and will let you dot-source any script using the add-module command, so I’d have to avoid modules altogether to really be 100% secure.

PowerShell loads “machine” profile scripts (which are located in the PowerShell folder) and “user” profile scripts (located in your Documents\WindowsPowerShell folder). But there’s a little more to it than that: PowerShell is a scripting engine which can be hosted inside any app, PowerShell.exe is a DOS-style console which is the default host. There are several third-party hosts available such as PowerShell Plus and PowerGUI and several open source hosts such as BgShell and PoshConsole … in order to support this ecosystem of hosts, the default PowerShell behavior is to load a host-specific profile script (for both the machine settings and the local-user settings). Not all hosts will do that, but anyway … the default host loads Microsoft.PowerShell_profile.ps1 and Profile.ps1 from both the user and machine locations.

By default, none of those profiles actually exist. Once you’ve installed everything as in Part 1, you should have a Profile.ps1 file provided by PSCX. This profile defines a whole bunch of values that are used by various PSCX cmdlets and scripts, so you may want to change some of it, but you should be careful about just deleting things until you’re well acquainted with the PSCX cmdlets. Over time, I’ve added settings to my profile for other snapins as well, and there gets to be a lot of noise in there that’s specific to different snapins, so instead of just leaving all of that in my main profile, I rename the Profile.ps1 file provided by PSCX and then dot-source it from a new blank profile script.

In fact, and I found that I started collecting a lot of scripts in my WindowsPowerShell folder so I created a sub-folder for them, and I automatically load everything that’s in that folder, so I don’t have to manually dot-source things when I add a new snapin profile.

Authenticode Signing your auto-load scripts

In order to make sure that automatically loading scripts doesn’t become a way for people to attack my computer, I made a decision awhile ago that I would only auto-load signed scripts. The how and why of this is a bit much to get into, and I wrote about Generating Windows Authenticode Code-Signing Certificates with OpenSSL a while back, so you can read that if you want more details, I want to review the simplest steps.

Edit: I should take a moment here to point out, in case you’re really new to PowerShell, that the first thing you’ll have to do is fix the error “File … cannot be loaded because the execution of scripts is disabled on this system.” I originally was just assuming you would have figured that out — it tells you to read the about_signing help, so you can just execute get-help about_signing and it explains in there what you need to do. In case you haven’t gotten that far, before you can execute the New-CodeSigningCert you’re going to need to run PowerShell as administrator (“elevated”) and execute this command: Set-ExecutionPolicy RemoteSigned … that will let you execute most scripts that you have saved locally without having signed them. You may want to tighten that up later and set it to “AllSigned,” but first you have to be able to sign scripts.

Generating a code-signing certificate

Edit: I’ve simplified this a bit, and modified the script to import the certificate to the Current User certificate store if you aren’t running in an elevated console (in Vista) — which should work fine if you’re the only user on your machine that needs to run the scripts — if you need them in the Local Machine store, you need to be running as administrator. The script will let you know which it does, so you’ll know, one way or another.

Step 1. Download my PoshCerts package and unpack it in your WindowsPowerShell folder — lets say in, WindowsPowerShell\PoshCerts\bin.

Step 2. Run the New-CodeSigningCert script to generate into the Certs folder. So if you’re in the WindowsPowerShell directory, you can just run it and you’ll be prompted for a few pieces of information that the certificates require, plus two passwords — and all of the keys will be generated into the Certs folder as files, and imported to your local store. Make sure you make a note of those passwords.

Edit: I came up with a Step 3. Under most circumstances (that is, unless you were planning on running a corporate Certificate Authority), you’ll have no further use for the CA certificate, If you want to make sure that nobody can abuse your root CA … you can and should just delete the private certificates, like so: Remove-Item *Root-CA.* -exclude *.crt

Signing Scripts

You can now sign scripts at will using the pfx file generated in step 2 with the Get-PfxCertificate cmdlet, or the Cert: provider (you have use -ImportAll when you call New-CodeSigningCert, not just -Import — that causes the import of your code-signing certificate to the “My” store … then you can do Get-ChildItem "Cert:\CurrentUser\My\$thumbprint" where $thumbprint is your certificate’s thumbprint).

Let’s rename our Profile.ps1 script and then sign it. We’ll create create a folder called “AutoModules” to stick your PSCX profile (and any future such scripts) in. If you’re still on PowerShell 1, you’ll just put the .ps1 files into that folder, and we’ll dot-source them.

Edit: The simplest

Checking for valid signatures

Once you’ve got that set up, we need to create the new profile script and modify it to load not just the PSCX module, but any other signed scripts we put in there. Paste this into your new Profile.ps1, and don’t forget to sign it.

If you’re testing PowerShell 2, you’ll want to treat these scripts as Modules … SnapIns themselves can be loaded as modules in PowerShell 2, but so can any script which needs to be dot-sourced. In this case, the easiest thing is to create a subfolder for each one and then use Add-Module with the folder name. There are some problems with that, which I’ll go into in Part 3.

If you are a .Net developer or a Computer Science researcher, and haven’t started using PowerShell, let me just make this argument for learning it:

PowerShell cmdlets are simple to write. The additional code required to make a .Net class into a cmdlet is very minor (at a minimum, a single method with a line of code to Write-Output something). Since cmdlets must derive from either Cmdlet or PSCmdlet you can’t just write every class as a cmdlet, but even non-cmdlet classes can be instantiated via New-Object and their methods and properties can be exercised.

After writing portions of a recent research project as PowerShell cmdlets, I would say that the ability to write a simple class and then use/execute from the command line and in scripts — plus the built in automatic argument parsing (PowerShell assigns pipeline input and command line parameters to object properties for you) makes PowerShell cmdlets quite useful for research and development. Because the overhead is so minimal, it minimizes the distractions of creating a user interface and allows you to focus your actual research goals. Additionally, because the PowerShell-specific code can be restricted to attributes and a method or two, the actual classes are still usable for other purposes. That is, your class is invokable within PowerShell, but it’s also reusabe within any .Net application, whether Windows.Forms, WPF, or even web apps.

Of course, since I’m primarily using PowerShell for research and development, I’m using the current CTP 2 release of PowerShell v2, some of what I’m doing in my profile won’t work until PowerShell 2 is released (next year?). I’ll try to mark the CTP-only features appropriately and offer PowerShell 1-compatible workarounds.

The first step, of course, is to install the software. To take full advantage of PowerShell 2, you need to have the .Net Framework 3.5 although you could use the .Net Framework 2.0 instead if you’re just using PowerShell 1.0. PowerShell 1 is only available as a “patch” so you have to choose the correct download for your platform through the Microsoft Download Center. However, since it’s still in CTP release, there is an installer for PowerShell 2 CTP2.

I also use the PowerShell Community Extensions and recommend them, although there’s a lot in there you may not use, there’s also a lot of extremely useful things — some of which are practically requirements. This package needs updating to work well with PowerShell 2, because PowerShell 2 has implemented natively some of the most popular features in PSCX, but it’s just a few minor changes. If you’re just getting started (or want to follow along with this series of posts), you should let PSCX install it’s profile (if you already have a profile, then in order to follow along with these posts, you should MOVE your profile out of the way before you install PSCX, and go ahead and let it create a profile from scratch).

Part 2