Today’s job involves rebuilding a PC based voice mail system that was struck by lightning. I was hoping to get lucky and find merely a bad power supply, but Thor was not smiling when he smote this old box and it looks like the mobo took the hit too. This is going to be so much fun! I don’t even know what software they’re running.

Here’s what I know:

• The computer is running DOS
• It has a four port Bicom modem card
• There are three ISA slots in use
• The hard drive spins up

I’ve had to put this job off from last week because it required digging into my hardware museum to find appropriate parts. After an hour of searching, I located a never used Epox EP-61BXA-M motherboard, 32 MB of PC100 RAM, and a Celeron 333 CPU. I tossed these into my cauldron, added a touch of AGP video and hit the power. Miraculously, the system booted and I was able to navigate the CMOS. I put an old hard disk on it and booted into Win98 with errors.

I decided to go ahead and burn the system in overnight to ensure all the parts were good, so I rebooted from my handy burn-in boot floppy and left it running. By morning, I had 200 error free passes.

I carried the parts into the office and finished reassembling the system. Along with the Bicom board, I had two jumperless ISA modems to install. I also moved the existing hard disk and floppy from the old system. 20 minutes with my screwdriver and I had her ready to boot.

When I fired the system back up, the first message I received was a CMOS checksum error. Fortunately, I keep a ready supply of CR2032 batteries for this little gotcha. I replaced the battery, booted in setup and reconfigured the CMOS to meet my needs. Most notably, I turned off PnP, and all onboard devices, including IRQs for the USB and VGA. No sense leaving something running that might conflict with the mystery modems from the original system.

One more reboot. I fondly watched MS-DOS load and then watched the voice mail system enable the Bicom board. It detected the board and configured it successfully, so I’m hoping I’ll have dialtone on all four ports. Without warning, I get the following message:

PANIC: [lpt.c:72]: prt_install
AX = 009F BX = 0048 CX = 0000 DX = 812B
SI = 0087 DI = FC46 DS = 8C13 ES = DDE0
IP = 0AB6 CS = 389E
Current Task = 05DE:02ED (-MAIN-)
System Halted

I didn’t need google to make the reasonable guess this software was expecting to find a parallel port active in the PC. I powered her down and entered the CMOS again to turn on the parallel port in SPP mode.

Sixty seconds later, I’m looking at the monitoring screen for the “pairtree Call Processing System Version 5.33f/2.27”. Rock.

I spent some time this morning chasing down an odd problem. I got a call from one of my customers regarding a puzzling email issue. For at least a month, he’s had no luck sending email from Outlook. The send dialog would sit forever trying to deliver a stack of phantom messages (i.e. not from the Outbox) and eventually timeout.

When he called on Friday, we decided to conference in his webhost and see what was going on at the smtp server. The admin for his domain checked the logs and discovered that every five minutes, there were stacks of errors being generated from these phantom emails. All of the emails were going to the inbox for a former employee. Since the inbox on the server no longer exists, the SMTP server was rejecting the message.

I telnetted into the server just to see what it was running and found Exim 4.52. I’m by no means an expert on the inner workings of ESMTP, but I assumed at this point that since the email was destined for a local domain, Exim was smart enough to recognize that the message was undeliverable and rejected it upon receipt of the message header.

Outlook 2002, being not so smart (or too smart if you prefer), valiantly kept attempting delivery. The real email messages my client needed to send remained queued up behind this phantom traffic and never made it out the door.

After a short discussion, we decided to recreate the user account to collect this email traffic and see what happens. As soon as we did, the test message my customer sent me went through. We scheduled an appointment for this morning to figure out where the phantom traffic was coming from so that the problem could be properly fixed. No sense waiting for the inbox to fill up or something equally occurs.

I arrived onsite and gave Outlook a once over to see where the traffic might be coming from. Checking the mailbox we created on Friday, I saw stacks of return receipts that were delivered on Friday. I searched for the return address in Outlook and in the registry to see if there was some setting amiss. I found nothing unusual.

Return receipts to an email account that hasn’t existed in over three months made no sense to me at all. I wondered if the former employee (who left on not such good terms and who has a modicum of skills) might be spoofing messages or left behind some sort of spyware that was grabbing her boss’s email. It seemed farfetched, but nothing else made sense.

When she left the company, I reloaded everything on the PC she used. I did a nuke and pave on Windows and performed a fresh installation of needed applications because the system had become so junked up by personal software and bootleg audio utilities. So I was pretty sure that her old computer wasn’t doing anything unexpected. We had also gone through the ritual of changing every password in the office at the time and I had performed a cursory review of their internal security too. Nevertheless, I doublechecked the other PC in the front office just to be sure it was clean.

