HOWTO: Show absolutely All Nested Properties of a PowerShell Object in a Treeview

If you’ve used PowerShell for length of time at all, I promise this HOWTO is going to be revelation and will fundamentally change how you use PowerShell.

PowerShell is full of objects.  All of those objects have properties.  Many of those properties have their own sub properties.  Those child properties can then still have even more properties underneath them. While it is fantastic that we have all of this data at our fingertips, it is often exceptionally difficult to know what’s available.  It’s a case of not knowing what you’re missing because you didn’t know about it in the first place.

To combat this, PowerShell includes an excellent command called Get-Member which shows what properties are available on an object.  The problem is, it doesn’t show sub properties and nor does it show the values of those properties. This combination makes searching for available data both frustrating and annoying.  I’m pleased to report I now have a solution for this problem!

I recently found myself having to learn about “JSON” for work.  In a nutshell, JSON is an alternative to XML and is a text based representation of data.  To work with JSON, PowerShell includes a cmdlet called ConvertTo-JSON. By complete accident I discovered that this cmdlet has a very interesting capability.  If you pipe any object into it, it will spit out absolutely everything PowerShell knows about that object, nested sub properties and all.

I then did some research and discovered a free standalone tool (no installation required) called jsonview.exe from CodePlex.  This tool provides a graphical tree view of JSON data.  Can you see where this is going? Wouldn’t it be amazing if you had a nice graphical interface to view all of the data inside of an object, regardless of how far down it was nested?

Consider the following example.  We have a cmdlet called Send-Email that isn’t working properly.  When we try to use it, all we get is an error “Unable to connect to the remote server”.

The question is?  What server?  And why can’t it connect to it?

Now you may be aware that PowerShell automatically writes all errors to a variable called $Error.  If we view that without any additional parameters, we get the same error message displayed to us earlier:

You may be aware that you can use the Get-Member cmdlet to view the specific properties available which is where we’ll find all of the actual useful details.  But as you can see, it can be difficult to understand:

Now only that, but this is only showing the first level of properties.  Each one of those properties may have sub properties underneath them.  Sorting through that is a giant pain.  Thankfully you’ll never have to do it again.

Instead, use the new cmdlet I am providing to you today called “Show-AllProperties”

Wait, it doesn’t appear to have done anything.  Oh but it has!  A new GUI Window has opened with a wonderful tree view showing all of the properties and their values!

Look at all of this detail!

From this we know that the Send-Mail command actually calls a command called Send-MailMessage on line 5 of the script.  It tries to connect with a username svcmail and a password of Sup3rS3cr3t (in plain text!) and is trying to connect to mail.microsoft.com on port 26.  That gives us more than enough information to troubleshoot the connection!

But this command is useful for so much more.  Any time you need to view what’s in an object, you can use this cmdlet!  Here is another example.  If you’ve spent any time with PowerShell and the Event Viewer you know that if you view an Event in the built in Windows Event Viewer, you have an “XML” tab that occasionally gives you additional valuable troubleshooting detail.  Unfortunately, there is no easy way of displaying this data in PowerShell – until now.

I have written a PowerShell command called Get-EventLogData that returns not only all of the regular event details but also all of the “EventData” (aka XML) details.  Let’s view these results in a GUI, shall we?

Get-EventLogData –LogName Security–EventID 5152 | sap

As you can see above, the default properties that are returned by the Get-EventLog cmdlet do not include the EventData which is often where all the useful information lies.  However my Get-EventLogData includes this data.  Then by passing it to the Show-AllProperties cmdlet makes it trivially easy to identify.

This Show-AllProperties function has fundamentally changed how I use PowerShell and has made it far more enjoyable and productive to use.  If you’d like this for yourself, here is what you need to do:

1) Download JsonView from https://jsonviewer.codeplex.com/

2) Copy and paste the following script into your default Powershell profile at “C:\windows\system32\WindowsPowerShell\v1.0\profile.ps1” (you may need to create the file)

3) Update the $JSONViewPath to the location of the application

# Displays all properties and sub properties of an object in a GUI
# JSON; Home; Properties; Object; GUI
# Requires -version 3
# JSONViewer Download Available At: https://jsonviewer.codeplex.com/

Function Show-AllProperties
{
    param
    (
        [Parameter(ValueFromPipeline=$true)] $InputObject,
        [Parameter(ValueFromPipeline=$false)]
        [ValidateRange(1,9)]
        [int]$Depth=4
    )

    # This specifies how many layers deep the JSON will go.  It seems that anything more than 5 can result in a signifigant performance penalty
    $JSONViewPath = "c:\bin\jsonview\jsonview.exe"

    if(!(Test-Path $JSONViewPath)) { Write-Error "$JSONViewPath is not found.  This is required."; break}

    # Need to use reserved PowerShell variable $input to bypass the "one object at a time" default processing of pipelined input
    $InputObject = $input
    $Date = Get-Date

    # Set the file path to the temporary file we'll save the exported JSON to so it can be loaded into jsonview.exe
    # We will constantly overwrite/reuse this file since we have no way of safely deleting it without knowing for sure it's not being used by the jsonview.exe
    $TempFilePath = $env:TEMP+"\PSjsonviewtemp.json"

    # Create a status bar so if the conversion takes a long time to run, the user has some kind of visual feedback it's still running  
    $Params = @{
            "Activity" = "[$Date] Converting object to JSON.  This process may take several minutes to complete." 
            "Status" = "(Note: Increasing the -depth paramater beyond 4 may result in substantially longer processing times)"
            "Id" = 1
        }
    
    Write-Progress @Params

    # Convert the object to JSON.  Need to use the Compress option to get around a bug when processing some Powershell Objects
    try { $JSON = $InputObject | ConvertTo-Json -Compress -Depth $Depth }
    catch { Write-Warning "This object cannot be converted to JSON. Try selecting a sub property and trying again.`n$_"; break }
    Write-Progress "Completed converting the object to JSON..." -id 1 -Completed 
    
    # Write the JSON to the temporary file and then open it with jsonview.exe
    $JSON | Out-File $TempFilePath -Force

    # Call the external JSON view application and pass it the file to display
    Start-Process -FilePath $JSONViewPath -ArgumentList $TempFilePath
}

# Set a three letter alias to make it faster to run
Set-Alias sap Show-AllProperties