A letter of apology to the VMware PowerPack community

UPDATE 10-JAN-11: I just published a beta version of the VMware vSphere PowerPack with PowerCLI 4.1 or later support.  You can read more about the beta and how to install it here.

I have heard via email and Twitter that quite a number of you were disappointed when you upgraded PowerGUI® Pro or PowerGUI® to version 2.3 only to discover that the VMware PowerPack does not work with PowerCLI 4.1.1.  Instead the VMware PowerPack today has a firm requirement for PowerCLI 4.0 U1.  I apologize for the disappointment that you have experienced with this and I felt I should take a minute to talk about the situation we are facing and let you know what our plans are going forward.

When VMware released version 4.1 of the PowerCLI, they completely changed the object model that they were using in earlier releases.  This change came with many undesirable and unwelcome side effects, effectively breaking backwards compatibility with many scripts that are built on top of the PowerCLI cmdlets, and the VMware PowerPack was no exception to the effects of those breaking changes.  We have been working with VMware to ensure that they are aware of the ramifications of changes like this, but it is an uphill battle because while they have said that they were committed to providing backwards compatibility for the old type names back into the PowerCLI in 4.1.1, our testing shows that this backward compatibility is not there like it should be.  Further, you may now start to see many warnings from scripts that previously ran without warning or errors because VMware is planning to deprecate many of the properties that were there in previous versions.  These warnings are a concern because they show that VMware is continuing to make changes that will break older scripts going forward without much communication at this point about why they are making those changes.  I am working with many other MVPs and vExperts in the community to give feedback about why this is really not a good idea, but unfortunately we haven’t had any knowledge about the changes in these releases any earlier than you have, so we haven’t been in a position to work closely with VMware to help prevent complications such as the ones introduced in the 4.1 and 4.1.1 releases.

Now we are faced with a decision about what should be done going forward.  I cannot simply do an upgrade for the VMware PowerPack to require 4.1.1 because existing customers who are using PowerCLI 4.0 U1 and who may not be able to upgrade to 4.1.1 right away due to internal policies will have a broken PowerPack on their hands if their PowerPack is auto-updated.  I can however create a separate version of the VMware PowerPack that does not auto-update to support users who have upgraded to PowerCLI 4.1.1 and who want to use the VMware PowerPack.  This will take some time though because the changes are not straightforward, and if you want a version of the PowerPack that has been put through the property quality control channels we will have to retest everything to make sure it works with the new version, which is no small feat for a PowerPack of this size.  I may also be able to create a version that works with both PowerCLI 4.0 U1 and PowerCLI 4.1.1, however I’m not very optimistic about that at this time.  There is also a VMware Community PowerPack available that I do not manage, and it suffers the same challenges.  All of this adds up to a lot of things to consider and a lot more work than should be required when looking at the right way to upgrade this PowerPack (and those considerations apply the VMware Community PowerPack as well as I just mentioned since it is partially dependent on the VMware PowerPack as well as the PowerCLI).

What will most likely happen is that we will create a version of the VMware PowerPack that requires PowerCLI 4.1.1 or later, and that we will try to support two different versions of the PowerPack for a while until we eventually deprecate the older version.  That is not what I would like to do, but my hand is being forced here so that is the only realistic option I see in front of me.  I may be able to create a preliminary beta version of that PowerPack fairly quickly, however it will not have been put through a full test cycle and it will not address the warnings that appear from properties that are being deprecated – that will require much more time and effort.  I will of course notify you when this beta version is available.  Our plan is obviously to support every new release of snapins and modules that come out that are used with our PowerPacks, ideally the moment that those releases become publically available, but usually providing that support is much easier than this so please bear with us as we work through the messy situation we’re in right now.

In the meantime I would recommend that you continue to use PowerCLI 4.0 U1 with the VMware PowerPack and the VMware Community PowerPack because it works very well and is something we can support today.  At the same time you can of course put version 4.1.1 of the PowerCLI in a separate VM so that you can work with both versions for a while — we are talking about a virtualization solution after all…

Thank you for your patience and continued support while we work through these challenges together.

Sincerely,

Kirk Munro