Now is the time for a desktop refresh
With the arrival of Windows 2000 (Win2K), many companies are considering the benefits of a complete desktop refresh. According to many surveys, companies plan to replace Windows NT Workstation and Windows 9x with Windows 2000 Professional (Win2K Pro). Given that the cost of visiting user desktops is typically much higher than that of upgrading servers (simply because administrators need to visit more desktops than servers), companies are planning their refresh projects according to long cycles—typically 3 to 4 years.
No one wants to waste money constantly upgrading a company's desktops, so plans call for a one-step strategy in which upgrades to the OS, applications, and any necessary hardware can occur simultaneously. Office application suites and browsers are typically at the top of such upgrade lists. With Microsoft Exchange 2000 Server on the horizon, now is a good time to review your email client options and factor them into your desktop refresh.
Currently, you have three primary options. First, you can use the latest version of Microsoft Outlook, the full-featured client that the Microsoft Office suite includes. Second, you can switch to an Internet-centric focus and select an IMAP4 client. Outlook Express—Microsoft's IMAP4 client—is part of Internet Explorer (IE), but you can connect many other IMAP4 clients to Exchange Server. After all, the primary advantage of opting for an Internet protocol is choice. Third, you can attempt to direct application access, including email, through a Web browser. This strategy is attractive because you don't need to install any application-specific code; however, you frequently miss out on features.
Each option has advantages and disadvantages. Let's take a close look at each to determine which choice is right for your company.
Going with Outlook
The latest version of Outlook shares the 2000 moniker with Exchange 2000, so you might think that Outlook is naturally the best client. Outlook 2000 easily offers the most features and functionality of any client that you can connect to Exchange 2000, and you can connect Outlook to an Exchange 2000 server as easily as to any previous version. However, you must pay for all those features. Outlook is part of the swollen Office 2000 application suite, and substantial effort is necessary to deploy and configure Office to user desktops. The requirement to upgrade to Office 2000 is one reason many companies are slow to move to Outlook 2000. The extended feature set is a double-edged sword—the availability of all those features is great, but do you really need them? Outlook is just like any other Office application: Customers use 10 percent of the product's features all the time, 20 percent of the features some of the time, and the remainder of the features hardly ever. I'm not yet sure which Outlook feature rivals Microsoft Excel's pivot tables in terms of neglect by the average user, but a few features are competing for that distinction.
Outlook doesn't deliver an especially smooth or comprehensive client for Exchange 2000, probably because Microsoft is tied to an overall schedule for Office and can't ship an update for Outlook until everything else is ready to go. Because of this situation, gaps appear in the client/server support matrix. For example, Outlook 2000 doesn't support Exchange 2000 features such as multiple public folder hierarchies and granular permissions. Outlook won't support these features until the next major Outlook release that accompanies the next version of Office, which will probably arrive in 2001.
In the hands of knowledgeable programmers, Outlook is a customizable and flexible tool. Anyone who doubts Outlook's elasticity needs only to review the set of add-ons and extensions available on the Internet (e.g., at Slipstick Systems—http://www.slipstick.com). Fans of VBScript find plenty to shout about in Outlook, and the Collaborative Data Objects (CDO) interface simplifies the manipulation of complex objects such as mailboxes, folders, or messages with sets of attachments. Articles and books comprehensively reveal the secret world of Outlook programming; however, relatively few people attempt to exploit Outlook's programming power, possibly because they're lost in the huge number of out-of-the-box features and can't think of anything they could possibly add. Nevertheless, should the need arise, Outlook can deliver extra features through customizations that range from a simple change in the standard view to the creation of thousands of lines of VBScript code that power a set of electronic forms. Of course, not only corporate programmers appreciate the range of possibilities that the Outlook programming model offers. Recent email virus attacks (e.g., Melissa, WormExplore.Zip) show that intruders can easily exploit the fact that every Outlook user can execute code that arrives on his or her desktop in neatly packaged attachments. If you choose Outlook, you'll need to use virus checkers to protect every Exchange server. Simply depending on the traditional desktop virus-checking agents won't provide adequate protection against viruses that leverage VBScript or HTML code.
If your network supports Internet protocols, Exchange 2000 uses them instead of Microsoft's proprietary protocols. For example, SMTP—rather than remote procedure calls (RPCs)—links routing groups (or sites, in Exchange Server 5.5 terminology). However, Outlook remains firmly embedded in the Messaging API (MAPI) and RPC domain, and in my opinion, Outlook doesn't even use RPCs well. For a real-world example, simply use Outlook to connect to an Exchange 2000 server over a dial-up connection, then monitor the number of bytes that the client transmits to the server. Much processing occurs before Outlook connects fully and lets the user perform any useful work. Outlook chews up a lot of network bandwidth and is easily the heaviest client in terms of connections. By comparison, IMAP4 clients such as Outlook Express are svelte lightweights that can connect, upload and download messages, and log off in the same amount of time Outlook takes to laboriously negotiate with Exchange 2000.
The problem doesn't lie with Exchange 2000. If the server mandated such a complex and drawn-out connection protocol, all clients would suffer. Despite the program's lead in features and functionality, Outlook 2000's MAPI-RPC implementation is inefficient. Evidence that the MAPI-RPC combination can deliver great performance and a reasonable feature set exists in the original Exchange Capone client, which shipped with Exchange Server 5.0 and 4.0 but mysteriously disappeared from the Exchange Server 5.5 CD-ROM. Capone is fast and powerful. Outlook 2000 is also powerful, customizable, and offers better forms processing, but it's huge and sluggish.
I don't want to treat Outlook unfairly. I should point out that Outlook serves two masters: Exchange Server is the primary server for Outlook in corporate environments, but you can also connect Outlook to other email servers through MAPI. For example, Compaq offers a MAPI driver through which you can connect Outlook to Compaq OfficeServer for OpenVMS. This flexibility illustrates the power of MAPI as a client protocol.
From an Outlook perspective, Exchange Server doesn't provide the largest group of potential clients. As part of the Office suite, the Outlook client is in the hands of more than 100 million people, many of whom configure Outlook in Internet mode to connect to IMAP4 or POP3 servers, including popular free email systems such as Hotmail. Splitting a client's personality and serving two distinct families of email servers is difficult, but that's what Outlook attempts to do. Sometimes I wonder whether Outlook falls short in its effort to be all things to all people.
Outlook 2000 is the best client for Exchange 2000 in terms of features. You pay for that large feature set in disk storage, Help desk support, and network bandwidth. If you can afford to deploy Outlook to user desktops and train users to take advantage of the feature set, Outlook does a great job.
Going with IMAP4
According to the pundits, the Internet is where all the action is. IMAP4 represents the state of the Internet art when it comes to messaging-client protocols, and any IMAP4 client can connect to Exchange 2000. Screen 1 shows the major properties that you must define to connect Outlook Express to an Exchange 2000 mailbox. Note that you use the same server for both incoming and outgoing mail, but you use SMTP to send outgoing messages. You can use the same server because every Exchange 2000 server can send and receive SMTP messages. Such isn't the case with Exchange Server 5.5, in which SMTP is an optional protocol that you enable by installing the Internet Mail Service (IMS) and configuring it to support IMAP4 clients.
The major advantage of an IMAP4 strategy is that any IMAP4 client running on any client platform can connect to Exchange 2000, and any client that supports Lightweight Directory Access Protocol (LDAP) can use Win2K's Active Directory (AD) to search for and validate email addresses before you send messages. Of course, you need to test clients against Exchange 2000 to determine which features they support, then decide which client to deploy. Clients must connect to a Global Catalog (GC) server to access information about all user accounts within a Win2K forest. Clients gain access by defining AD as a new directory service, as Screen 2 shows.
Companies that want a simple email client or that need to support multiple platforms for which a MAPI client is unavailable (essentially, any platform except Windows) typically select IMAP4. For example, IMAP4 is a great solution if you need to deliver a messaging service to a community of UNIX workstations.