Installation problems make Exchange upgrade fall flat

The GCN Lab recommends sticking with the current Microsoft Exchange Server software and
not upgrading to Version 5.5 until Microsoft Corp. fixes the installation application.

Version 5.5 will likely work fine, however, if you intend to do a brand-new
installation.

The lab's transition from Version 5.0 was far from fault-tolerant--a virtue Microsoft
has claimed for 5.5. In the end, a Microsoft engineer recommended we go so far as to
reformat our server drive and make clean installations of Windows NT 4.0 and Exchange
Server 5.5. We managed to avoid that by changing the names of five files.

If you do attempt the upgrade, fully back up your server first. Be sure to halt all
unessential services such as anti-virus scanning and utilities that might interfere with
writing to the hard drive.

We installed Exchange Server 5.5 on a dual-Pentium Pro 200-MHz Compaq Computer Corp.
ProLiant 5000 server running Windows NT 4.0 Server and Service Pack 3.

The first series of errors appeared when Exchange 5.5 tried to update three .edb files
from Exchange 4.0, installed more than 16 months ago.

Version 5.5 was supposed to convert priv.edb, pub.edb and dir.edb--the private, public
and directory databases, respectively--to a new schema.

The error messages indicated a formatting problem in our data stores, which hold users'
e-mail, calendar items and contact databases. The software identified the errors using
numbers such as c1032c00 and c1032c08.

Our first contact at Microsoft technical assistance told us to run a command-line
utility, edbutil.exe.

But Microsoft's online tech support warned that edbutil "can cause problems.
Before you run this utility, you should first make a backup copy of the database files.
Microsoft cannot guarantee that problems resulting from the use of this utility can be
solved. Use this tool at your own risk."

That sounded ominous. We did make extra copies of the .edb files, which would be a
tough job for networks larger than ours, which usually has fewer than a dozen Exchange
users.

Even so, our database files totalled almost 170M.

At first glance, edbutil worked fine when we did a consistency check on all our
databases.

We learned later about an alternate utility called isinteg.exe. If you confront similar
problems, we recommend you start with isinteg.

When we resumed installation, another error popped up, identified as c1032bfc.

Microsoft's next response was that we should completely uninstall anti-virus products
from Symantec Corp. and Computer Associates International Inc.'s Cheyenne Division.

But we didn't have either of those anti-virus applications on the server--only IBM
Corp.'s AntiVirus 3.0. Microsoft tech support then added that product to the list and told
us to uninstall it.

It's common to have to disable a virus protection program when installing new software,
but we've never had to uninstall one completely.

Exchange 5.5 still wouldn't install and returned the same c1032bfc error.

We then discovered that we had to uninstall Symantec's Norton Utilities for Windows NT,
too.

Merely stopping such applications services should allow trouble-free installation, but
in this case it did not.

Minus Norton Utilities for NT, Exchange did finally convert the .edb files for Version
5.5.

But the installation failed again when it attempted to access the imsperf.dll file. It
reported the file was in use even though no Exchange service or any other application
should have been accessing the performance file.

A Microsoft engineer recommended that we abort the upgrade. When we did, the
installation program failed to restore anything.

Our Exchange Server installation was stuck straddling two worlds with some files from
Version 5.0 and others from 5.5.

So much for fault-tolerant installation.

After checking the versions of several Exchange files, the engineer gave us three
choices: restore our backup copy; establish Exchange Server on another server, transfer
the data stores and pray; or wipe our server and do a fresh install of NT and Exchange
5.5.

We decided that restoring the backup would only lead to the same glitches when we
attempted another upgrade.

We could establish a new Exchange server only at the risk of not getting back all our
information.

We found the reformat and fresh installation idea unacceptable.

While on hold with tech support, we tried installation again.

When we hit the Dynamic Link Library roadblock, we searched in the Task Manager to see
whether anything was accessing that file. Nothing was.

On a hunch, we opened Windows NT Explorer and changed the name of imsperf.dll to
imsperf1.dll. If any app had been accessing that file, renaming it would have been
impossible.

Then we tried writing that file again and got a fresh imsperf.dll file just fine.

Four other .dll files popped up the same error message.

We renamed them, too, and all then wrote successfully.

The upgrade proceeded and, in the end, Exchange 5.5 came online.

We concluded that Exchange Server 5.5's setup program had been incorrectly reporting
the status of its message store files and a handful of its own .dll files.

We suspect government administrators might encounter some of the same problems and risk
harming their users' databases.

Although we finally succeeded and found that much of Exchange 5.5 itself works well, we
recommend that administrators wait until the upgrade path is freed of the obstacles we
encountered.

After Exchange 5.5 was up and running, we began working with its new Outlook Web
Access, which was supposed to fix authentication problems we discovered in Exchange 5.0 [GCN, Aug. 11, 1997, Page 47]. The lab
will report on this important feature in a future issue.

Any application upgrade that puts vital data at peril--even Microsoft warns its
utilities should be used "at your own risk"--deserves a poor rating.

When Microsoft releases the inevitable hot fixes and service packs, we'll take another
look at Exchange Server 5.5.