PowerShell Prep

I like watching cooking shows because eating is my hobby.  I used to wonder how the host could complete a three course meal in 22 minutes when it takes me 30 minutes just to get started because I had to go back to the store to get that one ingredient I forgot to put on my shopping list.

http://www.glovegame.com/nutrition.html

The secret of the cooking shows is that the ingredients are prepped -- all of the vegies are chopped up and all of the spices are pre-measured.  The host tosses them in a pot, stirs them together, then pulls the pre-made masterpiece out of the second oven.  (I guess the real secret is that the cooking show hosts cheat.)

Let's get prepped and ready so we can do some cooking with PowerShell.

Ingredients

1. Download the latest version of PowerShell.  PowerShell 2.0 is built into Windows 7 and Server 2008.  But there will be cool enhancements in PowerShell 3.0 so be sure to check Technet or Download Center before continuing. 
2. Get any other modules or add-ins you might use.  This can include:
1. The Remote Server Administration Tools (RSAT) which include modules for Active Directory and Group Policy management
2. The PowerShellPack that has some extra modules for OS management
3. The PowerShell Community Extensions which has some useful extras
4. If you are working on a specific server application such as Exchange or SQL or SharePoint there are add-ins available from the install media
5. VMWare's PowerCli if you will be managing VMWare vSphere environments
3. Download the PowerGui which includes the best free IDE for PowerShell. Windows 7 and Server 2008 come with an IDE but it lacks many of the features of the PowerGui Script Editor.
4. Download PowerGui PowerPacks for any applications you have to support. In particular the Active Directory PowerPack has many AD cmdlets that are often more powerful than those available in the Microsoft modules.

Recipe

Installing all this stuff is easy.  The downloads are all .exes or .msis.  A bunch of next-next-next and the installs are done.  One thing to note is that the RSAT modules are Windows features which are not available until you enable them. 

Control Panel > Programs > Turn Windows features on or off.

Expand Remote Server Administration Tools.  In the following examples I will use the Active Directory module so expand Role Administration Tools > AD DS and AD LDS Tools and select Active Directory Module for Windows PowerShell.  Select any other tools you will need.

While there are many useful extensions and add-ons for PowerShell, you probably don't want to install all of them, unless you plan to use them.  While it might be kind of handy to have everything available, at some point things get unwieldy.

http://www.wengerna.com/giant-knife-16999

There are two types of add-ons, modules and snap-ins.  Snap-ins are add-ons from version 1 of PowerShell while modules are add-ons available in version 2.  Because the Quest PowerGui ActiveDirectory PowerPack was available in version 1 it is still a snap-in.

How do you see what add-ons are available?

Get-Module -ListAvailable
Get-PSSnapin -Registered

Cmdlets in modules are not available until you import the module.  Cmdlets in snap-ins are not available until you add the snap in:

Import-Module <ModuleName>
Add-PSSnapin <SnapinName>

There are no cmdlets that contain the word "forest" until we import the ActiveDirectory Module

All PowerShell cmdlets have a verb-noun structure.  All of the Quest Active Directory cmdlets precede the noun with "QAD".  I don't have any QADComputer commands until I add the Quest.ActiveRoles.ADManagement snap-in.

But if I really want to save time in my PowerShell kitchen I should have the most common add-ons available every time I start PowerShell.  Frequently used modules or snap-ins can be included in my PowerShell profile.  There are four locations where you can store profiles, but the profile that is easiest to access is the one for the current user which is specified in the $profile variable.

Now when I launch PowerShell I have all of my Active Directory related cmdlets available.

Ummm.... OK.  Not quite.  When I install the Quest PowerPacks I get prompted to change the ExecutionPolicy to AllSigned.  The PowerPacks are signed so this setting is appropriate.  I will discuss signing in a future post.  But for now let's just bypass the execution policy for my test user.

Bypass is the least secure of the execution policies so I don't want to apply it everywhere.  Instead I apply it to just my test user by specifying -scope CurrentUser on the Set-ExecutionPolicy cmdlet.

Now when I launch PowerShell my add-ons are available

The default shell is good for running scripts behind the scenes such as logon scripts.  But for developing scripts the PowerGui Script Editor provides many advantages.  One of the advantages is that making add-ons available is a simple menu choice.

File > PowerShell Libraries...

ActiveDirectory and the Quest.ActiveRoles.ADManagement add-ons are already available because PowerGui still processes my profile script.  But cmdlets for other modules become available just by selecting them in this dialog and clicking OK.

Our PowerShell kitchen is prepped and ready.  Now we can start cooking so we can eat.

Commenters: What modules and snap-ins do you load in your profile?