Looking back at my customer’s Outlook, I noticed his calendar was pretty full. I asked the receptionist how he entered his appointments because I knew that he didn’t do it himself. The receptionist showed me how she created the appointment in her own calendar and then forwarded it as an iCalendar attachment to the boss. Interestingly, the staff at this office love the return receipt feature in email and have it turned on by default in Outlook. They also have automatic approval of read receipts set in Outlook.

I went back to the afflicted Outlook desktop and reopened the calendar. I then changed the view to show a list of appointments instead of the default calendar format. Interestingly, I discovered a huge list of birthday, anniversary, and payday reminders on the calendar. All of them were set as recurring appointments and some of them weren’t even scheduled to start until 2015. Those that populated dates in this year’s calendar had start dates that predated the employee swap in the front office.

Very interesting indeed. I asked how important the reminders were and the staff told me they were redundant since the boss got verbal and email reminders from the receptionist anyway. They told me to delete the recurring appointments which I gladly did. I’m sure that as each recurring appointment was scheduled automatically by Outlook, it generated the read receipts back to the old email address.

I’m scheduled to go back Thursday, so I’ll know then if the outbound email flood has been stemmed. I’m pretty sure I’ll be celebrating success when I check.

The most fascinating part of this for me was learning that iCalendar exists. And only seven years after its inception! According to wikipedia, Microsoft’s implementation is relatively stable as of Outlook 2002 and the standard has been implemented in a number of popular calendaring apps. There are also a few sites that let you publish your calendar online for free or you can do it yourself along with an RSS feed of upcoming events for news aggregators. Pretty darn spiffy.

Back to tackling the recalcitrant VM/386 system for me. I went back into the warzone with a primary plan and three backup plans. In that I was still unsure of the health of the dumb terminals and the complete lack of response to anything plugged into the Digiboard, I decided I needed to cover my bases. My plan was as follows.

1. Update VMINTS and retry my connectivity tests
2. Install free upgrade to VM/386 to see if problem clears itself up
3. Reconfigure VM/386 to use serial ports and retest with PC
• If successful, put a terminal on the cable and troubleshoot terminal settings
• Otherwise, call IGC (VM/386 guys) and pay for some support
4. Retry working terminal on Digiboard

All in all, I figured I had enough choices to get something going presuming the cables I used previously were still intact and functional.

My tools:

• VM/386 5.01 to 5.02 upgrade diskette
• an inline DB25 diagnostic plug with 25 LEDs to show me what’s happening on the wire
• an inline DB25 null modem adapter
• a DB25 loopback plug
• my laptop with PCTerm (freebie DOS terminal emulator from IGC) preloaded
• various gender benders and DB9-DB25 adapters

All in all, I felt well armed for success. For starters, I booted the server from the upgrade disk and updated the VMINTS file. Naturally, even this step had its difficulties. The front panel of the server has a bezel that doesn’t mate well with the eject lever for the floppy drive, so the diskette was stuck. I went into the CMOS and removed the floppy from the boot sequence. After numerous reboots, I finally cracked open the case and loosened the floppy drive retaining screws so I could force it to eject diskettes as needed.

Anyway, I rebooted VM/386 and verified the VMINTS file had been updated. It had a current date/time stamp, so I figure it did. Having had the foresight to backup the existing VMINTS file, I decided to run FC VMINTS VMINTS.OLD. Byte for byte, they were identical :/ . So much for that perceived obstacle. I went ahead and retested the terminal connections just for grins and they quite predictably remained broken.

Following my plan, I confirmed the backup of the \VM386 directory and root of C were still intact and then rebooted the upgrade diskette to commence upgrading the server software. Imagine my lack of surprise when the upgrade started copying the necessary zip files from the floppy to a temp directory and up pops a disk read error. I decided that if the file was indeed corrupted, the zip file wouldn’t extract anyway and I could restore my backup, I valiantly retried. After the third retry, the files finished copying and the upgrade proceeded without any further errors.

I popped the diskette out and rebooted the server. Being a 32 bit operating system, VM/386 works by launching a group of predefined virtual machines on startup. The first VM is the management console and another one starts for application access on the main computer (in this setup anyway). Upon restart, the management console came up successfully but the local application VM was totally corrupted on screen. The menu was visually trashed. I rebooted the application VM and got a normal looking menu. Switching to the management console, however, locked the computer up deader than a bug on a windshield. I couldn’t even toggle the numlock LED. After a few reboots with similar results, I decided to restore the backup and get the system back to a known working (I use that term somewhat loosely at this point) state.

Once I had the system stabilized and back to how I found it, I shut down VM/386 and fired up VMSYSDEF to reconfigure the serial devices. I added boards for both COM1 and COM2. On one, I told it I was connecting a WYSE 60 terminal, on the other, I told it I was running a PC with PCTerm.

