How much time do you spend testing? In the 11 years I’ve been in computer support, I’ve probably spent as much time testing hardware, software, and configurations as I’ve spent installing, upgrading, and actually configuring. But that’s the way it is with computers. Even though almost everything we deal with has already been tested and proven to work, there are so many aspects to a configuration that any change, no matter how slight, can cause failures you’d never dream of. And let’s not forget the user factor. Something that has worked perfectly in every other office might bomb in yours because your users have different habits.

This is not to say we can’t make changes without incurring problems. In fact, the majority of upgrades go very smoothly. Still, I’m willing to bet most computer support techs have developed a procedure similar to mine. No matter how insignificant, I always test any changes to be made by starting with just a few systems. Only after a problem-free day or two do I feel it’s safe to make the changes for the rest of the office.

A good example of this practice in action occurred a couple of months ago. My primary customer had a change of standards. Headquarters had decreed that all remote offices would stop printing via a print server and print entirely through IP. It was my job to install the TCP/IP Print Service on 150 Windows NT 4.0 systems, delete the network printers, and then reinstall them under LPR ports.
Check out these articles for more information on printer installation and setup:

Plan ahead
The job appeared straightforward and very easy. All the printers were the same model and already had IP numbers. A couple of systems people had been printing through IP for a couple of months without any problems, and they had very similar configurations to the rest of the office. The only thing that made the job less than a snap was that none of the 150 PCs in the office had the Microsoft TCP/IP Printing service installed.

The plan was simple. Another tech and I would come in after hours, we’d each log in as an administrator, add Microsoft TCP/IP Printing to Services, reboot, and go to the next PC. Once that was completed, we would make a second pass, add the printers using LPR ports and the IP numbers, and then delete the old printers. Finally, we would turn off the PCs and leave a note informing users of the change and instructing them to set a new default printer since the old default had now been deleted.

While it sounds a bit complicated, we were actually making very few changes. The PCs had been using the same printer drivers for over a year without any problems, so we didn’t even load new drivers. Still, we decided to start with a small group and see how that went before changing all of the computers. We chose 20 PCs whose primary users defaulted to Printer G. The entire process took only about 30 minutes. We left expecting no problems whatsoever. Boy, were we wrong!

The problem
The first thing that went wrong was the note. Everyone was intrigued and wanted to see how the new printing method worked. So at 8 A.M. everyone logged in, changed their default printer, and sent a test page. That in itself wouldn’t have been a problem, but I neglected to mention in the note that they would no longer get a message box letting them know the print job had been spooled. So everyone kept reprinting test pages. The printer got a real workout that morning.

The real problem, however, was in the printer driver. I still don’t understand why, but the same driver that worked perfectly while printing through the server completely trashed the print jobs in IP. I know what you’re thinking—the driver being used was actually on the server—but that’s not true. I know; I checked. With the PC handling the queue, the print jobs came out with garbage all over them. And with everyone printing corrupt test jobs at the same time, the printer repeatedly locked up. Around 10 A.M., we finally gave up and sent everyone back to printing through the server.

Turn failure into success
It took a day or so before we duplicated the problem and then found that the latest drivers from HP would resolve it. The next time we tried the install, everything went off without a hitch, so a day or two later we made the changes to the rest of the office. I’m still a bit annoyed that we didn’t find the problem with the driver before we reconfigured those 20 systems. But the failure proved that our decision to wait before reconfiguring the rest of the office was the right one. More often than not, when we do a test like that one, everything is fine. But over the years, the only tests I’ve regretted are the ones I didn’t perform.
It’s your turn to let us know how we’re doing. What do you think of Pat’s experience? Do you have a testing story or comment you would like to share? Let us know what you think by posting a comment or writing to Pat Vickers.