Google Toolbar Beta for Enterprise includes a Microsoft Windows Installer package that makes organization-wide distribution a snap.
Cool. So, I downloaded the .zip file and popped open the GoogleToolbarInstaller.msi and what should I find? Yep, you guessed it. The GoogleToolbarInstaller.msi file was created by the WiX toolset. Woohoo! How cool is that? Google uses the WiX toolset.
After calming down, I decided to look around and see how well the MSI was actually put together. Then my excitement dropped. The GoogleToolbarInstaller MSI package is a total fake. Their MSI file is nothing more than a wrapper around the old GoogleToolbarInstaller.exe. The Google Toolbar Beta for Enterprise does not use the Windows Installer to actually install the files (I'm not sure what install technology they are using). That means the Google Toolbar Beta for Enterprise does not get all of the transaction guarantees and other administrative/repair features that a true Windows Installer package would provide.
If you are an administrator looking to deploy this package, don't be surprised when you find that this MSI package doesn't behave exactly like real Windows Installer packages. The Google Toolbar Beta for Enterprise MSI package is really just a "Trojan horse" carrying their custom installation system. I really wish Google had used the Windows Installer technology more appropriately.
At the time I commented:
Rob- I'm usually nodding my head with you, but come on, Microsoft did the EXACT same thing with the Windows Media Player 9 Administratios Deployment kit that we talked about a couple blogs ago. Perhaps if AD GPO wasn't so restrictive in only understanding MSI people wouldn't feel the need to wrap legacy installer in a pseudo-msi package.
Well let's get back to the recent IEAK 7 release. Yes, you guessed it: Microsoft has once again done the exact same thing as Google. If you run the IEAK 7 wizard and build the MSI you'll notice that Microsoft ignored their very own setup expert and took a play straight out out of the Google playbook. They made a fake MSI package that doesn't publish the package and instead goes out of process to Setup.Exe to get the job done. All of this to get around the limitations of GPO without actually making the investment in MSI.
And of course the funniest thing is they used Windows Installer XML v2.0.3620.0 (candle/light) to get the job done. Just like Google.
For the record, I'm not against Adapter/Encapsulation Patterns. MSI is what it is and GPO is what it is. Enterprises have needs and I can understand how a product team would make one choice over another.
ReplyDeleteI'm just a little bit tired of listening to all of these best practices lectures from members of the Cult-Of-Microsoft and then see one of their own go and do their own thing.
In this case I'm sure the defense will be the `Microsoft is a big company` argument. Yet if someone outside of the firewall does it we hear how horrible they are. Still worse is if they were to use InstallShield to do it because then we would hear `InstallSUCK` or something similar when Macrovision didn't even have anything to do with it.
I am in total agreement with you here Chris. My first reaction is complete frustration as I have to jump through MSI hoops to produce a software package that DOES conform to MSI standards while Microsoft plays games with the standards. I don't know how many hours I have spent trying to resolve ICE warnings and errors in an effort to produce the best package possible.
ReplyDeleteLike you I am not against wrappers and such, but to be the one who writes the rules, and yet you cannot conform to your own ruleset is what gets me.
In my former position we called this 'ghetto repackaging'.
ReplyDelete;-)