I restarted VM/386, created profiles for my new settings, and then created two new VMs for testing. Since I was limited to five users, I had to shutdown some unused VMs. I connected my laptop via the serial cable and and put the diagnostic plug and loopback plug on the far end of the cable. I was able to get jibberish on the screen when typing and figured my baud rate was set incorrectly, but everywhere I checked, I had it set to 19,200 which matched the config in VM/386. I decided to guts it out and plugged the serial cable into the COM port on the back of the server. BOOM! Suddenly, I’m looking at the menu in VM3 on my laptop. It was the most beautiful thing I’d seen all morning. My customer was looking over my shoulder and started grinning from ear to ear.

Now that I knew I had a working connection, I decided to reconfigure the same port to accept a Wyse 60 terminal and try it AS IS with the dumb terminal to see if I could get one of those working. First, I tried the same loopback test on the terminal and was able to echo text back to the screen. I then put the terminal on the system and…. nothing.

I knew something simple was interfering. My connection was good and the serial port was working on the terminal. I could also see the dataline blinking on my diagnostic plug as I typed, so I knew the characters were going somewhere. I went into setup mode on the terminal (shift-Select on the keyboard) and checked the settings. I confirmed they matched the original settings (which presumably worked). I began wondering if I had problems with handshaking on either the transmit or receive lines. The transmit was set to XSP (I still don’t know what that is) and the receive was set to XON/XOFF. I tried a couple of different choices but still had no luck. On a lark, I changed the terminal emulation from Wyse-60 to PCTerm and… BOOM again! I was looking at the menu. I navigated around and started some programs to verify it was indeed working and must say, I was pleased.

Since I had two dumb terminals to reinstall, I quickly unplugged the current one and connected the second. I reset everything to match and gave it a go. Nothing. Furthermore, I wasn’t getting any blinky goodness on my diagnostic plug nor was I able to loopback the serial port. I decided this terminal was quite dead. On my previous visits, I had little success with either terminal, but I used this particular one more than the other and that may account for my previous lack of success. Nothing like multiple failures to frustrate troubleshooting.

I decided to see if I could get the working terminal up on the Digiboard. To make a long story short, it didn’t work. Diagnostics I downloaded from Digi International told me the replacement board was good, but I still couldn’t get anything to happen with it on any of several nodes. I now believe that the octopus cable was damaged along with the other Digiboard, but I didn’t have a spare to test with.

I realized I hadn’t tested printing yet. I brought the system back up with two working COM ports and reattached the working terminal. Par for the course, nothing came out of the printer from the application, a print screen, or by hitting Ctrl-P. I jumped back into the terminal setup and discovered the printer port was disabled. Clearly, this terminal lost its brains at some point and must have reset to factory settings or someone else had tinkered. After enabling the parallel port, everything printed as expected.

I conducted one more test using the RS-232 surge protectors the customer had on hand (even though they obviously didn’t provide protection) and then tested again with only the hardware I would use in the final connection just to be sure all the parts worked, I then headed downstairs to redeploy the terminal where it belongs. The cabling in the walls was unlabelled (of course), but I only had two to choose from, so I figured 50/50 odds weren’t too bad. Again, par for the course, I guessed wrong. To ensure I didn’t have other cabling issues, I plugged my diagnostic plug into the other cable to confirm I was getting a signal from the terminal downstairs and happily saw appropriate LEDs light. Making the connection with the correct cable, I had the most critical terminal back online!

It took about 15 minutes of searching to find the other serial cable I needed. The second connection was in the same office and the cable was installed by running it around the room along the baseboard. When they repainted and recarpeted the previous week, the contractors took the cable out and stashed it somewhere. I found the cable, installed Winterm on the computer at the other desk and ran the cable back around the room.

Pulling the computer out to connect the cable, I realize I’m short a connector. I used my DB9F-DB25F adapter at the server to plug into COM1. Oh, and of course, it wouldn’t physically fit with both serial ports stacked vertically at the back of the server, so I had to remove the power supply and move the 9 pin port to another spot on the back of the case. Regardless, I was short one adapter. I had to MacGuyver the existing adapter because Radioshack decide the 9 pin side needs those little hexagonal screw retainers which won’t mate with identical retainers on the port at the PC. To make it work, I used pliers and physically ripped the retainers from the adapter (no, they were not screwed on, they were welded to the ground plate). It was ugly, but it worked.

I ran to RadioShack and bought two adapters. To avoid the problem, I bought an adapter with a male 9 pin and then purchased a 9 pin F-F gender bender to provide some spacing at the PC connection. Back onsite, I got it all connected and pretty easily got a terminal session going in a window under Windows XP.

