Eating My Own Cooking

A traditional down-home expression says you can determine how good your cooking is by eating it yourself. Some employees at Microsoft have twisted that expression into, "We eat our own dog food," meaning Microsoft uses its own products to run its corporate services. I'm not sure I understand why Microsoft prefers to imagine it produces dog food instead of people food, but I admire Microsoft's principle of using its own products to run its services. In fact, I like the principle so much that I tried it myself.

I don't make products, so my twist on eating my own cooking (not dog food—I feed dog food to my dog) is to force myself to use and live with technology I've reviewed and recommended in this magazine. Lately, I've spent a lot of time reviewing and recommending thin-client technology, such as Microsoft Windows NT Server 4.0, Terminal Server Edition and Citrix MetaFrame. As a result, I decided to use these products as my core computing technology on a daily basis.

A Dog's Life
From a computing perspective, my day-to-day job consists of accessing my email, both Microsoft Exchange Server and Simple Mail Transfer Protocol (SMTP) email; accessing my Exchange-based calendar; word processing with Microsoft Word; performing spreadsheet analysis with Microsoft Excel; and sharing files with my fellow Lab Guys. I perform all these activities from my desk at the office, while I'm puttering around in my small office/home office (SOHO) lab, and while I'm on the road using my laptop.

Based on my application and location needs, I constructed an appropriate computing environment that lets me access my files from anywhere. First, I installed Terminal Server and Meta-Frame on an unbranded server in my office. For SOHO access, I installed a Wyse Winterm 3000 terminal and configured it to connect to the office server over an ISDN connection. Finally, I added both the Microsoft Terminal Server client and the Citrix Independent Computing Architecture (ICA) client to my laptop so I can access my applications using a dial-in Remote Access Service (RAS) connection when I'm on the road.

How did my thin-client computing grand scheme work out? Unfortunately, not as well as I would have liked. The first set of problems I encountered while installing desktop applications on the server system were predictable. I know that many applications are not compatible with the Terminal Server and MetaFrame architecture, but I was unprepared for how ugly the situation got.

Chasing My Tail
When I started loading applications onto the office server, everything went well. I loaded Eudora Pro (my favorite Post Office Protocol 3—POP3—mail client), Microsoft Outlook 98, and a handful of my favorite utilities. The installation went so well that I got overconfident and stopped taking snapshots of my Registry. Without these snapshots, I had no way of reverting my Registry to a safe point in case I ran into trouble during a subsequent product installation. My first sign of trouble happened while I was installing Microsoft Office 97.

The base Office 97 package installed without a hitch, although I later learned that it corrupted my Outlook 98 configuration in a major-league fashion. I wrote off this experience as my mistake—I should have installed Outlook 98 after I installed Office 97. After the Office 97 installation completed, I automatically began installing Office 97 Service Pack 1 (SP1), but the setup program wouldn't run.

Being a clever guy, I tried moving all the Office 97 files from my laptop to the server. I decided this approach was the quickest (and perhaps only) way to get the SP1 features onto the server. Although this approach worked, it introduced areas of instability in Office 97. For example, when I used the monitor and keyboard attached to the server to request a new Word document, I got a new (blank) document. When I performed the same function from a Windows terminal attached to the server, the software hung.

Don't get me wrong; I'm not blaming the Terminal Server and MetaFrame environment for all my problems. Clearly, I was asking for trouble when I moved Office 97 from my laptop to the server. However, if Terminal Server and MetaFrame would have run the Office 97 SP1 setup program, I wouldn't have found myself in such a sticky situation in the first place.

From Bad to Worse
After I worked through most of the problems with Office 97 and managed to reinstall Outlook 98 on the server, I tried to install Microsoft FrontPage 98. I can sum up my FrontPage 98 installation experience with one word—awful.

At first, FrontPage 98 appeared to install OK. However, when I tried to use the software, my system displayed an error message stating it couldn't find some of the FrontPage 98 .dll files. When I looked for these files on the server's hard disk, I found them right where they should be. After much experimentation (i.e., wasted time), I gave up and moved all the .dll files to a subdirectory defined in the PATH statement for all user definitions on the server.

If I were Microsoft, I'd be pretty embarrassed at how poorly its applications install and run under Terminal Server and MetaFrame. As bad as my experience was with Microsoft's applications, I had an even worse experience when I tried to install Qualcomm's WorldMail SMTP server software on my office server. During the WorldMail installation process, the setup program suddenly vanished without error or warning. One minute the installation was running, and the next minute I was staring at my standard desktop—ouch.

Dog Days
Through tenacity, persistence, and outright aggression, I got the business applications I needed up and running on my office server. The next challenge was actually using the server for my core computing on a day-to-day basis, and that's when the next wave of problems hit me. What happened? Was I able to overcome these new obstacles? Stay tuned, and I'll reveal these and other answers in next month's Lab Guys.

End of Article