On February 15, I was privileged to speak at MIGANG on PowerShell. As true with most of my PowerShell presentations, there are no PowerPoint slides for this presentation, just a custom module that has my comments on various topics.

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 disturbs me 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 our 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 Example 1 of 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 MIGANG-Feb2012 module here.

If you have PowerShell already installed, then here are the steps for using the module:

  1. Start PowerShell (ISE or console).
  2. Extract the zip file into one of the Modules folders in $env:PSModulePath.
    Mine has the following values:


    The best command I’ve found to see this in PowerShell is:

    dir env:PSModulePath | select Value

  3. Run the following command:

    Import-Module MIGANG-Feb2012

  4. Getting started with the module, run: Get-Help about_KeyTerms for more information.

I briefly ran through creating custom cmdlets in C#. 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 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 Copper Canyon afterwards! Thanks to all who came out for it!