The PowerShell Iron Scripter: My solution to prequel puzzle 2

As I mentioned in my previous blog article, each week leading up to the PowerShell + DevOps Global Summit 2018, will be posting an iron scripter prequel puzzle on their website. As their website states, think of the iron scripter as the successor to the scripting games.

If you haven’t done so already, I recommend reading my solution to the Iron Scripter prequel puzzle 1 because some things are glossed over in this blog article that were covered in detail in that previous one.

Prequel puzzle 2 provides you with an older script that looks like it was written back in the VBScript days. It retrieves information about the operating system, memory, and logical disks. This entry is fairly similar to my previous one as it queries all of the remote computers at once using a CIM session which is created with the New-CimSession cmdlet that was introduced in PowerShell version 3.0. Using the CIM cmdlets instead of the older WMI ones allows it to run in PowerShell Core 6.0.

The built-in DriveType enumeration is used for parameter validation and tabbed expansion / intellisense of the DriveType parameter.

I also decided to add the operating system ReleaseId which has to be retrieved from the registry.

The function shown in the previous example outputs the raw data returned by the cmdlets as a single type of object with a custom name. None of the disk or memory sizes are converted in case the person working with this function wants to use that raw information. The only exception is that locale is converted to decimal instead of returning it as the default hexadecimal value.

Who really wants to see drives or memory returned in bytes or kilobytes when they run a PowerShell command? A types.ps1xml file is used to extend the types of the returned object so the default output is much more user friendly.

If you’re interested in learning more about types in PowerShell, I recommend taking a look at the About_Types.ps1xml help topic.

Even through I’ve specified the default properties to return in the types.ps1xml file that was previously listed, I overwrite those defaults in a format.ps1xml file for its table view. I could have also provided a list view in the format.ps1xml file which would have eliminated the need to list the default ones in the types.ps1xml file, but I wanted to show how one of these files could be used to overwrite the other in one scenario, but not another. I’ve only shown the pertinent portion of the format.ps1xml file in the following example. See my IronScripter repository on GitHub for the entire file and module.

As with learning more about types, if you’re interested in learning more about modifying the default display of objects in PowerShell, I recommend taking a look at the About_Format.ps1xml help topic.

The types.ps1xml file has to be specified in the TypesToProcess section of the module manifest and the format.ps1xml file must be specified in the FormatsToProcess section. Once again, I’m only showing the relevant portion of the module manifest.

Running the function returns a nice looking table view with five properties. Notice the memory and freespace are returned in gigabytes even though the function itself didn’t convert those values to gigabytes. That’s because those properties are defined as script properties in the types.ps1xml file.

Piping to Format-List shows additional properties and their values, but not all of the properties.

Piping to Format-List and specifying all properties returns all of them. Certain commands will still hide some of their properties even in this scenario and you’ll either need to add the -Force parameter or pipe to Select-Object -Property * instead to view all of them along with their values.

Piping to Get-Member sheds some light on the different types of properties that are returned by this function.

The Get-MrSystemInfo function and the associated files shown in this blog article can be downloaded from my IronScripter repository on GitHub. They can also be installed from the PowerShell Gallery using Install-Module which is part of the PowerShellGet module that ships with PowerShell version 5.0 and higher. PowerShellGet can be downloaded and installed on PowerShell version 3.0 and higher, although the module shown in this blog article requires at least PowerShell version 4.0.

If you have a previous version installed and want to install the most recent version, Update-Module could be used instead.

Want to learn how to write PowerShell functions and script modules from a former winner of the advanced category in the scripting games and a multiyear recipient of both Microsoft’s MVP and SAPIEN Technologies’ MVP award? Then you’ll definitely want to attend my “Writing award winning PowerShell functions and script modules” session at the PowerShell + DevOps Global Summit 2018.


Leave a Reply

%d bloggers like this: