Making .msi Files

Anything that helps me easily get software onto—and more importantly, off of—my computer makes me happy. So, I like the one-click-does-it-all nature of Windows Installer files (i.e., .msi files). But Windows 2000 Ready .msi-formatted applications are scarce, so anyone who wants to make extensive use of .msi files needs to create those files. Fortunately, Win2K Server ships with VERITAS Software's WinINSTALL Limited Edition (LE) tool, which accomplishes ".msi-zing"; unfortunately, you need to do a bit of tinkering to create the perfect .msi file.

Why .msi Files?
In the old days, you could install an entire application simply by copying a file or two to your hard disk—and perhaps modifying the pathname. But most of today's applications consist of many files, including an entire program just for installing the application. These setup programs typically do several things. First, they create a program directory or two for the program files and data. Second, they put DLLs on your system's hard disk, but not always in the new application directories; instead, setup programs often put the DLLs in the \winnt or \winnt\system32 directory (even though application DLLs stored in those directories might interfere with the OS's or other applications' DLLs). Third, most applications associate themselves with a file extension and need to store some configuration settings, so the setup program puts the file extension and configuration settings into the registry. Finally, application installers typically put a shortcut on your Start, Programs menu. This list of tasks explains why setup programs are so big—they've got plenty to do.

You don't want to have to carry the setup program and its attendant files to every user's desktop and babysit the setup: You want a nice, centrally controlled, no-user-intervention-required way to install applications. Active Directory (AD) can provide that capability but can't easily use setup files; AD prefers applications delivered in .msi format. However, most vendors don't yet offer their wares in .msi format. So, if you want to use AD to deploy applications, you need to repackage most of those applications in .msi format. Because WinINSTALL LE comes free with Win2K Server (you'll find it in the \valueadd\3rdparty\mgmt\winstle folder on the Win2K CD-ROM), it's likely to be the repackaging solution that many of us will use.

Building an .msi Package
WinINSTALL LE creates .msi files using the snapshot approach, a tried-and-true method for describing and encapsulating an application. To create an .msi file for an application, you start with a clean, basically unused desktop PC that I call the prototype—I always use Symantec Ghost or Microsoft Remote Installation Services (RIS) to wipe the prototype's drive clean and give me a clean slate.

Before you install the application, you run WinINSTALL LE's discoz.exe program, which creates a record of the files, directories, and registry entries on the prototype—in other words, discoz.exe creates a before snapshot. Next, you install the new application on the prototype, tweaking and adjusting the program so that it works the way that you want it to. You reboot the computer to "fix" any registry changes—although often unnecessary, this step never hurts and sometimes helps. Then, you run discoz.exe again. Discoz.exe takes an after snapshot, noting any new files, directories, registry changes, and program shortcuts. Discoz.exe collects all the changes in a location you specify and builds an .msi file to accompany the changes. The .msi file gives you a package of directories, files, and registry changes, as well as a set of directions for Windows Installer.

I'll spare you the click-by-click details of running WinINSTALL LE, save to offer two suggestions. First, when you set up WinINSTALL to do the before snapshot, the program will ask whether you want to do an Enhanced Registry Scan. Doing the scan is always a good idea, so select that check box. Second, WinINSTALL's Help suggests that you not run discoz.exe on the prototype. Instead, install discoz.exe on another PC and share the program's directory in the second PC's \Program Files directory. Navigate to that shared folder, then run discoz.exe from there.

Installing a Package
Now, take a look at the .msi file's directory, which reflects the files and structure of the application you want to install. For this column, I created an .msi file of Lotus Organizer 6. That package contained a directory named Lotus, and applying the .msi file causes Windows Installer to create and populate a directory by that name. My package also contained a directory named \winnt, which told me that Lotus broke the rules when making Organizer. Examining an .msi file's directory also gives you an accurate measure of an application's footprint on your hard disk—the .msi file contains no compressed files that understate the application's installed size.

After you have an .msi version of an application, you can install the application in one of three ways. First, you can simply double-click the .msi file. Second, you can use the Msiexec /i command to do a silent install of the file from the command line. For example, the command that Figure 1 shows installs the package pilotdesk.msi from the \pilotdesk directory in the apps share on server1. (Like most Windows command options, the /i option is case-insensitive.) Third, you can use Group Policy to create a software deployment policy—a big topic that I can't cover in this column.

Some experimentation showed me that double-clicking an .msi file or typing the Msiexec /i command from the command line apparently doesn't invoke the Windows Installer service: These methods didn't install Organizer successfully when I logged on as a user without administrative power. But when I used Group Policy with my new .msi file to assign Organizer to the same user, then logged on as that user and selected Start, Programs, Organizer, Organizer installed hands-off.

I couldn't double-click or use the Msiexec command to install the Organizer .msi file for two reasons. First, Organizer's Setup program places some files into the \winnt and \winnt\system32 directories, and by default, users who don't have special rights can look at but can't add, delete, or modify files in those directories. Second, Organizer's Setup program wrote to two registry keys: HKEY_LOCAL_MACHINE\SOFTWARE and HKEY_CURRENT_USER\Software. Every user account has its own HKEY_CURRENT_USER\Software key, and you can write in your Software key to your heart's content. But only the System account and members of the local Administrators group can write to HKEY_LOCAL_MACHINE.

Why, then, did the Group Policy driven installation work? It worked because from the OS's point of view, Msiexec didn't run at my user account's request. Instead, Win2K thought that the System account started Msiexec, and the System account can write in the \winnt and \winnt\system32 directories. One reason Microsoft built Windows Installer as a service is so that Windows Installer can run under a user account that's different from the account currently logged on at the workstation. Windows Installer can run even when no one is logged on at the workstation, as is the case with services such as Microsoft IIS.

After I used Group Policy to assign Organizer's .msi file to my account, however, I found something annoying: Every time I logged on, Organizer installed itself whether I started it or not. That installation happened because Organizer not only put itself in my standard program menu but also put a shortcut into my Startup folder. The process of logging on tickles that shortcut, causing Organizer to install. So, I rebuilt the prototype system and the Organizer .msi file, this time removing the item from the Startup folder. The result was a nice, tame Organizer .msi file.

Some other applications for which I've created an .msi file have popped up automatically for a different reason: They've had an entry in the less obvious HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run subkey. (Some applications might also have an entry in the win.ini configuration settings file, although I haven't seen that happen for a few years.) The moral of this story is that you need to be prepared to rebuild your .msi file a few times, and be sure to test the file each time.

Working with What You Have
Many people ask me why they must give Administrator-level accounts to users to let them install software on their machines. Now you can see the answer: Like Lotus Organizer, many applications' setup routines write to directories and registry keys that non-Administrator users can't touch. But applications don't need to put DLLs into system-controlled directories or put registry entries into the HKEY_LOCAL_MACHINE key. (For an example, download Beermat Software's addictive—no pun intended—Dope Wars game at http://www.beermatsoftware.com or SkyMap Software's excellent SkyMap Pro planetarium program—created by Chris Marriott—at http://www.skymap.com.)

If you need to use an application that installs DLLs in a system directory, you can try two things. First, try moving everything that the application installed to the \winnt and \winnt\system32 directories to the application's directory. Organizer still worked when I did that. Second, try renaming the application's subkeys in HKEY_LOCAL_MACHINE\SOFTWARE (if setup added any subkeys), and determine whether the application will still run. (Organizer wouldn't.) Alternatively, you might add the local Authenticated Users group to the group of users who can modify HKEY_LOCAL_MACHINE\SOFTWARE, although that solution will weaken your system's security a bit. But the best answer of all is to let software vendors know that if they don't build their next version to Win2K-friendly specifications, you won't buy it.