Have I mentioned lately I still love DOS? I have a new customer. They are running VM/386 with two Wyse Link MC-5 terminals. The application is a homegrown accounting system running on Clarion Professional Developer. Have I mentioned that I started my business developing software using CPD?

Living in the lightning capital of the world happens to be pretty good for business. That kind of work tends to be seasonal, but it definitely is steady during the rainy season. This particular company took a lightning hit and their main computer took the brunt of it right in the old Digiboard. It took a couple of days to get a replacement card, but at least their old 300 MHz Pentium system is still running and stable.

I went in on a weekend to replace the Digiboard. I obtained the exact same board as a replacement and it happened to be unopened old stock from some place the customer found on the Internet. As it happened, after it showed up, they found a spare board sitting on a shelf. I swapped the board, plugged everything back in and fired it up. And . . . nada! The terminals were dark. I double checked the jumper settings (yes, these boards have jumpers and are made for 8 or 16 bit ISA slots). I swapped in the other new board but there was no love from the dumb terminals.

After a bit of fumbling around with various combinations of cables, adapters, gender changers and an external modem, I was fairly confident the terminals also took a hit, probably through the serial cable when the digiboard blew out. However, I wasn’t 100% confident because of this odd little feature in VM/386.

In VM/386, if you make even the slightest hardware change, you have to run a little utility that creates a file called VMINTS. VMINTS sits in the root of the C drive and does something known only to God and some (presumably) bearded guys at IGC. The only way to update your VMINTS file is to boot from your installation disk (or the copy you were instructed to make as part of the installation) and run a menu option to update it. Guess what? No installation disk or copy was anywhere to be found. Oh, and this was the weekend and the company had no computers with Internet access. It so happens that on this particular weekend, the office where the computers normally reside was ripped apart to allow painters and carpeters to do their thing.

So, no ability to reconfigure VM/386 in any meaningful way and no loopback plugs to properly test the terminals. Time to punt. After I left, I found IGC’s website and discovered they have a disk image available with the utility to build a VMINTS file. Woohoo! I carefully followed their instructions and made a bootdisk. I also spent some time digging around in my garage until I found my loopback plugs for 25 pin serial connections.

As an added bonus, I also found a null modem adapter and a serial diagnostic plug that sits inline with the serial port. I bought this thing years ago and never had the opportunity to use it. The packrat in me has finally been vindicated! The diagnostic plug is pretty nifty. There are 25 numbered LEDs on it. When signal voltage appears on a pin, the appropriate LED lights up.

In a fit of joyful optimism, I grab the serial terminals, my assorted plugs and connectors and the precious bootdisk and head back to see the customer. The first thing I tried was plugging the loopback adaptor into the serial terminal. The terminal was set to FDX but I couldn’t get any characters to echo back on the screen. I inserted the diagnostic plug into the mix and got lights on pins 2, 3 and a few others. Based on my limited knowledge, I expected to see something happen on screen but remained disappointed.

Ok, so my loopback ends up being inconclusive. Clearly, the serial port on the terminal is not completely dead, but I didn’t get the result I wanted. So, moving on the the PC with VM/386, I insert the boot disk only to discover the floppy drive isn’t aligned well with the front cover of the PC case and the diskette eject button is stuck in a position where I can’t properly insert the diskette. I rip the case apart and drop the drive cage so that I can boot from the floppy. The floppy starts to boot and I get the message “Can’t find BOOTLDR.SYS.” Hmm . . . I reboot the system to the C: drive and look at the contents of Drive A:. Yup, there it is. I remake the floppy on another computer (the Internet PC is now back in business). Same error.

Time to retreat and regroup. I make a few excuses and a LOT of apologies and head back to the office. Back on IGC’s website, I see that they have a free upgrade from version 5.01 to 5.02. The customer is running 5.01, so I’ve made a diskette with the upgrade. My next step will be to (hopefully) upgrade them to VM/386 5.02, update the VMINTS file and see if I can get either the terminals or a PC running the VTERM software (another freebie I grabbed from the IGC website) running. If I can’t get either working through the digiboard, I’ll try to run one or both off of the native serial ports in the PC. These serial ports have already been verified as active and working using the aforementioned external modem.

I’ll post a follow up once I get that far.

Tech: Microsoft Shared Fax Service
Platform: Windows Small Business Server 2003
Gotcha: Trust Relationship between computer and server

I have this love/hate relationship with Microsoft’s products. They do some things extremely well, but it seems all too often the I get a glimpse of the dark side and it scares the hell out of me. With every iteration of Microsoft software, the user interface seems to get more and more abstract, yet the underlying processes don’t change in any significant way. I know there are exceptions, but when I lose functionality I regularly use because the UI changed, it tends to piss me off. Hence my obsession with the command prompt.

Yesterday, I was tasked with installing fax sharing on a small network running SBS 2003. It sounds easy enough and the installation should have been completely routine. All of the workstations were running Windows XP Pro except one with Windows 2000. I launched the wizard on the server to enable the fax service and install a shared fax printer. So easy. I was already planning my next service call as I started making my rounds to configure the workstations.

