Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
PowerShell

A Quick PowerShell Tutorial: Adding a Hyper-V Custom View

Over the last few articles, I’ve been demonstrating how to extend the Hyper-V virtual machine object to add some testing and validation properties.

In the most recent article, I showed you how to use Update-TypeData. One thing you can do to make your life easier is to define a set of properties that you can reference via a single name. If you look at help for Update-TypeData, it seems an expression like this should work:

​
But with PowerShell 4.0 version that I'm using, this fails.

Error adding a property set (Image Credit: Jeff Hicks)
Error adding a property set (Image Credit: Jeff Hicks)
I suspect this is a bug. If I create a proxy version of Update-TypeData, I can see what the cmdlet is doing.
​
I'm not sure why the validateSet test is missing PropertySet or even why it is needed since the MemberType parameter is already properly typed. But I can't change this, so I'll resort to using a ps1xml file.
​
I'm using this file assuming that I've already run the Update-TypeData commands to define the additional properties. Otherwise, I need to define them in the XML file as well.
​
Assuming everything has been defined, I can go ahead and add my ps1xml file to my session.
​
Now I have a new property.

Viewing the new property set (Image Credit: Jeff Hicks)
Viewing the new property set (Image Credit: Jeff Hicks)
To use it all I have to do is select it.
Using the new property set (Image Credit: Jeff Hicks)
Using the new property set (Image Credit: Jeff Hicks)
Another approach is to define a custom view, which can take a bit of trial and error to get just right. For the sake of demonstration, I want a custom table view that gives me the virtual machine name, state, status and my new TestVHD property. To define a custom format view, use an xml file like this:

<?xml version="1.0" encoding="utf-8" ?>
<Configuration>
    <ViewDefinitions>
        <View>
            <Name>MyTest</Name>
            <ViewSelectedBy>
                <TypeName>microsoft.hyperv.powershell.virtualmachine</TypeName>
            </ViewSelectedBy>
            <TableControl>
            <!-- ################ TABLE DEFINITIONS ################ -->
            <TableHeaders>
                <TableColumnHeader>
                    <Label>Name</Label>
                </TableColumnHeader>
                <TableColumnHeader>
                    <Label>State</Label>
                </TableColumnHeader>
                <TableColumnHeader>
                    <Label>Status</Label>
                </TableColumnHeader>
                <TableColumnHeader>
                    <Label>TestVHD</Label>
                </TableColumnHeader>
            </TableHeaders>
                <TableRowEntries>
                    <TableRowEntry>
                        <TableColumnItems>
                            <TableColumnItem>
                                <PropertyName>VMName</PropertyName>
                            </TableColumnItem>
                            <TableColumnItem>
                                <PropertyName>State</PropertyName>
                            </TableColumnItem>
                            <TableColumnItem>
                                <PropertyName>Status</PropertyName>
                            </TableColumnItem>
                            <TableColumnItem>
                                <PropertyName>TestVHD</PropertyName>
                            </TableColumnItem>
                            </TableColumnItems>
                      </TableRowEntry>
                </TableRowEntries>
            </TableControl>
     </View>
  </ViewDefinitions>
</Configuration>

And unlike the rest of PowerShell, XML tags are case-sensitive. With this file, however, I can add it to my session.

​
I can use Get-FormatData to verify.

Listing format views (Image Credit: Jeff Hicks)
Listing format views (Image Credit: Jeff Hicks)
I can specify the view name with Format-Table, since I defined a table control.
Using the custom format view (Image Credit: Jeff Hicks)
Using the custom format view (Image Credit: Jeff Hicks)
When I defined the table, I didn't specify any column widths or alignment so PowerShell makes its best guess. I could use the –Autosize parameter. Or I can define column widths and alignments in my ps1xml file.
​
I can re-update the format data and try my command again.

A custom view with defined column widths (Image Credit: Jeff Hicks)
A custom view with defined column widths (Image Credit: Jeff Hicks)
As you can see there are a number of ways to extend what you see when you run a command in PowerShell. Whether you update type or format data, this ultimately depends on how you intend to use the information. Remember that if you don't run the update commands each time you start PowerShell, then you won't get your new views. Before we go, let me point out that you could technically modify the versions of the ps1xml files that ship with PowerShell. But don't. For one, the files are digitally signed, which means you won't be able to re-sign them with Microsoft's code signing certificate. And there's no guarantee that the files won't be overwritten or updated in the future. If you need to use .ps1xml files, create your own. This is definitely an advanced topic, so don't feel you have to do this. And if you get lost, post a comment, and I'll see what I can do to get you going in the right direction.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (0)

Leave a Reply

Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: