Have you ever wanted to read your e-mail while you were away from your office? Have you ever overslept and forgotten whether or not you scheduled a meeting for 8:00 A.M.? Well, worry no more! With Microsoft Outlook Web Access for Exchange Server, you’re never more than a browser (with frames support) away from your inbox. That’s right! You can have secure access to your inbox and calendar from any PC with Internet access in the world. The idea of having such freedom almost makes you want to hit the road, doesn’t it?
Outlook Web Access (OWA) became available with Microsoft Exchange version 5. Basically, OWA is intended to supplement Microsoft Outlook. It gives users remote access to many of the core components and functions of the client that they use in the office. Unfortunately, most administrators don’t know about it, so they don’t use its great features. In this Daily Drill Down, I’ll discuss how you can use these helpful features.
Outlook Web Access requirements
For your server, you’ll need the following components:
* Pentium 6/200 single processor
* 256-MB RAM
* Network connection to Microsoft Exchange Server
* Microsoft Windows NT operating system with Service Pack 4 (SP4) or later
* Microsoft Internet Information Server (IIS): Exchange Server 5.0 supports IIS 3.0 only, but Exchange Server 5.5 supports IIS 3.0 or later
* Active Server Pages (ASP), which are available on Microsoft Windows NT 4.0 Service Pack 3 CD-ROM
* Active Server components (which come with Exchange Server 5.0) or Outlook Web Access components (which come with Microsoft Exchange Server 5.5)
* Exchange Server 5.0 Service Pack 1 (SP1) or Microsoft Exchange Server 5.5 Service Pack 2 (SP2); SP1 and SP2 provide enhanced Outlook Web Access components
Microsoft MCTS Certification, MCITP Certification and over 2000+
Exams for just $99 Life time access
For your client, you’ll need an Internet browser that’s capable of displaying Active Server Pages. You’ll also need Internet Explorer 3.02 or later (or any third-party browser that’s capable of supporting frames).
Outlook Web Access recommendations
As with most other server-based products that Microsoft manufactures, you ought to dedicate at least one server to performing the foundation that’s needed by Internet Information Server and Outlook Web Access Server components. Microsoft recommends that Outlook Web Access and Microsoft Exchange Server not be installed on the same machine. (Please note that Windows NT Challenge/Response (NTLM) authentication isn’t supported.) Microsoft also recommends that you use load balancing hardware or software in order to serve users better and to improve server response and availability.
The Microsoft Outlook Web Access server performs most of the processing for connected clients. The OWA Server also handles the entire load that’s required by active client connections. Supporting one client on the Outlook Web Access Server is similar to running one instance of Microsoft Outlook. Thus, to support the connections and requests, the Outlook Web Access Server must run many active MAPI sessions to the Microsoft Exchange Server. The overhead that’s created by the Internet browser running on the client computer is small, but the session that’s created by the client connection to the Outlook Web Access Server consumes many resources on the Outlook Web Access Server. Keep this information in mind and plan the potential load on the Outlook Web Access Server accordingly.
When you plan any project, you must address scalability. The OWA Server consumes a large number of resources. To ensure that OWA maintains a semblance of scalability and to allow for organizational growth and changes, Outlook Web Access and Internet Information Server must reside on a dedicated server that’s separate from other Exchange Servers. As the number of clients increases, the load on the Outlook Web Access Server will increase, and you’ll need to add more Servers. You can add more OWA Servers without affecting the existing Microsoft Exchange Server or the mailboxes in your organization.
When you need to add another Microsoft Outlook Web Access Server to your organization, load balancing makes the addition of this server much easier. Load balancing, which is available in either hardware or software variations, allows multiple servers to process and handle requests that are intended for a single IP address. Load balancing has several benefits. First, users will need only one URL to access their e-mail accounts; the load balancing software or hardware will determine which Outlook Web Access Server handles the request. Another benefit is its continued availability. If a user makes a request and a member of a server load balancing team is down, the request will be directed to another server automatically. In some cases, load balancing software or hardware can distribute the load that’s placed on servers by noting which servers are busiest at the time of the request and then by directing the new request to a less burdened machine.
To satisfy general load-balancing requirements, Microsoft recommends that you use Windows Load Balancing Service (WLBS) as a load balancing software solution and Cisco’s LocalDirector as a load balancing hardware solution. WLBS supports up to 32 servers; LocalDirector supports up to 64,000. However, WLBS won’t work in OWA scenarios because WLBS uses round-robin DNS: When a request is made to a DNS server, the DNS server points the request to the next available member of the WLBS team. It doesn’t consider server load. Round-robin DNS only works with stateless ASP applications. Each user request is sent to the next server that’s a member of the WLBS team, but the new server interrupts the user’s ASP session. That means that users who try to access their e-mail via the OWA Server must log in every time they make another request.
Functionality
With Microsoft Outlook Web Access for Exchange Server, access to a user’s e-mail account is no longer restricted to a particular operating system. As long as the browser being used supports frames, access to important information is possible. OWA provides a true cross-platform messaging and application collaboration system. OWA is a MAPI application that’s composed of binary, HTML, and ASP script files. The scripts use Collaborative Data Objects (CDO) to access mailbox and public folder information that’s stored on the Microsoft Exchange Server computer. OWA also uses Microsoft Active Server Pages on the Internet Information Server. JavaScript and Java control, which are downloaded to the user’s Internet browser on demand, generate HTML pages.
Although the browser uses the downloaded JavaScript to perform some of the processing on the client computer, the Microsoft Outlook Web Access Server handles most of the processing that the Outlook Client usually completes. This server processing includes MAPI sessions, client logic, state information, address resolution, rendering, content conversion, and Remote Procedure Calls (RPC) communications with the Microsoft Exchange Server. The Exchange Server receives and completes requests that the Outlook Web Access Server makes. (These requests resemble requests from any MAPI client.)
The process
Here’s what happens when users open messages in their Microsoft Exchange Server Mailboxes using a browser with Outlook Web Access. First, a browser with the Outlook Web Access client sends a request to a Microsoft Internet Information Server and the OWA Server. This request includes a cookie that identifies the browser and the user. IIS accepts the request and hands it to Active Server Pages for processing. ASP verifies that the cookie points to a valid ASP session and that the user making the request has logged on properly. Next, the Internet Services API (ISAPI) filter determines which language to use when displaying messages in the browser. Then, ASP opens the script that’s named in the URL and executes any server-side Microsoft Visual Basic script that it contains. These scripts use CDO to open the message that’s in the user’s Microsoft Exchange Server Information Store. The message GUID is passed on within the query string of the URL. Next, The CDO rendering library (Cdohtml.dll) converts the requested message into HTML format, and IIS sends the HTML to the browser. Finally, the browser renders the HTML, including the embedded JavaScript.
Outlook Web Access security
You can configure Outlook Web Access to support one or more of several different types of authentication. As usual, there are advantages and disadvantages to many of these configuration options. The following configurations will authenticate OWA users:
* Anonymous
* Basic (clear text)
* Basic (clear text) over Secure Sockets Layer (SSL)
* Windows NT Challenge/Response (NTLM)
Anonymous authentication
If Outlook Web Access is set up to accept an anonymous connection, any user with access to the OWA Web page can use Outlook Web Access without specifying a Windows NT account name or password. When a user accesses OWA and makes an anonymous connection, Internet Information Server logs on the user with an anonymous (guest) account, which is a valid Windows NT user account. The default IIS user account is IUSR_computername. Be aware that anonymous authentication grants access only to resources that are anonymously published, such as public folders and directory content. Table A summarizes the advantages and disadvantages of using anonymous authentication.
Table A Advantages Disadvantages
All browsers support anonymous authentication. Anonymous authentication isn’t secure.
Users aren’t prompted for credentials. Users can access only public folders and resources.
Basic (clear text) authentication
When using basic (clear text) authentication, a user who tries to connect to OWA must supply a valid Windows NT account username and password. The user’s account and password are transmitted as clear text over the network to the Internet Information Server/Outlook Web Access Server. Validating users with basic (clear text) authentication gives users the ability to access an unlimited number of resources that are located on machines other than the user’s Outlook Web Access Server. A user can access e-mail on one Microsoft Exchange Server and public folders on another Microsoft Exchange Server.
Since basic authentication transmits clear text passwords across the network, Microsoft recommends that you also use SSL. SSL encrypts all information that passes through IIS. Table B summarizes the advantages and disadvantages of using basic authentication.
Table B Advantages Disadvantages
All browsers support basic authentication. Basic authentication isn’t secure.
Users can access all MS Exchange Server resources. Users are prompted for a username and password.
Users must be granted the right to log on locally on IIS.
Basic (clear text) over SSL
When using basic authentication over SSL, a user must specify a valid Windows NT user account name and password in order to access OWA. Usernames and passwords are transmitted as encrypted information over the network to the Internet Information Server/Outlook Web Access Server. Basic authentication over SSL allows users to access an unlimited number of resources, which may be located on machines other than the Outlook Web Access Server—just like basic (clear text) authentication does. Table C summarizes the advantages and disadvantages of using basic over SSL authentication.
Table C Advantages Disadvantages
Most browsers support basic over SSL authentication. Performance can become slow due to encryption.
Users can access all MS Exchange Server resources. Users are prompted for a username and password.
Basic over SSL is very secure. Users must be granted the right to log on locally on IIS.
Windows NT Challenge and Response (NTLM)
Windows NT Challenge and Response requires a user to specify a valid Windows NT user account name and password in order to access the OWA Server. The username and password are sent from the browser to the IIS as encrypted information. All information that the user wishes to access must reside on the same server as IIS and the Outlook Web Access Server. Windows NT Challenge and Response authentication isn’t supported if IIS and the OWA Server are located on the same machine that contains Microsoft Exchange Server. Table D summarizes the advantages and disadvantages of using Windows NT Challenge and Response.
Table D Advantages Disadvantages
NTLM is reasonably secure. Users can only access information on the IIS/OWA Server.
Users aren’t prompted for username or password. Not all browsers support NTLM authentication.
Multiple users
If multiple users are going to share the same computer and use it to access e-mail via OWA, Microsoft recommends that you disable local caching. Doing so lessons the chances that a message a user accessed via Outlook Web Access still resides on the local disk, where the wrong user could access it. Microsoft also recommends that you disable the save password option in Internet Explorer in order to lower the chances that a nosy user will access another person’s e-mail account.
Outlook Web Access installation
Below, I’ve provided a step-by-step guide that will explain how to install Microsoft Outlook Web Access. The test machine is a Windows NT 4.0 Server. Windows NT Service Pack 6a, Internet Information Server 4.0, and Active Server Pages have been installed.
1. Insert the Microsoft Exchange 5.5 CD-ROM into the machine on which you plan to install Outlook Web Access.
2. At the setup selection window, select Set Up Server And Components.
3. At the Choose And Install window, select Microsoft Exchange Server 5.5.
4. Accept the End User License Agreement.
5. At the Exchange Server Setup box, select Complete/Custom.
6. Make sure that the Outlook Web Access button is the only one that’s checked and click Continue. If you haven’t installed IIS 4.0 and/or Active Server Pages yet, you’ll be notified via a pop-up screen. (Setup won’t continue.) You’ll have to stop setup and install the missing component(s). Then, start these steps over. Please note that IIS 4.0, which can be found in the Windows NT 4 Option Pack, requires Internet Explorer 4.01 or better.
7. Exchange Server Setup begins and explains that it will stop the Internet Information Server Service.
8. Microsoft Exchange Server Setup prompts you for the name of the Microsoft Exchange Server to which the Outlook Web Access Server will connect.
9. Files are copied to the local computer. Services that OWA needs are stopped and started, and Outlook Web Access is installed.
10. Upon completion, a pop-up window appears and lets you know if all is well.
11. You’re finished.
12. To test your setup, open your browser, type the name of the computer that’s running Outlook Web Access in the address line, and press [Enter]. (The address probably will be something like https://computername/exchange.)
13. You’ll be prompted for your username and password. You may need to include your domain name, too (such as domainname\username). Don’t check Save This Password in your password list box. Doing so would allow anyone to access your mailbox from your computer.
14. You’ll be welcomed to your inbox.
15. After successfully reading and sending some e-mail messages, remember to log off and close your browser. That way, you can be certain that no unauthorized users will view your mail.
Conclusion
Microsoft’s Outlook Web Access provides a quick and easy method of increasing the accessibility of your company’s e-mail system. Configuring OWA properly gives you a solid and secure method of remotely accessing your e-mail. Of course, you must consider the variables when you’re implementing OWA. All Microsoft installations will be unique to your organization, so you should customize OWA accordingly. For more information on tuning and enhancing the performance of IIS and ASP, please point your browser here.
Scott Lape is the senior systems consultant for a national insurance company based in Louisville, KY. He also works as a part-time consultant to area networking firms and has done time as an instructor of Microsoft curriculum. Scott is currently in hot pursuit of the elusive title Cisco Certified Internetworking Expert (CCIE)—and has been an MCSE since before it was cool.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.