Best Laid Plans of a Man with a Mouse...

I previously reported that I spent last weekend inside a VB2005 project. Well I discovered why things looked so good but just didn't seem to work right. I thought I had found an interesting “feature” of Windows. If you changed the name of the computer in the registry entries (including the current running set), stopped and then re-started Workstation and Server services, the name got changed.

The next step was to install a certain unnamed remote managing agent onto the system, the agent installed using the new computer name, the desired result. The money step was to use the agent to install a couple of application packages onto Windows XP. The application packages installed fine and the applications worked, mostly.

Everything looked like it was working but it wasn't. The idea was to speed up the software installation process by avoiding so many freaking reboots and the “dead” time they generate. I might be onto something if I can find out the list of services that need to be stopped and then restarted. Is it worth the time? No.

What I found was that a number of the Windows services that start up as Automated didn't on the next reboot. So what it meant was that the re-director didn't know the name of the computer. What it tells me is that something gets hard-coded into the re-director during the naming/reboot process. My attempt to eliminate a required reboot created a short-circuit instead.

The idea was to limit the number of reboots needed because that also fragments the installation process of the OS image and the applications onto the Windows computer. Fewer reboots means a tighter install process with fewer opportunities for error or having something interrupt the process and stop it before completion. The goal is to build a fully automated system that requires a minimal interaction with the installer. Limiting the number of bits of information needed by the operator-installer also speeds up the process but also has the added benefit of making the whole system more reliable. The required amount of information needed from the installer-operator is down to 5 selections, I'd like to make it 3 if at all possible.

Yesterday I was talking to some of the operations staff and discovered that one pair of the software options for a specific hardware configuration I've been including support for has almost been eliminated from use in the field. They are down to one system running that configuration. That option allows me to soft-limit the options down to 3 items. I can program a pre-set default and allow the operator-installer to skip a step or just ignore it if desired. So over all I've lost some personal time but gained some system reliability in the process.

The lesson for me--talk to the guys that are really going to use the software you're writing, not just the manager requesting/specifying it.