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:

http://www.vexasoft.com/blogs/powershell/7255220-powershell-tutorial-try-catch-finally-and-error-handling-in-powershell

http://blogs.technet.com/b/heyscriptingguy/archive/2010/03/11/hey-scripting-guy-march-11-2010.aspx

• Use native Powershell commands and naming conventions.

Using native powershell commands, as much as possible, is also generally considered as good practice.

Eliminate Ellipsis In Powershell

When trying to display the result of some queries on screen, we may find that some of the output is truncated by ellipsis i.e. “ . . .” , often the case with multi-valued attributes. An example of the ellipsis can be found when retrieving the thread details of any process. The image below shows the output when querying the thread details for system process:

Get-Process System | select Name,Threads

The reason that the thread column gets truncated at 4 values is because of $FormatEnumerationLimit. Help about the variable can be found under About_Preference_Variables. The value is set at 4 by default in the powershell console and the value is 16 in the exchange shell.

The entire thread details can be listed by modifying the above command to:

Get-Process System | select Name,Threads | ft –Wrap –Autosize

An alternate method to display the threads would be to use the ‘ExpandProperty’ switch in Select-Object cmdlet:

get-process system | Select-Object Name -ExpandProperty Threads | ft Name, ID –AutoSize

The easiest method would be to change the default value of the $FormatEnumerationLimit.

The default value has been altered to 80 which displays the whole list of system threads on screen:

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:

http://blogs.technet.com/b/heyscriptingguy/archive/2011/09/08/use-powershell-to-pick-random-winning-users-from-text.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2011/05/27/use-a-simple-powershell-technique-to-create-random-numbers.aspx

http://technet.microsoft.com/en-us/library/ee156817.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2012/08/07/use-powershell-to-create-an-html-uptime-report.aspx