Showing posts with label scripting games. Show all posts
Showing posts with label scripting games. Show all posts

Thursday, 13 June 2013

Pointers from Scripting Games 2013


The scripting games have just concluded with all 6 challenges drawing to a close. The games presented a wonderful learning opportunity along with helpful insights from expert judges and peers. The knowledge gained from reviewing other contributors' scripts and comments was immense. You can check the scripts and comments by following this link.

A few pointers that i picked up through the games are listed below: 


  • Full command and parameter names

Every challenge in the scripting games explicitly stated the preference for full command and parameter names instead of alias or abbreviations. It makes it easier for everyone to understand the script without much effort.


  • Formatting

Formatting the code with white spaces and tabs to create indents makes for easy reading.
This was important particularly in the beginner’s events where it was encouraged to write a one-liner. By introducing carriage returns and indents wherever possible, the integrity of a one liner is not broken and it is presented in a much better way.


  • Comment based help
I admit I had never considered including comment based help in my scripts before the scripting games. But after realizing its significance and due to encouragement from the community, it is a staple in my scripts now.

Don Jones also explains the concept here


  •  Requires
The #Requires tag can be used in scripts to annotate the powershell version necessary to execute the script. It is generally placed on top of the script.


  • Write-Host
Write-Host cmdlet is only capable of outputting data on screen. It does NOT write to pipeline. Almost every need to include the cmdlet can be replaced by either Write-Verbose or Write-Debug or Write-Error or Write-Warning or Write-Output.

That being said, Write-Host cmdlet’s ability to display colorful data on-screen using the –Foreground and –Background switches is unique.


  • Format* commands
Similar to Write-Host, format commands are also the last one in the pipeline. It can display data on screen and there can be no further data manipulation.


  • Filtering on server side
When querying data specially from a remote computer, it is always better to filter data on the server and then retrieve them. The script’s execution time reduces considerably.


  • Error handling
Error handling was another important feature that was emphasized in the games, notably in the advanced challenges. Try/Catch/Finally blocks can be an effective method to include the same within scripts.

Refer the following links for further information:



  • Use native Powershell commands and naming conventions.
Using native powershell commands, as much as possible, is also generally considered as good practice.


Tuesday, 21 May 2013

Scripting Games - Beginner Event 4


The Scripting Games has been discussed in the previous post. The games are now four events old.  Event 4 of the Beginners track posed the challenge below:

Dr. Scripto isn’t saying that he dislikes auditors, but they do seem to show up at the most inconvenient times—and with the oddest requests. So he’s tossing this particular auditor request over to you.

This auditor would like a report that shows 20 randomly selected (well, as random as you can get) users from Active Directory. For each user, the auditor wants to see their user name, their department and title, and the last time they logged on. You also need to show the date their password was last changed, and whether the account is disabled or locked out. So that’s seven pieces of information. You’re to put that information into an HTML-based report file, and the file must show the date and time that the report was generated. Please make sure that all of the dates are normal looking, human-readable dates and times.

Keep your command as concise as possible, although that doesn’t mean you’re not allowed to use full command and parameter names—that’s always okay to do! A domain admin will always run the command, and the resulting HTML file will be manually emailed to the requesting auditor.

My solution for the event was:

Import-module ActiveDirectory

Get-ADUser -Filter * -Properties Name,Department,Title,LastLogonDate,PasswordLastSet,LockedOut,Enabled | get-random -count 20 | select Name,Department,Title,PasswordLastSet,LastLogonDate,LockedOut,Enabled | ConvertTo-Html -PostContent "<hr>","Report Generated at : ", (get-date) | Set-Content "C:\Users Report.htm"

The first line imports the ActiveDirectory module with the assumption that the module is not pre-loaded. The ‘Properties’ switch in Get-ADUser switch specifies the user attributes to be retrieved that are not displayed by default; ex: Dpartment, Title, LastLogonDate.  ‘Get-Random’ command in the pipeline outputs random 20 users.  The required properties are then selected and the output is converted to HTML and saved on the local drive.

Helpful links:




Tuesday, 14 May 2013

Scripting Games - Beginner Event 3


The Scripting Games are a six week event that lets you showcase your scripting skills based on six challenges. You can either choose compete in the Advanced or the Beginner’s track. I have registered for the beginner’s event since it is my first year being part of the games. It is a great learning experience to see such diverse approaches on any challenge. If you haven’t registered yet, it’s not too late. Please follow the link below for more details:


The Games just concluded its third event. The beginner track event challenged the competitors to come up with a one liner for the below scenario:  

Dr. Scripto has been fielding a lot of calls from the Help Desk lately. They’ve been asking him to look up information about the local hard drives in various servers –mainly size and free space information. He doesn’t mind helping, but all the requests have been getting in the way of his naps. He’s asked you to write a one-liner command that can get the information for him – and he wants the output in an
HTML file.

















The Doctor says you don’t need to parameterize your command – it’s okay to write it to run against localhost, and he can just change that computer name as needed in the future. The resulting HTML does need to go into an HTML file on disk someplace, and he wants you to pay special attention to the following:


• The browser displays “Disk Free Space Report” in the page tab when viewing the report.
• “Local Fixed Disk Report” is in the H2 (“Heading 2”) HTML style.
• The report ends with an HTML horizontal rule and the date and time that the report was generated.
• The size and free space values are shown as gigabytes (GB) and megabytes (MB) respectively, each to two decimal places.

The command you write can assume that both WMI and CIM are available on the remote computers, and that all the necessary firewall rules and authentication have already been taken care of.


 The one-liner solution I came up for the challenge was:

Get-WmiObject -Class "win32_logicaldisk" -Computername "localhost"-Filter "Drivetype = 3" | Select-Object @{Name="Drive";Expression={$_.DeviceID}},@{Name="Size(GB)";Expression={"{0:N2}" -f ($_.Size/1GB)}},@{Name="FreeSpace(MB)";Expression={"{0:N2}" -f ($_.FreeSpace/1MB)}} | ConvertTo-Html -title "Drive Free Space Report" -precontent "<H2>Local Fixed Disk Report</H2>" -body $_  -postcontent "<hr>",(get-date) | Set-Content "C:\FreeDiskReport.htm"

The report generated using the above command: