Home > Blogs > VMware PowerCLI Blog > Author Archives: Antonio Dias

Author Archives: Antonio Dias

Go get PowerGUI

If you use PowerShell at all and you haven’t at least tried out PowerGUI, you’re missing out. It’s a great product. Think of it as an administrator’s Swiss Army knife. And now think of being able to easily snap new tools into that knife, have them work with each other, and customize them to your liking. Fantastic.

The most recent release raises the bar even higher. Sometime back, they added a very nice standalone (and integrated) script editor. Now that editor includes a debugger. Set breakpoints. Inspect variables. Step through the script. And it’s free. If you do any PowerShell scripting at all and you haven’t tried this out, go get it now.

Antonio Dias

FullArmor Workflow Studio supporting VMware’s PowerShell interface

Beta 1 of FullArmor Workflow Studio 1.1 includes support for our PowerShell cmdlets. Workflow Studio lets you combine PowerShell automation with the power of workflows. Those of you who saw FullArmor’s Danny Kim demo the integration during our VMworld talk know just how powerful this is. Sorry, you can’t actually see the demo in the PPT but you can see Danny demo a different application of the same product. FullArmor’s done a nice job – PowerShell and workflow really is like combining chocolate and peanut butter. It’s compelling enough that even before this beta of version 1.1 with specific support for VMware integration, some users were figuring it out on their own.

Note that you need to get an early access copy of our cmdlets before you can use them with Workflow Studio 1.1.

Antonio Dias

PowerShell GUIs

The PowerShell community has quite a few UI-driven or UI-friendly tools that work nicely with custom scripts. Examples include PowerGUI, PowerGadgets and Workflow Studio.

In that spirit, I sometimes want an ad hoc UI for some of my management activities. The attached script lets me take data and wrap it in a super-simple UI. At the top, I have a multi-column listview showing the data. At the bottom, I can have buttons with scriptblocks attached to them to act on the selected rows. Simple stuff but useful. And quite general-purpose.

Here are a couple of usage examples. I showed a variation on this during my VMworld talk this year:

