Lesson 3: Designing a Microsoft Exchange Web Integration Strategy

Exchange 2000 Server is tightly integrated with Web technologies. IIS, which is now coupled with Exchange, is required on all Exchange 2000 Server computers. IIS is responsible for client protocols and manages all HTTP, Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), Network News Transfer Protocol (NNTP), and Simple Mail Transfer Protocol (SMTP) client requests. All Exchange 2000 protocols are hosted within the IIS process. Exchange 2000 HTTP also supports Web Distributed Authoring and Versioning (WebDAV), which allows rich collaborative interaction with the Web Storage System in Exchange. As a result of its interaction with IIS, Exchange can support Web-based access to its e-mail services, which is implemented through the Microsoft Outlook Web Access component of Exchange. This lesson introduces you to Outlook Web Access and describes several steps that you should take when designing an Exchange integration strategy in order to provide browser-based messaging to your clients.

After this lesson, you will be able to

  • Provide an overview of how Outlook Web Access delivers Web-based messaging services to your Internet clients
  • Design a strategy for implementing Exchange 2000 into your Web environment

Estimated lesson time: 30 minutes

Outlook Web Access

Outlook Web Access allows users to gain access to their mailboxes from nearly any location that supports Internet connectivity. Because client access is through a browser, access isn’t limited by operating system or location, and client computers don’t have to be configured with a special e-mail client.

Outlook Web Access supports various Web browsers, including Netscape Navigator 4.08 and later, Internet Explorer 4.01 Service Pack 1, and Internet Explorer 5 and later. When used with Internet Explorer 5, Outlook Web Access provides clients with a user experience similar to Microsoft Outlook. Outlook Web Access supports such functionality as the preview pane, drag and drop functionality, HTML text editing, and right-click menu options.

Web browsers other than Internet Explorer 5 can also take advantage of Outlook Web Access as long as they comply with HTML 3.2 and JavaScript. However, these browsers don’t support as many features as Internet Explorer 5. Yet even when using Internet Explorer 5, Outlook Web Access doesn’t support all the functionality of Outlook. For example, with Outlook Web Access, you can’t work offline, create Outlook rules, or access tasks and journal items.

When a user tries to access an object in Outlook Web Access, a series of events occurs. Figure 9.8 provides an overview of these events. Each step is described below.

Figure 9.8 - Accessing Exchange objects on the Web

When a user attempts to open a message, the following events occur:

  1. A user accesses the mailbox by calling a URL and clicks a message to open it.
  2. The IIS request processor calls the Exchange HTTP ISAPI extension, which parses the information in the request and determines the action to be performed.
  3. The IIS server determines whether the user has rights to gain access to the item.
  4. The extension parses the correct form and queries Web Storage System to bind the data.
  5. The Web Storage System sends the data back to the Exchange HTTP ISAPI extension.
  6. The Exchange HTTP ISAPI extension renders the data in HTML or Extensible Markup Language (XML), based upon the browser type and version, and sends it to the client.

Outlook Web Access uses IIS to receive requests and pass them to the Web Storage System. The Web Storage System stores and manages documents, e-mail messages, Web pages, multimedia streams, data elements, and other items in a semistructured, hierarchical database. Outlook Web Access doesn’t use Messaging Application Programming Interface (MAPI) to communicate with the data store and doesn’t use ASP for client access. Clients use HTTP and WebDAV to communicate with the Outlook Web Access service.

To implement Outlook Web Access into your Web environment, you must determine an Exchange topology, ensure system availability, and plan your Web access authentication. The following sections discuss each of these tasks.

Determining an Exchange Topology

When designing an Exchange topology, you have two options from which to choose: installing Exchange in a single-server environment or installing Exchange in a multiserver environment.

In a single-server environment, the client connects directly to the Exchange 2000 Server computer that hosts the mailbox. You must add an Exchange virtual root and a public virtual root to IIS. The virtual roots point to their corresponding directories in Exchange.

