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.
Generally, if you're interested in simple messaging, IMAP4 is a good solution and is the fastest way to access messages on an Exchange 2000 server. Clients such as Outlook Express support advanced features such as autosignatures, an HTML-format message editor, spell-checking, the ability to work offline, and secure email. (IMAP4 clients can use the same X.509 version 3 certificates that Outlook 2000 uses, so interoperability isn't a concern.) Outlook Express even supports rules processing, as Screen 3, page 124, shows, although the capability isn't quite as sophisticated as the capability that Outlook 2000 offers. However, if you want features beyond basic messaging (e.g., calendaring, applications hosted by Exchange Server public folders), IMAP4 loses some of its luster. You can certainly access public folders' contents by adding the folders to the list of default folders that the client automatically accesses, but you won't be able to use any customized forms or code to drive the folders' content.
Alternatively, you can use Network News Transfer Protocol (NNTP) to access public folders on an Exchange server. Screen 4, page 124, shows Outlook Express accessing a newsgroup called Windows 2000 Forum, a popular forum for Compaq consultants. A public folder on an Exchange Server 5.5 system actually hosts the newsgroup, but the newsgroup appears in exactly the same format as any other NNTP newsgroup. However, once again, you can't access any customized forms or code.
Missing out on access to electronic forms and code isn't a disaster for the majority of Exchange installations because few people have deployed applications that exploit public folders. Perhaps administrators are intent on delivering the messaging service and haven't decided how best to use public folders, or perhaps administrators are reluctant to use Exchange Server as the basis for applications. Every company is different, so before you can assess whether IMAP4 is a viable candidate for deployment, you need to understand exactly how your implementation uses public folders.
Going with a Browser
The browser strategy is essentially a search for a stateless client. In other words, you want a client that you don't need to configure in any way. The user simply points the browser at a URL to launch an application, and the application downloads the code necessary to provide the feature set. Of course, this strategy has existed under a different name—mainframe computing—since nearly the dawn of computing. Users who dubbed mainframe and minicomputer email systems "green-screen email" upon the advent of PC-driven client/server email applications such as Exchange Server and Lotus Notes now seem quick to embrace the concept of a stateless client. This new support for the stateless client probably has a direct relationship to the effort and expense necessary to deploy, maintain, and update PC clients.
The advantage of a stateless client is that you don't need to configure any user data on the PC. Everything, including software updates, comes from the server. Users can move from PC to PC and access email without interfering with other users' data, which might have previously downloaded onto the PC. This flexibility comes at a cost. Network traffic is higher because all the data, including application code, must come from a server. Working offline is impossible because a stateless client offers no support for the user data necessary for offline work.
Microsoft's first attempt to provide Web-based email for Exchange Server—through the Outlook Web Access (OWA) application—has somewhat flawed foundations. To be fair to Microsoft, no one could have foreseen in 1996 that the company's chosen implementation (which heavily features MAPI and RPCs) would collapse under strain. The version of OWA that Exchange Server 5.5 includes works well in conjunction with IIS 4.0, but its bottlenecks become more evident under load and peak at between 700 and 800 concurrently connected clients on servers as powerful as 4-way Pentium III 500MHz boxes equipped with 1GB of memory. No matter how many CPUs a server has, or how fast they process data, OWA bottlenecks still throttle scalability.
Company history demonstrates that when a Microsoft product fails, the company improves the next version. Microsoft might not get the product perfectly right the second time but usually makes progress. This tendency is evident in OWA 2000. The application is different from its predecessors. The architecture scales better than before, the feature set is more comprehensive, and performance to the browser is snappier.
Key to these improvements is Microsoft's removal of MAPI and RPCs from the OWA equation. Browsers now channel all communications through an IIS 5.0 application that connects directly to the Information Store (IS) process through an interprocess mechanism called epoxy. The IIS application performs all crucial rendering and optimizes the amount and type of traffic that the IS sends to clients. OWA now supports WWW Distributed Authoring and Versioning (WebDAV), an extension to HTTP 1.1 that lets browsers execute document-management functions on server data and that exploits such Web developments as Dynamic HTML (DHTML) and XML to offload processing to browsers. WebDAV, which the Internet Engineering Task Force's (IETF's) Request for Comments (RFC) 2518 describes, is also called HTTP-DAV.
An application that implements standards is fine, but you see the whole picture only when the client side supports the same standards. IE 5.0 is the best complement to OWA 2000. In Microsoft terms, IE 5.0 is an example of a rich client, through which the user attains the maximum feature set and performance, and the user interface (UI), which Screen 5 shows, comes very close to the UI that Outlook 2000 delivers. OWA 2000 also supports reach clients such as Netscape Navigator and IE 4.0 (which don't support WebDAV or XML), but those clients' feature sets aren't as broad as IE 5.0's feature set and their performance isn't as snappy. For example, you can't change views on-the-fly or click an object to select it. However, the improvements that Microsoft has made in Exchange 2000 mean that reach clients benefit from Exchange 2000 even if their UIs aren't as pretty as that of IE 5.0.
From a server perspective, the best news is that OWA 2000 eliminates the bottlenecks that limited OWA performance. Today's multi-CPU systems can support thousands of OWA clients, a capability that makes browsers much more attractive as the basis for an email client.
Ignoring Some Strategies
I've tried to show you the major client strategies that you can take with Exchange Server. Obviously, I've ignored some possible options. For example, I haven't discussed the Exchange Server client for DOS, primarily because I don't know anyone who has used it successfully. I eliminated the Exchange Server 16-bit client because I don't want to recommend an option that I wouldn't use myself. If you need to cater to 16-bit desktops, I recommend you look at an IMAP4 or browser solution, which will deliver better features than those of the turgid MAPI 16-bit Microsoft client.
I've also ignored the Outlook client for Apple Macintosh systems because I've never used it. The general opinion voiced on the Exchange Internet mailing list (at http://www.swynk.com) is that the latest iteration of the Mac client (i.e., version 8.2.1) might be better named Outlook Lite because the client still doesn't deliver the features that Outlook 2000 offers. However, the Mac client does provide standard messaging features—you might call it a compromise between Outlook Express and Outlook 2000 in terms of features and functionality. Don't expect to run Outlook on anything other than a well-specified PowerPC Mac (equipped with a G3 or G4 CPU). Indeed, the latest client will run only on a PowerPC.
If you run older Mac systems, you'll need to consider other options, such as an IMAP4 or POP3 client or Web browser. However, you'll still encounter obstacles. Mac browsers don't support some of the protocols that Microsoft used to create the rich browser client in OWA 2000, so functionality is limited to the reach client. This situation won't improve until Microsoft or Netscape update their Mac browsers to support WebDAV and XML. For that reason, an IMAP4 client such as Netscape Communicator is probably the best solution for low-end Mac systems. You can obtain calendar access by firing up OWA through a browser, if necessary.
On a more fundamental level, be aware that some of the file formats that Outlook for Mac uses differ from Outlook 2000, so you can't share information by transferring Personal Address Books (PABs) or personal stores (PSTs). Finally, significant interoperability problems exist in calendaring because the Mac client still uses the older Schedule+ system instead of Outlook's Calendar. Therefore, ensure that users who want to share calendars use the same client. Because Outlook 2000 supports the most comprehensive set of calendaring features, it's your best option in this case. Microsoft understands that its Mac client isn't strong and is working on a new version that addresses many of the current shortcomings. Expect to see development in this area by the end of 2000.
Finally, I haven't discussed how to use POP3 to access Exchange 2000. This option is feasible if you need simple messaging connectivity. You can configure clients such as Outlook Express in much the same way that you configure IMAP4, but you'll experience reduced functionality.
Make Your Choice
No client is perfect; each has its unique and attractive points. Client software has evolved quickly over the past 3 years, and you can be sure that the evolution will continue. However, you probably can't afford to go back to user desktops and upgrade clients annually, so take the time to review what is available today. Your move to Win2K on the desktop is fast approaching, and Outlook 2000, IMAP4, and OWA all work well on Win2K Pro. The option is yours: Will you upgrade your email client when you move to Win2K?