By Tom Henderson

TURNING Microsoft Mail into something presentable was certainly no mean feat. But it seems the folks at Microsoft got it right this time with Exchange Server-for the most part.

MS Mail, Exchange's predecessor, was like the kid nobody wanted to play with. It had a fatuous file structure, gateways only a mother could love, and it couldn't play nicely with external mail systems without constant supervision. Worse yet, when you invited it onto your system, it largely ignored the existence of all prior competitive releases.

Older MS Mail servers ran on OS/2. But as you'd expect, Microsoft doesn't allow that kind of behavior, now that its divorce from IBM is final. Exchange Server 4.0 requires Windows NT, but it does not need to reside on a Primary or Backup Domain Controller. Living on a PDC or BDC, however, does help. MS Exchange is the latest component in BackOffice, Microsoft's suite of NT applications that also includes SNA Server, SQL Server and Systems Management Server.

Exchange won't work with just any NT version, either. It refuses to install over anything prior to NT 3.51, Build 1057 with Service Pack 4. And the Service Pack it wants isn't the one you can download from the Internet or various online services; it's the one on the Exchange Server CD-ROM in the Support directory for your specific processor. The downloadable Service Pack versions may lack needed files that are included on the Server CD version.

If you've been using the older MS Mail Server software on hardware of that era, you'll want to upgrade your Exchange Server platform to at least a fast 486, pre- ferably a Pentium or Alpha with lots of DRAM. Exchange comes with an Optimizer program that refused to start here at Unitel when we told it we had 50-plus users and just 32MB of DRAM. It looked baleful when we added 16MB, but it worked.

Now for the good news: MS Exchange Server imports old MS Mail and digests users, groups and stored MS Mail messages. It can also link your old MS Mail installation to MS Exchange via a pipe called the MS Mail Message Transfer Agent (MTA). You can connect another type of MTA, for SMTP (simple mail transfer protocol, otherwise known as Internet Mail) if TCP/IP is correctly installed on Exchange Server's NT platform.

And there's more. Exchange can import entire NetWare binderies (users and passwords) through another wizard. It can also import Digital's All-In-1 and IBM's Profs. And if you get the file-format information and export data from your favorite e-mail system, you can import that, too.

Finally, Exchange can be an administrative focal point for full NT user-account administration. As it imports or migrates mail systems, NetWare binderies or foreign accounts, Exchange acts as an agent for user administration. All you do is create an account via importation/migration or manual entry and set up the user's mailbox.

Everything looked good until I tried one of the features that sets Exchange apart from its ancestors-folder replication. Exchange allows two basic types of folders, Public and Private. Inside these folders are data files, forms contents (more on forms next time) and even applications. It's possible to synchronize folders via the LAN, a remote connection or through any method Exchange supports.

However, no folders will synchronize to an Exchange client until you create an Offline folder, which isn't installed. Nor is the process of creating a file obvious or even well described in the Microsoft Exchange Help screens. If you try to synchronize folders from a remote or local connection to Exchange, it'll balk and ask you to create such a folder.

To create an Offline folder, choose a mailbox (if you have several, use your primary mailbox) and click on File/Properties, then choose the Synchronization tab. Pick on- or offline synchronization for the folder. This spawns a wizardette that allows you to pick the name and location of the Offline folder file. The one you choose then becomes the repository for mail and other changes made to public or private folders and their contents. Once reconnected to MS Exchange, choose Tools/Synchronize/All Folders to allow updates to proceed correctly.

NetWare, Windows 95 and 3.1x users will hit another rough spot. Although NetWare-based Exchange clients should find MS Exchange Server, I haven't been able to make that option work without enabling GSNW (Gateway Services for NetWare) on the Windows NT server. Although it's spectacularly easy to install GSNW on an NT server (and its associated account on a NetWare server), it slows the mail link and, in theory, shouldn't be necessary. Once GSNW is enabled, however, NetWare clients can find Exchange over IPX/SPX (NWLink Services on NT Server) or via TCP/IP, if the routing is set up for the connection.

When you sand down these and other burrs, Exchange becomes easier to live with. The SMTP-Internet Mail support is easy to set up. It's so easy, I initially had trouble because I set too many options, second-guessing the Exchange documentation.

Mail users who find that their messaging systems don't correctly decode files from the Internet have easy options in Exchange. Exchange supports several encoding file methods, such as MIME (multipurpose Internet mail extensions) and UUencode (UNIX-to-UNIX encoding), with several options. The encoding is necessary because the Internet is 7-bit. All nontext files (documents, programs and so on) must be changed to 7-bit to cross the Internet, then decoded back to their original 8-bit condition. Exchange allows domains (such as cmp.com) to be encoded to match their decoding ability. This means binary attachments to messages can be ÒtunedÓ for each organization doing e-mail, allowing formerly incompatible Internet mail gateways to exchange files correctly without user intervention.

So there you have it. A little spit and polish and a lot of sanding, and Exchange becomes a lot more attractive than its unruly predecessor.