This past Tuesday, I was privileged to speak at the Cleveland C#/VB.NET SIG on extending PowerShell. Since I knew that my audience wasn’t necessarily familiar with PowerShell (except a few), I spent the first half of the session introducing PowerShell and many of its key concepts with the help of a custom module, built specifically for this presentation.

The only PowerPoint slides that were used were Sam’s slides to announce upcoming user group meetings, events, and sponsor information. Otherwise, I chose not to use PowerPoint and took a page from my friend Matt Casto‘s book, using a technology to present the technology. (He had done a presentation on Silverlight at a Central Ohio Day of .NET using a Silverlight app to show “slides”. I thought this was a cool technique and figured I could use PowerShell to explain PowerShell.)

The custom module is a manifest module, as I generated a PSD1 file for the module. However, if you remove the PSD1 file, the module is then considered to be a script module, as was covered in the talk.

To give you some background, my $profile has the following setup:

Set-Alias alias Set-Alias

function Get-Home{
    cd ~

$PSModulePath = $env:psmodulepath

I use the alias example because it irritates me to no end that there are some Linux commands that are already aliased, but the obvious alias alias was left out.

The function Get-Home is referenced in one of my help files. There’s a story behind this one. Again, this goes back to my Linux/Unix background. While Matt and I were working on the book, he had an example of a custom function that would get the user’s home directory. He used some long, convoluted path after the cd command. Of course, I had to come back and explain to him what the ~ meant, as I used to type cd ~ a lot when I spent time in the Unix labs on campus in my college days. It wouldn’t be until later on, as I was preparing for this talk, that I found the ~ explained in a PowerShell help file. (It’s in the help text for Resolve-Path.)

Finally, I included the $PSModulePath variable for two reasons. One, there’s improper documentation that this variable is a pre-defined variable. There are community comments that point out this flaw. The other reason is so that I can use the environment variables as a good segue into the providers topic.

I noted that I was not really going to get into covering creating custom providers, as there is a lot of detail behind that. However, if you want to talk providers, Oisin Grehan is a PowerShell provider master. He is also the guy behind the PowerShell Script Provider, to allow writing PowerShell providers in PowerShell scripting language and not necessarily in C#.

The other recommendation that was mentioned was to use the #PowerShell hashtag on Twitter, as there are many awesome PowerShell MVPs and notable people who work with it who are gratiously answering questions and helping as needed, providing direction for learning more on PowerShell.

You can download the custom ClevSIG2011 module here.

If you have PowerShell already installed, then here are the steps for using the module:
1. Extract the zip file into one of the Modules folders in $env:PSModulePath. Since this is unique to me, I put mine in my DocumentsWindowsPowerShellModules folder.
2. Start PowerShell (ISE or console).
3. Run the following command: Import-Module ClevSIG2011
4. Getting started with the module, run: Get-Help about_KeyTerms for more information.

The second half of my presentation involved creating custom cmdlets. In our book, I wrote about cmdlets to work with the Windows 7 Libraries feature – the feature that deals with Documents, Music, Video, Pictures, Contacts, and Downloads. The code that I used for that part will most likely be included in supplemental materials for our book. You can pre-order the Automating Microsoft® Windows Server 2008 R2 Administration with Windows® PowerShell 2.0 book through a variety of vendors.

I had a lot of fun presenting to such a lively crowd, and I especially enjoyed talking with others at Mavis Winkle’s afterwards! Thanks to all who came out for it!

One thought on “Extending PowerShell – Notes from my 4/26 Presentation

  1. It was a great presentation; the thing that struck me was how if you are doing anything with either generating builds for deployment, staging systems, or wanting to have some handy-dandy maintenance scripts ready that Powershell is a game changer. All the things that I wanted to do in the DOS world but then said “Ugh, way too much work for the payoff” are now within easy grasp.

    Practical example:
    If I have an application that is depending on several components to be configured in certain ways, it is now easy for me to use some Powershell to check the registry, the filesystem, the database, and even have hooks into my application ( by creating my own cmdlets – get the book! ); this would be mighty powerful to give to my customers and to my support staff to run before anyone begins to do anything. The equivalent is the ability to give doctors an MRI for a patient prior to cracking them open. Am I overstating? I really don’t think so ( after spending the last several months slogging through doing the same sort of thing in a variety of languages to varying degrees of success and satisfaction! )

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.