Practicing PowerShell in Helsinki

helsinkiI am very happy to announce that in addition to my appearance at the MVP-AllStars conference on 9 June 2015 in beautiful Helsinki, Finland but that I will be following it with a 2 day, intense PowerShell workshop aimed at Järjestelmänvalvojat (system administrators or IT Pros). I think this is going to be a blast and if you are any where in the region, or can hop on a plane, train or ferry, I hope you’ll consider attending.

The workshop is intended to provide enough practical PowerShell knowledge and experience that you can begin using it effectively the next day. Somehow I’m hoping I can cover the following material.

Day 1

  • What is PowerShell and Why It Matters
  • Understanding the PowerShell paradigm
  • The Power of a PowerShell Provider
  • Learning the PowerShell Language
  • PowerShell Remoting
  • WMI and CIM

Day 2

  • Exporting, Importing and Converting Objects
  • PowerShell Scripting Concepts and Security
  • Creating Effective PowerShell Scripts and Functions
  • PowerShell in Action
  • Getting Started with Desired State Configuration (DSC)
  • Questions, Answers and Next Steps

I don’t do many public classes so you won’t want to miss out. You can learn more at Seating will be limited and there is early-bird pricing so please don’t wait.

Friday Fun: What’s My IP

Today’s Friday Fun is a “quick and dirty” solution to the question, “What is my public IP address?” There are plenty of web sites and services you can visit that will display that piece of information. Naturally I want an easy way to get this in PowerShell. Recently I came across a reference to a web site that simply displays your IP address. To see for yourself go to

Pretty cool.

This means I can use PowerShell.

The content property is all I need so here’s a one-liner.

Of course that’s a lot to type so I put together a simple function.

Now I can easily get my public IP.

Nothing fancy, just getting the job done. Enjoy.

PowerShell Blogging Week: Supporting WhatIf and Confirm

We hope you are enjoying this experiment in community blogging. In today’s contribution I want to demonstrate how you can add support for WhatIf and Confirm to your advanced PowerShell functions. It is actually quite easy, especially if your function is simply calling other PowerShell commands that already support –Whatif and –Confirm. The recommended best practice is that if your function will do anything that changes something, it should support these parameters. Here’s how.

In your function you will need to use the cmdletbinding attribute and specify SupportsShouldProcess.

Beginning with PowerShell 3.0 this is all you need but you will see scripters explicitly setting this to $True.

That’s fine, although personally I find it redundant. If SupportsShouldProcess is listed then by default it is True. There is no need to explicitly set this to $False. Simply omit it. When you add this attribute, you will automatically get the –WhatIf and –Confirm parameters. The best part is that if your function is simply calling PowerShell cmdlets that already support –WhatIf, they will automatically inherit this setting. Here’s a sample function.

The function deletes all files from the %TEMP% folder that have a last modified time older than the last boot up time. As you can see in the help, PowerShell added the necessary parameters.

When I run the function with –Whatif it is passed on to Remove-Item.

It is really that easy. I also automatically get support for –Confirm.

Things gets a little trickier when you want to support WhatIf for a function where your commands don’t natively recognize SupportsShouldProcess. This would be true of any .NET static method or even a command line tool you might be running, to name a few examples. To add your own support you need to invoke the built-in $PSCmdlet object and its ShouldProcess() method. Here’s a simple example.

This function hypothetically is going to perform some action on a folder and I’m simply displaying the folder name in upper case. The important part is the If statement. This is the bare minimum that you need. If you specify –WhatIf you’ll be prompted.

The operation will be the name of your script or function. The target is the ShouldProcess parameter value which in my example is the path. But you can provide more specific information by specifying ShouldProcess parameters for the target and action. Here’s a revised function.

You must have the code for ShouldProcess otherwise even if you set the cmdletbinding attribute, PowerShell won’t know which commands need WhatIf. You can also have as many ShouldProcess statements as you need.

When it comes to confirmation, things get a little trickier and it might depend on what you really need. As you saw above, any cmdlet that supports –Confirm should automatically inherit the setting. This works because there is another cmdletbinding attribute called ConfirmImpact which has a default value of Medium. Other options are Low and High. My first function could also have been written like this:

Confirmation happens by comparing the value of ConfirmImpact with the built-in $ConfirmPreference variable which has a default value of High. If the value of $ConfirmPreference is equal to or greater than ConfirmImpact, PowerShell will prompt for confirmation. Let’s test this out.

Notice that I am also using for WhatIf. In this function the ConfirmImpact is set to high which means PowerShell will always prompt.

If I edit the function and change to ConfirmImpact to Medium or Low, then PowerShell will only confirm if I ask.

You don’t have to specify anything for cmdletbinding. If you know you always want confirmation you can do something like this:

Notice the use of the ShouldContinue method. When I run this function, PowerShell will always prompt for confirmation.

I also added a switch parameter called Force so that if it is specified, the user is not prompted for confirmation.

The downside to this approach is that help doesn’t show anything.

Perhaps in special cases this is what you want. Personally, I think you are better off using the cmdletbinding attributes as I did for my Set-Folder6 example.

Adding support for WhatIf and Confirm doesn’t take much effort and it will take your advanced function to the next level.

This post is part of the PowerShell Blogging Week series on Windows PowerShell Advanced Functions, a series of coordinated posts designed to provide a comprehensive view of a particular topic.

Other articles in this series:

We hope you found our work worth your time.

Advice, solutions, tips and more for the lonely Windows administrator with too much to do and not enough time.