Would you like to provide your users with accessibility to your company’s e-mail system no matter where they are? With Microsoft Outlook Web Access for Exchange Server, they’ll never be more than a browser (with frames support) away from their Inbox. They can have secure access to their Inbox and calendar from any PC with Internet access in the world.
This article appears courtesy of TechRepublic’s TechProGuild, the subscription Web resource for IT administration and support professionals. Among other great benefits, TechProGuild offers in-depth technical articles, e-books, and weekly chats moderated by industry experts on hot topics such as the latest OS developments and career advancement. Sign up now for a FREE 30-day trial of our TechProGuild service.
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 put these helpful features to work in your organization.
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
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 of Microsoft’s server-based products, 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 that 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. 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 process much easier. Load balancing, which is available in hardware and 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 works only 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.
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:
- Basic (clear text)
- Basic (clear text) over Secure Sockets Layer (SSL)
- Windows NT Challenge/Response (NTLM)
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.
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 them the ability to access an unlimited number of resources that are located on machines other than the 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.
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.
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 wants 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.
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 lessens 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 with Windows NT Service Pack 6a, Internet Information Server 4.0, and Active Server Pages installed.
- Insert the Microsoft Exchange 5.5 CD-ROM into the machine on which you plan to install Outlook Web Access.
- In the Setup Selection window, select Set Up Server And Components.
- In the Choose And Install window, select Microsoft Exchange Server 5.5.
- Accept the End User License Agreement.
- In the Exchange Server Setup box, select Complete/Custom.
- Make sure that the Outlook Web Access option 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 later.
- Exchange Server Setup begins and explains that it will stop the Internet Information Server Service.
- Microsoft Exchange Server Setup prompts you for the name of the Microsoft Exchange Server to which the Outlook Web Access Server will connect.
- Files are copied to the local computer. Services that OWA needs are stopped and started, and Outlook Web Access is installed.
- Upon completion, a pop-up window appears and lets you know if all is well.
- You’re finished.
- 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 http://computername/exchange.)
- 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, since that would allow anyone to access your mailbox from your computer.
- You’ll be welcomed to your Inbox.
- 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.
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 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 worked as an instructor of Microsoft curricula. 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.
If you’d like to share your opinion, please post a comment below or send the editor an e-mail.