neverblog.net

Since I started creating MSI installers for Windows XP’s Windows Installer, there are a few bad habits that I’ve apparently let slip into my work, and Vista is quickly showing me when and how. The first one I found is that Vista’s Installer doesn’t let you mess around at will, as long as you’re installing from an account with administrative privileges, as XP basically does. Instead, you have to carefully consider what you’ll be doing with your install logic, then run any Custom Actions in a such a way as to pass Windows Installer’s new, far more robust, checks.

Stefan Krueger of installsite.org has written up a nice list of 7 reasons (PDF) why your installer might fail in Vista, even though it cooks right along in XP. I immediately noticed I was guilty of #2, and thanks to Stefan and the recent acquisition of InstallShield 2008, I was able to quickly modify my previously unusable installer (based on Alan’s successful Ghost AI version) for McAfee ePO and have it run on Vista for the first time.

It’s interesting also to note that #6 on the list explains that the built-in Administrator account in Vista is actually different from the other ‘administrator’ accounts created in the OS. That’s why right-clicking an executable and choosing ‘Run as Administrator’ can often have different results in Vista than simply running it through, say, your own administrative account.

Of course, it’s not always a good idea to go ahead and run your CA in the system context. I found out why pretty quickly when all of our systems started reporting in with the username ‘SYSTEM’ in ePO, denying us a sometimes useful piece of information that we used to have in XP, namely the last logged-in user on a particular system. But, while we’re still in the wild west era of Windows Vista, anything that makes an installer work is welcome news.

windows, vista, XP, MSI, installshield, epo, mcafee, installer

Recently at work, I had to come up with a way to uninstall any installed versions of Java on our AD managed systems, then install versions 1.5.11 and 1.4.2.12 (the latest versions of 1.5 and 1.4, essentially). Luckily, Alan found a site that directly addresses this issue, and I was able to quickly grab all the upgrade codes for the previous Java MSIs. Armed with this info, I quickly inserted all the upgrade codes into the 1.5.11 JRE MSI, which I had extracted from the setup .exe bootstraper (it’s in %username%\Local Settings\Application Data\Sun\Java\jre1.5.0_11). I tested it with 1.5.10 on my system, and it upgraded it like a charm.

Since the upgrade code for each sub-version is different (why, Sun, why?), you have to paste about 20 codes in one by one, which is a major pain. As a service, I’ve created an MSI that is only the upgrade codes. Just paste the upgrade table of this MSI into the Sun Java one (I’m not providing a hacked MSI on this site, that would just be stupid), and you’re good to go, and you can avoid the 20 stupid table entries. Here’s the file:

Downloaded a total of 193 times

java, jre, uninstall java, automatic uninstall java, MSI, AD, group policy, active directory, sun java

In an effort to provide additional security in Windows Vista, Microsoft has added the User Account Control (UAC) dialog prompts. Since these run on a special ’secure’ desktop that is technically just an image of your actual desktop, so traditional means of manipulating the dialogs don’t work. However, Microsoft hasn’t left MSI developers out in the cold. The Windows Vista blog has a great article about automatically handling the different types of UAC dialogs you’ll encounter in Vista. As a developer, you’ve probably turned the UAC off on your machine, but you obviously have to assume your end users have it turned on, so this is a hurdle that must be overcome when packaging apps for deployment.

Most of the work you’ll need to do involves the application’s manifest, which the blog article clearly sketches out and provides an example of. There is the typical amount of grousing in the comments, no doubt since Vista is uncharted territory and Microsoft isn’t the greatest at providing an immediate response on new problems in their technology. However, it’s great to see that these additional security features have been added without entirely handicapping developers–although there will no doubt be a slight learning / frustration curve to overcome first.

Now, to install InstallShield 11.5 on a new Vista box. Exciting commentary and reviews to follow!

application deployment on vista, application packaging, automatic user account control, installshield, installshield on vista, msi, msi on vista, UAC, UAC MSI, user account control, user account control in msi, windows installer vista

Windows Server 2003 offers systems administrators a new* and exciting tool for deploying applications across the domain: MSI deployment with Group Policy using Active Directory. Basically, if you can turn any app setup into an MSI, you can easily push it to any and all machines on your domain through Group Policy. Using the silent flag for msiexec, you can make these installs completely automatic, with no user interaction whatsoever. When your user boots up the machine, there is a slight delay while the MSI installs, advertised by a small dialog box in the top left corner, which indicates what app is being installed. After the install is complete, the user will be logged in completely normally, with the new app available to them. For a detailed walkthrough on deploying your app through Group Policy, click here. You can also read the Microsoft documentation here.

* I know, Microsoft claims this worked in Server 2000. Did you try it?
.msi, GPO, active directory, app deployment, application deployment, deploy application, group policy, install application remotely, msi, remotely deploy msi, systems administrator

