Get more work done. Use SMS Installer for mundane admin tasks like software installation. Your challenge: getting comfortable with scripting.

Systems Engineering: Pushing Software with SMS Installer

Get more work done. Use SMS Installer for mundane admin tasks like software installation. Your challenge: getting comfortable with scripting.

Microsoft tends to understate things in its product literature. SMS Installer is a perfect example. As you’re digging through its documentation, you’ll come across a blurb that says something like, "You can use the SMS Installer to prepare software application packages for shipment to users via SMS." Gullible as you are, you load the Installer and try to prepare a package. But it turns out the Installer is complicated and you can’t guess your way through it. Some windows are intuitive, others not so. And what’s up with this script editor section anyway?

That’s the purpose of this article. I’ll take you on a road-trip through Installer-land. We’ll take a simple application, package it, and install it with SMS Installer, so you can get a feel for how you use the product. To join in the fun, you’ll need SMS Installer and Niko-Mak’s WinZip (available from WinZip, the Windows version of the PKZip compression utility, is ideal for this exercise. Just in case you want to read along on this exercise, I’ve provided numerous screenshots.

Note that you don’t have to use WinZip; you can use any software product. I chose WinZip because it’s quick, easy to install, and makes a good Installer test vehicle.

Also see...
Catherine Moya reviewed SMS 2.0 in the June issue, and she followed up with a review of the SMS 2.0 exam in this issue.

The Basics

Let’s say in a matter-of-fact tone right up front that you will not only want to have, you’ll have to have a development computer with Installer loaded on it. This computer should be roughly the same as the computers on your users’ desktops. Why? Because you want to closely simulate the user’s environment. If you test the package on a Windows NT 4.0 workstation with 96M of RAM and a 400MHz Pentium II processor, but users have Windows 95 desktops with 133MHz Pentiums and only 16M of RAM, your tests won’t detect any comparative differences. Besides that, you want as clear and accurate a registry, .INI file, and directory change picture as you can get; and you wouldn’t get it on a machine quite different from your user’s computers. You want to make sure that you set up a lab environment where you can prepare your Installer scripts.

Not only that, after creating a package, you’ll want to blow away the lab machine’s configuration and reinstall everything so that it’s back to its pristine beginning before you start another package. It’s not a wise idea to prepare one package over another. You could obtain some disk image software and save yourself a lot of time with respect to this.

Where To Start

You must have a primary site server in house before you can install the Installer. You don’t have to have it on your site server, but the executable that creates the Installer checks if you have a site server before you install it. You can download the SMS 1.2 Installer from the Web and If you’re using SMS 2.0, the Installer is included by default in the Express setup (in the Custom setup, you have to choose it).

You have two Installer installation choices, 16-bit or 32-bit, but you only need to install the 32-bit application. There’s a section in the Installer that allows you to tell it to compile for any 16-bit applications you may have.

The SMS 2.0 version of Installer looks the same as the 1.2 version. Unless you know what you’re looking for, you won’t see any differences. Most of the changes involve the addition of script commands in the script editor section (more on this later), though there are some new or revised features in the installation expert section. I’m certain, in Microsoft’s fashion, that they’ve revisited the code and tweaked it so it works better and more economically.

Preparing Your Package

OK, so you want to package an app so you can send it to users via the SMS 1.2 Package/Job or the SMS 2.0 Package/Program/Advertisement methodology. SMS 1.2 users will receive the package via Package Command Manager (PCM), and SMS 2.0 users will receive it through an Advertisement notification.

Why would you want to do this? Because the Installer allows you to take a non-Microsoft software package and walk through its installation while the Installer "watches" the installation, which is called the "Repackage" process. When the application finishes installing, you can use the Installer to prepare a script that will include the files just copied to your machine as you installed the app, any registry or .INI entries made, and any customized script options that you decide to include. You can then compile the whole thing into a runtime .EXE file for download to users through PCM or SMS 2.0 Advertisements (or as a downloadable on an intranet).

The Installer has two discrete sections: the Installation Expert (see Figure 1), which is a GUI editor for making changes to pieces of your application; and the Script Editor (see Figure 2). You can toggle between the two using the View menu item.

Figure 1. The Installation Expert offers a graphical approach to making changes to your application.


Figure 2. The Script Editor lets you see the scripting behind the application.

Let’s begin installing WinZip by preparing some up-front information for the script. Remember that the things you do in the Installation Expert section get translated into a script. We’ll start in the Installation Expert section by providing the application name. We’ll also tell the Installer that this is a 32-bit installation suitable for Windows 95 and Windows NT computers. Then we’ll run the repackage function and wind up the process by editing the script.

Note: If you compile something as a 16-bit executable, you can expect to see considerably slower installation of the application on user’s desktops.

Modifying the Installation Attributes

The Installation Expert has two sections, Attributes and Summary. An "executive summary’ of the attributes are shown in the right-hand pane of the Installation Expert window. You double-click on any Installation Attribute to bring up the properties for that attribute. Depending upon the attribute you’re editing, there will be several tabbed sections. The attributes you’ll edit are Installation Interface and Advanced Configuration. You might work with the User Configuration attribute, but my experience has been that you’ll seldom work with the Application Files, Runtime Support, or System Configuration attributes.

Setting Application Title, Directory Location

Begin by double-clicking on the Installation Interface attribute or, alternatively, highlight the attribute and click the Properties button. You’ll be presented with a five-tabbed window (see Figure 3). We’re most interested in the last four tabs, the Application, Dialogs, Graphics and SMS, though it’s interesting to note that you can create floppy-based installations. (Even more interesting, the SMS 2.0 32-bit Installer does not include an option for CD-based installations. This in spite of the much touted Courier sender—a sender that allows you to use Zip drives or CDs to sneakernet your SMS files to an unconnected site server.)

Figure 3. Your first decision: What kind of installation package do you want to create?

Click the Application tab. Here, you’ll designate the application’s title and its directory location. The Software Title field maps to an Installer variable, %APPTITLE%, which you can use in scripts. Suppose you wanted to create a custom registry key like "Workstation Software History"; by referencing %APPTITLE% you’d automatically create a subkey with the application’s title. Likewise, the directory you designate automatically maps to the %MAINDIR% SMS variable. A good operative method for this field is to leave it blank for now and tell the application where to place the files during the repackage process. The Installer will see the directory location and place the files accordingly. It’s important to keep track of what %MAINDIR% is for later, when you edit scripts. Figures 4 and 5 show the Application tab filled in and subsequent %MAINDIR% declaration in the script editor. Note that checking the "Place default directory under Program Files" puts %MAINDIR% under %PROGRAM_FILES%. If you leave this box unchecked %MAINDIR% points to a root directory.

The SMS 2.0 Installer puts "Untitled" in both the Application Title and Installation directory fields. This could be a gotcha if you’re using the new Installer, so watch it!

Figure 4. Setting properties for Application title and directory location.


Figure 5. Declaring the variable for the directory location of files to be installed.

Designating Dialogs

Now click the Dialogs tab (see Figure 6) This screen consists of nine initial application installation dialogs that are common to most installations. Some applications add their own dialogs and this screen will wind up populated with something new after you run repackage, so it’s wise to re-check it before you compile, especially if you want a silent installation. Unchecking all dialogs gives you a silent installation. At this time, if you’re following along in exercise mode, uncheck all dialogs.

One Dialog option that you might find confusing is the branding/serializing option. It’s useful if you want to provide succinct serial numbers for future patching/upgrading.

Figure 6. To perform a silent installation, uncheck all dialogs in the Dialogs tab.

Add Zing with Graphics

With the Graphics tab, you can add a bitmap to the installation. Here, you can create your own bitmap, or you can find a generic bitmap that fits almost anything. In my work I’ve used the winnt256.bmp bitmap for most installations. Figure 7 shows you Details for a selected bitmap. Notice that you can set a bitmap’s appearance, including how it "flies" onto the screen. In this case, we’ve specified that the bitmap fly from the bottom. If you’re following along, pick a bitmap and make your adjustments. The SMS 2.0 Installer only makes cosmetic changes to these screens.

Figure 7. SMS Installer only makes cosmetic changes, but it does provide some options for the way the bitmap is displayed during an install.

Making It Palatable for SMS

Click the SMS tab (see Figure 8). Here, you can supply the Manufacturer, Product, and Version. SMS 2.0 administrators will find this feature very handy. The 2.0 software inventory feature automatically picks up this information, calling it a known vendor, so packages are sent out with this information included. Note too that you can include a serial number and have the Installer create a Program Definition File (PDF) file, a script that contains input information for a software application installation. If you’re following along, fill in the data you’d like in this screen. If you’re familiar with SMS 1.2’s version of this tab, you’ll see only one change: In 1.2, the Create PDF checkbox is checked by default; in 2.0 Installer, you’ll have to manually check it. In fact, in version 2.0 if you don’t supply a Manufacturer, this feature won’t even be enabled. When done, click the OK button to exit the Installation Interface attribute and go back to the Installation Expert.

Figure 8. This SMS tab is where you specify the application’s "About" information, such as manufacturer, product, and version, for display to the user during installation.

Advancing Your Cause

Now click the Advanced Configuration attribute and click Properties to edit its properties. Here you see a nine-tabbed screen. By and large, the tabs you’ll work with are Global, Screen, and Options. With the possible exception of Languages, you’ll seldom need to enter the other tabs: Settings, Patching, Compiler Variables, Signing, and Font. It’s possible for you to compile your application in several languages, though you have to specify these languages when installing the Installer program, prior to calling them from your script.

The SMS Program Command Manager (PCM) is lousy at handling system reboots by an installed application program. You’ll be better off if you disable this function with the "Suppress Reboot Message During Silent Installations" button and add a variable that suppresses restart, then pass a second package with a reboot program in it or have the user manually reboot the computer. SMS 2.0’s package features provide much richer granularity in terms of machine reboots so this will not be as much of an issue for you as a 2.0 administrator.

Uninstall Wars

The Install Log Pathname box, by default, points to the %MAINDIR% directory. Two files get installed with this setting: UNINSTAL.EXE and INSTALL.LOG. The INSTALL.LOG file can be interesting to read, especially when you have a script that’s failing for some reason. Here’s one hint: If you have a Visual Basic application that installs VB .OCX or .DLL files, you’ll have a problem with them self-registering. This shows up in the INSTALL.LOG file. It’s a simple thing to edit each one while in Script Editor mode and turn off the self-registering feature.

If you place INSTALL.LOG and UNINSTAL.EXE in the %MAINDIR% directory, and then install an updated package in the same directory, you won’t be able to uninstall the previous package because INSTALL.LOG got written over and is now invalid for the previous application’s uninstall. A workaround for this is to place your uninstall files in a different directory for each iteration of a package. You can edit the Install Log Pathname box as %MAINDIR%\Uninstallx\INSTALL.LOG, where x is the iteration of the program that you’re currently packaging. This way you have multiple uninstall paths. If you’re only going to install this package once, fuhgetaboudit.

In the Destination Platforms box you can determine whether this is a 16-bit (Windows 3.x, 95 and NT) app or a true 32-bit app. Most of the time you’ll pick a 32-bit app—not the default in either SMS 1.2 or 2.0 Installer. A 32-bit installation is preferable always to a 16-bit installation, because it’s so much faster. However, some applications, especially older Windows apps, simply won’t package correctly in 32-bit mode, and you’ll have to resort to 16-bit.

Click the "Suppress Reboot During Silent Installations" box, key in an uninstall directory if you want one other than the suggested default, and select a 32-bit installation. Figure 9 shows this screen.

Figure 9. Specify the Install Log Pathname, uninstall directory, and 32-bit installation in the Advanced Configuration attribute.

So Many Options!

Now click the screen tab. Here you can make changes to the background color that the installation shows up with. You can also adjust the placement and type of progress bar that shows up. The progress bar, if you’re not familiar with the term, is the "thermometer" that appears when installing an app, to give you some idea about its progress. This is automatically built into the Installer, and you can instruct Installer where you want it to show up.

There’s no difference between the SMS 1.2 and 2.0 Installer relative to this screen. Select a different Top Color for your app (see Figure 10).

Figure 10. Let the user know how the installation is progressing.

Now click the Options tab. The only thing we’re interested in here is the Fast Create button. This is a fine button for smaller apps, but on large apps or on recompiles you don’t want this button checked. It has a tendency, when checked, to overlook things. A good modus operandi is to work with this button always unchecked. Click OK to return to the Installation Expert screen. Note that the SMS 2.0 Installer Options screen is identical to the SMS 1.2 screen.

Add a Custom Registry Key

Now let’s pursue a unique use of the Installer—creating a custom registry key. You can also delete existing registry keys and perform other registry-type functions with the Installer.

From the Installer Expert screen, double-click the User Configuration attribute and switch to the Registry tab (see Figure 11; both 1.2 and 2.0 Installer programs look the same). You’ll see a four-paned window. The top left pane is the current registry, the bottom left pane is the suggested registry. In the right-hand panes are the values for the different registry keys. Let’s add a registry key.

In the bottom left pane drill down to the HKEY_Local_Machine key, then click the New Key button. In the key field type:

Software\Machine History

In the Value Name field type in %APPTITLE%. (Remember where %APPTITLE% gets populated?) In the Data Value box type:

Installed %DATE%

We’ll declare %DATE% in the Script Editor section of this article. Click OK. Figure 12 shows what you should type in; Figure 13 shows the final registry key. Click OK to return to the Installation Expert screen.

Figure 11. Your starting point for designating modifications to the registry. Before...


Figure 12. ...Typing in custom registry key settings...


Figure 13. ... And after! You’ve just changed the registry keys.

Running the Repackage Process

Now that you’ve set some preliminary options, you can put the Installer into Repackage mode and install the application to your lab machine. Keep in mind that this does a "for-real" installation to the lab computer. To test your finalized package, after you’ve compiled the script you’ll have to blow away the machine and bring up a clean installation. Otherwise you have no way of validating whether the package works.

Click the Repackage button. The Repackage Installation window shows up, and it’s not very intuitive. You want to do two things here: establish the directories that SMS Installer ignores during repackaging, and perform the repackage. Click the Change button. There are two tabs to this screen: Files/Directories and Registry Keys. Click the bottom Add button and add the directories C:\MS and C:\Temp to the files to the list of ignored files. You want to ignore the MS directory on your SMS 1.2 clients because this is where the SMS client files live. (In SMS 2.0 it’s in the %SYSTEMROOT%\MS directory.) You also want to ignore the Temp directory’s files. Figure 14 shows this screen. Click OK to return to the Repackage facility.

Figure 14. Time to repackage, which means telling SMS Installer which files to include and ignore.

Click Browse to run your application installation and find the installation executable. If you already know the path and filename, simply key it in. Figure 15 shows this screen. Then click Next.

Figure 15. Testing the application installation.

The Repackage facility scans your registry, directory structures, and .INI and .DLL files, then runs the installation executable. You move through the installation of the application just as though you’re installing it for real on a computer (which you are!). When the app is done, execution returns to the Repackage facility. At this point you can click the Run Setup button to install another application. You can install numerous applications this way. When done, click Next again and the Repackage facility rescans the registry, the directory structures, and any updated files and notes the changes. Figure 16 shows the Repackage screen after it has completed the application installation but before it rescans the computer. Click Finish to end the Repackage function.

Figure 16. What you get when the repackage process is done.

Tip: SMS 1.2 Installer appears to overlook registry keys that are longer than 250 characters. I can’t prove this, but I’ve had difficulty with long registry keys being picked up by the Installer. I don’t know if this is fixed in SMS 2.0 Installer.

Note that the SMS 1.2 and 2.0 Installer screens are identical when using the Repackage facility.

Script Editor—The Guts of the Installer

Now the final part—tweaking your script. You’ll find that you can do quite a bit of work from the Installation Expert, but not all. You’ll also find that it’s sometimes more convenient to use the Script Editor to declare and populate a variable or do some other function. Creating a new registry key, for example, is something that the Installation Expert simplifies and the Script Editor makes convoluted. As you use the SMS Installer, you’ll learn when to jump to one section or another.

Add the %DATE% Variable

Switch to the Script Editor view by clicking View | Script Editor. The Script Editor is divided up into panes. The left- pane, the Actions pane, contains the various script commands for use in customizing the script. The right-hand pane, the Installation Script pane, is the actual script you’ll be writing or manipulating.

The script is broken up roughly into thirds. The top section of the script consists mostly of Installer-generated script lines that do branding and serializing, backing up old files (if selected), and other functions. Global variables are declared in this section of the script. The middle section is the copying of your application’s files to the computer’s hard drive. The bottom section does link creation, registry adjustment, and cleanup.

The main difference between the SMS 1.2 and SMS 2.0 Installer program lies in the addition of many Actions to the Script Editor. For example, SMS 2.0 uses the Microsoft Management Console (MMC). You can write new components for the MMC, called snap-ins. Thus, the SMS 2.0 Installer has an Install MMC Snap-in line included in the Actions pane.

Position your cursor on the "If System Has Windows 95 Shell Interface Start Block" line near the top of the script. In the Actions pane, find the Get System Information action and double-click it. In the Variable box type DATE and then click OK. This creates a system variable called DATE that retrieves the system date and time. Remember our registry key creation? Now we have a variable called %DATE%, loaded with the system date and time. When the package installs on a user’s computer, you can go to the registry, pull up HKLM\Software\Machine History and see when this application was installed. Pretty cool, huh? Figure 17 shows the variable declaration and what it looks like when it’s put into the script.

Figure 17. Declaring a date variable in the Script Editor.

Check for %MAINDIR% Location

Scrolling down through the script, you’ll see the application installation files being copied to their respective directories. It’s important to verify exactly what %MAINDIR% has been set to, so that you know where the files are being copied. I’ve had experiences where I set %MAINDIR% to a root directory, though I wanted the files copied to Program Files\%MAINDIR%, so I’ve had to restart the package preparation. Likewise, I’ve had older apps that absolutely, stubbornly refuse to live under Program Files, so I had to install them in a root directory. I’ve learned to closely watch what the Installer is calling %MAINDIR%, to make sure it’s where I want it to be!

Suppress Restart with a Variable

As I mentioned, a system restart sometimes creates havoc with PCM. You’ll have to figure out other ways to reboot a machine, apart from having the application reboot it for you.

You can add a "comfort level" variable at the end of the script to assure a non-restart. Scroll to the bottom of the script and highlight the bottom line. In the Actions pane scroll down and double-click the Set Variable action. In the Variable box, type in RESTART, then click OK. This essentially declares a null variable called %RESTART%. Since %RESTART% is populated from the Installation Expert, you’ve effectively nullified any application’s ability to restart the computer. Again, in SMS 2.0 you’ll have much more granularity in the kind of rebooting you can do with a computer, so this isn’t as big an obstacle as it is in 1.2 (see Figure 18). After you’ve set it, move it to the bottom of the script with the Move Down button (ninth button from the right on the toolbar).

Figure 18. Declaring a variable that suppresses an application’s ability to restart the computer.

Compiling the Script

The Compile button can be run from the Installation Expert or from the Script Editor. I prefer to run it from the Script Editor because I’ll finalize changes within the Script Editor. The Compile button in the Script Editor is the fourth button from the right on the toolbar. Once you’ve compiled the script, it’s ready to send out via a package and job. There will be three files in the directory you save your work in: .IPF (the Installer file), .EXE (the application executable), and .PDF (the PDF file). You can pull up the .IPF file for later editing, but keep in mind that you’ll have to have the application installed before you can recompile any changes!

Parting Words

The scariest part of the Installer to most administrators is the Script Editor section. But the Installation Expert and Script Editor sections are heavily intertwined, so you wind up toggling between the two quite a bit. As you work with the Script Editor, you’ll find that it’s pretty straightforward. For me, the hardest part to get used to was to learn to ignore the Installer-added script lines that didn’t mean anything to me and to pay attention to the script lines that affected my installation.

Some developers don’t feel that the Installer does a good job of closely checking registry entries and other files. You’ll have to turn to third-party software if you need to examine the registry more closely. However, chances are good that you won’t package anything that presents problematic issues requiring such drastic measures.

One last caveat. Keep in mind that some Installer .EXE compiled scripts can be enormously large because they contain the source files. If you don’t have the bandwidth to upload 90M packages to each client, it’s best to check into alternatives. SMS 2.0 provides much more robust bandwidth monitoring than 1.2, although 1.2 had some tricky workarounds that you could set in place.

You can use the Installer for your Microsoft and your non-Microsoft apps, though both SMS 1.2 and 2.0 include pre-prepared PDF files for Microsoft applications. The problem with PDF files is that the user generally gets an installation choice. That’s a two-fold problem: the user has to choose, and the user gets a choice. The Installer allows you to make the choices and to give users a silent package that contains exactly what you want them to have.

comments powered by Disqus
Most   Popular