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 floydian_99@yahoo.com. 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 in general.

1. Introduction
2. The good...
3. The bad...
4. And the ugly
5. InstallRite
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...:-)

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.

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 leadership?

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.

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 built.

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...