Outlook Web Access: Bringing Exchange 2000 Server to the Masses
By David Sayer (Issue 3 2000)
With its improved feature set, scalable architecture, and high-availability options, Microsoft Outlook Web Access (OWA) has been reborn in Exchange 2000 Server. This article is intended to help you design an OWA solution by explaining the technologies that provide its scalability and availability: the Exchange 2000 Server front-end/back-end topology, Windows 2000 Network Load Balancing, Microsoft Cluster Services, and storage area networks.
Microsoft Exchange 2000 Server arrives this fall, replete with technologies that will extend the messaging and collaboration features of its predecessor, Exchange 5.5. While organizations requiring increased uptime will welcome its availability features, such as active/active clustering and multiple databases per server, Exchange 2000 Server will also be scalable enough to serve populations larger than America's biggest corporations.
Organizations intending to host high-capacity Internet messaging solutions will likely consider Exchange 2000 Server and its re-engineered Outlook Web Access (OWA). No longer an Exchange Server add-on, OWA is native to every Exchange 2000 Server and capable of supporting significantly larger user loads per server while leveraging the high-availability features of Windows 2000.
Exchange 2000 Server OWA (OWA 2000) solutions will be especially attractive to certain types of organizations:
- Educational institutions with large, transient populations
- Application Service Providers (ASPs) requiring a scalable and highly available platform that supports multiple organizations on shared servers
- Organizations building extranets or portals for customers and business partners
- Organizations with distributed mailbox servers that would like to centralize messaging services
The revamped information store (messaging database) of Exchange 2000 Server has contributed to the increased scalability of OWA 2000. The information store is now a Web Store that provides access to any mailbox object through a URL. Messaging operations no longer require a MAPI session and can be performed using HTTP-DAV methods. HTTP-DAV, also known as WebDAV, incorporates extensions to HTTP that provide collaborative file authoring capabilities. Within OWA itself, Active Server Pages have been replaced by Web Forms that leverage Dynamic HTML and Extensible Markup Language (XML), which reduces server-side processing and client-to-server communication.
Enhancements Improve User Experience
Microsoft has concentrated on delivering a richer client experience in OWA 2000, especially for those using Internet Explorer 5. Drag-and-drop operations, rich text editing, right-click context menus, and a preview pane are a few of the "fat-client" features now available in OWA 2000. Embedded objects and multimedia messaging are also supported. Before you toss your Outlook Deployment Kit, however, note that these Outlook features are not included in OWA 2000:
- Task and journal entries
- Spelling checker
- Background name resolution
- Off-line use
OWA 2000 Raises Active User Load Ceiling
Exchange Server 5.5 OWA is not recommended for active user loads above 500, and 800 users is the acknowledged ceiling. The Exchange 2000 Server development team has raised this ceiling and aims to have servers support as many WebDAV/OWA 2000 users as normal MAPI/Outlook users.
Judging from tests performed in Dell labs using Release Candidate code, the development team appears to have succeeded. Preliminary results indicate that OWA 2000 will support peak concurrency rates of 3,000 users or more per server. As always, load capacity will vary depending on usage profiles, server specifications, and solution design, but a three- to five-fold increase in client capacity over OWA 5.5 is expected.
The Web Store is not the only architectural change in Exchange 2000 Server. All core services—directory, protocol, and storage—have been re-implemented. The Exchange directory services have been transferred to Active Directory. IIS 5.0, which now runs on every Exchange 2000 Server, handles all messaging protocols. The addition of storage groups allows a single server's data to be distributed across multiple stores, minimizing data corruption risk and increasing service levels. These changes were not essential to increase Exchange Server performance, but rather to increase the scalability and availability of the application architecture.
Front-End/Back-End Topology Provides a Scalable Architecture
A chief scalability enhancement in Exchange 2000 Server is its support of a front-end/back-end topology. A front-end Exchange 2000 Server hosts no stores and is dedicated to communicating with messaging clients, whether they speak HTTP, Post Office Protocol 3 (POP3), or Internet Message Access Protocol 4 (IMAP4). A front-end server is only a protocol handler, and back-end servers containing the public and private Web Stores ultimately process all client requests.
Figure 1 illustrates a simple front-end/back-end environment. The messaging client communicates only with the front-end server, which proxies requests to the back-end servers. The Active Directory server (domain controller), while not part of the Exchange 2000 Server front-end/back-end topology, plays a central role in enabling this process. The front-end server cannot authenticate the client request without consulting Active Directory. The front-end must also perform a Lightweight Directory Access Protocol (LDAP) query against the domain controller to obtain a user's home server. In a dual-authentication scenario, back-end servers will also communicate with the domain controllers before processing a request.
Figure 1. A Simple Front-End/Back-End Topology
Promoting an Exchange 2000 Server to a front-end simply involves checking the box next to "This is a front end server" under the server's General properties tab. This change causes the Exchange/IIS server's DAVEX.DLL to be replaced with EXPROX.DLL, the high-speed proxy agent that forwards all client requests to the appropriate back-end servers.
In this role, front-end servers are suitable for placement in a "DMZ" perimeter network, because the servers contain no user or message databases. To provide login and session security, the front-end server can perform Secure Sockets Layer (SSL) encryption and decryption with a server certificate. Note, however, that SSL overhead carries a CPU performance penalty of at least 15 percent.
Front-end/back-end architectures can scale elegantly by providing users with a single namespace to access all back-end servers. This namespace gives the illusion of a large, monolithic system. More importantly, it minimizes user confusion over server names and enables a single URL for OWA.
Network Load Balancing Enhances Front-End Scalability
The Windows 2000 Network Load Balancing (NLB) service complements the front-end/back-end topology by providing both scalability and application availability. NLB is used to scale the front-end horizontally by creating a cluster of servers that distribute and balance client requests. An NLB cluster (not to be confused with Microsoft Cluster Services) can include as many as 32 servers that act as a single Exchange 2000 Server front end. Should one or more of those servers fail, client traffic is redirected to the remaining hosts, thereby maintaining application availability.
Of course, front-end application availability means nothing to users if they cannot also access mailbox data on the back-end server. To offer the highest availability of data, Microsoft Cluster Services (MSCS) can be used to provide storage group failover if a back-end server fails. A storage group is one or more stores sharing a transaction log set.
MSCS Enhances Back-End Availability
MSCS should be implemented on back-end servers when mission-critical Exchange 2000 solutions demand high availability of data. MSCS supports Exchange 2000 Server in a two-node, active/active configuration (with four-node clustering available in the Windows 2000 Datacenter Server). This support makes clustering more cost-effective than active/passive clustering in Exchange 5.5 because all servers are being utilized. Each cluster partner actively supports users and is ready to take over the other's stores if a failure occurs. Although this means that a cluster can potentially serve twice as many users, user loads per server should be held to 50 percent of capacity to enable one server to support all users during failover.
SANs Provide Storage Flexibility
Using a storage area network (SAN) for back-end Exchange 2000 Servers provides superior storage flexibility (as well as performance and redundancy) by accommodating growth and consolidation. SANs also support high-availability configurations such as MSCS. With the introduction of storage groups and multiple databases per server, Exchange 2000 Server may require flexible storage designs best supported by SANs. Using a SAN platform for the back-end Exchange 2000 Server makes sense in most enterprise or hosted environments, particularly for organizations experiencing irregular growth patterns and ever-changing user populations.
Figure 2 illustrates an OWA 2000 environment that uses all of the technologies for availability and scalability. Organizations with a SAN may choose to install domain controllers in the SAN. The domain controllers in Figure 2 are left standing alone to emphasize their functional role.
Figure 2. A Mission-Critical Exchange 2000 Server OWA Environment
Consider Server Design for Best Performance
As Exchange 2000 Server roles become more specialized, so do their hardware specifications and design principles. For example, front-end servers do not require additional disk volumes for stores and transaction logs. A separate SCSI channel and volume for the pagefile is recommended. Providing hefty CPU and RAM resources is essential for front-end performance and will increase user concurrency rates. Front-end servers in an NLB cluster will not require many availability features because a failure will not affect a client's ability to use the solution. The PowerEdge 2450—shown in Figure 2 —is an excellent front-end server choice because it offers dual Pentium III processors, integrated dual-channel SCSI, and redundant power in a 2U rack-optimized design.
Unlike Exchange 5.5, Exchange 2000 Server returns a performance benefit when equipped with more than two processors. Many organizations will choose to deploy four- and eight-way back-end servers, which will drive the number of mailboxes per server higher. Such a trend requires the back-end servers to have ample storage capacity—preferably SAN-based storage.
Plan For Effective Use of Disk Resources
Disk resources are used differently in Exchange 2000 Server because of the flexibility of storage groups. Additional stores can be created on a server in one of two ways: A store may be added to an existing storage group, or a new storage group can be created to contain the new store. The difference between the two approaches involves the transaction logs. Each storage group has one set of transaction logs for all of its databases (up to five in Release Candidate 2), so creating another storage group will require another set of transaction logs. This will not necessarily require an additional disk volume since multiple sets of transaction logs can share the same logical drive. The same applies for stores, as illustrated in Figure 3 .
Figure 3. Storage Groups Can Share Disk Resources
For best performance, continue to separate transaction logs (on a RAID 1 or RAID 10 volume) from databases (RAID 5 or RAID 10), as with Exchange Server 5.5. If using RAID 10 (mirrored stripe sets) seems wasteful with its 50 percent storage efficiency, consider its excellent read/write performance and that multiple sets of transaction logs can share the volume.
Since the Active Directory database uses an Exchange Server-like Extensible Storage Engine (ESE) database, apply these same disk layout principles to domain controllers. If you do not expect the Active Directory database to grow large enough to justify the three disks needed for a RAID 5 volume, then use a two-disk RAID 1 mirror set. Microsoft's Active Directory Sizer tool can help to estimate the size of the database file (NTDS.DIT) for a given Active Directory implementation. You can download this tool from www.microsoft.com/windows2000/downloads/deployment/sizer/default.asp.
Dell also has created the PowerMatch for Microsoft Exchange 2000 Server sizing tool, which generates detailed Dell server and storage configurations based on user, storage, and growth requirements. It even specifies hardware for OWA 2000 configurations that use the front-end/back-end topology. This tool may be downloaded from Dell's Exchange Web site at www.dell.com/exchange.
Leverage OWA 2000 for a Hosting-Ready Solution
Exchange 2000 Server greatly improves upon Exchange 5.5 as an Internet messaging platform, thanks to its Web Store, flexible application architecture, and the Windows 2000 availability features—NLB and MSCS. You can leverage these technologies in OWA 2000 to produce hosting-ready messaging solutions for use in such environments as universities, corporate extranets, and ASP data centers.
David Sayer (email@example.com) is a senior consultant with Dell Technology Consulting and specializes in Exchange Server. Prior to joining Dell, he provided messaging and migration services to companies such as GE, Xerox, and United Technologies. He currently designs and deploys Windows 2000 and messaging solutions for Dell's Enterprise and ASP customers. David is also a member of Microsoft's Exchange 2000 Task Force and is a Microsoft Certified Systems Engineer (MCSE).