If you’ve worked with MSIs before, you’re aware that you can either stream setup files with the MSI directly, or attach them separately in .cab cabinet files to be extracted at run-time. The former method saves file space: when the user installs the program, only the MSI is cached in WINDOWS\Installer, so the data in the cabinet does not occupy space on the user’s hard drive. The downside, of course, is that you can no longer get clean copies of those files during a re-install unless you have the original installation media. The other major downside, from an Active Directory standpoint, is that you can only push single MSIs with Group Policy, not multi-file installs.
So, if you have an MSI with a separate .cab file, what’s the easiest way to stream that cabinet? First you’ll need the Windows Installer SDK (available separately from the 1.2Gb Microsoft Platform SDK as a 7.9Mb download here). In there is a program called msidb.exe. Its only mission in life is to pack .cabs into .msis, so it’s appropriate for the task. If you’re into esoteric stuff like that, you can check out the full docs here.

1) Put the .cab and the .msi in the same directory as msidb.exe.
2) Open a DOS prompt and navigate to the directory with msidb.exe in it.
3) Run the following command, replacing the defaults with the names of your MSI and CAB files “Msidb.exe -d mydatabase.msi -a mycab.cab”
4) In the Media table of your MSI, rename the link to the .cab file with a # sign in front of it. In other words, if your file is called Data1.cab, the Cabinet column of the Media table should now read #Data1.cab.

Your MSI will now look inward to find the files it needs, and after all, isn’t that what world peace is all about?

msi, .msi, .cab, cabinet file, cabinet, stream, stream cabinet, stream .cab, media table, msidb, msidb.exe, windows installer, windows installer sdk, download, active directory, AD, group policy

Orca: free MSI editor or perfect killing machine? Yes.

I’ve been working a lot recently with Macrovision’s AdminStudio package, which includes their popular InstallShield .msi creation software. While it’s safe to say that InstallShield provides a serious level of drag-and-drop ease with their product, it’s also equally safe to say the $1500 price tag is probably out of the reach of most home users who, say, want to package up their GPL app into a nice, clean installer format. That’s where Orca comes in.

A free app available from Microsoft as part of their massive (>1.5Gb) SDK, but better acquired on its own as a tiny download from Aaron Stebner’s blog. The direct link for download is here.

Now, Orca obviously doesn’t include all of the GUI features that you’ll find in InstallShield-after all, it’s a free product from Microsoft-but it’s certainly good for what it does allow you to do: make quick and easy edits to existing .msi’s and create simple installers for free. I recently used it to add in several products to the Upgrade table for an existing installer, a task which is particularly simple with Orca’s direct editing interface. Also, in spite of being less drag-and-drop than its expensive Macrovision cousin, Orca does feature really helpful pop-up dialog boxes that provide the user with paradigms and expected values to enter into the MSI tables, a feature that will be of great help to those just getting started with creating .msi’s. All in all, it’s a really nice tool for Microsoft to hand out for free, and something fun to have on your computer to spy on the inner workings of other people’s installers.

Orca, msi, .msi, installer, installshield, adminstudio, macrovision, microsoft, edit MSI, edit .msi, msi table, GPL, application packaging, free software

InstallShield 11.5 provides an easy way to search the registry for a desired value

Oftentimes when creating a new installer, it is necessary to provide for the contingency of previously installed software that will need to be removed. This can be a previous version of the same software (although those modules should maintain the same unique IDs, making this extra procedure unnecessary) or it can be a piece of software that will conflict with the software you’re trying to install (i.e. an old anti-virus program). Either way, in order to effectively remove the software, you’re going to need to:

1) Search for the program’s existence, and
2) Run its UninstallString from the registry.

Thankfully, InstallShield provides a couple of easy ways to accomplish this. The first (ideal) way to run the other software’s uninstaller is to do a simple system search for the registry key UninstallString for the program you wish to remove. The advantage to this method is that the search is very specific–it only looks within a particular key–so you can easily do 100 of these searches in the course of an install. In order to create the appropriate Custom Action within your MSI in this manner, do the following:

1) In the ‘System Search’ screen, add a new search by right-clicking and choosing ‘Add…’ (or hit Ins).
2) Choose ‘File Path, as specified by a registry entry’ at the next screen.
3) For the Registry Root choose ‘HKEY_LOCAL_MACHINE’
4) For the Registry Path type ‘SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\**ProgramName**’ (in other words, to uninstall Macromedia Flash, type ‘SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Macromedia Shockwave Player’
5) Under the optional Registry Value field, type ‘UninstallString’
6) Pick a memorable name for your new file-path variable like FLASH8PATH, then choose the top option to only store it in the tables, not use it as an install condition (you will attach the custom action later).

Your System Search is now complete, and will look for the UninstallString for Flash Player, then store that value to the variable FLASH8PATH. If you wish, you can immediately use this variable to create Install Conditions for different Custom Actions, either as an exists/does not exist check that launches an .exe or something, or by using the actual path contained in the variable. To launch the uninstaller, create the following Custom Action:

Working Directory: SystemFolder
Filename & Command Line: FLASH8PATH
Return Processing: Synchronous (Ignores exit code)
In-Script Execution: Immediate Execution

NB: You need to schedule the Custom Action after the AppSearch action in the InstallExecute sequence, because that’s when the MSI checks the registry for the key…it will fail otherwise.

systemfolder, custom action, msi, windows installer, previously installed, anti-virus, installshield 11.5, installshield, search registry, registry, installer, appsearch, installexecute, .msi, uninstallstring, variable, install conditions, uninstaller