out-form -title "Disconnect Devices From…"
              -data (get-vm) -columnNames ("VM", "Floppy Count", "CD Count")

              -columnProperties ("Name", "FloppyDrives.Count", "CDDrives.Count")
              -actions @{"Disconnect" = {$_ | get-cddrive | set-cddrive -nomedia

                               -confirm:$false; $_ | get-floppydrive | set-floppydrive -nomedia

This gives me a list of VMs along with the number of floppy and CD drives for each. I select one or more, push the "Disconnect" button, and the floppy and CD devices are disconnected. With a little PowerShell command-line (and a little bit of scripting backing it), we have a custom application. Now take that command, drop it in a .ps1 file alongside the out-form script and we have a packaged, redistributable application. Cool. :)

Unless you've got an early access copy of our PowerShell cmdlets, you can't try the example above yet. But here's an example you can try:

out-form -title "Services" -data (get-service)
              -columnNames ("Name", "Status")
              -columnProperties ("DisplayName", "Status")

              -actions @{"Start" = {$_.start()}; "Stop" = {$_.stop()};}


This obviously isn’t the most interesting use case. After all, Windows already has a service manager. The interesting uses will come from things you do in your environment. For me, that’s virtualization management, thus the example above. If you think this might be useful, download the script and try wrapping a UI around something you manage. Use it yourself. Hand your newly-created app to a coworker. If you find this useful, I’d love to hear about how you use or improve it.

Here’s the script: 

Download out-form.ps1

Hopefully the parameters are self-explanatory. Here’s a quick summary of each just in case:

1. title – title string to display

2. data – the objects providing the information to render

3. columnProperties – the properties of the data to display, one per column

4. columnNames – name to give each column. If not specified, the property names will be used (columnProperties). If specified, columnNames must be the same size as columnProperties

5. actions – an associative array mapping names to scriptblocks. Each name string will have its own button with the accompanying scriptblock linked to its click event. If not specified, no buttons will appear.

Antonio Dias

PowerShell Namespaces (RE: The trouble with the tribbles)

Poshoholic raises the question of PowerShell namespaces.

I’ve been thinking about this, too. I think it’s important for usability to keep the naming uncluttered, which is why you’ll find Get-VM as opposed to Get-VMWVM or some such in the VMworld presentation I posted last week.

That said, the potential for naming collisions isn’t something to simply dismiss and also plays into usability. I’ve been thinking along the same namespace lines as Kirk. It turns out that we already have some amount of namespace support in PowerShell as long as we’re talking about snapins. Based on that, here’s a strawman of something that might work today:

Now imagine that each snapin defines a namespace mapping variable. To make it concrete, let’s imagine a snapin named foo that wants to use the names get-host and get-process itself. So that snapin defines its namespace mapping like this:


With this, we can achieve the affect of a "using namespace" construct like this:

So we see based on the errors that our invocations were in the correct "namespace" as we’re trying to invoke these cmdlets from the foo snapin. And now to stop using that namespace:

This could be made much more like a "using namespace" construct as in Kirk’s post by passing the commands to be executed as a script block and resetting the namespace after execution.

Aside from that, this is obviously incomplete, not taking into account aliases instead of or in addition to cmdlets, etc. And it doesn’t work at all for functions which don’t have a snapin to distinguish them (any thoughts on alternatives?). But maybe it’s a reasonable strawman for dealing with the problem using existing mechanisms. What do you think? Better suggestions?

Antonio Dias

I used Get-Process and Get-Host as examples because we’re all familiar with them. This obviously isn’t an encouragement to stomp on existing names, just a thought exercise around alternatives to prefixing the nouns.


We noticed the Documentation One Liner topic over on the Windows PowerShell group’s blog. We don’t have a one-liner but we do have a little script that Angel, one of the team members, wrote to tackle the same problem. We chose to map the help into HTML in a javadoc-ish format. Below, you can see a little sample of applying it to one of the core cmdlets. Click on the image to see full size.

Here are the script and stylesheet: Download doc-style.css Download New-HtmlHelp.ps1

Usage: New-HtmlHelp [commands for which to generate help] [target directory] [title]

Example: New-HtmlHelp (get-command -pssnapin microsoft.powershell.management) ./cmdletHelp "Management Cmdlets"

Then open ./cmdletHelp/index.html in a browser. To complete it, create a web page that describes the package in the ./cmdletHelp/right-frame.html file.

This script is a quick-and-dirty hack and makes some assumptions that are valid for our environment. In other words: It works for us. YMMV. Note: the script as attached isn’t signed. Please read it over and validate it for yourself. If you add any improvements, we’d certainly appreciate a link to them. 🙂


“Hello World” | out-host

PowerShell provides a great automation platform for Windows. At VMware, we’ve been exploring PowerShell interfaces for VMware Infrastructure and VMworld gave us a good opportunity to provide a sneak peek at some of the forms those interfaces could take. You can view the slides from that session here: Download VMworld2007_IO30.pdf

In case you don’t feel like browsing through the slides, here’s a quick sample:

Get-VM qa* | Get-NetworkAdapter | where { $_.NetworkName -eq "red" } | Set-NetworkAdapter -NetworkName "blue"

This little example shows off some of the leverage and simplicity a PowerShell interface could provide. Hopefully, it’s self-explanatory but I’ll translate it anyway: For all virtual machines with names that start with "qa," change any network adapters they may have that are attached to the "red" network to instead be attached to the "blue" network. This is pretty typical PowerShell syntax, composing a few simple commands with a little bit of PowerShell language scripting to accomplish a task. And it’s indicative of the kind of simplicity we’re trying to achieve.

On the PowerShell development team, we’re very excited about this work and we’re interested in feedback from any of you who may have comments and in particular from anyone who attended the VMworld session on this topic (IO30).

To keep up with ongoing work, please subscribe to one of our blog feeds: