Event 2: My way…

Now that event 2 is closed for new entries – time to let you guys know how I would do it. Again: feel free to complain, comment, judge. I hope I will show you few tricks here and there that will help you with next event, or at least: will help you understand what you might have done wrong. Not that I’m assuming you did, I just noticed few gotchas in this scenario that I wanted to addresses. Have I succeeded? As you probably already know, there is no definite answer to that question.

“Why?” answer first

I made some code decisions and before you dig into code I wanted to show you why I made those decisions in the first place. Have you noticed that description mentioned Windows 2000 server? And that it was very vague on whole processors count thing? There is a reason for that. Basically, most of the information you needed was available via WMI in Win32_ComputerSystem class. But if you did your homework you should know, that this class evolved. You can find more details in few places:

• MSDN description of Win32_ComputerSystem
• Hotfix for Windows 2003 that levels Win32_ComputerSystem on this OS with Vista
• Don’s article on relatively similar topic

I guess you know by know why description was so unclear (at least: that was my impression, I’m not in author’s head or anything ). Now – to my solutions.

Beginners next

I must say that it was tougher than the first one for me. If you read first part – you should know why. You really had to check for that potentially missing properties in Win32_ComputerSystem and react. Also: you couldn’t assume that based on OS version some properties will be missing: if someone applied above mentioned hot-fix to Windows Server 2003 you would miss opportunity to take more data. What I settled on is:

Get-WmiObject -ComputerName (Get-Content C:\IPList.txt) -Class Win32_ComputerSystem |            
    ForEach-Object {            
        if ($LogicalProcessors = $_.NumberOfLogicalProcessors) {            
            $Processors = $_.NumberOfProcessors            
        } else {            
            $Processors = 'N/A'            
            $LogicalProcessors = $_.NumberOfProcessors            
        }            
            
        $OS = $_.GetRelated('Win32_OperatingSystem').Version            
            
        New-Object PSObject -Property @{            
            Name = $_.Name            
            Processors = $Processors            
            LogicalProcessors = $LogicalProcessors            
            OSVersion = $OS            
            PhysicalMemory = $_.TotalPhysicalMemory  |            
                Add-Member -MemberType ScriptMethod -Value {            
                    "{0:N2} GB" -f ($this / 1gb)            
                } -PassThru -Name ToString -Force            
            
        }            
    }            

I don’t want to use Get-WmiObject twice, so I just use GetRelated method to read Win32_OperatingSystem on remote box for OS version. I also use technique that makes code slightly more concise: assign value to variable inside “if” statement. If right side is $null, or expression on the right will result in an error – you are going straight to “else”. If not, part of job is done, so you just do second part. Finally, trick I picked up from one of attendees last year – override ToString method to get nicer report on memory (in GB) without turning that property into string (you still can sort on it).

Finally: advanced…

With advanced I decided to do few extra things that are maybe not necessary, but I felt they may be useful in the tool like that. First of all I like if my custom objects produced by advanced function look nice. Number of options that can get you there is different depending on PowerShell version you use. I’m using v3 all the time, so I feel urge to add OutputType matadata to any command that produces some output, even if that’s only custom “made up” types. For that to work smoothly though we need to add some information into Extended Type System (ETS).  Another part was credentials: scenarios says that we have admin credentials, but I decided that it may be handy to provide option to specify this credentials as alternate credentials, rather than run whole PowerShell with that privileged account. Those two pieces together (plus meeting requirement for pipeline support) formed my param block (and it’s decoration):

[OutputType('WMI.Inventory')]            
param (            
                
    # Name of computer to be invetoried.            
    [Parameter(            
        ValueFromPipeline = $true,            
        ValueFromPipelineByPropertyName = $true,            
        Mandatory = $true            
    )]            
    [Alias('CN','Name')]            
    [string]$ComputerName,            
            
    # Optional alternate credentials            
    [Management.Automation.PSCredential]            
    [Management.Automation.Credential()]            
    $Credential = [Management.Automation.PSCredential]::Empty            
)            

Next, begin block. I usually don’t do that, but here I decided to create a filter. Feature, that didn’t live up to it’s expectations and was slowly forgotten. Here however I would like to use it instead of gigantic Foreach-Object scriptblock:

filter ConvertTo-WmiInventory {            
        if ($LogicalProcessors = $_.NumberOfLogicalProcessors) {            
            $Processors = $_.NumberOfProcessors            
        } else {            
            $Processors = 'N/A'            
            $LogicalProcessors = $_.NumberOfProcessors            
        }            
            
        $OS = $_.GetRelated('Win32_OperatingSystem').Version            
            
        $Out = New-Object PSObject -Property @{            
            Name = $_.Name            
            Processors = $Processors            
            LogicalProcessors = $LogicalProcessors            
            OSVersion = $OS            
            PhysicalMemory = $_.TotalPhysicalMemory  |            
                Add-Member -MemberType ScriptMethod -Value {            
                    "{0:N2} GB" -f ($this / 1gb)            
                } -PassThru -Name ToString -Force            
            
            }            
        $Out.PSTypeNames.Insert(0,'WMI.Inventory')            
        $Out                 
    }            