Although the single-server environment requires less equipment and administrative overhead, it limits how effectively you can implement Exchange 2000 Server in your environment and which methods you can use to ensure high availability. For example, suppose your system requires Secure Sockets Layer (SSL) connections. The steps necessary to encrypt and decrypt data are processor-intensive. If the data store is also located on the same server, processing power must be shared among the different types of operations, and it becomes more difficult to maximize performance for any one type of operation.

Achieving fault tolerance can also become more complicated in the single-server environment because you have to factor in load-balancing issues with issues surrounding the management of stored data.

On the other hand, a multiserver environment provides far more flexibility and can provide a more secure and highly available model. In a multiserver environment, the front-end server communicates directly with the client and forwards requests to the back-end server for processing. The back-end server hosts the data store. Figure 9.9 illustrates how a multiserver environment is set up.

A multiserver environment provides a number of benefits:

  • The multiserver model supports a unified namespace. You can disperse groups of users across back-end databases but allow them to connect to the front-end server by using a single server name.
  • You can isolate back-end servers from attacks. You can locate back-end servers behind a firewall or on a different subnet. Front-end servers can each be configured with one network interface card (NIC) that connects to the Internet and another NIC that connects to the secure, internal LAN.
  • Multiple servers allow you to isolate processing tasks. Front-end tasks can be performed on computers separate from the processing of data that occurs on the back-end. For example, SSL processing can occur on the front-end servers only. From there, the front-end and back-end servers can communicate without the overhead of SSL.

The multiserver model has the added benefit of being easier to scale out and make fault-tolerant. You can use Windows 2000 NLB to set up a front-end cluster that’s load balanced, and use the Windows 2000 Cluster service to set up a back-end cluster to provide failover protection to the data store.

Figure 9.9 - Multiserver Exchange configuration

Ensuring System Availability

As you can see in Figure 9.9, the multiserver configuration by itself provides no fault tolerance. However, by using Windows Clustering technologies (NLB and the Cluster service), you can make Outlook Web Access highly available to your Web users, as shown in Figure 9.10.

NLB balances the traffic on the front-end Exchange Server computers. If one of the servers fails, the load is distributed to the remaining servers in the cluster. Before you install Exchange 2000 Server on the front-end cluster, you should install and configure NLB. From there, you can install Exchange and configure it as the front-end server.

The Cluster service provides failover service on the back-end cluster. When failover occurs on one of the servers in that cluster, the second computer provides the services that were being provided by the failed server. When you configure the Cluster service, you must create at least one virtual server for each node. Each virtual server is responsible for one or more storage groups. A storage group is a collection of Exchange databases that share a set of transactions logs. You can configure a maximum of five databases per storage group, and each Exchange Server computer can support up to four storage groups. As a result, you must ensure that, in the event of failover, a single node isn’t supporting more than four storage groups.

For example, suppose each node in a two-node cluster is configured with two storage groups. If failover occurs, the remaining node would be supporting four storage groups. However, if each node were configured with three storage groups, the remaining node would have to support six storage groups in the event of failover, which it couldn’t do.

Figure 9.10 - Multiserver Exchange configuration using NLB and the Cluster service

Planning Web Access Authentication

Outlook Web Access supports two forms of user authentication: Basic and Integrated Windows. Outlook Web Access also supports SSL encryption and Anonymous access.

Basic Authentication

Basic authentication is part of the HTTP specification. It’s the most flexible type of authentication and is commonly used on intranets. Basic authentication is supported by most browsers and is independent of the hardware platform, but it isn’t considered secure because passwords aren’t encrypted when they’re sent to the server. With Basic authentication, each user must enter a user name, domain, and password whenever the user logs on to be authenticated by Outlook Web Access.

Integrated Windows Authentication

Integrated Windows authentication can support Kerberos authentication or NTLM authentication. Integrated Windows authentication uses Kerberos when the client is running Windows 2000 and Internet Explorer 5. This configuration offers the best security, efficient communication, and transparency. Integrated Windows authentication uses NTLM instead of Kerberos for other client configurations. You can’t use Integrated Windows authentication when Exchange is set up in a front-end/back-end configuration.

SSL Encryption

