Three years after its debut, Microsoft Outlook Web Access (OWA) is splitting at the seams and showing more signs of wear than any other Microsoft Exchange Server component. Originally introduced as part of Exchange Server 5.0, OWA lets you use a Web browser to connect to Exchange Server mailboxes and process mail, contacts, and calendars. OWA also lets you use a Web browser to set options such as account passwords and out-of-office notifications.
With updates in Exchange Server 5.5 and Exchange Server 5.5 Service Pack 1 (SP1), Microsoft has steadily improved OWA's functionality, but recent technical developments (e.g., the Web-enabling of the Information Store—IS) have bypassed the original architecture. The time has come for a complete OWA makeover—and that's exactly what Microsoft delivers in Exchange 2000 Server (formerly code-named Platinum). OWA's new technical underpinnings leverage Web browser advances to make OWA more usable and scalable than ever before.
If you want to deploy an easy-to-use, easily maintained client solution that uses Exchange Server as a mail server, you need to consider OWA—not only its benefits but its limitations. And if you decide that OWA is worth a try, you'll need to understand OWA 2000's architecture, its major changes from previous versions, its administration, and its performance. After all, OWA 2000 is more than simply an upgrade—it's a whole new beginning.
The Search for a Stateless Client
Systems administrators will likely tell you that the biggest challenge they face in large Exchange Server deployments is installing client software on users' desktops. For example, Microsoft Outlook 2000 is the most feature-rich and functional Exchange Server client, but it's fat and often difficult to deploy. Each Outlook 2000 feature demands a lot of disk space and requires user training and Help desk support. Also, you need to configure a Messaging API (MAPI) profile before you can use Outlook 2000. Although large hard disks can handle fat clients and you can use solutions such as Microsoft Systems Management Server (SMS) to deploy the software and third-party products such as Profile Maker (http://www.autoprof.com) to ensure that the system generates profiles automatically, you're looking at a lot of extra work. Profiles aren't simple, especially when you need to set default options and configure offline or personal folders.
OWA is Exchange Server's implementation of a stateless client. A stateless client leaves no footprint on a PC. The local machine holds no user data or profile, so users can move between PCs without worrying about creating a user profile. Everything stays on the server, thus reducing deployment workload at the expense of higher bandwidth requirements. OWA's feature set is not as rich as that of Outlook 2000, but reduced training and support requirements offset the limited options. Microsoft designed OWA to meet the needs of users who simply want to send a few messages or consult a calendar from time to time. Typical OWA users might work in educational institutions or use Outlook at work but want a simpler client at home.
The ever-growing popularity of Web browsers across multiple platforms—including the latest developments in microbrowsers for cellular telephones—makes OWA an essential Exchange Server connectivity option. Simply put, OWA introduces Exchange Server to a huge potential community of client connections. From a deployment perspective, OWA lets systems administrators connect to desktop platforms that don't have an Outlook option (e.g., OS/2, UNIX, low-end PCs).
In the Beginning
Microsoft based the original OWA architecture on frames, Active Server Pages (ASP), Collaborative Data Objects (CDO), and MAPI. The user interface (UI) is built around a set of frames that delineate components such as the Outlook bar, an icon bar, and folder contents. ASP contains VBScript code that references CDO objects to manipulate items such as mailboxes, folders, and calendars. The OWA application runs under Microsoft Internet Information Server (IIS) and communicates with Exchange Server through MAPI. The application interprets incoming HTTP requests that browsers make, translates the requests into MAPI functions, executes the functions, then sends the results back to the browsers in standard HTML.
Historically speaking, OWA has its limitations. If you want to connect only a couple of browsers to Exchange Server, OWA does a great job. However, as the number of connections climbs into the hundreds, OWA is less desirable. The maximum number of connections that OWA can support is between 700 and 800, no matter how powerful the host server is in terms of CPU speed, number of CPUs, or amount of available memory. The interpreted nature of the code in ASP—with the amount of work that the OWA application performs to pass requests back and forth between browsers and Exchange Server—limits scalability. A major goal of the new version of OWA is to address scalability.
OWA's designers used the best tools at their disposal to create the first version of OWA. In 1996 and 1997, ASP seemed like a great way to create browser applications, and MAPI was the only way to communicate with Exchange Server. Consequently, ASP and MAPI were OWA's natural foundation. Exchange 2000 marks a fundamental shift in Exchange Server's technical underpinnings. Additionally, new technologies are available to replace ASP and MAPI. Therefore, the fact that OWA 2000 uses a very different approach to deliver a highly functional and high-performing user experience comes as no surprise.
OWA 2000 depends on five major technical advances:
These advances are the essential underpinnings of OWA 2000 and illustrate the radical overhaul that Microsoft has undertaken in this release.
Major Changes All Around
OWA is an optional Exchange Server 5.5 component, but OWA 2000 installs by default on all Exchange 2000 servers. Figure 1 illustrates the new OWA architecture. Because Exchange 2000 depends on IIS to handle incoming requests for all Internet protocols (including HTTP), IIS is also mandatory on all Exchange 2000 servers. When you install Exchange 2000, it registers as an Internet Server API (ISAPI) application with IIS, and the setup program creates virtual roots for three applications:
IIS interprets incoming HTTP requests from browsers and scans the URL to determine which application needs to handle the request. The basic URL to connect to OWA is in the form http://server_name/exchange. This URL causes IIS to conduct a logon sequence to identify which mailbox to connect the user to, as Screen 1 shows. However, IE 5.0's default behavior is to use your cached Windows NT credentials for authentication. You'll see the logon screen only if the cached credentials are expired or you're attempting to connect to an Exchange server in a domain different from the one you're logged on to—a circumstance that might occur if your logon domain still uses NT 4.0. Exchange 2000 runs only on Windows 2000 (Win2K). Most often, users will include their mailbox in the URL as follows: http://server_name/exchange/mailbox_alias. For example, to connect to my mailbox on a server called mail1.compaq.com, I'd use the URL http://mail1.compaq.com/exchange/redmond.
The code for the Exchange Server ISAPI application resides in davex.dll, which can connect to mailboxes or public folders in the IS. OWA 5.5 uses MAPI for these connections, but OWA 2000 uses epoxy, a new high-speed interprocess link, to connect IIS to an HTTP protocol stub within the IS process. The stub then links to exoledb.dll (i.e., the general access point for Internet protocols), which in turn processes the requests for mailbox, folder, or item-level data.
Data that the OWA application sends back to the browser traverses the same route, with DavEx performing much of the basic rendering that ASP script code formerly accomplished. OWA 2000 uses EXIFS to transfer data from the new streaming database, if necessary. The streaming database is where Internet clients store information in its native format (e.g., MIME). MAPI clients continue to use the EDB databases as their basic repository.
HTTP-DAV, which Internet Engineering Task Force (IETF) Request for Comments (RFC) 2518 describes, is an extension of the basic HTTP 1.1 specification that adds a set of methods (i.e., commands) to let browsers perform basic document management and file-system commands. Through DAV, browsers can retrieve and set properties on documents, as well as copy and move files. The most interesting method is Search, which lets browsers use a Microsoft SQL Server-like syntax to enumerate folder contents or item properties and combine them into a set that a browser can manipulate. The combination of HTTP-DAV and XML lets a browser fetch data (e.g., the set of items in a folder) from Exchange Server, then sort that data on the local workstation—without further reference to the server. OWA 2000 uses these technologies to deliver an advanced set of UI features to browsers that support DAV.
Rich vs. Reach
OWA 2000 supports two distinct classes of browsers: rich and reach. Rich browsers deliver the highest level of functionality, whereas reach browsers let you connect the highest number of browsers to Exchange Server. Unfortunately, the ability to support reach browsers requires you to attain a lowest common denominator in the feature set. Therefore, the capabilities of the two browser families differ widely.
Rich support is available to browsers that understand the latest technologies (e.g., XML, HTTP-DAV). IE 5.0 is currently the only browser in this category, so IE 5.0 delivers the fastest and most attractive interface. With features such as hot-key support (e.g., Ctrl+Enter to send a message), right-button pop-up menus, drag-and-drop support, and in-frame navigation, the IE 5.0 interface approaches the standard you'd expect from a Win32 client—which is a tribute to OWA's developers. Screen 2 shows what you can expect from a rich browser. Unlike previous versions, the OWA 2000 interface uses only two frames.
Screen 2 illustrates several of OWA 2000's new features, including the folder treeview in the left frame, which lets you navigate your folders quickly and easily. The left frame also includes the navigation shortcuts that you find in the Win32 Outlook client. The right frame, which shows the preview pane activated, displays a folder's contents. OWA 2000 now supports a rich-text editor, so the preview pane can display the variety of colors and fonts that users like to include in messages.
Other features available for rich browsers include the following:
These small enhancements help to narrow the gap between OWA and the full-blown Outlook client.
Interestingly, Microsoft has attempted to mitigate the browser's static nature by forcing updates when OWA knows that you've added new items to a view. For example, if you create a new appointment, OWA 2000 automatically refreshes the view to show the new item in your calendar. Unfortunately, OWA still can't determine whether new mail has arrived in your Inbox, so you need to click the Check New Mail button occasionally to receive notifications.
Microsoft has also improved interoperability with other clients. OWA 5.5 can't deal with embedded OLE objects or embedded messages. Users are often frustrated by the
From an architectural perspective, support for HTTP-DAV and XML lets Exchange 2000 offload much processing to rich browsers. Therefore, the server can download raw XML data fetched through DAV search operations to the browser, which then takes responsibility for formatting and displaying the data. Views are a good example of browser rendering in action. The browser caches the data for the initial view, which the browser can reformat without consulting the server. For example, a user can sort the view by a different column or switch to a different view (e.g., from the daily view to the monthly view in the calendar). Caching also improves performance by minimizing round trips to fetch data from the server. Older browsers don't cache data, can't process XML data, and don't support the Extensible Style Language (XSL) protocol to implement local sorting.
Obviously, Microsoft can't expect everyone to upgrade to IE 5.0 overnight; backward compatibility is essential. The challenge is to upgrade and improve older reach browsers' performance when they connect to Exchange 2000—without using any of the new protocols. To meet this challenge, OWA 2000 reduces the amount of data that the server downloads, cleans up the script code in the ASP, simplifies the UI to fewer frames, and takes advantage of the additional performance that the new architecture delivers. Nearly all the functionality available to rich browsers is available to reach browsers, but some major differences in the UI exist. All references to items exist as hotlinks for reach browsers, so you need to select an item (from a folder list) and then double-click it before OWA can process the item. Rich browsers use the same point-and-click, scrollable, multiselect model that Win32 clients use. IE 3.02a or Netscape Navigator 3.0, both of which deliver a reasonable working environment, still set the baseline support for reach browsers. However, after you've experienced IE 5.0 with OWA 2000, you won't want to go downlevel again.
Some Missing Features
Even with rich browsers, OWA is missing some features. The ability to work offline is notably absent, and you can't access personal folder files (PSTs). You can't set rules through OWA, although the server will honor any rules that you set through an Outlook client. Secure MIME (S/MIME) messaging isn't possible because the necessary encryption technology might not be available on the platform that the browser runs on. Don't expect to be able to recall a message or recover deleted items because those options are missing from the OWA UI, as are the options to set up public folders, modify permissions on public folders, and maintain distribution lists (DLs). You have access to the Global Access List (GAL), but because the GAL uses Lightweight Directory Access Protocol (LDAP) instead of MAPI, the access is less smooth and you can't browse the GAL to locate a recipient. This limitation isn't surprising: LDAP is a search protocol, so it delivers the results of your searches as discrete operations. MAPI incorporates the concept of cursor locations within a data set, letting you browse forward and backward from any point in the GAL. Given Microsoft's habit of adding new features with each OWA release, some of the missing features will probably appear eventually.
Customization
Previous versions of OWA are easy to customize because a large portion of the source code is in ASP, which you can edit with tools such as Microsoft FrontPage. However, you need to reapply customizations every time Microsoft releases a new Exchange Server version or service pack. By contrast, OWA 2000 implements a much higher percentage of the code as compiled code (e.g., the davex.dll module), and the source code isn't available outside Microsoft. Therefore, you have fewer opportunities to edit source code and modify OWA's appearance. OWA 2000's implementation of the URL namespace means that you can insert references to Exchange Server data directly inside any Web page, and you can enhance URLs with OWA 2000's command qualifiers. For example, you can now specify a view, sort items in a certain order, and start a calendar at a specific date. For example, the following URL displays my calendar in monthly view starting March 1, 2000: http://server_name/exchange/redmond/calendar?View=Monthly&Date=20000301.
Discovering the features that are missing and the tricks you can perform using OWA 2000's new customization capabilities will take time. Expect sites such as Slipstick Systems (http://www.slipstick.com) and CDOLive (http://www.cdolive.com) to be reliable repositories of sample code, as well as fine sources for tricks and techniques.
OWA Administration
To manage OWA 2000, you typically select Server, Protocols, HTTP, Exchange Virtual Web Server from the Exchange System Manager console. Exchange 2000 stores all of OWA 2000's configuration data in Active Directory (AD), but a slight disconnect currently exists between Exchange Server and IIS. Remember that Exchange Server registers three applications (i.e., Exchange, Public, and Exadmin) with IIS. IIS stores those applications' details in its metabase rather than in AD. Screen 3 illustrates some of the properties of the Exchange ISAPI application as viewed from the IIS Microsoft Management Console (MMC). A link between the IIS metabase and AD is necessary so that administrators can manage this component in the same way that they manage other Exchange Server components such as connectors and public folders. A background thread that runs under the Exchange System Attendant process provides the link between the IIS metabase and AD, but it doesn't work in beta 3. Microsoft product developers have promised to fix this disconnect before the product finally ships. Fortunately, OWA 2000's default settings work well, so you needn't make significant adjustments.
IIS uses the virtual root for Exchange Server to access content. Screen 4 shows that IIS expects the content to come from a local path mapped to the M drive. In fact, IIS uses the M drive to redirect requests for content through the EXIFS, which implements a Win32 interface or file system for items in the IS. EXIFS is available to any Win32 application that can—subject to permissions—use standard Win32 I/O functions to access the IS. Screen 4 shows an example of this feature in action: EXIFS has used the M drive to enable DOS access to a folder in my mailbox. Through EXIFS, the standard Dir command lists all the items in the folder as if they were files on an NTFS or FAT drive. You can use other commands (e.g., Type) to view the contents of items, and you can add items to folders by creating them in DOS or Windows Explorer or by copying them from another directory.
Performance and Bandwidth
Microsoft plans to release Exchange 2000 in April. Formal performance measurements tend to factor into the final phase of product engineering, but early indications show that OWA 2000 is a much more scalable solution than OWA 5.5 is. The removal of MAPI sessions, the removal of direct HTTP support, and the implementation of a high-speed connection between IIS and the IS have produced a very responsive client. At the 1999 Microsoft Exchange Conference, Microsoft gave firm indications that its goal is for OWA 2000 to support approximately 80 percent of an equivalent MAPI client workload on a server. Consequently, a server that is capable of supporting 2000 active MAPI clients will likely support 1600 OWA connections.
Because of the amount of communication that occurs between browser and server, OWA 5.5 often demands more bandwidth than a MAPI or IMAP4 client. Considering the added features, you might ask how much bandwidth is necessary to connect a browser to Exchange 2000. We don't yet know exactly how OWA 2000 will perform, but Microsoft has allegedly reduced network demand toward the level that a MAPI client requires. However, even without solid performance tests, you can see that smarter connectivity and the ability to exploit browser capabilities to process data without reference to a server can only improve matters. Every user is unique, so your mileage will vary according to workload and the nature of the messages that OWA processes.
Microsoft designed Exchange 2000 to support deployment in a front-end/back-end configuration. Some servers will act purely as protocol proxies, passing communication to back-end servers that handle storage. The major advantages of this configuration are easy scalability and the capacity to give users a single point of contact from which to access their mailbox—no matter where their mailbox resides. IP load balancing, implemented in hardware or software (e.g., Windows Load Balancing Services), accepts incoming client requests to an address such as http://mymail.com/exchange and directs them to IIS on front-end servers. The front-end servers perform authentication, then consult AD to determine which back-end server to connect to. All major ISPs use a similar configuration to service massive communities of clients, and OWA 2000 is a major weapon in Microsoft's campaign to promote Exchange Server to ISPs. This configuration doesn't support MAPI clients.
Is OWA for You?
Can you replace Outlook 2000 with OWA? If you're accustomed to the way Outlook works and use many of its features, you probably won't want to give up Outlook. But companies that want to deploy Exchange Server to user communities but avoid the burden of client deployment and maintenance now have an effective alternative. How many people will decide that they can do everything through a browser? What effect will OWA 2000 have on the popularity of full-blown clients? Only time will tell.
Even if you're happy with Outlook 2000, OWA 2000 is a great way to connect to Exchange Server. And OWA 2000 is more than acceptable as a secondary client when Outlook isn't available, such as when you're travelling, working at home, or using someone else's PC. Browser support has improved enormously since 1996. Keep an eye on further improvements over the coming years.
