Use PowerShell

Back on the PowerScripting Podcast

2012-05-15T20:35:26Z

You think Hal and Jonathan would learn, but they keep having me back on the show.

Hal was out of town, but Jon and I had a great talk about Server 2012 and PowerShell V3. As always, there was great conversation in the chat room and some good questions. Jon had a surprise for us all. After the interview, he played Jeffrey Snover’s keynote from the PowerShell Deep Dive.

Check out this episode and the other great shows and interviews they have.

PowerShell at PICC

2012-05-12T13:13:40Z

I had a great time with my classes at PICC. Both the PowerShell Fundamentals class and the PowerShell Tips and Tricks class were a lot of fun and resulted in great conversations at the breaks and after the classes.

The fun continued in the evening with the Bird of a Feather sessions where we spent some time talking about Server 2012, Server Core, and remote server management. What a great time.

I’ve uploaded my slides and sample scripts and I’ll have the shell histories from the classes posted in a day or two (I need to comment them so they are useable…), so check back on Monday for the annotated shell histories.

I wanted to say a big thank you to everyone who attended my class and especially those who made a point of talking to me about problems they face or where they are using PowerShell.

I also wanted to thank the organizers of PICC for having me out again this year.

Want to PICC up some new skills?

2012-04-29T23:04:42Z

If you are out on the East Coast and want to pick up some new skills or freshen up some old ones, check out PICC – the Professional IT Community Conference.

PICC is hosted in New Brunswick, New Jersey and is two days of great SysAdmin content (May 11/12).

You’ll find half day training sessions on things like:

PowerShell (by your truly)
Puppet
Time Management
Technical Resume Writing
IPv6
Workplace Presentations
and more…

There are also conference sessions on topics like:

Ganeti (Virtualization Management Platform)
Windows Deployment with MDT 2010
Scaling the StackExchange Platform
Configuration Management
Securing MySQL
Deep Application Monitoring
and more…

I’ll be there, and I’m definitely going to walk away better prepared to do my job.

What are you doing to improve your skillset?

The Games Are Afoot!

2012-04-05T15:30:00Z

The Scripting Games that is!

This year’s games are in progress, but it’s not too late to start. Each weekday a new event is posted, but you have a week to turn in your solution, so get out there and start writing some PowerShell.

All the details you need are available from the Scripting Games All In One Links Page, where the Scripting Guy Ed Wilson has thoughtfully provided (and updates daily) links to the events, rules, and other great information.

What Type Of Events Are There?

Well, the first couple of challenges give us an idea..

In the beginner category, you’ll be doing things like:

In the advanced category (should you dare..), you’ll find challenges like:

What’s In It For Me?

The Games are a great way to get hands on with PowerShell in a non-destructive manner. None of the challenges are going to require you to “format c:”. You also have a chance to win some prizes, so get out there and try them out!

Cascadia Community Conference – 2012

2012-03-26T21:37:00Z

I had a great time at the Cascadia conference this past weekend. I missed Friday, but got to spend all day Saturday teaching PowerShell to a great group of attendees. There were some great questions and interesting thoughts developed in both the Fundamentals class and the Tips and Tricks class.

I want to thank the organizers of the conference for having me out and especially to the attendees for my classes, most of whom spent all day with me.

For those that were in the class, I’ve linked to a zip file with some of the commands we ran through, and an xml file with the shell history for the problem we worked through in the afternoon.

To load the shell history, you can use Import-Clixml (path to the xml file) | add-history. After that Get-history will have all the commands we ran when we tried to work out the error handling for that web request.

PowerShell V3 – Default Parameter Values

2012-02-27T14:06:23Z

PowerShell Version 3 introduces the concept of Default Parameter Values.

This allows you to specify a value for one or more parameters for one or more commands.

To implement this, you need to populate a new hashtable – $PSDefaultParameterValues

That Description is Not Helpful

Let’s look at some examples –

First off, we can specify the value for a parameter for a specific command. The pattern used for the hashtable entries is “NameOfCommand:NameOfParameter” = “ValueOfParameter”.

(I’m stealing some of these examples from the samples provided in CTP1.)


$PSDefaultParameterValues = @{"Get-Process:Name"="powershell"}

Get-Process

Get-Process e*

With that set, every time we run Get-Process and do not specify the Name parameter, the PowerShell runtime will stick “powershell” in for that value. A specified parameter will always override a default value.

