It has been in the making for more than a year and today the DevFarm Team announces the GA of their PowerWF Studio product.
For those of you that haven’t played with the Release Candidate, PowerWF Studio combines PowerShell and Windows Workflow Foundation in a sleek GUI.
It allows you to drag-and-drop any “activity” from the Toolbox onto the IDE’s Workflow canvas. No more looking through endless lines of PowerShell code, your script is available as a nice graphical workflow drawing.
But PowerWF Studio has much more to offer.
There was an interesting question in the PowerCLI Community on how to use the -RunAsync parameter. The user wanted to create a number of new guests and start each guest once the creation was complete. This can be done rather easily by using a New-VM cmdlet and piping the result to the Start-VM cmdlet.
Only problem was, the creation of the new guests was done in Async mode.
That’s where the Get-Task cmdlet and the use of a hash table come in handy.
You should know by now that alarms are a powerful tool to help you manage and monitor your vSphere environment. But in my opinion there is a basic operation missing.
There is no easy way to move an alarms from one entity to another entity. No drag-and-drop in the vSphere Client, no Move-Alarm cmdlet in PowerCLI.
A practical example, you have developed this fantastic new alarm and for testing purposes you had defined it on a single virtual machine. Now the tests are done and your alarm is ready for production. But there is apparently no easy way to move your new alarm to the root of your vSphere environment.
A couple of weeks ago Charu Chaubal published his draft vSphere 4.0 Security Hardening Guides in the Security & vShield Zones community. If you haven’t read them yet, you definitely have to put them on your To-do list.
A vSphere administrator often considers security as a necessary evil that he has to take care of at a point in time, preferably a few days before an audit is going to take place
Charu’s Guides can make this exercise a lot easier. And if we add to those guides some scripts to automate the hardening process, the vSphere administrator has no more excuses to tackle security on a regular basis (like it should be !).
An interesting question was raised in the PowerCLI community by Jörn. He wanted to find all the guests that had been powered off for more than a week.
Before you tackle such a request, it is useful to sit down and think a bit about the solution. If you are going to search through all the events in your vCenter to answer this question, you could be in for a surprise. Depending on the size and activity of your vSphere environment this straight-forward solution could run for hours !
But there is a better way of doing this.
In a comment on one of the previous dvSwitch posts, see dvSwitch scripting – Part 2 – dvPortgroup, Gert asked how he could check if a portgroup with a specific VLAN Id existed on a distributed virtual switch.
Since a function that allows you to search for a portgroup that meets specific requirements can be quite useful, I decided to create a new function to do just that.
Additionally I will show in this post how you can change the VLAN Id of a specific portgroup.