Don’t assume a Cmdlet has -WhatIf

Imagine that you are writing a script, or preparing to run a command that will perform a change on your domain. For instance, you are running the FailoverClusters module and want to move a cluster group on a given condition. Just to be cautious, you add the –WhatIf parameter at the end of the Move-ClusterGroup cmdlet to only simulate actually moving that cluster group which might affect email, file access, or possibly the backend SQL instance for sharepoint or another application. But guess what, that parameter doesn’t exists! Now you have just begun failing over a resource group on your cluster bringing an outage to your environment and your bosses demanding an explanation. How could this have been avoided? Fortunately, this did not happen to me as I was being over-cautious and wanted to make sure that the –WhatIf parameter was actually available for the Move-ClusterGroup cmdlet. Sure enough, it wasn’t there and I quickly commented out that line and replaced it with a start-sleep command to simulate the moving of the cluster groups in my cluster balancing script.

Now this might be easier to find if your typing in the console and tabbing into the WhatIf, but what if your working on a multi-line script, or in a hurry?  Sometimes in the heat of the writing you just might type –WhatIf without really knowing for sure if the cmdlet you’re using actually supports it.

Jeffrey Hicks (Twitter|Blog) and Sean Kearney (Twitter|Blog) wrote some great articles on adding –WhatIf support to advanced functions here and here. So with that, I am not going to go into doing that here and why having this will save yourself from yourself, but instead I will talk about the current cmdlets that are available and their use (or lack of use) of the –WhatIf parameter to potentially save you from yourself when running a command that implements some sort of change.

You might be wondering: How can I find out if a cmdlet has the WhatIf parameter? You’re in luck because here are three ways to find out!

You can find out if a cmdlet supports the WhatIf parameter one of a few ways:

  1. Use Get-Help <cmdlet> and look for the WhatIf

 image

2.  Start typing –wha and then hit tab to see if it auto-completes.

image

image

3.  Or you run this one-liner to find all of the cmdlets that support –WhatIf

Get-Command -type cmdlet | Where {$_.Parameters['Whatif']} | 
Format-Wide -Property Name -Column 4

image

The count of cmdlets supporting WhatIf in the picture is 85.  All of these cmdlets perform some sort of action that either sets, deletes, creates, stops, starts, etc… You get the idea. A lot of cmdlets that have the ability to effect change on your environment, both positive and negative (if not used correctly).

But back to a almost issue that I had a few days ago. After I noticed this, I decided to find out what other cmdlets in the FailoverClusters module do not have the –WhatIf parameter available. Here is what I found:

Get-Command -module FailOverClusters | Where { -Not $_.Parameters['whatif']} |
Select Name

image

I see several cmdlets list above that need to have the –WhatIf parameter available. All of the Move* cmdlets and Stop* cmdlets to name a few. I am sure there could be a number of reason why WhatIf wasn’t included in some of these cmdlets, but hopefully there will be an update or something in the next Service Pack that might add WhatIf to some, if not all of the cmdlets that make a change to a system. It also makes me want to check out other modules or snapins such as the Exchange Snapin and PowerCLI snapin.

To be fair, here are the cmdlets in the FailoverClusters module that do support –WhatIf

Get-Command -module FailOverClusters | Where {$_.Parameters['whatif']} |
Select Name

image

Not that many compared to what it should have. But still better than nothing.

This is just my opinion, but any cmdlet, advanced function, script, etc… that performs any type of action or change, whether it is performing a create, delete, set, update, etc… needs to have some sort of –WhatIf or confirmation before making that change. It really takes not time at all to implement this and saves you and others time, money and possibly your employment.

So remember fellow PowerSheller’s:

Don’t assume a cmdlet has –WhatIf. Double check before adding that to your script and running it to test the action. This can be done by using one of the 3 methods I listed earlier or any other method you can think of!

About these ads

About Boe Prox

Microsoft PowerShell MVP working as a Senior Systems Administrator
This entry was posted in News, powershell and tagged , , , , . Bookmark the permalink.

One Response to Don’t assume a Cmdlet has -WhatIf

  1. Your script throws “Cannot index into a null array” errors in PowerShell 3.0. Checking for $_.Parameters first seems to fix this:

    Get-Command -type cmdlet | Where {$_.Parameters -and $_.Parameters[‘Whatif’]} | Format-Wide -Property Name -Column 4

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s