Right away, I ran into a slight glitch. One workstation had the fax service already installed and connected to local modem that no longer existed. Deleting the Fax printer flat out didn’t work. The status stayed at “Deleting” despite several reboots. I finally uninstalled the service completely, rebooted again for good measure, and then reinstalled it. One down, four to go.

The next three went smoothly. The two XP Pro machines required a CD since the install image wasn’t available on C:. Fortunately, this office actually organizes their media and I had no trouble locating the CD. The Windows 2000 computer – piece of cake. I had these three machines done in about 20 minutes with nary a hiccough or senseless reboot.

Last machine – this computer is used by the one person in the office who actually uses his computer regularly. He primarily runs Autocad and Office. Ruh roh! XP Pro isn’t fully patched and is still running Service Pack 1. So, off to Windows Update I go to download SP2. 30 minutes later, it’s downloaded and installed. I reboot and login to the network to install the client fax service. I marvel at how SP2 lets me login in under a minute instead of the customary three minute wait while the server downloads the profile. The warm glow of imminent success turns into sudden annoyance when I try to connect the shared printer for the fax. \\server\fax is not available.

I decided to browse for it. A half a dozen clicks later, I see that this computer is all alone on the network. It’s as if the workstation was suddenly transported into the middle of a black hole. Time distortion jokes aside as I wait for the attempted server connection to timeout, I contemplate my options. First things first, I decide that I may as well finish patching the OS, so I rerun Windows Update (yes, my black hole is still Internet connected). At least I know the problem is server/domain related now. I get the next batch of updates, reboot, lather, rinse, repeat.

When I no longer have critical updates to install, I try again. Nothing. “The network is unavailable.” “\\server\fax does not exist”

I decide to head for familiar ground – {Flag}-R CMD {Enter}. An anemic little, black window pops up begging for input. I resize it to make it readable and type NET VIEW. One workstation found. I decide to go for it – NET USE Z: \\SERVER\DATA. Trust relationship between computer and domain corrupted (I’m paraphrasing the message). At least now, I have an error message to deal with.

Google wasn’t much help this time. I found two message threads with the same error that were unanswered.

Now, I get paid by the hour, but there are some days that I just need for things to go smoothly. This happened to be one of them. My wife and I happen to be sharing a car this week and I had it. Meanwhile, our daughter was riding the schoolbus home for the first time and someone needed to be there to meet her. Needless to say, I wasn’t totally focused on the problem at hand.

At the server, I logged in as administrator and started navigating the directory tree. Under computers, I deleted the one in question. No help. Back at the workstation, I decided to login locally and rename the computer. I logged out and then logged in locally as administrator. I renamed the computer, rebooted it and tried again. No help.

By now, I was 40 minutes behind schedule and decided I had to go. I asked if I could call in to continue troubleshooting by telephone. My next step was to log in to the workstation again as administrator and take it out of the domain. I had the customer change the login from domain to workgroup and edit the workgroup name to ‘workgroup.’ At this point, the computer asked for a login to authorize the change. The local administrative password wasn’t enough. I had the customer try the server administrator login and it took it.

Whiskey
Tango
Foxtrot

I’m now completely befuddled. The login works to authorize leaving the domain, but the domain and all computers in it are invisible. Maybe it’s cached? Regardless, one more reboot later I’m still lost. I decided to go ahead and get back on the domain since this test appeared to be a deadend. Two steps back, one step forward and we’re rebooting again and logging back into the domain (and yes, it did require a password from the server before I could rejoin the domain).

Now, here’s the weird part. It works. I don’t know why the PDC decided to start trusting the computer again, but there it is. The customer was able to login to the domain using both the administrator and his user accounts. I wish I knew why it works, but there it is.

I’ve been self-employed for over ten years. Over that time, I have provided a changing mix of technology oriented services to my customers. Troubleshooting, networking, website design, programming – whatever they need as long as the checks clear.

I’m still pretty passionate about providing good service to my customers, but I’m finding I run into more and more situations where people just don’t want to pay a fair rate for service. Consequently, I keep my active customer list pretty narrow and spend most of my time keeping my regular customers happy.

I don’t actively market my service using traditional methods such as yellow pages, mail outs, newsletters or cold calling. Over time, I’ve tried them all and found most methods to be a costly waste of time. Too many people respond expecting hours of free expertise by phone. The few good customers I picked up by advertising barely covered the cost of the ads. Pretty much everyone who finds me does so when an existing customer refers me. So far, that has served me well, but there are times when I’m sweating the bills just a bit.

Technology is a wonderful thing. I really love what I do. I get a big charge out of solving problems for people and I don’t mind routine work like stomping viruses and excising spyware. But one thing really gets to me. . . When good tech goes bad. Inevitably, some piddly little one hour job installing an off the shelf piece of software goes south for no apparent reason and with no obvious warning.

For now, I’ll focus on those little morsels of pain and humiliation and see where it takes me.

Welcome to life in the trenches.