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. 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. To use it all I have to do is select it. 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. I can specify the view name with Format-Table, since I defined a table control. 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. 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.
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.