Printing proved to be a bit of a challenge. This PC has a parallel connected inkjet but their old application needs to print to this monstrous DataProducts 8820 wide-carriage dot matrix printer. I successfully printed a small report to the inkjet, but I knew it wouldn’t work for some of those 160 column reports. I checked the inkjet and realized it supported USB, so we robbed a USB cable from a computer down the hall and I reconfigured the printer to use USB. I then used the parallel port to connect the dot matrix. Windows didn’t have an appropriate print driver and I couldn’t find one through google, so I installed the printer as a generic text printer and let Windows send a test print job. So far so good.

I fired up the application and tried to send the same report to the dot matrix. Winterm gives me something like Unable to print to LPT1. retry/discard output. I give up. Opening a dos window, I’m able to copy a text file to the printer without errors. I suspect the problem is buried in how the application addresses LPT1, but I’m pretty confused since I printed succesfully to the inkjet earlier.

I clean up the windows printer list a bit by removing about six unused printer configs and reboot to confirm the problem didn’t clear up. Sadly, it didn’t. I mentioned before I used to program heavily in Clarion For DOS and I know it pretty well and have dealt with many of its foibles running under various versions of Windows. I figured I could eventually get it working, but I decided to recommend a product I’ve used sucessfully before. I told my customer what the circumstances were and recommended they drop $25 on DOSPrinter, a very useful program that can either grab text files and properly send them to any windows printer or intercept LPT1 and send it to any windows printer. Basically, $25 is less than they’d be paying me for additional labor to troubleshoot, so they agreed to try the software.

I reconfigured Winterm to send all printer output to c:\winterm\print.me and installed DOSPrinter. After a really brief configuration, DOSprinter grabbed the output and printed it to the correct printer. Success! Before I finished, I decided to edit the LPT port in device manager and changed it to LPT2. I didn’t want any future tinkering with DOSPrinter to break anything, so I wanted it safely away from LPT1 and potential capturing/redirecting activity.

All in all, the customer was VERY happy to have their system up and running again. The final casualty list was one dumb terminal, one Digiboard Com/8i, probably one Digiboard DB25 8 port octopus cable, and some minor bruising to my ego for not leaving the hardware side technically perfect. Life goes on.

Two weeks ago, I finally quit procrastinating about updating my Antivirus software. I’d been running Norton Systemworks 2002 for a while and the updates expired in late June. My intentions were to remove Systemworks and install the latest release of Norton Antivirus. I’ve been holding back only because it seems that about a third of the time I attempt to reinstall NAV for customers, I have problems.

Most recently, I ran into a situation where the installation would rollback after getting about 90% of the way done. I diligently followed the instructions and then more instructions and never got it working. I never received a tangible error message and I couldn’t find any logging of the installation to troubleshoot the problem. I finally switched the customer to another product and moved on. Mostly, I can get the installation to work by running the uninstallers, removing all references to SYMANTEC and NORTON from the registry and then purging any lingering files from the file system, but it shouldn’t be that hard to upgrade.

I’ve had more than a few bad experiences with McAfee as well, so I decided I needed to try something new. I uninstalled most of Systemworks and decided to try AVG Free Edition by Grisoft. The installation went smoothly, I updated and ran a full system scan. AVG doesn’t include an integrated scanner for Thunderbird, but the default email scanner that hooks port 110 seems to work just fine. As a bonus, I discovered that my PC now runs about 2-3x faster than it did before. I attributed this to AVG being a bit leaner than Norton and patted myself on the back for being so smart.

The only oddity I discovered is that AVG remains convinced my 11 year old DOS program for processing credit cards is infected with an unknown virus. I don’t even use the program any longer, but I’m loathe to delete it. Sadly, the free version of AVG doesn’t allow me to exclude that file from the scan. Ah well, the price was right and AVG isn’t interfering with it.

Today, I decided to look at my logs to see what else I might have missed and I notice that AVG quarantined a file allegedly infected with Trojan horse Dropper.Agent.8.B. I expect infected files to pop up occasionally because not all of my email addresses have built in AV filtering, but this particular file was C:\WINDOWS\$NtServicePackUninstall$\cisvc.exe. I’m wondering how the hell an infected file made it so far into my system. On my home computer, I have the connection firewalled, behind a NAT interface and I’m very conservative about what programs I install and run.

First, I google the file itself to see what it does. MSDN says it is an Indexing Component for the Indexing service. I decide to google the bug to see what it does. I immediate find dozens of hits all pointing to this post basically saying the problem is a false positive by AVG rather than an actual Trojan.

The file has now been restored and I suffered no ill effects. From the posts I read, I saw that others detected the file in the DLL cache, the system restore cache and in other places. A quick search of my hard disk turned up 4 copies of the file. Now I’m worried that AVG isn’t doing a thorough job. If it found one copy, shouldn’t it have found the others? More things to research I guess.

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.