There are several new features in Microsoft Office Outlook Web Access (OWA) for Microsoft Exchange Server 2003, including forms-based authentication, gzip compression, and attachment blocking. This article contains instructions for configuring various settings and features in Outlook Web Access for Exchange 2003.
Expand the following sections to see more information about the setting or feature.
Note If you are using Exchange Server 2003 Service Pack 1 (SP1), the steps in this section do not apply. The WebDAV address check is not present in Exchange 2003 SP1. Instead, if you are using Exchange 2003 SP1 or a later version, follow these steps to restrict access to Outlook Web Access:
In
the Active Directory Users and Computers snap-in,
right-click the user account that you want to restrict from using OWA, and then
click Properties.
Click the Exchange Features tab, click
Outlook Web Access, and then click
Disable.
By default, Exchange 2003 user accounts that are mailbox-enabled are also enabled for Outlook Web Access in Exchange 2003.
You can enable users in your corporate network to access Outlook Web Access. At the same time, you can deny access to external clients. The key to this approach is a combination of a recipient policy and a special HTTP virtual server. To use this approach, follow these steps:
Create a recipient policy with a Simple Mail Transfer Protocol (SMTP) domain name. Users who connect to an HTTP virtual server must have an email address that has the same SMTP domain as the virtual server. Creating a recipient policy is an efficient way to apply the same SMTP domain to multiple users.
Collapse this imageExpand this image
Note Outlook Web Access users do not have to know the name of the SMTP
domain.
Apply the recipient policy to the user accounts that you
want to enable access for.
On the front-end server, create a new HTTP virtual server
that specifies the domain that is used in the recipient policy.
After you have completed these steps, users whose email addresses do not have the same SMTP domain as the HTTP virtual server cannot log on and access Outlook Web Access. Also, as long as you do not use the SMTP domain as the default domain, external users cannot determine what the SMTP domain is because the domain does not appear in the From field when users send email messages outside the organization. For more information, click the following article number
to view the article in the Microsoft Knowledge Base:
HTTP 401 or 404 error messages when you access OWA implicitly or explicitly
In addition to enabling Outlook Web Access for users in your corporate network, you can also prevent specific internal users from accessing Outlook Web Access. You do this by disabling the HTTP and Network News Transfer Protocol (NNTP) protocols for those users.
To prevent an
internal user from accessing Outlook Web Access, follow these steps:
In the Active Directory Users and Computers snap-in, open
the user's Properties dialog box.
On the Exchange Features tab, click
Outlook Web Access, and then click
Disable.
When you use Microsoft Internet Explorer 5 or later versions to access Outlook Web Access, new installations of Exchange 2003 and upgrades to Exchange 2003 use the browser's language settings to determine the character set to use to encode information such as email messages and meeting requests.
If you upgrade a server that is running Exchange 2000 Server that was changed to use a browser's language setting, Exchange 2003 continues to function in the same manner. The following table lists the language groups and respective character sets.
Collapse this tableExpand this table
Language group
Character set
Arabic
Windows 1256
Baltic
iso-8859-4
Chinese (Simplified)
Gb2131
Chinese Traditional
Big5
Cyrillic
koi8-r
Eastern European
iso-8859-2
Greek
iso-8859-7
Hebrew
windows-1255
Japanese
iso-2022-jp
Korean
ks_c_5601-1987
Thai
windows-874
Turkish
iso-8859-9
Vietnamese
windows-1258
Western European
iso-8859-1
If you expect Outlook Web Access users in your organization to send mail frequently, you can change registry settings so that users who are running Internet Explorer 5 or later versions can use UTF-8 encoded UNICODE characters to send mail.
To change the default language setting for Outlook Web Access, follow these steps.
Collapse this imageExpand this image
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
Enabling forms-based authentication (Cookie-auth) lets you enable a new logon page for Outlook Web Access that stores the user's name and password in a cookie instead of in the browser. When a user closes the browser, the cookie is cleared. Additionally, after a period of inactivity, the cookie is cleared automatically. To access email, the new logon page requires the user to enter a domain, a user name, and a password, or a full user principal name (UPN) email address and password. Forms-based authentication logon does not support Windows Live ID authentication with Outlook Web Access. This is a limitation of the Forms Based Authentication feature in Exchange 2003.
To enable this logon page, you must first enable forms-based
authentication on the server and then secure the logon page by setting the
cookie time-out period and adjusting the client-side security settings. For
more information, see the “Enabling forms-based authentication” and “Setting
the cookie authentication time-out” sections.
In Exchange 2003, forms-based authentication automatically sets the default domain for Basic Authentication on the Exchange virtual directory in Exchange System Manager to a backslash character (\). This restriction is designed to support user logons that use the UPN format. If you change the default domain setting in Internet Information Services (IIS) to anything other than the default domain setting of "\", Exchange System Manager resets the default domain setting to "\" on the server.
Additionally, if forms-based authentication is
deployed in a front-end/back-end configuration, the default domain setting on
the back-end server must match the default domain setting on the front-end
server, or you may experience authentication problems. Because the front-end
server requires "\" as the default domain, if forms-based authentication is
enabled on the front-end server, the default domain on the back-end server must
also be set to "\" in Exchange System Manager.
For more
information about why you must modify the settings for the Exchange and Public
virtual directories in Exchange System Manager, click the following article
numbers to view the articles in the Microsoft Knowledge Base:
Changes to virtual directory settings are not maintained
To work around this issue, change the Logon.asp page in Outlook Web Access to specify your domain or to include a list of domain names.
Collapse this imageExpand this image
Note If you customize the Logon.asp page in Outlook Web Access, your changes may be overwritten if you later upgrade or reinstall Exchange 2003. For more information about how to customize
the Logon.asp page, click the following article number to view the article in
the Microsoft Knowledge Base:
Outlook Web Access session unexpectedly quits when forms-based authentication is used
Collapse this imageExpand this image
Important Microsoft does not provide assistance in customizing Outlook Web Access objects, and if you contact Microsoft about an Outlook Web Access issue for a server that Outlook Web Access is customized on, you must replace the customized files by using the original versions of the files. For more information, click the following article
number to view the article in the Microsoft Knowledge Base:
You must enable Secure Sockets Layer (SSL) on the server before
you enable forms-based authentication. For more information about how to install a certificate in
Microsoft Windows Server 2003 before you enable SSL, click the following
article number to view the article in the Microsoft Knowledge Base:
How
to install imported certificates on a Web server in Windows Server 2003
To enable forms-based authentication in Exchange
2003, follow these steps.
Collapse this imageExpand this image
Note In a front-end/back-end server environment, you must enable
forms-based authentication only on the front-end server. Do not enable
forms-based authentication on the back-end server. In an environment where you
do not use a front-end server, enable forms-based authentication on the mailbox
server.
Start Exchange System Manager.
If administrative groups are enabled, expand
Administrative Groups.
Expand Servers, and then expand your
front-end server.
Expand Protocols, expand
HTTP, right-click Exchange Virtual Server,
and then click Properties.
Click the Settings tab, and then select the Enable Forms Based Authentication check
box.
In the Compression list, click the level
of compression that you want.
Collapse this imageExpand this image
Note We recommend that you do not enable compression in a single-server environment because compression in a single-server environment adds an additional load on the server.
Click OK.
If you receive a message that states that the IIS service
must be restarted, click OK. To restart IIS, open a command prompt, type the following command, and then press ENTER: iisreset
If you enabled forms-based authentication on a
front-end server, follow these steps on your back-end servers:
Start Exchange System Manager.
If administrative groups are enabled, expand
Administrative Groups.
Expand Servers, and then expand your
back-end server.
Expand Protocols, expand
HTTP, and then expand Exchange Virtual
Server.
Right-click the Exchange virtual directory that appears
under the Exchange Virtual Server container, and then click
Properties.
Click the Access tab, and then click
Authentication.
For your Outlook Web Access logon page, you can give users two kinds of security options for authentication. Depending on their requirements, users can select either of these security options on the Outlook Web Access logon page:
Public or shared computer - Tell users to select this option when they access Outlook Web Access from a computer that does not use the security settings for your organization. For example, an Internet kiosk computer does not use the security settings for your organization. The Public or shared computer option is the
default option and provides a short default time-out option of 15
minutes.
Private computer - Tell users to select this option when they are the sole operator of the computer and the computer uses the security settings for your organization. This option allows a much longer period of inactivity before automatically ending the session. Its internal default value is 24 hours. The Private computer option is intended to benefit Outlook Web Access users who use personal computers in their offices or in their homes.
Additionally, when Outlook Web Access clients log on by using forms-based authentication, they can also choose between the following two kinds of Outlook Web Access client versions:
Premium - This is the default version. It provides all
Outlook Web Access features.
Collapse this imageExpand this image
Note The Outlook Web Access premium client has special code so that
typing in a message body is considered as activity.
Basic - This version provides faster performance but fewer
features than the premium client. Use this version if you are on a slow
connection.
In Exchange 2003, Outlook Web Access user credentials are stored
in a cookie. When the user logs off from Outlook Web Access, the cookie is
cleared and it is no longer valid for authentication. Additionally, by default,
if your user is using a public computer and selects the Public or
shared computer option on the Outlook Web Access logon screen, the
cookie on this computer expires automatically after 15 minutes of user
inactivity.
The automatic time-out is valuable because it helps protect a user's account from unauthorized access. However, although the automatic time-out greatly reduces the risk of unauthorized access, it does not eliminate the risk that an unauthorized user could access an Outlook Web Access account if a session is left running on a public computer. Therefore, make sure that you educate users about precautions to take to avoid risks.
To match the security requirements of the organization, an
administrator can configure the inactivity time-out values on the Exchange
front-end server. Exchange 2003 uses the following information to determine
user activity:
Interaction between the client and the server is considered as activity. For example, if a user opens, sends, or saves an item, switches folders or modules, or refreshes the view or the web browser window, this is considered as activity.
If a user enters text in Outlook Web Access items, it is
not considered as activity. For example, if a user types in appointments,
meeting requests, posts, contacts, tasks, or other items, this is not
considered as activity.
To configure the time-out value, you must first enable forms-based authentication and then change the registry settings on the server.
To set the Outlook Web Access forms-based authentication
public computer cookie time-out value, follow these steps.
Collapse this imageExpand this image
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
On the Edit menu, point to
New, and then click DWORD Value.
Type PublicClientTimeout for the name of the DWORD, and then press Enter.
Right-click the PublicClientTimeout DWORD
value, and then click Modify.
Under Base, click
Decimal.
In the Value data box, type a value that
represents the number of minutes for the time-out. This number must be between
1 and 43200. (43200 minutes are equal to 30 days.) If you do not set a value, a
value of 15 is assumed.
Collapse this imageExpand this image
Note The maximum possible value is 43200 for 30 days.
Click OK.
Collapse this imageExpand this image
Important You must restart IIS for the changes to take effect. Also, if you set the TrustedClientTimeout value to a value that is lower than PublicClientTimeout, the TrustedClientTimeout value uses a value that is equal to the PublicClientTimeout value. Similarly, if you set the PublicClientTimeout value to a value that is greater than the TrustedClientTimeout value, the TrustedClientTimeout value uses a value that is equal to the PublicClientTimeout value.
To set the Outlook Web Access forms-based authentication trusted computer cookie time-out value, follow these steps:
On the Exchange front-end server, log on by using the
Exchange administrator account, and then start Registry Editor.
Locate and then click the following registry subkey:
On the Edit menu, point to
New, and then click DWORD Value.
Type TrustedClientTimeout for the name of the DWORD, and then press Enter.
Right-click the TrustedClientTimeout DWORD
value, and then click Modify.
Under Base, click
Decimal.
In the Value data box, type a value that
represents the number of minutes for the time-out. This number must be between
1 and 43200. (43200 minutes are equal to 30 days.) If you do not set a value, a
value of 1440 is assumed.
Collapse this imageExpand this image
Note The maximum possible value is 43200 for 30 days.
Click OK.
Open a command prompt, type net stop
w3svc, and then press Enter.
After the services stop, type net start
w3svc, and then press Enter.
When you enable forms-based authentication in Exchange 2003, you
can also enable gzip compression for static and dynamic files in Exchange 2003
virtual directories and virtual servers. By using compression, users can
experience performance increases of up to 50 percent when they use slower
network connections such as traditional dial-up access.
Depending on the compression setting that you use, Outlook Web Access compression works by compressing static or dynamic web pages.
Collapse this tableExpand this table
Compression setting
Description
High
Compresses both static and dynamic pages
Low
Compresses only static pages
None
No compression is used
To use data compression for Outlook Web Access in Exchange
2003, the following prerequisites must be met:
Client
The client system must be running Windows 2000 or a later version and must use one of the following web browsers:
Internet Explorer 6 with the 328970 cumulative update or a later version. For more information about the 328970 cumulative update,
click the following article number to view the article in the Microsoft
Knowledge Base:
MS02-066: November, 2002, cumulative patch for Internet Explorer
Netscape Navigator 6.0 or later versions.
Server
Forms-based authentication must be enabled.
When you enable gzip compression in your Exchange environment, you must consider the type of deployment scenario. The recommended approach is to deploy dedicated front-end servers. In this kind of scenario, the following requirements apply:
The front-end Exchange 2003 computer must be running under
Windows Server 2003.
The back-end Exchange 2003 computers may be running under
either Windows 2000 or Windows Server 2003.
Another kind of deployment scenario involves not deploying dedicated front-end Exchange computers (also known as a back-end only deployment). In this situation, the Exchange 2003 computer must be running under Windows Server 2003.
Collapse this imageExpand this image
Note If you use Exchange 2003 front-end servers to access Exchange
2000 back-end servers, disable Outlook Web Access compression support on the
front-end servers until all back-end servers are upgraded to Exchange
2003.
Together with the previous prerequisites, you may also have to
enable HTTP 1.1 support through proxy servers for some dial-up connections.
(HTTP 1.1 support is required for compression to function
correctly.)
To enable data compression, follow these steps:
Click Start, point to
Programs, point to Microsoft Exchange, and
then click System Manager.
Expand Servers, expand
ServerName, expand
Protocols, and then expand HTTP.
Right-click Exchange Virtual Server, and
then click Properties.
Click the Settings tab.
elect the Enable Forms Based
Authentication check box.
To configure compression, click the compression level that
you want to use in the Compression box, and then click
OK.
Click OK.
Restart the following services:
Microsoft Exchange System Attendant service
IIS Admin Service
Collapse this imageExpand this image
Note You must configure SSL in IIS before you can enable forms-based
authentication on the server.
In Exchange 2003, Outlook Web Access makes it more difficult for people who send junk email messages to use beacons to retrieve email addresses. Beacons frequently come in the form of images that are downloaded onto a user's computer when the user opens a junk email item. After the images download, a beacon notification is sent to the sender of the junk email informing the sender that the email address of your user is valid. The result is that the user receives junk email more frequently because the junk email sender now knows that the email address is valid.
In Outlook Web Access, an incoming message that has any content that might be used as a beacon, regardless of whether the message actually contains a beacon, prompts Outlook Web Access to display the following warning message:
To
help protect your privacy, links to images, sounds, or other external content
in this message have been blocked. Click here to unblock
content.
If users know that a message is legitimate, they
can click the Click here to unblock content link in the
warning message to unblock the content. If your users do not recognize the
sender or the message, they can open the message without unblocking the content
and then delete the message without triggering beacons. If your organization
does not want to use this feature, you can disable the blocking option for
Outlook Web Access.
To disable the blocking option, follow these
steps:
Use a web browser to gain access to Outlook Web Access.
Click Options.
Under Privacy and Junk Email Prevention,
click to clear the Block external content in HTML email messages check box.
With Outlook Web Access, you can block users from opening,
sending, or receiving specified attachment types. In particular, you can do the
following:
Prevent users from accessing certain file type attachments. By default, all new Exchange 2003 installations block attachments of Levels 1 and 2 file types and Levels 1 and 2 MIME types. This feature is especially useful in stopping Outlook Web Access users from opening attachments at public Internet terminals. Opening attachments at public Internet terminals could potentially compromise corporate security. If an attachment is blocked, a warning message that indicates that the user cannot open the attachment appears in the InfoBar of the email message. Outlook Web Access users who are working in their offices or who are connected to the corporate network from home can open and read attachments. You can enable full intranet access to attachments by providing the URL to the back-end servers and permitting attachments on the Exchange back-end servers.
Prevent users from sending or receiving attachments that have specific file name extensions that could contain viruses. This feature in Outlook Web Access matches the attachment blocking functionality in Outlook. For received messages, a warning message that indicates that an attachment is blocked appears in the InfoBar of the email message. For sent messages, users cannot upload any files that have extensions that appear on the block list.
To change the attachment blocking settings, you must change the registry settings on the server.
Collapse this imageExpand this image
Note In a front-end / back-end configuration, the registry
modifications should be made on the back-end server.
To do this,
follow these steps.
Collapse this imageExpand this image
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
Back to the top