Let’s go the other way and, instead of specifying one command, set a parameter value on all commands (that have that parameter.


$cred = Get-Credential mydomain\mydomainadminaccount

$PSDefaultParameterValues = @{"*:Credential" = $cred}

This would provide your $cred to any Credential parameter.

We can also use wildcards to match multiple commands.

$PSDefaultParameterValues = @{"*-AD*:Server" = 'MyDomainController'}

This would provide a default value to the Server parameter for any command whose noun started with AD (like everything in the ActiveDirectory module.

Since this is a hashtable, it can hold many different mappings –


$PSDefaultParameterValues = @{

  "*:Credential" = $cred

  "Get-Process:Name"="powershell"

  "*-AD*:Server" = 'MyDomainController'

}

To turn off DefaultParameterValues (without removing everything you have set up), you can set a key “Disabled” equal to $true.

$PSDefaultParameterValues += @{"Disabled" = $true}

This concludes our brief look at DefaultParameterValues for today.

Go grab Version 3 CTP2 and give it a whirl…

When Import-Module Does Not

2012-01-06T16:46:58Z

A question came up about the behavior of Import-Module (in the context of this interesting discussion of whether module authors should provide aliases), especially with Version 3 and the auto-loading of modules (what’s that?).

So What’s the Question?

Does the auto-loading of modules in PowerShell Version 3 use Import-Module behind the scenes? If it does, can we use default parameter sets to control what types of things are imported?

What Actually Happens?

So, it turns out that Import-Module does get called behind the scenes and a default parameter set (new feature) can be used to customize the import of new modules.

$PSDefaultParameterValues = @{
	"Import-Module:Alias"=@()
	"Import-Module:Function"='*'
	"Import-Module:Cmdlet"='*'
	"Import-Module:Variable"='*'
}
Get-Module
Get-BitsTransfer
Get-Module

This example (when used in PowerShell V3) will (from a base PowerShell session) show you what modules are loaded, attempt to run the Get-BitsTransfer command, and then show you what modules are now loaded (should include the BitsTransfer module now). Since we’ve provided an empty array to the Alias parameter for Import-Module, any module that is imported will import any aliases.

Seems Like It Works… Where’s the Problem?

The problem comes in when you specify that only one of the four parameters (Alias, Function, Cmdlet, and Variable).

You might expect that when you specify one parameter (example Alias), that the other portions of the import (Function, Cmdlet, and Variable) would behave just like if you did not specify any of them.

Example -

Open a new PowerShell session (V2 or V3) -


Import-Module BitsTransfer
Get-Command -Module BitsTransfer

Get-Module

This will import BitsTransfer module and all attendant commands and functions. Note the ExportedCommands in the Get-Module output.

Open a new PowerShell session and try -


Import-Module BitsTransfer -Alias @()
Get-Command -Module BitsTransfer

Get-Module

This should import the BitsTransfer without any aliases (yes, I know BitsTransfer doesn’t have any aliases, but I wanted a module that most any Windows 7 or Server 2008 R2 machine would have – feel free to test with whatever module you desire).

This did import the BitsTransfer, but no commands or variables were imported. It only attempted to import aliases, and since we specified that aliases were to be an empty array, nothing was imported.

This is counter-intuitive and is not the experience we should have. Specifying one parameter should not change the default value of other parameters (from all to none in this case).

What Can I Do About It?

First of all, open PowerShell and try it! If you have one of the CTPs of Version 3, try it there. Also try it in V2 using Import-Module directly.

Then go to Microsoft Connect and vote up https://connect.microsoft.com/PowerShell/feedback/details/716857/module-partially-loads-with-import-module.

PowerShell V3 – Auto-loading of Modules

2012-01-06T15:32:38Z

PowerShell V3 includes a new “feature” – Auto-loading of modules.

What Does It Do?

Module discovery has been updated to make the exported commands for modules that are not loaded visible in a PowerShell session.

In Version 2, if you run Get-Module on a module that is not loaded but in your PSModulePath, you’ll get some metadata about the module, but nothing about the ExportedFunctions, ExportedCmdlets, ExportedAliases, or ExportedVariables.

Version 3 changes this, allowing Get-Module to retrieve information on all the exported features of the module.

This enables tab completion to complete the names of commands from modules that are not loaded. It also provides information to the PowerShell runtime on where to get the command information from, if the module is not loaded.

So, in Version 3, if you run a command from a module that is not loaded, the runtime will search your PSModulePath for the first command that it can find that matches that name and load the module that command is in for you.

I’m Not Sold

I really don’t care for this feature. I like to be in control of what module I import. The order in which modules are automatically imported depends on your PSModulePath. You don’t get to pick what the order is… User specific PSModulePath entries are first, then machine specific PSModulePath entries. This can cause a host of unexpected problems when there are command name collisions.

For example, the new Hyper-V cmdlets for Windows 8 cannot manage down-level Hyper-V machines, so you might need James O’Neil’s Hyper-V module from Codeplex. Both modules have Get-VM. Since James’ module will be in my user PSModulePath (most likely), unless I specifically load the Windows 8 Hyper-V module, running Get-VM will always load James’ module.

Starting 2012 with a Bang

2012-01-03T15:30:00Z

I’m so excited for 2012, personally and professionally. I started the year with a great honor, I was awarded a Microsoft MVP award for PowerShell.

Just a bit of background…

I started in IT in 2006 as the IT guy for a municipal police department. It was the first such full time position the department had. I immediately became responsible for a public safety network that needed to be operational 24/7. This required me to deal with a lot of intermittent issues or requests and I quickly saw that I needed some tools to get my job done well.

I looked around and found out that the *NIX guys had it pretty well covered with shell scripting, Perl, Python, TCL, sed, awk, etc.. I went looking for the Microsoft equivalent. I found Python and started doing some scripting with that. I loved the syntax and structure, as well as the availability of an interactive interpreter. The biggest pain was in dealing with the COM layer interactions. I explored C# and began to dabble with that as well.

And then I found PowerShell. I’ve been a PowerShell fanatic since the day I discovered it. It was a shell language. It had a scripting capability. I could extend it with .NET and C#. It worked with WMI and COM in a much more interactive manner and I didn’t have to go through some of the hoops that I had to with Python. It was also a Microsoft product (and eventually was available through Windows Update or with newer OSes in the box), which made it easier to deploy (policy-wise and distribution-wise).

Since that point in early 2006, I have been pushing PowerShell to help in all of the varied environments I’ve found myself in. I’ve become a speaker and a trainer and love sharing the capabilities of PowerShell and seeing others find value and make their work easier (or even possible).

This wouldn’t have been possible without…

I never would have been awarded this without the ceaseless lobbying of Doug Finke and the great interactions I’ve had with various members of the PowerShell team. I know a number of other PowerShell MVPs also were vocal in nominating me (forgive me if I forgot anyone), including Shay Levy, Marco Shaw, Aleksandar Nikolic, and Ravikanth Chaganti. I also had some great support from some of the Clustering MVPs (like Mike Steineke) and team (thanks Rob). Last, but not least, I’ve had great support from my local DPE team. Our local Developer Evangelist, Clark Sell, has never stopped encouraging me in spreading my thoughts on PowerShell and the development of a unified management API to .NET developer groups in our region (and further via his podcast). Our local IT Pro Evangelist, Brian Lewis, has been a stalwart supporter of both user groups we have going in the Milwaukee area, the Greater Milwaukee Script Club and the Greater Milwaukee IT Pro User Community.

Finally,

I want to thank you, the readers of my blog, the attendees of my script club or IT Pro user group, and any of the various attendees of talks I have given. Thank you for allowing me to share a bit of my experience and thoughts with you and I can’t wait to see where this year goes (PowerShell V3 is on the horizon!!!).

Checking Your Pipes For Leaks

2011-09-14T13:00:00Z

(NOTE: I started this post a few weeks ago)

This morning I woke up with my kitchen floor covered in water. As I was cleaning it up, I couldn’t help drawing some parallels between fixing a leaky pipe and a "leaky" (non-performing) script.

My repair process this morning took the following steps:

Contain the leak
Locate the source of the leak
Stop the leak
Check for related damage
Mitigate the related damage
Patch the leak
Confirm the leak is fixed
Monitor the leak site

Since most of you won’t really care about the plumbing in my kitchen, let’s run through how dealing with this problem applies to troubleshooting a misbehaving script (or function).

Containing the Leak

The first step I needed to take was to contain the leak.. in PowerShell, that means I need to pull that script or function from general use, as well as terminating any running instances.

This can be tougher than you think, especially if you are using remote jobs or are performing a sequential series of actions that cannot be rolled back (especially if you don’t have good logging in place!).

Locating the Source

After I’ve got the leak contained, I had to find where the leak was coming from. For my misbehaving script, I either need to find what has failed. Normally, the errors that I’m getting will help point me towards the source of the problem.

However, if I’m not getting errors, I need to step through the script (or function) and can use Set-PSBreakpoint to create an entry point in my script where I want to start walking through.

If my script (or function) is an advanced function, I could use -Debug and have it break on any Write-Debug statements that I’ve used throughout my script. This is a GREAT reason to have a periodic Write-Debug statement before any significant blocks of logic in your script.

Stopping the Leak

Once I’ve found the source of the leak, I can begin to stop the leak. In my kitchen leak, I had to turn off the water.

In the case of my script, I have to find any scheduled tasks using it and stop them or advise other people who might be using the script to stop using it until I can publish a new script.

Checking for Damage

Once I had my leak stopped, I started to check for residual damage that I might have to control. Water had leaked onto where the power cord for my water heater plugged into an extension cord, This caused the GFI outlet to trip.

Collateral damage from a misbehaving script or function can be disastrous. Very often, scripts are run under administrative credentials and can have unexpected side effects. When locating the source of the leak, I’ll check to see what other systems or areas that the script is touching and examine them for potentially improper changes or updates. Finally, I need to document any “damage” or errors that the script created.

Mitigating the Damage

Once I found that the GFI was tripped, I unplugged everything on that chain. I let everything dry out and replaced the extension cord.

For a misbehaving script, this is going to vary based on what the script was actually doing, but this can be one of the most important steps. I have to record all the actions I take to mitigate the “damage” found in the previous step. Even if I decide not to do anything about the damage I found in the previous step, that is still an action and should be documented.

Patching the Leak

Patching the leak is pretty straightforward. Going to the source of the leak, I removed the faulty tap and patched the pipe.

In my script, that means going to the source of the faulty logic or source of the errors and either fixing the logic and/or adding error handling to deal with the source of the errors. I’ll also add additional Write-Verbose or Write-Debug statements to make tracing problems and verifying functionality easier. For scripts that will

Confirming the Leak is Fixed

After I patched the leak, I turned the water back on and watched it for a short while to make sure that there was no seepage from the patch. I tested down-level plumbing to make sure that the pressure was appropriate as well.

After I’ve added my error handling and/or fixed the logic, I’ll run the script again, perhaps with –Verbose or –Debug. If I’m really motivated, I’ll make sure there is the CmdletBinding attribute and add –WhatIf support.

Monitoring the Leak

After I was able to confirm that the leak was fixed, I stayed home and periodically checked the line to watch for any seepage or residual problems. Over the next few days, I continued to monitor the site of the patch for any issues, though not as frequently.

After I’ve fixed my script, I’ll continue to watch was it gets used, perhaps logging all the output, until I’ve regained confidence in the project.

Resources for the WI .NET User Group

2011-09-14T03:51:35Z

I’ll get the slides posted sometime (in the middle of migrating my machine to the developer preview of Win 8), but the links I mentioned are:

—Project Home – http://www.show-ui.com

—Codeplex Site – http://showui.codeplex.com

—Doug Finke’s Blog – http://dougfinke.com/blog

—Joel “Jaykul ” Bennet’s Blog – http://huddledmasses.org

—James Brundage’s Blog – http://blog.start-automating.com/

Where I’ll be this Fall

2011-09-08T15:32:59Z

I wish I could have make it out to Build or the PowerShell Deep Dive, but I’ll settle for these:

September 13th – Wisconsin .NET User Group – Talking about Scriptable UI with PowerShell and ShowUI
September 29th – Greater Milwaukee IT Pro User Group – Talking about the PsTools in the Sysinternals Suite
October 1st – SQL Saturday #98 (Iowa City, IA) – Talking about Scriptable UI with PowerShell and ShowUI
November 1st – LaCrosse IT Pro User Group – Going over an Introduction to PowerShell

Waiter, There’s a Bug in My Get-Help!

2011-08-15T13:00:00Z

My friend Robert Robelo was kind enough to point out a problem with the proxies created by the CommandAssist module.

In trying to research the problem, I found that PowerShell crashed ( yes, crashed.. not throwing an error, but CRASHED) when Get-Help could not resolve the command it needed to provide help for.

Setting the Stage

Reproducing the Problem

Create a module that exports a function

$Path = 'c:\users\smurawski\documents\windowspowershell\TestModule.psm1'
$null = new-item $Path -ItemType File -Force -Value @'
function Test-One {
	[CmdletBinding()]
	param($x)
	$x
}

Export-ModuleMember -Function Test-One
'@

Import the module

Import-Module TestModule

Create the proxy module

Get-Module TestModule |
	New-AssistedModule -ModulePath c:\users\smurawski\documents\windowspowershell\TestAssisted

Import the proxy module

Import-Module TestAssisted

Try to Get-Help for Test-One (shell will crash here)

Get-Help test-one

What’s Happening?

In the proxy command that is generated, there is a help item (ForwardHelpTargetName) that is created to point the help file back to the original command. Since you could possibly have multiple commands, aliases, and functions with the same name, there is a second help entry (ForwardHelpCategory) that allows you to specify what type of command you are forwarding to.

NOTE: The following is my opinion of what is happening based on my testing. I haven’t attached a debugger and watched to verify, but I have tested enough to confirm a workaround. This occurs in both the ISE and PowerShell.exe. I have not tested in other scripting environments.

In this case, both the original command and the proxy are functions, so Get-Help goes into a loop until it hits a recursion max and crashes PowerShell.

Get the Duct Tape

Finding a Workaround

So, how can we get around this? CommandAssist relies on pointing back to the source command for the help files.

Fully qualifying the command in the proxy will solve the problem. I’ve updated the proxy command generation to qualify the command in the ForwardHelpTargetName with the module prefixed name of the source command.

The Downside

If you’ve been playing with CommandAssist, you will want to regenerate your proxies.

Let’s Get This Fixed

Vote it up on Connect!

I don’t know about you, but I would like to see this type of error not crash PowerShell. I’ve filed a Connect bug and would appreciate if you would head over and vote it up! The team really does respond to community feedback and Connect is a great way to show that this is important to you!

Using -Assist in an Assisted Module – CommandAssist

2011-08-13T15:50:34Z

This is the the meat of CommandAssist module, providing a contextual assistant to supplying the right parameters to a command.

Getting to the Meat of It

In the last post, we created a proxy module for ActiveDirectory module, so what does that really get for us?

Starting off in a new shell, I’ve imported the AssistedAD module and I’m going to try out the -Assist parameter for Get-ADUser

Import-Module ADAssist
Get-ADUser -Assist

Initially, I was prompted for a Filter parameter, as that parameter is marked mandatory in the default parameter set. I supplied a "*" and moved on. You’ll notice that I did not have to load the ActiveDirectory module, the CommandAssist module or the ShowUI module, as the proxy module handles all that in the background for you.

What I then got was:

You’ll notice that there are three tabs, Filter, LdapFilter, and Identity. Each tab represents a parameter set and shows the associated parameters for that set.

You will only be able to pass parameters for one parameter set, which can alleviate the common error of

Parameter set cannot be resolved using the specified named parameters

This is a key benefit of CommandAssist versus other tab completion options.

As you add parameters, the command line at the top will change to reflect your changes to the parameters.

Parameters that take a specified enumeration (like AuthType in this case) will have a dropdown box with the available options.

If I change parameter sets, the command line changes to reflect my new parameter selections.

However, your previous selections on an alternate tab have not changed, so you can return to that tab and continue editing if you determine that is the appropriate parameter set to use.

What other information would you like to see here?

Please post a comment on the blog or a message on Twitter if any additional information or features you think might be useful for this! I’d love to hear how you think this might provide value in your usage or your environment.

Creating an Assisted Module with CommandAssist

2011-08-13T15:15:50Z

The CommandAssist module allows you to easily create proxies functions for every command in a module (or snapin).

There is a handy command to generate these proxy modules included with the CommandAssist module.

Building an Assisted Module

The easiest way to explain what happens is to walk through the usage of New-AssistedModule. To that end, we’ll create a proxy of a module that I’ve been use regularly – the ActiveDirectory module.

NOTE: You will need to have ShowUI available in your module path (you can check with Get-Module ShowUI). You do not need to have it loaded into your session, CommandAssist will take care of that.

First we’ll load the CommandAssist module:

Import-Module CommandAssist

Second we will load the module we want to create a proxy for:

Import-Module ActiveDirectory

NOTE: This only has to be done the first time to create the proxy. Afterward, the proxy module will load the real module in the background.

Third we will use New-AssistedModule to create our proxy module.

$NewModulePath = c:\users\smurawski\Documents\WindowsPowerShell\Modules\AssistedAD
Get-Module ActiveDirectory |
	New-AssistedModule -ModulePath $NewModulePath

As noted in the screenshots, the module created has proxies for each command that add the -assist parameter. There also is a module file that will load all of the proxies, as well as the source module (in this example, AssistedAD.psm1).

The next post will review how the -Assist parameter works.

NOTE: The proxy module will load the real module in the background (so if you distribute it, the end user will need the source module or snapin as well).