You can distribute this document freely, as long as no changes are made to
the file, or as long as credit for it is not pretended by someone else. All
comments and suggestions about the material presented here should be directed
at firstname.lastname@example.org. If future
versions of this document include add-ons coming from other people than me,
then proper credit to the various authors will be clearly identified. All version
updates of this document are to be released by me.
You can find this paper and more online at http://www.geocities.com/floydian_99/
The goal of this paper is to present a simple and efficient way to do software
deployment in a Windows environment network. I also discuss, as a background
reference, my previous experiences on that field during my previous jobs.
While doing my research this summer, I found a nice program that I immediately
fell in love with. Better yet, it had a twin sister even more attractive. These
programs are InstallWatch and InstallRite, available at www.epsilonsquared.com.
In my paper "A poor man Tripwire-like system on Windows 9x/NT", I
described how to use InstallWatch/InstallRite (identified as InstallRite from
hereon) to have a setup similar to a basic Tripwire system (www.tripwire.com),
and another paper, "Computer snooping using InstallRite", covering
on how it could be used to collect information on computer usage. This paper,
the third in what I now call the "InstallRite series", is probably
the one the most awaited for by it"s author, Gavin Stark from Epsilon Squared:
it will cover the use of InstallRite with its initial intent and purpose, to
monitor software installation and the benefits that comes from it (read $$$).
This document is presented to anyone who has interests in computer support,
NT administration, software deployment, configuration management and computing
Table of contents
2. The good...
3. The bad...
4. And the ugly
6. The experiment
7. In conclusion
Anyone who"s done work in some kind of tech support in a networked environment
has dealt with issues related to software installation. On large networks, it
is almost impossible to maintain a standard configuration even though you are
in the process of deploying, because there"s so many machines that the standards
will change a few times by the time the project"s over. Also, too strict configuration
(like, same hardware and software standards for the whole company, engineers
and secretaries alike) can cause more disruption in the users productivity.
For example, when a specific piece of software is used by a user who does a
particular task that nobody else does, and that software isn"t considered as
standard software by the project leaders (sic!), even if they have been notified
of the potential problems this may cause. I have a vast experience in this field:
I must have installed Windows 95 (and the needed productivity software) at least
1000 times, if not the double. I worked on a cutover from OS/2 to Windows 95,
then later upgraded these machines to Pentium level (all installed by our small
team of 4). I also took part in several real-estate moves, involving each time
a network reconfiguration for each machine. Add to this all the troubleshooting
you can get in a 300 PC network. Back in these days, we were in charge of the
whole department, from A to Z, and we were independant from other departments.
Then I took part in a project to replace these computers with more recent model,
but this time it was part of a company-wide project, and the goal was to standardize
the practices in IT in all the company. I was "involved" in the project
as *they* were upgrading *my* department, and then *I* had to clean *their*
mess. I was later involved with various parts of this project, as it was evolving.
I could predict the resulting failures they encountered, but they failed to
listen to me. After all, I was only a "tech" then, completely disregarding
my education and my VAST knowledge of Windows 95 and NT, not to mention my knowledge
of the department they were invading in a way that reminded me of the Anschluss
(if you don"t know what this is, go back to your history books).
I had plenty of time lately, so I had the chance to try a few things that I
didn"t have the time to try at my previous jobs, and one of them was to try
if InstallRite can really deliver its promises on the matter of software installation
and deployment. Here are the results of all this.
2. The good...
It makes good sense to have a firm grip on the configuration of the software
installed on your users PCs. It also makes sense to standardize these configurations,
or else you"ll end up with a heterogeneous computer base to troubleshoot, which
is a major headache. But at the time (that was 5 years ago), there weren"t so
many tools to do automated stuff, so we did most of it manually. So while we
were at it and installing Windows 95, MS-Office, McAfee antivirus, Acrobat Reader,
Internet Explorer, legacy software and so on, we took great care to configure
it properly at the same time, in order to ease up our lives a little. We knew
that in Office, for example, the clipart is installed only on the first instance
you want to access it, after the installation of Office itself. So you had to
go in PowerPoint, start a blank presentation, and click on the Clipart button
to launch the clipart installation procedure. If at this point, you clicked
"Cancel", this screen wouldn"t appear anymore, and you had to so all
sorts of things to get it properly installed afterwards. So that meant we had
to do it now, so users won"t call afterwards about ClipArt not functioning.
Another benefit from standardized configurations was that I had a better control
on what was going on with the machines (see "Virus protection in a Microsoft
Windows network, or How to stand a chance"). Or let"s say that people from
the other city (from your department) is in town and uses one of the computers
here, they will face an environment similar to theirs (since it"s standard),
so less chances that they"ll open a problem call.
We also used one of these tools that let"s you copy a hard drive byte-by-byte
aver the network (but the disks, or sometimes the whole machines, have to be
identical), and these saved us a lot of time, because we only had to configure
one machine (I should say one of each model) and clone it over the network.
We still had to go around and reconfigure the machines after the installation
was complete (we were using static IP at the time, so we had to put back the
proper IP address in each machine). Note that with NT machines, you need another
tool to change the SIDs of your machines, or else all your machines will think
they are all the same. When it came to upgrade a single piece of software on
existing machines, however, it was still the good old fashioned way: with the
CD or over the network, and go on each machine individually.
The hours were long sometimes, but in the long run it paid off because we knew
everything that was installed on our computer base, which means more stable
machines, i.e. less work. Aaahh, do I miss these long lunches and these afternoons
at the movies...:-)
3. The bad...
As you may have noted, configuration was standard through the department, but
not through the company, as two different departments often had different policies
and implementation. So the company went on and imposed "THE" standard,
through an acronym-based-name project, that I will refer to here as Project
SOB. At this time, the company moved all it"s IT employees into one of it"s
subsidiary, and sold it to a big-time IT firm. Thus, maintaining our jobs was
equating to the company becoming a customer of the IT firm. But as Project SOB
was taking form, it was clear that all management and decision making involved
in this project was made by the higher-up of the IT firm, without seeking knowledge
from the people already on the field (they made us fill repetitive forms about
what software was installed on each individual computer, all with version info,
forms that we had to verify for mistakes after they type it in a database, but
they failed to listen when we were trying to raise real issues).
If I stick to software deployment issues, here"s what went bad. One part of
Project SOB was to replace all desktop computers in the company to have a standardized
computer base for all the company, hardware and software. Nothing wrong with
that, of course. But the "standard image" of a SOB computer was far
from being perfect. Remember that Clipart quirk I told you about earlier? They
didn"t do it. Antivirus software was configured with (poor) default configuration.
And on and on. They haven"t been tested at all (not by me anyway, even if I
clearly and definitely required so) and were pushed on a rush by "higher-ups".
I previously made arrangements with the deployment team to install 3 or 4 stations,
so I could at least test them in a real environment before giving it my go.
Then I wanted the deployment to be done during work hours, where it is easy
to speak with the user and figure out that she has a folder on her C: drive
where she keeps all her work (even if it is against policy), or to transfer
existing e-mail (some people used more than one e-mail software, as the company
standards moved from none to Lotus Notes to Netscape in less than 18 months).
Instead, they pushed the installation of 88 desktop computers over the week-end,
figuring they "should be all done by Monday, since they"re pre-configured
and all." As we were deploying machines, we were finding all the misconfigurations
(like that SMS client they installed, because they planned to have SMS servers
up in 6 months. Because no SMS server was available, this caused the machines
to hang solid for about 30 seconds every time at start-up. A year later, there
was still not a single SMS server installed). So new bugs found meant that we
had to go over each previously installed machine to fix them too. That delayed
the deployment a lot. And when this was done, we (my boss and I) had to go over
each machine again to put the "local settings" in the machines (template
folder on shared network drive for MS-Office, local network printers, etc.).
That was Sunday night, 9PM. We knew we had a big night of work (after being
there for the past three days), but we knew we could manage to get all 88 PCs
to be fully functioning by Monday morning. As we were doing or third and fourth
machine, Murphy"s law proved true once again: the network went down. This is
a bummer, because when you put network information on Windows, like a printer
share name, it will always try to connect. And if it can"t find it, it will
refuse to install. We called network support (a voice mailbox), which meant
that the problem could only be fixed in the early business hours of Monday morning.
In a way, that pleased us, because we knew that we could go home and sleep.
But on the other way, we knew the shit would hit the fan the morning after...
Monday morning, 84 people (remember, we could at least do 4) were not able
to work for the whole day (we had to attend emergency meetings in order to explain
this big mess instead of being on the floor to fix it), and the Chief of the
Department wants blood. We calmly explain to him the fiasco that happened over
the weekend, how we valiantly fought against it, how we lost (politics, my boss
is bigger than yours), how we did everything we could to clean the mess. This
story continues in the next chapter, "And the ugly", because it does
get ugly. I"m sorry to cut this story clean, but I would like to focus this
chapter on software installation and deal with the "brown stuff" later.
So that leads me a few months later, when my department computer base is once
again under my control (after much proscribed-but-necessary-for-stability tweaking
of the SOB standard), came the time of software upgrades. I have to admit we
were due indeed. Office 97 had two service packs out by then, and it became
accepted by the SOB standard to be the new office suite (we were on Office 95
until then). Antivirus went on a major upgrade release as well, and some utility
software were available to all users in the company, thanks to company-wide
site license or freeware (stuff like WinZip, Acrobat Reader, ftp tool, etc.).
So they wanted to try to do these installations automatically, with as less
human intervention as possible. A noble cause, I must agree. They approached
the problem with an in-house utility interface on top of WinInstall (if I remember
the name correctly). I wasn"t involved in the creation of the software packages
that were to be distributed with this tool (even if I requested it), so I don"t
how they are created. But for debugging them (because they were poorly tested
again, some people never learn) and going up to identifying what causes the
problems in his packages (because he had no clue why it was acting up), I could
deduct that it was script based. It is probably a sequential list of all single
items to be done in order to install a specific software. Each single file,
directory or registry entry created or deleted (because you could use it also
to de-install software, useful when performing automatic software upgrades).
The list was then parsed and the tool performed the actions specified in the
list. Since it was sequential, you can guess that some of the bugs were relating
to some file trying to be copied in a folder that does not yet exists, which
resulted in the file failing to be copied. The installation of a particular
software, Windows Media player caused the computer to freeze sometimes (most
of the times), but rebooting the computer and re-launching the install process
fixed it (it always ran fine the second time). For some reason, the guy building
the package could not make a working one for McAfee (I offered him some help,
after all, I knew quite a bit about this product, as you can see in my paper
"Virus protection in a Microsoft Windows network, or How to stand a chance"),
so he used the tool to launch the original setup files (with default configuration,
as this was the SOB standard). But for the WinInstall tool then proceeded immediately
to the next item in the list, even if the McAfee install was not finished yet.
So He had to include in the list a Notepad file that would pop-up, and that
we had to close when the antivirus software was done installing. Closing notepad
would let WinInstall to continue his tasks. As you can see, this was more of
a semi-automatic system than automatic.
We upgraded a whole building this way (about 1000 PCs, ten people to do it).
It was a pain. Other people in my position encountered bugs different than mine.
All because the only testing done was done on a clean test machine, not an in-the-real-world-production
PC. And because this tool wasn"t efficient at all, even if I have to disagree
with the project reports on that one. The worse is, in another part of the big
monster that Project SOB had become, another team was working exactly on the
same thing as us, with a different tool that worked pretty much in the same
way as ours. They used the other solution to upgrade previously deployed PC
(and encountered similar problems), while the newly deployed machines had the
newer versions on them.
Another funny thing with Project SOB was with the new browser/e-mail standard.
They chose Netscape to run internal and external e-mail, but they didn"t want
all the features available. They also did some customization so it would be
pre-configured to the right mail server. What they did was one of the strangest
things I"ve seen so far (and I"ve done quite a few myself): the installation
program they crafted for this one was a self-extract .zip file, containing the
original Netscape setup files along with a slew of batch files. The self-extract
would launch one of these batch files, which took care of determining OS (95
or NT), then to create some folders where the user profiles would be kept, along
with .bin file containing the server addresses. Then it would proceed to install
Netscape like it normally would, then some other batch file finished the job
by cleaning up the parts we were not to use. These batch files were very elaborate,
and they took some things from granted in the batch files code. I found this
out because this package wouldn"t install on a particular machine. The batch
file thingy would bust me out before the software would really install, without
giving me any clue as to what was going on. So using WinZip, I opened the self-extract
file and open the batch files one by one, trying to figure out what was happening.
It turns out that somewhere they hardcoded C:\TEMP, and the machine that I had
problems with, the temp folder was C:\TMP. Silly, isn"t it? They should have
used the environment variable instead.
4. And the ugly
This chapter may seem a bit off-topic, but I decided to include it here because
it causes great interference on smooth and efficient software and hardware installation
and configuration management: internal politics. And this topic is wide in meaning.
It"s the project managers who plan *our* deployment without consulting us to
prevent and avoid potential problems, it"s the push from higher up who wants
the most possible machines deployed in the shortest amount of time, no matter
what the level of quality of these installation is (because it leads to a bonus
for the Project manager, but not a dime more for the guys who make them look
good by cleaning up the mess), because some group is under union and the other
is not (more on that below), the fact that managers are not from the IT background
(more later on that one also), you name it, you got it. Here, I"ll pass under
silence some incidents with one sick-minded individual that also happened to
be one of the managers involved in the SOB project. He caused a disruption in
Internet service for over 30 of my users, all because of his poor planning.
A new machine also meant a new network connection, switching from static IP
that needs approbation for Internet access to a DHCP address that was allowed
access no matter who. As they deployed 88 machines, the 30-or so laptops were
not received yet, but the network guys planned them for deployment, so the Internet
access for the static IP"s was removed. So, on Monday morning, add to the 84
non-working PCs, 30 laptop users who are sure glad that they can still work
on their machines, but they have lost Internet access in the process. Instead
of fixing this relatively simple problem, he tried to get me fired with false
accusations. These users got their Internet access 1 month later, after many
complaints for the service to be restored, when they got their new laptop with
a DHCP address. I had other problems with this individual, so I consider this
to be a single event, while the rest of this chapter is the kind of brown stuff
that happens all the time in big corporations. As for this sick-minded guy,
he got promoted to the position that would have made him my boss, had I not
resigned for another job a month before.
Back to our botched weekend deployment. The deployment team comes from another
subsidiary from the same BIG company, and these guys have union. That means
that their jobs is to get the machines out of the box, put them on the desk,
connect and test the new network connection, and disconnect the old PC that
will be picked up a few days later in order to have a chance to transfer over
data we may have missed at deployment time. Pretty simple, repetitive. The networking
stuff is their turf, I don"t argue with that. But to go faster, we would have
liked to help them put the machines on the desks, so we could start our tweaking
earlier. But we couldn"t, because that would "steal job" from these
guys, although they were working overtime big time, and really wished they"d
be home early (a comprehensive feeling). Unionizing is a good thing, but today"s
unions are only a tool in the hands of the bosses to get more squeeze from the
employees, and this is one fine example. The union argument is that if there
is simply too much work for them to do, then the employer simply has to hire
more people. But in the meantime, it is the employees themselves who are putting
nearly impossible time sheets for months, just because they"re shortstaffed
and nobody can give them a hand. And then they send us to "teamwork oriented"
meetings to increase our productivity. Sheesh. At least, they agreed to help
us to transfer the files from the old machine over to the new one, because we
were only two guys doing it, and they had to wait after us to disconnect the
old machines. Since they weren"t feeling like spending the whole weekend there
(which eventually happened anyway), they helped us do it. After all, these guys
were victims just as my boss and I. All in all, we were about 15 people total
(guys in the field and managers alike) failing miserably what 4 of us (my boss,
2 other guys and myself) had successfully achieved numerous times (at one time,
the department was split up in 7 different sites).
On Monday morning, like I said, shit hit the fan big time. Head of the department
wanted... a head. So him, VP Tech Support of Big IT firm, Boss of the subsidiary
that was delivering the PCs, Project manager, network manager (the sick puppy),
my boss and I are all gathered together for an emergency meeting in order to
figure out what went wrong (as all Hell was breaking lose outside the doors,
because over 100 people couldn"t work properly, if at all). So we spent most
of the day explaining everything, how the systems were poorly configured, lack
of testing, and most of all our repetitive tries to prevent all this by raising
potential issues. At the end of the day, that was interpreted as "lack
of communication between all people involved", meaning we"re as guilty
as them because *they* didn"t listen to us(!), and that another meeting would
follow between people involved in the project in order to identify the root
causes of all this, and how it can be avoided in the future. No one got reprimanded
for all this crap. And they agreed that the fact that the network went down
was not predictable, and they concluded that in the long run, this is what prevented
us to get the machines in working condition in time (!!!).
The story behind this was that the Head of IT was getting a bonus if a ridiculous
number of PCs would be delivered on a certain amount of time. How many? Well,
the first phase (in which I took part) was to install 400 PCs in a matter of
approximately 2 months. Our 88 were part of that 400. This is why it was rushed
like that. Then Phase 2 was supposed to be able to deploy 1000 machine per week,
on a 40 000 computer base. You read it right; it"s not a typo. Do I need to
precise that Head of IT "resigned" somewhere in between Phase 1 and
Phase 2? The massive deployment progressed at a much slower rate (but I don"t
have numbers), and they had much bigger problems at other sites, where the IT
personnel was less experienced.
Another problem with corporate politics is power. Not the power to do things,
the power represented in numbers. Power in headcount (at this stage, they forgot
we are human beings), power in budget (the bigger, the better, even if many
of these costs could have been avoided and would actually saved money for the
company). But not the power to do things. Example (BTW, all of the examples
I brought in this document are any other are real and factual, even if some
of them may appear quite incredible): neither the custom Netscape package or
the base image for the new machines being deployed are configured to use the
proxy server in order to access the Internet. This means that after the "automatic"
installation, we still had to go and configure it properly in order to work.
When I realize this, I call up the SOB e-mail team (they were taking care of
the whole Netscape software):
ME: Hi there. I just noticed that although the standard configuration goes
into great lengths to have the software self-configured in order to easily access
e-mail profiles and all, but you guys forgot to put the proxy information.
SOB rep: I"m sorry, we don"t deal with the proxy, it"s
not part of our mandate. For proxy problems, call the networking department.
ME: But it"s a configuration that you have to put IN Netscape for it in order
to work. The proxy itself doesn"t have any problem, it"s Netscape who"s misconfigured.
SOB rep: I"m sorry, I can"t help you. Please call Networking.
Well, how could I win with these kinds of arguments? No need to say I did not
call networking. I would have sounded like an idiot dweeb if I"d done this,
because they would have told me "Call the SOB team", of course. Again,
the problem here is not technical, it"s lack of leadership from the different
groups to take their responsibilities. Then again, who said that power means
Another example of lack of leadership in a project: 6 months after they started
deploying Windows 95 PCs, they changed the SOB OS standards to Windows NT (somehow,
I managed to predict that 6 months earlier, what a psychic!). Now get this:
the SOB standard specified no Local Administrator password on the machines,
leaving it to the tech support and NT admins to set one of their choice, if
they felt like putting one(!!!). I cried foul at this nonsense, but that didn"t
change a thing. You would say that this doesn"t make these machines more vulnerable
than a Windows 95 machine, and you would be right. But why switch to NT if you
don"t intend to use its capabilities? So of course, 6 months later, it is a
mess, there are as many passwords as there are people in the tech workforce,
each password being something hard to guess like agf$vm87 (of course, now that
they are security conscious), and no one can practically login on a machine
as Administrator on the first try (or even the first 5 tries, sometimes not
at all). This is a bummer, because you often have to log in as Administrator
to install software or to modify configuration settings as part of the troubleshooting
process. It is then that they decided to put standardized local Admin passwords
on building basis (each building have its own Admin password), but they implement
it on the machines only as the techs are called to work on these machines as
part of the support duties. That means that a machine whose user doesn"t call
tech support for problems won"t be updated. So much for standardization. It
looks nice on paper, but in the real world, nothing is changed. The problem
here is that the Mother-company Security department should have taken ownership
(pun intended) of the configuration policies of these machines. Computer security
is the only thing they haven"t outsourced, and what they had was a Security
group not involved in company-wide projects, and an IT firm that administers
servers and domains with no concern over security because it is not their mandate.
Lack of leadership, seems like no one wanted that hot potato.
I also identified as part of the "politics" shenanigan the lack of
IT knowledge on the part of project managers. And it takes more than getting
a MCSE to claim to have knowledge. 6 months before they started Phase 1 of Project
SOB, they presented a document that detailed every single part of configuration
that will make the SOB Desktop Standard. One of these configuration items was
quite ironic/moronic (you choose): it was specified that the PCs be delivered
without any floppy disk drive, in an effort to protect the company"s computers
from computer viruses and preventing rogue employees to get confidential information
out. Did I tell you that these machines are all connected to Internet, with
full browser-mail-newsgroup-ftp capabilities (and more)? CQFD! Of course, they
changed this one, as this would have been a ridiculous implementation. Let"s
just say that it was common practice for the employees of that big IT firm to
forward virus hoaxes, even after numerous reply-back on my part mentioning that
this was a false alert, all with links to the hoax pages of McAfee and Symantec.
I guess this one explains the rest.
Examples like this are numerous, and you can see even more by checking the
List Of The Day on Dilbert"s website (www.dilbert.com).
OK, enough ranting about the past, now it"s time to talk about InstallWatch
and InstallRite. I first discussed about these programs in my papers "A
poor-man Tripwire-like system on Windows 9x/NT" and "Computer snooping
using InstallRite". This time, I"m going to talk about the proper use of
these softwares. They both do the same thing, although InstallRite have one
more feature. Both are freely available from www.epsilonsquared.com.
What it does is rather simple, and efficient. The first step is to make a full
database of your system, including files, folders, date stamp of files, and
CRC check. It does the same with the Registry. Then you install a piece of software
on the machine. Then you perform another scan of your machine hard drive, and
any changes reported compared to the initial scan is considered to be part of
the software installation. We it is finished, you get a complete image of the
trace left by an installation package. InstallRite will even let you build an
InstallKit, which is a self-extract file that will copy all files and registry
entries as they have been identified as part of a software package. You can
also use this to perform uninstalls.
This is interesting, because it is not a sequential script or a batch file
like we saw earlier. In fact, it is much simpler than this, it gives you the
final result of the installation process, not the process itself. This means
that you can install a piece of software, configure it to suit your needs, and
then make an InstallKit containing all your custom settings. You are now ready
to install this little baby on your machines. It allows PATH redirection, so
if some machines have different path names, it will still be working. You can
specify what action to take when encountering existing files, and force or prevent
rebooting after install (if you leave this blank, it will reboot only if needed).
This is really interesting, because all you have to do is build one version
of every software package you want to deploy for each different Windows platform
you may have (95, 98, NT, French version, Spanish version, etc.) on your site.
Then, you simply make these InstallKit run on your PCs, either through the network,
or with a CD. You can even make a script or a batch file that would call a bunch
of InstallKit one after the other. That is, at least, in theory. Let"s see if
it can live up to its promises.
6. The experiment
I was having some limitations on my Windows 95 machine, so I decided to setup
Windows NT on it as a triple-boot machine (95-NT-NT). While I was at it, I decided
I would take the opportunity to monitor each software install with InstallRite.
Of course, that means that it takes more time than usual to install each software
(especially if you keep adding stuff, the scans will take longer), but it pays
off in the end, as we"ll see. One NT system would be my "kit building machine",
and the other one will be the "recipient" to verify the effectiveness
of software installation. So I proceeded to scan my system before each software
install, and I took the time to configure/tweak these programs to my taste.
If you have serial numbers to enter for your shareware programs, do it now too
(but make sure you have enough licenses). When this is done, I complete the
process, and I get the whole installation trace in a single entry in InstallRite.
Before doing an InstallKit, I recommend doing one check through the installation
trace to make sure that InstallRite didn"t pick up more than what you intended.
As I point out in my paper "Computer snooping using InstallRite",
Windows activity itself can generate things that will be picked up by InstallRite.
You should clean these entries up, just to make sure you won"t get stability
problems afterwards with a bug-contaminated software package. Once the cleaning
is done, you simply click on "Build InstallKit", and choose the appropriate
options in the dialog window. The result is a self-extract file that once executed
will deliver the same result on your hard drive as the completed normal installed
software would leave, along with configuration.
I actually did my tests with the following software packages: Adobe Acrobat
Reader, GetRight, WinZip, ZoneAlarm and Microsoft Office 97. I also tested an
uninstall process with WinZip. And I decided to push the envelope by doing the
same thing with Service Pack 6 and my audio card drivers.
Nothing too spectacular with installing WinZip, Acrobat Reader and GetRight.
These programs are quite simple and quite small, so everything goes smoothly.
One double-click and a couple seconds after, these softwares are installed and
already configured to my liking. Then I proceed with ZoneAlarm, which contains
a lot of configuration options. Among them is the list of applications allowed
to connect to Internet. Here again, it worked fine, except for one little quirk:
the check box that enables logging (in the Alerts panel) does not stick over
with the InstallKit package. But everything else is as it should be. This could
be because I cleaned one entry too much in the installation trace database.
Then came the real meat: Office 97. Now this is where InstallRite becomes an
interesting tool. After my initial scan of the system, I installed Microsoft
Office 97 on my PC. Then I rebooted, and installed the Service Release 1 and
Service Release 2b. I rebooted again, and then proceeded to install the clipart.
I did other customizations, and when I was satisfied, I perform the second scan
to capture the result. When I installed it on my "recipient machine",
everything went perfectly fine. The installation would require a reboot (only
one), and be fully operational and up to date with patches. Service Pack 6 worked
perfectly fine as well, and if you made backup information available for de-installation
when you installed it, that follows as well.
But InstallRite doesn"t do miracles. When I first installed my Audio card drivers,
I needed to reboot the computer 3 or 4 times, as it was detecting the same hardware
again and again, until it was happy with its settings. Even if I did my second
scan only after the Audio drivers were completely installed, I still had to
reboot 3 or 4 times when I installed the InstallKit on the recipient machine.
Nothing to blame on InstallRite, I guess it"s the way the Audio Drivers are
What I didn"t say yet is that installing the InstallKits are much more faster
than regular installs, or even "silent installs" from original setup
files. First, you save the time by not clicking on all these setup screens,
choosing the path and the program group you"re going to install to, the License
agreement that you don"t have the choice to agree anyway, etc. You also save
time in the case of a program like Ms-Office, as the InstallKit doesn"t waste
time "Checking for available free space", when it was clearly showing
on the preceding screen that there is plenty of space. It doesn"t waste time
also for "Checking for previous versions installed", when you already
took care on de-installing the previous version. You save the time of not having
to take extra steps to apply the patches, as they are already included. And
it also saves time on copying the files to the hard drive. It is not copying
some default files that it writes to after, it delivers the right stuff right
ahead. You can notice the speed gain with small applications like WinZip, but
you can really appreciate it when you deal with big applications like MS-Office.
Instead of taking about 5 minutes the regular way (from CD), it only took around
1:30 to 2 minutes flat with the InstallKit. That"s efficient.
And the Uninstall package successfully performed as well. A word of notice
about de-installs: when you"re in the process of collecting your data to build
the InstallKit, make sure to go ahead and clean up the de-installation process.
Most of the times, de-installing software will still leave some traces on the
machine of its presence. Making sure to remove everything before doing the second
scan will ensure you that you will have an "improved" remover.
Also, I couldn"t try it, but the same technique could probably be used to create
a package for a network printer. You install a network printer on one machine,
you capture the installation footprint, and now you can install this printer
to your machines without having to go and define it in the Printer panel on
every machine. I wish I had that for Project SOB, I would have kicked ass!
Hardware and software deployments have never been an easy task. I never told
you about that place where I used to work where we were performing OS/2 upgrades
by launching a command file from the network (this actually worked great, but
it was time consuming because the whole system was overwritten, system and apps,
no matter where the updates were applying to). To avoid frustration on users
and on IT workers, anything that can ease up the process is a welcome thing.
As far as OS installation goes, InstallRite can"t really help you (unless someone
designs a way to do it, let me know), but to install any other kind of software,
patch or configuration, this is the best tool I"ve worked with over the years.
And it is largely because this tool was build with simplicity in mind. Nothing
beats that. Now, if only we could get rid of politics...