What's worse...both ISO's seem to have the same build#, nice version management.That's because the version is the same, the only thing that's different is the ISO image, it was corrupted. so technically there isn't a fix to the build, its a fix to the ISO.
I think the point being made is two-fold:
1. To the people who downloaded and/or installed the original corrupted version, the bits have changed.
2. There are 2 different .ISOs out in the wild right now, each with different bits and MD5SUM hash values, but both with the same build number. Furthermore, it looks like the old December build is still available from this page:
http://www.vmware.com/download/vi/vi3_patches.html where it's still showing a December '07 date for the .ISO.
One of the fundamental best practices when working with ESX is to verify the SUM (or better yet MD5SUM) hash values of download or copied files to check the integrity of the files. I'm certain this step gets overlooked - I'm guilty of it myself from time to time. However, what I'd be interested to know is if the original .ISO that was put up on VMware's website matched the MD5SUM hash value that they published? Big shame if that step got fouled up because that is the source of the version control problem now in play. Now the updated version has been published and no doubt verified and the bits have changed, but the build number published on the website and within the .ISO stays the same.
To explore the dilemma a little further, there are people who have used the original December .ISO to update half of their ESX servers and they use the updated February .ISO to update the other half of their servers. Running an esxupdate on all of their servers will show a build number of 64607 but no build date so without supplementary documentation from the end user, it is not known which of those servers got the "good" .ISO and which ones got the "faulty" .ISO.
Jason Boche
VMware Communities User Moderator
