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 youre digging
through its documentation, youll 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 cant guess
your way through it. Some windows are intuitive, others
not so. And whats up with this script editor section
Thats the purpose of this article. Ill take
you on a road-trip through Installer-land. Well
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, youll need
SMS Installer and Niko-Maks 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, Ive provided numerous screenshots.
Note that you dont have to use WinZip; you can
use any software product. I chose WinZip because its
quick, easy to install, and makes a good Installer test
Lets say in a matter-of-fact tone right up front
that you will not only want to have, youll 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 users 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 wont 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 wouldnt get it on a machine quite different
from your users 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, youll
want to blow away the lab machines configuration
and reinstall everything so that its back to its
pristine beginning before you start another package. Its
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 dont 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 youre
using SMS 2.0, the Installer is included by default in
the Express setup (in the Custom setup, you have to choose
You have two Installer installation choices, 16-bit or
32-bit, but you only need to install the 32-bit application.
Theres a section in the Installer that allows you
to tell it to compile for any 16-bit applications you
The SMS 2.0 version of Installer looks the same as the
1.2 version. Unless you know what youre looking
for, you wont 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. Im certain, in Microsofts fashion,
that theyve 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
|Figure 2. The Script Editor lets
you see the scripting behind the application.
Lets 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. Well start in the Installation Expert
section by providing the application name. Well
also tell the Installer that this is a 32-bit installation
suitable for Windows 95 and Windows NT computers. Then
well 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
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 youre editing, there will be
several tabbed sections. The attributes youll edit
are Installation Interface and Advanced Configuration.
You might work with the User Configuration attribute,
but my experience has been that youll seldom work
with the Application Files, Runtime Support, or System
Setting Application Title, Directory
Begin by double-clicking on the Installation Interface
attribute or, alternatively, highlight the attribute and
click the Properties button. Youll be presented
with a five-tabbed window (see Figure 3). Were most
interested in the last four tabs, the Application, Dialogs,
Graphics and SMS, though its 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 sendera 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, youll designate
the applications 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% youd
automatically create a subkey with the applications
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. Its 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
The SMS 2.0 Installer puts "Untitled" in both
the Application Title and Installation directory fields.
This could be a gotcha if youre 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.
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 its
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 youre
following along in exercise mode, uncheck all dialogs.
One Dialog option that you might find confusing is the
branding/serializing option. Its 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
Ive used the winnt256.bmp bitmap for most installations.
Figure 7 shows you Details for a selected bitmap. Notice
that you can set a bitmaps appearance, including
how it "flies" onto the screen. In this case,
weve specified that the bitmap fly from the bottom.
If youre 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
youre following along, fill in the data youd
like in this screen. If youre familiar with SMS
1.2s version of this tab, youll see only one
change: In 1.2, the Create PDF checkbox is checked by
default; in 2.0 Installer, youll have to manually
check it. In fact, in version 2.0 if you dont supply
a Manufacturer, this feature wont 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 applications "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 youll work with are
Global, Screen, and Options. With the possible exception
of Languages, youll seldom need to enter the other
tabs: Settings, Patching, Compiler Variables, Signing,
and Font. Its 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. Youll
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.0s 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.
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 thats failing for some reason. Heres
one hint: If you have a Visual Basic application that
installs VB .OCX or .DLL files, youll have a problem
with them self-registering. This shows up in the INSTALL.LOG
file. Its a simple thing to edit each one while
in Script Editor mode and turn off the self-registering
If you place INSTALL.LOG and UNINSTAL.EXE in the %MAINDIR%
directory, and then install an updated package in the
same directory, you wont be able to uninstall the
previous package because INSTALL.LOG got written over
and is now invalid for the previous applications
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 youre currently packaging. This
way you have multiple uninstall paths. If youre
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 youll pick a 32-bit
appnot the default in either SMS 1.2 or 2.0 Installer.
A 32-bit installation is preferable always to a 16-bit
installation, because its so much faster. However,
some applications, especially older Windows apps, simply
wont package correctly in 32-bit mode, and youll
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 youre 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.
Theres 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 were
interested in here is the Fast Create button. This is
a fine button for smaller apps, but on large apps or on
recompiles you dont 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 lets pursue a unique use of the Installercreating
a custom registry key. You can also delete existing registry
keys and perform other registry-type functions with the
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). Youll 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. Lets
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:
In the Value Name field type in %APPTITLE%. (Remember
where %APPTITLE% gets populated?) In the Data Value box
Well 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! Youve
just changed the registry keys.
Running the Repackage Process
Now that youve 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 youve
compiled the script youll 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 its 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 its in the %SYSTEMROOT%\MS directory.) You also
want to ignore the Temp directorys files. Figure
14 shows this screen. Click OK to return to the Repackage
|Figure 14. Time to repackage,
which means telling SMS Installer which files to include
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
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 youre 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
|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 cant prove this, but Ive
had difficulty with long registry keys being picked up
by the Installer. I dont 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 EditorThe Guts of
Now the final parttweaking your script. Youll
find that you can do quite a bit of work from the Installation
Expert, but not all. Youll also find that its
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,
youll 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
youll 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 applications
files to the computers 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 users 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 its put into the script.
|Figure 17. Declaring a date variable
in the Script Editor.
Check for %MAINDIR% Location
Scrolling down through the script, youll see the
application installation files being copied to their respective
directories. Its important to verify exactly what
%MAINDIR% has been set to, so that you know where the
files are being copied. Ive had experiences where
I set %MAINDIR% to a root directory, though I wanted the
files copied to Program Files\%MAINDIR%, so Ive
had to restart the package preparation. Likewise, Ive
had older apps that absolutely, stubbornly refuse to live
under Program Files, so I had to install them in a root
directory. Ive learned to closely watch what the
Installer is calling %MAINDIR%, to make sure its
where I want it to be!
Suppress Restart with a Variable
As I mentioned, a system restart sometimes creates havoc
with PCM. Youll 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, youve effectively nullified
any applications ability to restart the computer.
Again, in SMS 2.0 youll have much more granularity
in the kind of rebooting you can do with a computer, so
this isnt as big an obstacle as it is in 1.2 (see
Figure 18). After youve 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 applications ability to restart
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 Ill finalize changes within
the Script Editor. The Compile button in the Script Editor
is the fourth button from the right on the toolbar. Once
youve compiled the script, its 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 youll have to have the application
installed before you can recompile any changes!
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, youll find that its
pretty straightforward. For me, the hardest part to get
used to was to learn to ignore the Installer-added script
lines that didnt mean anything to me and to pay
attention to the script lines that affected my installation.
Some developers dont feel that the Installer does
a good job of closely checking registry entries and other
files. Youll have to turn to third-party software
if you need to examine the registry more closely. However,
chances are good that you wont package anything
that presents problematic issues requiring such drastic
One last caveat. Keep in mind that some Installer .EXE
compiled scripts can be enormously large because they
contain the source files. If you dont have the bandwidth
to upload 90M packages to each client, its 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. Thats 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