Easy-to-use isn't easy to administer

B ill Gates is on a mission to make productivity software easier to use. That's great for end users, who only see the tip of the office suite iceberg. What users don't see is the administrative end - the portion of the software iceberg that can sink ships if not configured correctly. If Bill really wants to make software easier for us all, he should make it as easy to install and configure as it is to use.

For more than a year my company, which has more than a little technical savvy, has experienced e-mail problems - all because the Microsoft software wasn't configured optimally. Whose fault is this? Partly ours - we couldn't seem to hit upon the best way to configure the Exchange Server software and Outlook client. But Microsoft deserves a hefty portion of the blame for providing poor documentation and instructions on how to best set up the software.

I've long dissed Outlook (pet name: "Lookout!") because it didn't work right, especially remotely. Our technical people have spent hundreds of hours tweaking and twiddling with Exchange and Outlook, always with dismal results.

Like many other companies, our original office network was based on Novell's NetWare platform. Our early e-mail system was based on GroupWise, which worked well for office and remote users alike. NetWare and GroupWise set our notions of what a network should be and how it should work.

Then we started to hear more about Microsoft Exchange Server and its complementary products, including Outlook and Internet Information Server (IIS). The concept of Outlook's full integration of productivity tools sounded good. And with IIS, Microsoft was promising the next level of connectivity for a widely distributed work force, which we have. So we migrated to Exchange and Outlook.

When we installed the original Windows NT servers and the various application software packages, we configured the software using an approach instilled during our NetWare days. And why not? It seemed reasonable at the time, and the Microsoft documentation wasn't clear on its installation and configuration instructions.

What followed was a year of disastrous disappointment with Exchange and especially with Outlook.

Our Outlook remote users were incredibly frustrated with the performance and capabilities - or lack thereof. We had selected Outlook based on the promise of seamless integration of our common office productivity tools, such as e-mail, calendaring and scheduling. We also wanted to make use of remote access via the Internet, an integral feature of IIS. Very few of these features worked properly, if at all.

Even though Currid & Co.is small, we have the power of the pen behind us, and Microsoft offered to help us get Exchange and Outlook up and running correctly. But even this consultation process dragged on for months. On Microsoft's direction, we tried many "solutions," including beta software, software downgrades and upgrades, patches and fixes, server reconfigurations and everything else anyone could think of. We talked with everyone from technical support people to product executives. We spent a lot of time trolling for answers on Microsoft's Online Support service, where we found thousands of pages of (sometimes conflicting) information about configuring Exchange, IIS and Outlook. Through the service's user groups, we learned we weren't alone in our problems. Many others from around the world described similar problems and offered jury-rigged solutions.

It wasn't until two people from Microsoft's professional consulting service paid a visit that we learned the error of our ways. According to them, the software simply wasn't configured properly. They tweaked and twiddled for a day, and now the software seems to work as expected. Of course, the jury is still out until we give it a thorough shake-out.

We learned a few lessons from this exercise:

First, don't make assumptions on how a product should work. We let our NetWare philosophy influence how we thought Microsoft networking should work. We learned the two vendors use quite different approaches.

Second, if you're having technical troubles, take a look at how you've configured things. If necessary, bring in an expert. It took a few experts with years of Microsoft networking experience to point out our problems. While the configuration was not unreasonable, we would not have come up with it on our own.

And the last lesson is for Microsoft. We found the documentation for these complex products to be woefully inadequate. In some cases, Microsoft's own instructions were contradictory and confusing. We had little choice but to make the assumptions we made, which led to our problems.

So, Mr. Gates, if you want to make a product that's easy to use, make it easy for the administrators as well.