PowerCLI: Get every VM added to vCenter in the last 30 Days!

At seemingly random intervals I get requests from management to report every Virtual Machine that was added/removed in the last x days. This has traditionally been a manual process, and one that I loath.

While deploying a VM this morning I set up my normal tell me when your done one-liner…

As I was typing I wondered how long a task’s history was kept, and if I could query it via the SDK? Low and behold not only can I but it’s too easy!


PowerCLI Update VMware Tools without a reboot.

UPDATE:  This Functionality has been completely replaced with the Update-Tools cmdlet!

 UPDATE: 2009-7-31Recently several individuals have contacted me to report complications using my update-tools script. These issues center around my use, and dependency on WMI, and what appears to be vSphere 4 growing pains. Hopefully, the PowerCLI team can get this functionality built into the VUM cmdlets! Until then some assembly required!

There appears to be a bug in the VMwareToolsUpgrader.exe that will cause the system to reboot no matter what. This behavior is especially bothersome because the VI API simply calls that executable to perform any non-interactive upgrade.

This morning I was updating a smaller farm to 3.5u4. 15 minuets into the tools upgrade process I had enough… Enter PowerShell, I whipped up a quick script that will update All Windows VM’s to the latest version of VMware Tools.

Using this script I updated 50 Vm’s in 40min. There is alot of room for improvement here. I opted for the slow and steady pace, but larger environments could easily tune this to 100 at a time.


P.S. I started with Invoke-VMScript but only half of the vm’s had PowerShell installed, and I needed something that would hit them all.

PowerCLI SpeedBoost: Advanced functionality hidden within Get-View

Everyone knows how to use the Get-View cmdlet to retrieve the full managed object from a VI implementation (Impl) object, but did you know you can skip the Impl entirely? For instance have you ever needed the following?

If so you may want to try:

I’ve found the latter to be around 1200% faster!  Additionally, by selecting the properties of interest at run time  an additional performance boost can be obtained.  For example suppose you just wanted the Name of every ESX host in vCenter.

is 300% faster then the traditional

When you really need to optimize you VI Scripts just add some filters. For instance a 400% performance boost can be obtained by replacing,


but what if you need the Impl object?  It’s still 150% faster to convert back from the managed object that to retrieve then to get the impl in the first place.

Finally the grand pooh-bah of hidden potential… nested parameters within filters!  Say you want to locate all windows vm’s that have out of date tools.

traditionally we would approach this with something like,

Wait for it….

Over 800% faster and WAY less code! Although using get-view to it’s full potential can seriously increase your scripts performance I would leave it in your scripts.   The cmdlets provided in the PowerCLI are built around an interactive experience, the SDK is NOT!  While it may be faster to get all vm’s with get-view. The information returned from Get-VM is more useful when working from the cmdline.

Happy Scripting,

Bonus:  The function I was writing when I discovered this enhanced functionality… that’s right it was hidden in the help.

PowerShell: Enough with the text files already

A note to all PowerShell enthusiast, PowerShell has made it, it’s on the map… A significant portion of that success is due to the power of the pipeline. It’s ability to act as the glue for any task.  Unfortunately, the  skill level required to implement this glue depends on the echo-system.  As a PowerShell enthusiast you are a member of this echo-system, and any code you write either helps or hurts this effort.  In short when posting code to the world show them what well written code looks like!  Writing a function that is hard set to read a list of servers from a text file is NOT good code!   Personally I think this should throw an error.

Okay so I don’t approve of reading from a text file, so what’s my solution?  Remove that part of the logic entirely!  There are literally hundreds (perhaps thousands) of techniques that could be used to retrieve data for any given operation.  leave the getting to the end user.  If you must get the data then show a more practical approach.  Seriously,  it’s Windows PowerShell after all, that list of computers… chances are they’re all running windows… and there is a high probability that they belong to a domain! In your examples highlight extracting the data from AD.  After all would you really use static data in one of your scripts?

If you just can’t use the quest cmdlets use ADSI anything but a text file. Another one of my favorites is importing a list of IP Addresses.  I know it’s incredibly easy to create a list of IP Addresses in Excel, but is that really the lesson?  Hey PowerShell is the most important thing since the mouse, but if you need 254 concurrently numbered IP’s get Excel…  just add the code

Even better highlight why it’s so important to always emit object.  Show the benefit of such an approach.

I know, I know it’s all been done before.  I know we already had the why you should emit object discussion, and the foreach construct vs foreach-object cmdlet debate, etc… believe it or not the community has grown ten fold since those discussion’s where closed.  While I don’t want to constantly rehash this stuff… I’m asking that we don’t perpetuate the problem by using BAD techniques when we know better.

If you don’t have time just omit it.   Hide that part from the point of the post.  There is nothing wrong with

After all the do-something is the important part!  Just leave populating $servers to someone else… Why does this matter?  Simple, you never know what someone will learn from your code.  I read PowerShell post all the time, and I am constantly learning something new.  Just not always what the author intended.  The point of post x was to teach me how to use widget x from PowerShell.  Only I found this $? thing (what is that, and what does it do?)…   The next guy finds the same post via google because there trying to figure out the foreach construct, and bamn that get-content server.txt just became part of his repertoire.  Chances are he never even got to the part for widget x.  Moral of the story it’s better to omit part of the solution then to publish a poor answer.

Another penalty imposed by this hard coded methodology is it totally breaks the has-a model PowerShell was built around.  requiring a text file with a list of server names is the text book definition of the is-a model.  lamen terms by hard coding such a critical portion of your code… by importing data from a file you limit the flexibility of  your code.

It’s not all bad though, a couple years ago there where 10 guys.  Ten people who taught all of us how to use PowerShell.  Today there are 10 new PowerShell bloggers every day, and it appears that every team in Redmond (except SCCM) has PowerShell on it’s road map. I’m not trying to be the code police, but can we at least loose the text files?