PowerShell for Windows Admins

Jun 23 2014   11:24AM GMT

Bad practices – making scripts needlessly interactive

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Tags:
PowerShell

the PowerShell community spends a lot of time talking about best practices when using PowerShell. I’m not convinced this approach is working as we keep seeing the same bad practices coming through on forum questions. I thought I’d turn the problem on its head and present a now-and-again series of bad practices. These are things I’ve seen people doing that either make their script far more complicated than it needs to be or just completely negates the power that PowerShell brings to your  daily admin tasks.

I think that a lot of this is due to people not taking the time to learn the best way to use PowerShell. The thinking goes something like this  – I can script with XXX language.  PowerShell is a scripting language. Therefore I know how to use PowerShell.

NO. WRONG.

PowerShell should be thought of more as an automation engine then a scripting language. The reason for using PowerShell is to perform tasks that are one or more of repetitive, boring, long, complicated, error prone, can’t be done in the GUI. The goal of automating a task should be that you can run it automatically without human intervention if you need to.

I’ll give an example.

Some years ago I was involved in migrating a new customer into the managed service environment of the company I was working for. Step one was to move them out of their previous supplier’s data centre. As part of that move I wrote a PowerShell script that shutdown every machine in that environment. The script took a list of computers from a file and shut them down in order. My final action was to shutdown the machine I’d used to run the script.

I actually ran the script manually but I could have run it as a scheduled job – which I did another time.

What do I mean by making scripts needlessly interactive?

Consider this example:

 

$hs = @”
Press 1 to reboot computera
Press 2 to reboot compuertb
Press 3 to reboot computera and computerb

“@

$x = Read-Host -Prompt $hs

switch ($x) {
1  {Restart-Computer -ComputerName $computera; break}
2  {Restart-Computer -ComputerName $computerb; break}
3  {
Restart-Computer -ComputerName $computera
Restart-Computer -ComputerName $computerb
break
}
}

 

The script defines the prompt – a menu in effect. Gets the user choice and performs the required reboots. It works BUT its so wasteful in terms of the effort required.  Even worse its not sustainable. When you add another computer your choices become a, b, c, a+b, a+c, b+c, a+b+c.  Now think what happens as your list of possible computers grows to 5 or 10 or 100!

Every time you find yourself typing Read-Host sop and ask yourself if its really needed. I’m not suggesting that cute little animals will die if you use it but you will cause yourself unnecessary work – now and in the future.

So what should you do?

Use a parameterised script.

 

[CmdletBinding()]
param (
[string[]]$computername
)

foreach ($computer in $computername){
Restart-Computer -ComputerName $computer
}

 

call the script reboot.ps1 for sake of arguments.

You can then use it like this

./reboot –computername computerA
./reboot –computername computerb

./reboot –computername computerA, computerb, computerc

 

if you have a lot of machines to reboot

./reboot –computername (get-content computers.txt)

put the names in a file (one per line) and call the script as above. You could even have different files for different groups of computers if required

Less typing and easier to use and maintain.

Now you’re using the power that PowerShell brings you.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: