Monthly Archives: November 2009

Submitting VMware Workstation 7 to install

Roughly a month ago, VMware released a new major version of its Workstation (and Fusion) software (i.e. 7.0 (and 3.0, respectively)). So, it seemed like a good time to upgrade from version 6.5.3. Past protocol suggested the following approach: uninstall old, reboot, and install new. Unfortunately, and unexpectedly, this approach failed to result in an up-to-date Workstation installation.

Shortly after launching VMware-workstation-full-7.0.0-203739.exe, the installer presented:

(Version: )

Clicking the Uninstall button resulted in a second cryptic dialog being presented:

The MSI '' failed.

“The MSI ” failed.” seems to be a fairly unique phrase, especially when combined with VMware, etc.; so, I Googled to see what others had encountered. Suffice it to say that I found nothing that ultimately solved my installation issue–although I was able to reclaim over 9 GB of free space by running CCleaner, thanks to one post.

So, I confirmed that my host operating system is supported by VMware Workstation 7.0. I further confirmed that my Windows file system and registry were both clean of VMware-related content–rebooting after this confirmation. Nada.

Sometimes I’ve seen installers insist on being the party to uninstall older software. Since I’d uninstalled VMware Workstation 6.5.3 myself, I tried to reinstall the older software, reboot my host OS, and retry installing VMware Workstation 7.0:

6.5.3 install-uninstall

In hindsight, I could have seen that this wouldn’t resolve anything, but I clicked Uninstall as before…only to end up with the failed mystery MSI dialog once more.

So, I tracked down where VMware Workstation 7 wrote its installation logs: %TEMP%\vmware_*.log. I re-ran the installer to arrive back at the top state above, allowing me to recognize the associated log file and examine its state at the point of presenting the uninstall panel:

20091128194313:INFO    CGetMSIStateOperation::Execute: Examining the system for VMware Workstation.msi
20091128194313:INFO    CGetMSIStateOperation::Execute: MSI Data ProductCode: {A3FF5CB2-FB35-4658-8751-9EDE1D65B3AA}, PackageCode: {CDA82EA5-329A-428D-8ED3-9857244767DE}, UpgradeCode: {14F539F3-C4A4-4597-A29D-8C1D753ACC93} , Version:
20091128194313:ERROR** CGetMSIStateOperation::GetSysVersionString: ::MsiGetProductInfo failed to retrieve the version string for {{98D1A713-438C-4A23-8AB6-41B37C4A2D47}} due to error: 1605
20091128194313:INFO    CGetMSIStateOperation::Execute: Installed MSI Data ProductCode: {98D1A713-438C-4A23-8AB6-41B37C4A2D47}, Version: 
20091128194313:INFO    CGetMSIStateOperation::Execute: Default MSI Action: upgrade, Details: cross product
20091128194313:INFO    CBootstrapCmd::RunOperation: Operation 'GetMSIState' completed successfully with return code 65539
20091128194313:INFO    upgrade
20091128194313:INFO    cross product
20091128194313:INFO    CGetMSIStateOperation::Execute: Examining the system for 
20091128194313:INFO    CGetMSIStateOperation::Execute: MSI Data ProductCode: {233A935E-6132-48B2-840F-37C9D32555D5}, PackageCode: {46F73961-902A-4A20-BB36-5060DC6ACB2C}, UpgradeCode: {2A0F937B-3E75-47D8-9306-14D45CC0F756} , Version:
20091128194313:INFO    CGetMSIStateOperation::Execute: Default MSI Action: install, Details: 
20091128194313:INFO    CBootstrapCmd::RunOperation: Operation 'GetMSIState' completed successfully with return code 65539
20091128194313:INFO    install
20091128194313:INFO    SaveSetting: Wrote setting 'action', value 'upgrade'
20091128194313:INFO    {98D1A713-438C-4A23-8AB6-41B37C4A2D47}
20091128194313:INFO    SaveSetting: Wrote setting '{98D1A713-438C-4A23-8AB6-41B37C4A2D47}', value ';'
20091128194313:INFO    {98D1A713-438C-4A23-8AB6-41B37C4A2D47}

Right away, I could see that the installer was recognizing an unexpected upgrade state rather than the expected “fresh” install state. Fortunately, the log also captured more details behind this divergent recognition: “failed to retrieve the version string for {{98D1A713-438C-4A23-8AB6-41B37C4A2D47}} due to error: 1605.” First of all, this log statement is a bit of an oxymoron, since Windows error code 1605 (ERROR_UNKNOWN_PRODUCT) means “This action is only valid for products that are currently installed.” That is, if the product isn’t installed, then shouldn’t the current installer be “happy?” Second, this error led to the sparse dialogs (i.e. ” (Version: )” and “The MSI ”failed.”).

1605 redux

Again in hindsight, I could have Googled the suspect GUID to determine its relationship with VMware Workstation 5.5. However, I went back to my Windows Registry to perform additional forensics first. The first RegDB reference I found is associated with Windows’ ARP Cache, which has to do with Windows’ TCP/IP stack (i.e. needs to be left intact). I did find another RegDB key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders, with a value named C:\WINDOWS\Installer\{98D1A713-438C-4A23-8AB6-41B37C4A2D47}\, which I removed. Nevertheless, after rebooting, I was still unable to install VMware Workstation 7.0

So, I thought that if my 6.5.3-based hack appeared to have some merit, perhaps a similar, 5.5-based hack could, too. First I had to download the 5.5.9 installer and unearth my version 5.5 license key. With these in hand, I installed VMware Workstation 5.5.9 and then rebooted my host OS as directed.

Following reboot, I re-ran the VMware Workstation 7.0 installer, yet again:

5.5.9 install-uninstall

This time, after clicking Uninstall, I was eventually presented with the ability to proceed with installing the new software. After choosing to reboot at the end of the installation process and rebooting, I’m able to run VMware Workstation 7 as I originally expected.

Hopefully this knowledge sharing will help you to avoid the wasted time and energy I experienced. At least that’s my purpose in posting. Cheers…

PDF from Confluence

Atlassian’s Confluence software offers a decent collaboration canvas in the form of an enterprise wiki. For example, Confluence can support the practice of “living and active” specifications (instead of, for example, obsolete-once-authored-in-Word specs). Often, though, it’s good to have a more self-contained snapshot in hand (e.g. increase traceability from one review-based state to another, support Customer audits, etc.). Fortunately, Confluence supports export to PDF.

Given its rather prominent display by default in the upper right hand corner of every wiki page, most Confluence users are aware of how to export a single page as a PDF document:

Export page as PDF

However, Confluence also supports exporting a set of wiki pages (up to an entire wiki space) as a single PDF document; yet, this feature is less well known. Here is the step-by-step process to leverage this feature (e.g. to export a multi-page, wiki-based spec as a single PDF document):

  1. Click the browse space link (on any page in the page set of interest):
    Browse Space
  2. Click the advanced link:
  3. Click the export space link:
    Export Space
  4. Configure your export as follows (recommended):
    Configure Export
  5. After setting PDF output, including comments, and clearing all selected pages, select the particular pages that make up the page set of interest.
  6. Click the export button at the bottom of this export space page.

Happy Thanksgiving!

More complete PDC09 downloader-renamer

First of all, I want to thank Mike Swanson (@anyware) for his original work (e.g. for MIX09 and also for PDC09). Good stuff.

That being said, I noticed that there were posted sessions missing–six altogether–from the 11/19/2009-dated batch files here; so, I thought I’d post my “fix”:

It may be worth noting that my rename “style” includes session codes (e.g. SVC29), making it easier (for me anyway) to distinguish one overall theme from another.

For your convenience, here are copy of the original instructions for PDC09 use:

If you’d like to download all of the keynote and session content, download a recent build of cURL (~250K), and extract it to your folder-of-choice. Then, download (1.49KB) and extract the PDC09Downloader.bat file to the same folder. From a command prompt, start PDC09Downloader by passing it one of the following parameters: WMVHIGH, WMV, MP4, PPTX. Then wait. For files that aren’t available, cURL will download a file that is around 221 bytes in size (if you change the extension to .htm and open it, you’ll see that the file is simply an HTML “not found” error page).

To rename the files, first, download the PDC09 Renamer batch file (4.52KB). Then, extract the PDC09Renamer.bat file to the folder that contains your downloaded files, and from a command prompt, type PDC09Renamer WMV to rename all of the .WMV files to the full session title. By changing the parameter, you can also rename your PPTX and MP4 files.

Update at 6pm Pacific: It looks like both of my scripts, above, are live on, too.

Suggestions to improve conference scheduling

So, I finally was able to complete my PDC sessions scheduling. It was a bit more “involved” then I expected, and I have a few suggestions for, in this case, Microsoft as they prepare for future conferences:

  • Enable Outlook (ICS-based) scheduling sooner
  • Include the online session home page as a link in the ICS file
  • Default to “no alert” in ICS files (e.g. avoid creating noise from multiple sessions of interest all vying for my attention on my smart phone)
  • Add a map link to help guide attendees to where sessions are being held (i.e. nowadays location-aware service is expected, IMHO; so, allow users to opt-in where correlating to present location (device GPS coordinates) is concerned)
  • Promote session hashtags (e.g. help guide the use of Twitter et al by going beyond just #PDC09)
  • When you post a location and date/time, and you change it, indicate the change more prominently (e.g. maintain version history)

Next year, I’d love to say something like, “I’m a PC. PDC10 scheduling…was my idea.” :-)