SSL encryption provides the highest level of security and operability between clients and server because the entire communication session is encrypted. By itself, SSL isn’t an authentication mechanism. It provides a secure channel for other authentication mechanisms, such as Basic, and most browsers support SSL. However, SSL places an additional burden on the server, but if a front-end/ back-end configuration is used, the front-end servers can usually manage SSL.

Anonymous Access

Anonymous access allows users to access specific resources without being prompted for authentication. As a result, you don’t have to define accounts for these users. All browsers support anonymous access and administration is simpler.

Making a Decision

You can use Outlook Web Access to provide users with Web-based access to their e-mail accounts. To set up this service, you must determine an Exchange topology, ensure system availability, and plan your Web access authentication. Table 9.10 provides an overview of which factors you must consider when performing each of these tasks.

Table 9.10 Setting Up Outlook Web Access

Task Considerations

Determining an Exchange topology

You can set up Exchange 2000 server in a single-server environment or a multiserver environment. In a single-server environ- ment, the client connects directly to the Exchange 2000 Server computer that hosts the mailbox. This configuration limits how effectively you can implement Exchange 2000 Server in your environment and which methods you can use to ensure high availability. In a multiserver environment, the front-end server communicates with the client and forwards requests to the back-end server, which hosts the data store. This configuration provides more flexibility than a single-server environment and can provide a more secure and highly available model.

Ensuring service availability

You can make a multiserver environment highly available by creating a front-end cluster and a back-end cluster and then implementing NLB on the front-end cluster and the Cluster service on the back-end cluster.

Planning Web access authentication

Outlook Web Access supports Basic authentication and Integrated Windows authentication. It also supports SSL encryption and Anonymous access. Integrated Windows authentication isn’t supported in a front-end/back-end configuration.

Recommendations

When planning your Outlook Web Access implementation, you should use a multiserver environment. You should also create an NLB cluster on the front end of the perimeter network and a Cluster service cluster on the back end of the perimeter network. In addition, you should use SSL with Basic authentication to authenticate users.

Example: Web-Integrated Messaging for Northwind Traders

Northwind Traders provides e-mail services to its employees. Because some employees travel extensively, they can’t always check their e-mail through their regular dial-up connections and e-mail clients. As a result, administrators at the company implemented the Outlook Web Access service in Exchange 2000 Server, which allows the employees to check their e-mail anywhere an Internet service is offered, such as airports, Internet cafes, or hotels.

Because employees travel to different parts of the world and may access their e-mail accounts at any time of day, any day of the week, e-mail availability had to be assured to be highly reliable. Consequently, administrators use a multi-server environment configured with Windows Clustering technologies, as shown in Figure 9.11. In addition, redundant network paths and components are used to avoid any single points of failure.

Lesson Summary

Exchange 2000 Server supports a service known as Outlook Web Access. Outlook Web Access allows users to gain access to their mailboxes through their browsers, so access isn’t limited by operating system or location. To imple- ment Outlook Web Access into your Web environment, you must determine an Exchange topology, ensure system availability, and plan your Web access authentication. When you implement Outlook Web Access, you can choose one of two Exchange topologies: a single-server environment or a multiserver environment. In a single-server environment, the client connects directly to the Exchange 2000 Server computer that hosts the mailbox. In a multiserver environment, the front-end server communicates directly with the client and forwards requests to the back-end server for processing. The back-end server hosts the data store. A multiserver environment provides far more flexibility and can provide a more secure and highly available model. If you implement a multiserver environment, you can create front-end NLB clusters and back-end Cluster service clusters to provide high availability. Outlook Web Access supports four authentication methods: Basic, Integrated Windows, SSL, and anonymous access. SSL provides the greatest security.

Figure 9.11 - Northwind Traders Web-based e-mail service



Microsoft Corporation - MCSE Training Kit. Designing Highly Available Web Solutions with Microsoft Windows 2000 Server Technologies
MCSE Training Kit (Exam 70-226): Designing Highly Available Web Solutions with Microsoft Windows 2000 Server Technologies (MCSE Training Kits)
ISBN: 0735614253
EAN: 2147483647
Year: 2001
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net