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:
- The introduction of the Microsoft Web Store (i.e., the Web-enabling of the IS). You can use a URL to access every item in the IS.
- A set of new browser protocols in Microsoft Internet Explorer (IE) 5.0. These protocols include Dynamic HTML (DHTML), Extensible Markup Language (XML), and HTTP-DAV. OWA also makes extensive use of IE 5.0 behaviors, which let page designers specify how a page displays.
- The removal of protocol access from the IS. Exchange 2000 depends on IIS to handle protocol access for all Internet clients (i.e., HTTP, POP3, Internet Message Access Protocol 4—IMAP4).
- The implementation of large sections of crucial code (which render output for browser display) as compiled code instead of interpreted code. The net effect is a significant performance increase and the removal of a scalability-inhibiting OWA bottleneck.
- The implementation of the Exchange Installable File System (EXIFS). The EXIFS lets you quickly access streamed data, such as MIME content and audio and video data.
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:
- Exchange, which allows access to user mailboxes
- Public, which allows access to public folders
- Exadmin, which you use to perform administrative operations
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.
Prev. page
[1]
2
next page 
