It's what's on the inside that counts

Have you ever ran a PowerShell Cmdlet, looked at the properties and want do something with one of those properties like sort or group the output and have it fail? This has happened to me a few times. One example of this was with the NetApp PowerShell Toolkit.

I was looking at snapshots and wanted to sort by their Created date.Notice that there is a Created column in the output


Looks good, but when I try to sort by Created I get the same output as when I sort by “foo” (This is not a good thing)


It turns out “Created”, just like “foo”, is not a real property contained in the SnapShot objects. Lets see what is really there. There are a couple ways you can see what’s really going on. First, you can use get-member


Get-member tells us that there are a couple properties, AccessTime and AccessTimeDT that could be useful. From this I can infer that Created is somehow related to AccessTimeDT. But how and why is the real question.

An author of a PowerShell module can create a xml file that tells PowerShell how to display data in the console. If we go and look at the formatting file in the NetApp toolkit, we find that Created is mapped to the AccessDT property for SnapMirror objects.


So what’s this mean for you as a person using PowerShell. If Sorting or grouping by a property is not working, make sure that property is real. You can use get-member or go hacking through the format.ps1xml file for that particular module.

What does this mean for PowerShell Module authors? I would say be very careful of how you present data to end users. My humble suggestion is to use types.ps1xml file and create script properties and have those properties exposed to end users using the format file. This way, we can sort, group, and filter by the properties we expect to be there.

Comments are closed