As you can see this filter will combine data from remote WMI repository and produce object of pseudo-type we’ve defined in OutputType attribute. What next? We have some common WMI options that we plan to use, so we can define them here too:

$WmiOptions = @{            
        Class = 'Win32_ComputerSystem'             
        ErrorAction = 'Stop'            
    }            

With all that preparations done, we have veeery short process block to create:

try {            
        Get-WmiObject @PSBoundParameters @WmiOptions |            
            ConvertTo-WmiInventory            
    } catch {            
        Write-Warning ("Issue with '{0}': '{1}'" -f             
            $ComputerName, $_.Exception.Message)            
    }            

But function is not everything we need. I assume this is “library” type of script (one that you would dot-source) so next step will be defining and adding formatting data that we need. I would do that in v2 only – in v3 we can do it slightly different way. With much less effort, but unfortunately – with some things we need to drop from view. But first let’s create some ps1xml file on-the-fly and apply it to current session:

$FormatPs1Xml = [Io.Path]::GetTempFileName() |             
    Rename-Item -PassThru -NewName {            
        $_ -replace '\.\w+','.format.ps1xml'            
    }             
            
Set-Content -Path $FormatPs1Xml.FullName -Value @"
<?xml version="1.0" encoding="utf-16"?>
<Configuration>
<ViewDefinitions>
<View>
    <Name>WMI.Inventory</Name>
    <ViewSelectedBy>
        <TypeName>WMI.Inventory</TypeName>
    </ViewSelectedBy>
    <TableControl>
        <TableHeaders>
$(foreach ($Width in 30, 10, 15, 12, 18) {
      @'

            <TableColumnHeader>
                <Width>{0}</Width>
            </TableColumnHeader>
'@ -f $Width
})
        </TableHeaders>
        <TableRowEntries>
            <TableRowEntry>
                <TableColumnItems>
$(foreach ($Item in 'Name', 'OSVersion', 
    'PhysicalMemory', 'Processors', 'LogicalProcessors') {
        @'

                    <TableColumnItem>
                        <PropertyName>{0}</PropertyName>
                    </TableColumnItem>
'@ -f $Item
          
})
                </TableColumnItems>
            </TableRowEntry>
        </TableRowEntries>
    </TableControl>
</View>
</ViewDefinitions>
</Configuration>
"@            
            
Update-FormatData -AppendPath $FormatPs1Xml.FullName            

As you can see – I create temporary file, rename it to name with proper extension for formatting files (Update-FormatData is kind of picky on that), generate necessary XML (without repeating stuff that loop can repeat for me) and finally – I update my format data. End result:

As you can see – I simply reused file I’ve created for beginner event.

v3: better, simpler v2

Now few things that I would do differently in last part if I would target PowerShell v3. I won’t go into details on function part – there are many changes possible there. What did change in PowerShell v3 that suddenly ps1xml files are no longer so valid for nice custom objects? For me it’s Update-TypeData than now supports inline operations:

Update-TypeData -DefaultDisplayPropertySet @(            
    'Name'            
    'OSVersion'            
    'PhysicalMemory'            
    'LogicalProcessors'            
) -TypeName WMI.Inventory -Force            

I just defined special property set for my custom type with single line of code (turned into few lines just to make blog readable ). This property set will tell PowerShell what is the order of my properties (honestly, with v3 I would take care of order in the function itself) and – what is more important, limits shown properties to four that I care about the most. This way I will get table rather than list by default:

Finally, we need to take advantage of OutputType we defined earlier. I don’t know of better way than updating our pseudo-type with same list of properties we actually have in it once it leaves our function:

$Note = @{            
    MemberType = 'NoteProperty'            
    Value = $null            
    TypeName = 'WMI.Inventory'            
}            
            
foreach ($Property in @(            
    'Name'            
    'OSVersion'            
    'PhysicalMemory'            
    'Processors'            
    'LogicalProcessors'            
)) {            
    Update-TypeData @Note -MemberName $Property             
}            

Why is that cool/ important/ valuable/ must have for v3 users? Take a look:

We could get same effect using ps1xml file (and with better intellisense support) but now we can get it working in few lines of code. Only because we defined OutputType, and told PowerShell what properties our type has. And with that – I’m going straight to Scripting Games page to find some jewels there. Promise to come back to you once I finished reviewing your scripts with some cool ideas I picked up this year!