Learn Powershell | Achieve More

We have finally hit the final event of the 2013 Scripting Games! The past 6 weeks have given us many amazing scripts and some that were in need of extra work. Regardless, for those of you who have finished all 6 scripts in your respective, I say Congratulations! You have hit the finish line sprinting hard to the end! Now you can sit back and know that you made it and have learned (hopefully) some great things along the way. Remember, not only have you learned some new techniques, but also the techniques that you have used have taught others how to write better scripts!

Now it is time to check out some of the good and bad things that I have noticed during Event 6.

Good

There were a lot of good things that I saw during this event, but some that stood out to me were the following:

[System.Management.Automation.Credential()]$LocalCred = [System.Management.Automation.PSCredential]::Empty

What is happening here is that a user could provide a PSCredential object into the $LocalCred parameter or just specify a username or even just specify the parameter like a switch. Quite a few options for just one parameter. The important thing here is the use of $LocalCred = [System.Management.Automation.PSCredential]::Empty which prevents a popup from occurring even if the parameter wasn’t used. Pretty important thing to keep in mind when adding a parameter for credentials.

Using –Confirm:$False to handle the ‘Are you sure?’ prompts was exactly what we were looking for in the requirement of avoiding these types of prompts and making the code as smooth as possible for someone to use.

Using Workflows was awesome as it allowed you to chain together different parts of the process to include adding information to the TrustedHosts, renaming a computer, performing a reboot during multiple parts of the process and ultimately adding the computer to the domain. Using workflows allows a more cleaner approach for areas like this when more than one operation needs to happen before another operation can be started. Good stuff!

Bad

The following is not a valid item for comment based help:

.REQUIREMENTS
     Requires PowerShell 3.0

Instead, the individual should have used the following valid way to show that PowerShell V3 is required:

#Requires -Version 3.0

Using ‘*’ in the TrustedHosts is a BAD idea! Very big security issue in that it means that the local system with this configuration will trust ANY remote system. Instead, it is better to only add the systems that are absolutely needed to avoid any unnecessary remote systems from accessing the local computer.

Lack of proper examples in the comment based help only hurts the overall self discovery of scripts and functions. Please make sure that you use at least 2-3 examples to cover the very basics of the function to something a little more advanced.

This one gave me a headache:

if ($WhatIf) {
    function WriteStatus($status) {Write-Host "WhatIf: $status"}
} else {
    function WriteStatus($status) {Write-Verbose $status}
}

This is really disappointing at this stage in the Scripting Games to see someone still trying to add their own –WhatIf/-Verbose/Help parameters in a function. PowerShell does all of this by itself, all you have to do it research a little to find out the proper way to accomplish this. Hint: take a look at [cmdletbinding(SupportsShouldProcess)] and also possibly using $pscmdlet.ShouldProcess() to make this really work for you.

Neutral

I added this for a couple of items that that showed a good practice or looked cool, but at the same time had some things that I didn’t quite like/agree with either. Hence, the neutral part.

I saw quite a few hard coded passwords in the scripts that left me wondering why. I get that the event called for passwords to be used and that it would be hard for others to reviewing to remember those passwords when running the code, so instead of it being in my bad list, it went the neutral. Because in the real world, you wouldn’t hard code a password in a script. I did like the person who attempted obfuscation of the password with RegEx:

(-join ("5040737377307264" -split "(?<=\G.{2})",19 |
ForEach-Object {if ($_) {[char][int]"0x$_"}}) |
ConvertTo-SecureString -AsPlainText -Force)

Still a security issue as the password can still be revealed, but at least it is a minute bit tougher for someone to figure out if they were just glancing at the code and didn’t try to run this snippet. Very cool!

Using New-Object –TypeName System.Management.Automation.PSCredential was something that I really didn’t think of doing, namely because I would whether prompt the user for credentials vs. using this and a hard coded password. Not exactly a bad thing in the submissions here, but I would be hesitant to use this in a real world script.

All in all, I have been very impressed with all of the submissions regardless of how good or not so good they were. I can honestly say that I learned some great tricks from the submissions. As I mentioned before, it is safe to say that everyone has learned something during these games, whether it has come from the community judging, the actual submissions themselves or from some of my fellow judges making their commentaries. Great job to everyone and I will see you all again for the next Scripting Games!

With week 5 in the books, I can see that everyone just continues to grow and show some great submissions. Of course, nothing is perfect and can always show areas of improvement, but trust me, you are all doing an excellent job!

I was hoping to have this article completed prior to now, but between a flight to Tech Ed and forgetting my power cord for the laptop, I am just now getting this accomplished. Better late than never . Luckily, my fellow judges have put together some amazing blogs for this event that you should definitely review as well. So lets get to some of the things that I did and didn’t like.

What I liked

I liked seeing those people that were using Select –Unique or even Sort –Unique to pull out all of the duplicate IP addresses that were in all of the log files. By doing this, it becomes easier to identify all of the IPs rather than trying to figure out which ones are unique manually.

I was intrigued by those you used Import-Csv and then parsing the data with [ipaddress]. Very cool stuff! In fact, one of my tips on the PowerShell Magazine mentioned using [ipaddress] to validate an IP address.  So kudos to those of you who went this route! It shows just how many possibilities there are in solving a given requirement.

What I didn’t like

I have seen quite a bit of people using Get-Content to pull in the file data and then piping that into Select-String. While this does work, it isn’t exactly the most efficient way to accomplish this. Instead you should use Get-Content with the –ReadCount of 0 to pull the data as one string to work with. Either way will get you better off.

If you are going to use a regular expression for IP addresses, don’t use the following:

\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\

Ok, I am not talking about how this really doesn’t help for invalid IPs, but then again, we are not validating IP addresses, just looking for them. The problem is that this could actually be shortened down because ideally we are looking for the same items 3 times in a row. Instead take a look at doing something like this:

(\d{1,3}\.){3}\d{1,3}

As we are now down to voting for Event 6, I want to say “Great job!” to everyone that has submitted scripts for 1, 2 or all of the events. I promise that this will do nothing but make all of us better PowerShell scripters by reviewing everyone else’s submissions and by leaving constructive feedback.