Chapter 5: Outlook Web Access

---

Overview

Experienced Exchange administrators are all too aware that the speed of client deployment limits how quickly they can deploy Exchange within an enterprise. Outlook is a highly functional client, but deploying Outlook takes a lot of work, especially if you want to tailor the options to suit your company's requirements. To some degree, the utilities in Microsoft's Office Resource Kit, including the Outlook Custom Installation Wizard, and tools from company like ProfileMaker (www.autoprof.com) help to speed deployment. However, there are often situations where you simply do not need to provide Outlook to user communities that, for one reason or another, only need relatively simple features.

The major advantage of a Web-based client is that it does not need an administrator to download code or otherwise configure a user PC. Simply point the browser to the correct URL to launch the application, and the browser downloads whatever code is necessary. Of course, there is nothing new in this strategy, because it has existed under a different name (main- frame computing) almost since the dawn of computing. Those who decried mainframe and minicomputer email systems with the term "green screen email," at the advent of PC-driven client/server email applications such as Exchange and Lotus Notes, now seem to be quick to embrace the concept of a Web client, possibly because they have been burned by the effort and expense required to deploy, maintain, and update PC clients.

With Web clients, users can move from PC to PC and access their email without interfering with data belonging to other users who might have previously used the PC. There is obvious flexibility in this approach but at a cost. Network traffic is higher because all data, including application code, must come from a server. Working offline is not possible, because there is no way to support the user data needed to work offline. Web clients do not usually satisfy people who need to work offline regularly, such as road warriors. Road warriors love their ability to work anytime and anywhere with or without network access.

From a strategic aspect, delivering a highly functional Web client is important to Microsoft for a number of reasons:

• The size of the potential market (and therefore paid client access licenses) for Exchange is only limited by the number of browsers in use.

• Browsers support many platforms that Microsoft does not build clients for, so clients are available for Exchange on platforms that it would not otherwise cover.

• Browsers do not require the same hardware performance or capabilities as full-featured clients, so it is much less expensive to deploy a browser-based messaging system.

• Browsers provide a ubiquitous low-maintenance, zero-configuration, low-support client that can be quickly deployed for schools, universities, or in any other situation where people want messaging, but perhaps not to the degree of sophistication available in purpose-designed clients.

• A browser is the client of choice for many ISPs, largely because they can control the user interface and can incorporate revenue-generating advertisements, which in turn pay for the free email service usually offered as an inducement to subscribe. The success of hotmail.com or any of its competitors is evidence of the popularity of browsers in the ISP world.

• Microbrowsers in new devices such as cellular phones can link to Exchange over a suitable network connection such as GPRS.

People often talk of browsers as stateless clients, because they do not leave traces of their presence on a PC in the same way that a client such as Outlook does. The browser downloads some files (cookies, .html, and .asp pages plus associated graphics) into the local cache, but this is nothing in comparison to the footprint left by Outlook. Before Outlook can start, you need to create a profile, which involves making changes to the system registry. During operation, Outlook creates and uses other files, such as offline stores, personal folders, the offline address book, the Outlook bar, and so on. If different users access the same PC, they can interfere with each other's data and settings, albeit unwittingly. The usual solution is to either make sure that PCs are purely personal devices only used by a single individual, or to keep as much data as possible on servers and download to client PCs after they have logged on to the network. Either approach works, but the first requires you to deploy at least the same number of PCs as you have users (and probably more), while the second can only be implemented through hard work and good system management. Both options add to the overall cost of deployment.

The first release of the Outlook Web Access (OWA) application was in Exchange 5.0. This release supported basic messaging and public folders but did nothing for calendaring, task management, or setting options such as passwords. OWA worked, but it was slow and clunky when compared with Outlook, and there were many missing features, since OWA could not support more than 300 (approximate) concurrent users on a well-configured server. Matters were somewhat improved in Exchange 5.5, but the architecture used could not deliver the required combination of performance, scalability, and functionality, so a fundamental rewrite was required.

---