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.
- By Bill Heldman
- 07/01/1999
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
www.shareware.com).
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.
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 www.microsoft.com/smsmgmt. 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.