Front-End and Back-End Server Topology

Guide for Microsoft Exchange Server

2003 and Exchange 2000 Server

Microsoft Corporation

Published: December 12, 2006

Author: Exchange Server Documentation Team

Abstract
This guide discusses Exchange Server front-end and back-end server architecture and
topology.

Comments? Send feedback to [email protected].

Contents
Front-End and Back-End Server Topology Guide for Microsoft Exchange Server 2003 and
Exchange 2000 Server..........................................................................................................1

Contents...................................................................................................................................3

Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange
2000 Server...........................................................................................................................9

Introduction to Front-End and Back-End Topologies for Exchange Server 2003 and Exchange
2000 Server...........................................................................................................................9
Assumed Knowledge...........................................................................................................10
New Exchange Server 2003 Features for the Front-End and Back-End Architecture.........10
Kerberos Authentication......................................................................................................10
RPC over HTTP..................................................................................................................10
Exchange Server 2003 Editions..........................................................................................11
Forms-Based Authentication...............................................................................................11
Outlook Web Access Version Support.................................................................................11

Front-End and Back-End Topologies Overview......................................................................12

Front-End and Back-End Topology Advantages.....................................................................14

Single namespace...............................................................................................................14
Offloads SSL Encryption and Decryption............................................................................14
Security...............................................................................................................................14
Improved Public Folder Access and Features.....................................................................15
Increased IMAP Access to Public Folders...........................................................................15
Multiple Protocols Supported..............................................................................................15

How a Front-End and Back-End Topology Works...................................................................16

Integration with Internet Information Services.........................................................................16

Remote Procedure Calls in a Perimeter Network...................................................................16

Dependency on DSAccess.....................................................................................................17

System Attendant on Front-End Servers................................................................................17

Supporting POP and IMAP Clients.........................................................................................19

Authentication for POP and IMAP Clients...........................................................................19
IMAP Access to Public Folders............................................................................................19

Running SMTP for POP and IMAP Clients.............................................................................20

Supporting HTTP Access........................................................................................................21
Finding User Mailboxes.......................................................................................................22
Logging on to Outlook Web Access.....................................................................................22
Simplifying the Outlook Web Access URL...........................................................................24
Enabling the "Change Password" Feature..........................................................................24
Finding Public Folders.........................................................................................................24

How to Simplify the Outlook Web Access URL.......................................................................29

Before You Begin................................................................................................................30
Procedure............................................................................................................................30
For More Information...........................................................................................................30

Authentication Mechanisms for HTTP....................................................................................30

Dual Authentication.............................................................................................................31
Pass-Through Authentication..............................................................................................31
Authentication Methods.......................................................................................................32
Client to Front-end Server Authentication............................................................................32
Basic Authentication............................................................................................................32
Forms-Based Authentication...............................................................................................33
Front-End to Back-End Authentication................................................................................33
Integrated Authentication.....................................................................................................33
Basic Authentication............................................................................................................34
User Logon Information.......................................................................................................34

Remote Procedure Calls (RPCs) in the Exchange Front-End and Back-End Topology..........34
Features Lost by Placing an Exchange Front-End Server in the Perimeter Network without
RPC Access.....................................................................................................................35

Considerations When Deploying a Front-End and Back-End Topology..................................36

Do Not Cluster Front End Servers.......................................................................................36
Recommended Server Configurations and Ratios..............................................................36
Load Balancing...................................................................................................................36
Reducing Virtual Server Creation........................................................................................37

Using Firewalls in a Front-End and Back-End Topology.........................................................38

Port Filtering........................................................................................................................38
Source Port versus Destination Port...................................................................................38
Direction of the TCP Connection.........................................................................................38
IP Filtering...........................................................................................................................39
Application Filtering.............................................................................................................39

Helping to Secure Communication: Client to Front-End Server..............................................39

Configuring SSL in a Front-End and Back-End Topology....................................................40
SSL Accelerators.................................................................................................................40
SSL Offloading....................................................................................................................41
 Forms-Based Authentication...............................................................................................42

How to Enable Forms-Based Authentication When Using SSL Offloading.............................42

Before You Begin................................................................................................................42
Procedure............................................................................................................................42
For More Information...........................................................................................................43

Securing Communication: Front-End to Other Servers..........................................................43

IP Security (IPSec)..............................................................................................................43
IPSec Protocols...................................................................................................................44
IPSec Policy........................................................................................................................44
IPSec with Firewalls and Filtering Routers..........................................................................44

Service Packs: Upgrading Front-End and Back-End Servers.................................................45

Upgrading Considerations for Outlook Web Access............................................................46

Scenarios for Deploying a Front-End and Back-End Topology...............................................47

Advanced Firewall in a Perimeter Network.............................................................................47

Scenario..............................................................................................................................48
Setup Instructions...............................................................................................................48
Discussion...........................................................................................................................49
Issues..................................................................................................................................49

How to Set Up a Front-End and Back-End Topology with an Advanced Firewall in a Perimeter
Network...............................................................................................................................50
Before You Begin................................................................................................................51
Procedure............................................................................................................................51

Front-End Server behind a Firewall........................................................................................52

Scenario..............................................................................................................................52
Setup Instructions...............................................................................................................52
Discussion...........................................................................................................................53

How to Set Up a Front-End and Back-End Topology with a Front-End Server Behind a
Firewall................................................................................................................................53
Before You Begin................................................................................................................53
Procedure............................................................................................................................54

Web Farm with a Firewall.......................................................................................................54

Scenario..............................................................................................................................55
Setup Instructions...............................................................................................................55
Discussion...........................................................................................................................55
Issues..................................................................................................................................55

How to Set Up a Front-End and Back-End Topology with a Web Farm Behind a Firewall......55
Before You Begin................................................................................................................56
 Procedure............................................................................................................................56

Front-End Server in a Perimeter Network...............................................................................56

Scenario..............................................................................................................................57
Setup Instructions...............................................................................................................57
Discussion...........................................................................................................................58
Issues..................................................................................................................................58

How to Set Up a Front-End and Back-End Topology with a Front-End Server in a Perimeter
Network...............................................................................................................................59
Before You Begin................................................................................................................59
Procedure............................................................................................................................59
For More Information...........................................................................................................60

Configuring Exchange Front-End Servers..............................................................................60

How to Designate a Front-End Server....................................................................................60

Before You Begin................................................................................................................60
Procedure............................................................................................................................61
For More Information...........................................................................................................61

Creating HTTP Virtual Servers...............................................................................................62

How to Create a Virtual Server...............................................................................................62

Procedure............................................................................................................................62

Configuring Authentication......................................................................................................63

How to Configure Authentication on a Front-End Server........................................................63

Before You Begin................................................................................................................64
Procedure............................................................................................................................64

Configuring the Front-End Server to Assume a Default Domain.............................................64

Configuring Forms-Based Authentication for Exchange Server 2003.................................65

How to Configure a Front-End Server to Assume a Default Domain......................................66

Before You Begin................................................................................................................66
Procedure............................................................................................................................66

How to Configure Forms-Based Authentication on Exchange Server 2003............................66

Before You Begin................................................................................................................67
Procedure............................................................................................................................67

Allowing the Use of an E-Mail Address as the Logon User Name..........................................67

How to Allow the Use of an E-mail Address as the Logon User Name...................................68
Before You Begin................................................................................................................68
Procedure............................................................................................................................68
Disabling Unnecessary Services............................................................................................69

URLSCan and IIS Lockdown Wizard......................................................................................70

Disconnecting and Deleting Public and Mailbox Stores..........................................................71

Configuring Network Load Balancing.....................................................................................72

Configuring Secure Sockets Layer.........................................................................................72

How to Configure SSL for POP3, IMAP4, and SMTP.............................................................72

Procedure............................................................................................................................72

How to Configure SSL for HTTP.............................................................................................73

Procedure............................................................................................................................73
For More Information...........................................................................................................73

Configuring SMTP on the Front-End Server...........................................................................73

Mail for Internal Domains....................................................................................................74
Mail for External Domains...................................................................................................74

Configuring DSAccess for Perimeter Networks......................................................................74

Disabling the NetLogon Check............................................................................................75
Disabling the Directory Access Ping....................................................................................75
Specifying Domain Controllers and Global Catalog Servers...............................................75

How to Disable the NetLogon Check on a Front-End Server..................................................76

Before You Begin................................................................................................................76
Procedure............................................................................................................................76

How to Disable the Directory Access Ping..............................................................................77

Before You Begin................................................................................................................77
Procedure............................................................................................................................77

Hosting Multiple Domains.......................................................................................................77

Method One: Create Additional Virtual Servers...................................................................78
Method Two: Create Additional Virtual Directories..............................................................80

How to Add a Virtual Directory Under an HTTP Virtual Server in Exchange Server 2003......80
Procedure............................................................................................................................81
For More Information...........................................................................................................81

How to Create Virtual Directories...........................................................................................81

Procedure............................................................................................................................82

Configuring a Back-End Server..............................................................................................82

Configuring Authentication on a Back-End Server..................................................................83

Creating and Configuring HTTP Virtual Servers on Back-End Servers..................................83
Method One: Configure Additional Virtual Servers..............................................................84
Method Two: Create Additional Virtual Directories..............................................................84

How to Configure Additional Virtual Servers on a Back-End Server.......................................84

Before You Begin................................................................................................................85
Procedure............................................................................................................................85

Configuring Firewalls..............................................................................................................85

Configuring an Internet Firewall..............................................................................................86

Configuring ISA Server........................................................................................................86

Configuring an Intranet Firewall..............................................................................................87

Advanced Firewall Server in the Perimeter Network...........................................................87
Front-end Server in Perimeter Network...............................................................................88
Basic Protocols...................................................................................................................88
Active Directory Communication.........................................................................................89
Domain Name Service (DNS).............................................................................................90
IPSec...................................................................................................................................90
Remote Procedure Calls (RPCs)........................................................................................91
Stopping RPC Traffic...........................................................................................................91
Restricting RPC Traffic........................................................................................................91

Front-End and Back-End Topology Checklist.........................................................................92

Front-End and Back-End Topology Troubleshooting..............................................................97

Troubleshooting Tools.........................................................................................................97
General Troubleshooting Steps...........................................................................................97
Logon Failures....................................................................................................................98
Troubleshooting Outlook Web Access.................................................................................99

Copyright................................................................................................................................99
 9

Front-End and Back-End Server Topology

Guide for Exchange Server 2003 and
Exchange 2000 Server
Microsoft® Exchange Server 2003 and Microsoft Exchange 2000 Server support using a
server architecture that distributes server tasks among front-end and back-end servers. In
this architecture, a front-end server accepts requests from clients and proxies them to the
appropriate back-end server for processing. This guide discusses how Exchange Server
2003 and Exchange 2000 Server support the front-end and back-end server architecture.
Also covered are several front-end and back-end scenarios and recommendations for
configuration.

Note:
Download Front-End and Back-End Server Topology Guide for Microsoft Exchange
Server 2003 and Exchange 2000 Server to print or read offline.

Introduction to Front-End and Back-End

Topologies for Exchange Server 2003
and Exchange 2000 Server
Microsoft® Exchange Server2003 and Microsoft Exchange2000 Server support using a
server architecture that distributes server tasks among front-end and back-end servers. In
this architecture, a front-end server accepts requests from clients and proxies them to the
appropriate back-end server for processing. This guide discusses how Exchange Server2003
and Exchange2000 Server support the front-end and back-end server architecture. This
guide also describes several front-end and back-end scenarios and provides
recommendations for configuration.

Note:
A front-end server is a specially configured server running either Exchange
Server2003 or Exchange 2000 Server software. A back-end server is a server with a
standard configuration. There is no configuration option to designate a server as a
back-end server. The term "back-end server" refers to all servers in an organization
that are not front-end servers after a front-end server is introduced into the
organization.
 10

Important:
The information in this guide pertains to Exchange Server 2003 or later, and
Exchange 2000 Server with Service Pack 3 (SP3) or later. Therefore, if you are
running earlier builds, upgrade to either Exchange Server 2003 or
Exchange 2000 Server with Service Pack 3 (SP3) to take full advantage of the
features described in this guide.

Assumed Knowledge
You should have an understanding of Microsoft® Office Outlook® Web Access, Outlook
Mobile Access, Exchange ActiveSync®, RPC over HTTP, Hypertext Transfer Protocol
(HTTP), Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), and
Internet Message Access Protocol (IMAP) version 4rev1 in a standard Exchange
deployment, in addition to basic Exchange 2000 Server and Microsoft Windows® Internet
Information Services (IIS) concepts.

New Exchange Server 2003 Features for the

Front-End and Back-End Architecture
Exchange Server 2003 builds on the front-end and back-end server architecture and adds
new features and capabilities such as RPC over HTTP communication that enables users
with Outlook 2003 clients to access their Exchange information from the Internet.
Additionally, the standard version of Exchange Server 2003 enables you to configure a
server as a front-end server.

Kerberos Authentication
New for Exchange Server 2003 is the ability for the Exchange front-end server to use
Kerberos authentication for HTTP sessions between the front-end and its respective back-
end servers. While the authentication is now using Kerberos, the session is still being sent
using clear text. Therefore, if the network is public or the data is sensitive, it is recommended
that you use Internet Protocol security (IPSec) to secure all communication between the
Exchange front-end and back-end servers.

RPC over HTTP

With Exchange Server 2003 you can now use the Windows RPC over HTTP feature to
enable users who are running Outlook 2003 to be able to access their corporate information
from the Internet. Information about how to plan, deploy, and manage this new feature for
Exchange is in Exchange Server 2003 RPC over HTTP Deployment Scenarios.
 11

Exchange Server 2003 Editions

Exchange Server 2003 is available in two editions, Exchange Server 2003 Standard Edition
and Exchange Server 2003 Enterprise Edition. You can configure either for use as a front-
end server in a front-end and back-end server architecture.

Note:
Exchange 2000 Server can be used only as a back-end server in a front-end and
back-end configuration. However, Exchange 2000 Enterprise Server can be used as
a front-end server or a back-end server in a front-end and back-end configuration.
For more information about the differences between Exchange 2000 Server and
Exchange 2000 Enterprise Server, see Microsoft Knowledge Base article 296614,
"Differences between Exchange 2000 Standard and Enterprise versions."

Forms-Based Authentication
Exchange Server 2003 includes a new authentication feature for your Outlook Web Access
clients. For information about how to enable this feature, see Authentication Mechanisms for
HTTP.

Outlook Web Access Version Support

To provide the new Exchange Server 2003 version of Outlook Web Access for users,
Exchange Server 2003 must be installed on both the front-end server and the back-end
server to which your users connect. When users connect to an Exchange 2003 front-end and
back-end server, they are able to take advantage of the following features:

• Forms-based authentication
• Replying to and forwarding posts in a public folder through Outlook Web Access

• Integrated authentication between the front-end and back-end servers

Different combinations of Exchange Server 2003, Exchange 2000 Server, and Microsoft
Exchange Server 5.5 determine the version of Outlook Web Access that your users can use.
The following table lists the version of Outlook Web Access that users have access to, based
on the versions of Exchange that are installed on the front-end and back-end servers.

Outlook Web Access versions available to users

Front-end server Back-end server Outlook Web Access version

Exchange 5.5 Exchange 5.5 Exchange 5.5

Exchange 5.5 Exchange 2000 Exchange 5.5

Exchange 5.5 Exchange 2003 Not supported

 12

Exchange 2000 Exchange 5.5 Not supported

Exchange 2000 Exchange 2000 Exchange 2000

Exchange 2000 Exchange 2003 Not supported

Exchange 2003 Exchange 5.5 Not supported

Exchange 2003 Exchange 2000 Exchange 2000

Exchange 2003 Exchange 2003 Exchange 2003

The Exchange Server 2003 version and the Exchange 2000 Server version of Outlook Web
Access are substantially different from the Exchange Server 5.5 version of Outlook Web
Access. The Exchange Server 5.5 version of Outlook Web Access uses Active Server Pages
(ASP) to communicate with an Exchange computer that uses Collaboration Data Objects
(CDO) 1.2 and MAPI. The number of clients that can access the mailbox store at the same
time is limited by the MAPI-based connection to the Exchange computer.

The Exchange Server 2003 version and the Exchange 2000 Server version of Outlook Web
Access do not use MAPI to access the mailbox store, and they do not use ASP pages for
client connections. Clients continue to connect to the Web Access Component through
Hypertext Transfer Protocol (HTTP). However, the Internet Information Services (IIS) server
that hosts the Outlook Web Access component uses the Microsoft Exchange Store service to
provide access to the user's messaging functions. IIS receives Outlook Web Access client
requests as a proxy for message traffic between a Web client and an Exchange 2003 server
or an Exchange 2000 server. If the server contains the Exchange 2003 database, Outlook
Web Access uses a high-speed channel to access the mailbox store. If the server is a front-
end server, Outlook Web Access sends the request to a back-end server using HTTP.

Front-End and Back-End Topologies

Overview
The figures in this topic describe the common implementations of the front-end and back-end
server architecture. The following figure illustrates a simple Exchange front-end and back-end
topology.
 13

An Exchange front-end and back-end server architecture without an advanced firewall

The following figure illustrates the recommended scenario that uses an advanced firewall,
such as Microsoft® Internet Security and Acceleration (ISA) Server with Service Pack1 (SP1)
and Feature Pack1, between the Internet and the Exchange front-end server.

The recommended Exchange front-end and back-end server architecture

 14

Front-End and Back-End Topology

Advantages
The front-end and back-end server topology should be used for multiple-server organizations
that provide e-mail access to their employees over the Internet. Additionally, organizations
that use Microsoft® Office Outlook® Web Access, POP, IMAP, and RPC over HTTP on their
internal network can also benefit from a front-end and back-end server topology.

Single namespace
The primary advantage of the front-end and back-end server architecture is the ability to
expose a single, consistent namespace. You can define a single namespace for users to
access their mailboxes (for example, https://mail for Outlook Web Access). Without a front-
end server, each user must know the name of the server that stores their mailbox. This
complicates administration and compromises flexibility, because every time your organization
grows or changes and you move some or all mailboxes to another server, you must inform
the users.

With a single namespace, users can use the same URL or POP and IMAP client
configuration, even if you add or remove servers or move mailboxes from server to server.
Additionally, creating a single namespace ensures that HTTPS, POP, or IMAP access
remains scalable as your organization grows. Finally, a single namespace reduces the
number of server certificates required for SSL encryption because clients are using SSL to
the same servers and using the same namespace.

Offloads SSL Encryption and Decryption

Clients such as Microsoft Office Outlook® 2003 or Outlook Web Access that access your
Exchange servers from the Internet should use Secure Sockets Layer (SSL) to connect to
their Exchange servers to protect the traffic from interception. However, processing SSL
traffic can be a significant overhead for a server. The front-end and back-end architecture
allows the front-end to handle the SSL encryption, freeing up the processor on the back-end
Exchange servers to allow for increased overall e-mail performance. Additional improvements
can be made using SSL accelerators or offloading SSL encryption to advanced firewalls
(such as ISA 2000 with Service Pack 1 and Feature Pack 1).

Security
You can position the front-end server as the single point of access on or behind an Internet
firewall that is configured to allow only traffic to the front-end from the Internet. Because the
front-end server has no user information stored on it, it provides an additional layer of security
 15

for the organization. In addition, the front-end servers authenticate requests before proxying
them, protecting the back-end servers from denial-of-service attacks.

Improved Public Folder Access and Features

A front-end Exchange server increases the robustness of accessing public folders, as it
knows the state of back-end servers and can use multiple referrals to access public folder
data. This includes system data such as calendar free/busy information. In addition, in
Exchange Server 2003, a front-end Exchange server enables your users using Outlook Web
Access to reply or forward to posts in public folders. Without a front-end server, public folder
posts can be only read.

Increased IMAP Access to Public Folders

The IMAP protocol specification allows a server to refer a client to another server. Exchange
supports this referral functionality in cases where a public folder store on a particular server
does not contain the content requested and the client needs to be referred to another server.
However, this requires a client that supports IMAP referrals, and most clients do not support
referrals. (The University of Washington Pine client and toolkit is one example of a client that
supports referrals.)

When a non referral-enabled IMAP client connects through a front-end server, the client can
access the entire public folder hierarchy, as the front-end server itself will automatically
handle any referrals. This makes the referral transparent to the client. For more information
about non referral-enabled IMAP clients, see Request for Comments (RFC) 2221 and RFC
2193.

Multiple Protocols Supported

The front-end and back-end architecture supports RPC over HTTP, HTTP, POP, and IMAP.
You can also install SMTP on the front-end server, although there are essentially no
differences between SMTP on a front-end or back-end server.

Note:
The MAPI remote procedure call (RPC) protocol (that is used by Outlook on non-
RPC over HTTP mode) is not proxied by the front-end server. Outlook has built-in
support for handling situations where mailboxes are moved from one server to
another or where content is not available on a server.
 16

How a Front-End and Back-End Topology

Works
Although the general functionality of the front-end server is to proxy requests to the correct
back-end servers on behalf of the client computers, the exact functionality of the front-end
server depends on the protocol and the action being performed.

This section discusses the Windows® and Microsoft Exchange Server components that are
essential to understanding how front-end and back-end topology works. Make sure that you
understand how these components function in a front-end and back-end topology and assess
whether the modifications will affect your organization.
This section also explains how front-end and back-end servers support the various client
protocols.

Integration with Internet Information

Services
Exchange stores configuration information in Active Directory® directory service, whereas
Internet Information Services (IIS) stores configuration information in the metabase. The
metabase is a local configuration database shared by the protocols that IIS supports. The
Exchange System Attendant service regularly replicates relevant configuration changes made
in Active Directory through Exchange System Manager to the metabase. You can tell when
the configuration replication has occurred by looking for entries in Event Viewer from the
metabase update service (MSExchangeMU). To view MSExchangeMU events, in the server's
properties, on the Diagnostics Logging tab, set the MSExchangeMU logging level to
Minimum or greater.

Remote Procedure Calls in a Perimeter

Network
If you decide to situate your Exchange front-end servers in a perimeter network, be aware
that remote procedure calls (RPCs) are used to access Active Directory.

Note:
It is recommended that you use an advanced firewall server (such as ISA Server)
instead of the front-end server in the perimeter network. For more information, see
Advanced Firewall in a Perimeter Network.
 17

Remote Procedure Calls are used by Internet Information Services (IIS) to authenticate
clients on the front-end server.

Dependency on DSAccess
DSAccess is a shared Exchange Server component that accesses and stores directory
information in a cache. DSAccess dynamically detects the directory servers that other
Exchange components should contact, based on criteria such as Active Directory site
configuration and Active Directory server availability. Exchange front-end servers use
DSAccess to determine which server contains a particular user's mailbox, the Simple Mail
Transfer Protocol (SMTP) addresses that exist for a user object, the servers that contain
public folder stores, and so on.

DSAccess uses Lightweight Directory Access Protocol (LDAP) for most operations. However,
DSAccess still uses RPCs to call the NetLogon service for each domain controller and global
catalog server that it discovers.

If you put a front-end server in a perimeter network where you want to restrict RPC traffic
between the perimeter network and the corporate network to specific services only, the
NetLogon RPC from DSAccess to domain controller and global catalog servers may fail. If
this occurs, DSAccess determines that RPC connectivity is just blocked, and that the servers
are still available. However, DSAccess continues to send the NetLogon RPC, which may
affect performance.

To stop DSAccess from doing the NetLogon RPC check, you can create a registry key. For
more information about optimizing DSAccess in a perimeter network, see Configuring
DSAccess for Perimeter Networks.

System Attendant on Front-End Servers

By default, Exchange System Attendant no longer requires RPCs when it runs on a front-end
server. The components of System Attendant that use RPCs are no longer loaded on front-
end servers; therefore, these components are disabled when you designate a server as a
front-end server. The following list briefly describes these components:

• DSProxy

The DSProxy service refers MAPI clients (such as Microsoft® Office Outlook® 2002) to
global catalog servers for global address list lookups. DSProxy also allows MAPI clients
with older versions of Outlook to access Active Directory. DSProxy no longer runs on
front-end servers; therefore, the front-end server can no longer determine which back-
end server contains a MAPI client's mailbox. As a result, you cannot point a MAPI client
 18

to the front-end server to determine the user's back-end server and then route the
request to the appropriate server.

Note:
To enable DSProxy on the front-end server for routing MAPI client requests,
install Exchange 2000 Server Service Pack 3 (SP3) and create the registry key
described in Microsoft Knowledge Base article 319175, "XADM: You Cannot
Perform a Check Names Query Against a Front-End Exchange Computer." Note
that to receive these referrals, the client must have RPC access to the front-end
server. Additionally, the front-end server must have RPC access to domain
controllers.

• Recipient Update Service

The Recipient Update Service updates recipients in the directory to match address lists
or recipient proxy policies. The Recipient Update Service no longer runs on front-end
servers, so be sure that none of your front-end servers are designated to run the
Recipient Update Service. To do this, in Exchange System Manager, under Recipients,
check the properties of each Recipient Update Service and ensure that no front-end
servers are named in the Exchange server field.

• Offline Address Book Generation (OABGen)

OABGen creates the offline address book. Without the OABGen service, front-end
servers no longer generate offline address books.

• Group Polling

System Attendant uses group polling to ensure that the local computer remains a
member of the Domain Exchange Servers group. System Attendant polls the Domain
Exchange Servers group and adds the local computer back to the group if it is no longer
a member. Front-end servers no longer perform this function.

• Mailbox Management

The Mailbox Management service starts and stops the mailbox cleanup process
according to the settings defined in Recipient Policies. Mailbox Management no longer
runs on front-end servers.

• Free/Busy (madfb.dll)

The free/busy service manages user schedules. This service no longer runs on front-end
servers.
 19

Supporting POP and IMAP Clients

When you use a front-end server, the names of the servers that host the mailboxes are
hidden from the users. Client computers connect to one host name shared by the front-end
servers. As a result, moving users between servers is transparent to the users and requires
no reconfiguration of client computers.

To log on, a POP or IMAP client sends the front-end server a logon request that contains the
name of the mailbox to be accessed. The front-end server authenticates the user and uses
Active Directory to determine which back-end server contains the user's mailbox. The front-
end server then proxies the logon request to the appropriate back-end server. The back-end
server then sends the results of the logon operation back to the front-end server, which
returns the results of the operation back to the client. Subsequent POP or IMAP commands
are similarly handled.

Note:
SMTP must be available to allow POP and IMAP clients to submit e-mail. You can
install SMTP on the front-end server or set up a separate SMTP server. E-mail
submission through SMTP on the front-end server works the same as it does on any
other server running Exchange. For more information about how to configure SMTP
on a front-end server, see Configuring Exchange Front-End Servers.

Authentication for POP and IMAP Clients

POP and IMAP e-mail clients send user and password information in clear text. If the front-
end server is accessible from the Internet, you should configure SSL so that user
authentication information and data is not passed over the Internet in clear text.

IMAP Access to Public Folders

When a non referral-enabled IMAP client connects to a back-end server, it can access only
public folders that have a replica on the user's home server. To access public folders that
have replicas on other servers, an IMAP client must be referral-enabled. A referral-enabled
client issues special commands to an IMAP server to create a list of the public folders
available to the client. When the client computer requests a public folder that does not have a
local replica, the server responds to the client request with a referral URL that contains the
name of the server that has the public folder. The referral-enabled IMAP client computer then
creates a new connection to that server to retrieve the appropriate information.

In a front-end and back-end topology, however, the front-end server acts as a referral-
enabled client, so IMAP clients connecting to the front-end server do not need to support
referrals; the front-end server handles referrals for them. It transparently maps non referral-
enabled client requests to their referral counterparts, making the entire list of public folders
 20

available to a non referral-enabled client. When the front-end server receives a referral
response from the back-end server, it does not pass this response back to the client. Instead
it follows the referral for the client and makes a connection to the appropriate back-end server
that has the data. The back-end server then responds with the requested item, which the
front-end server relays back to the client.

Running SMTP for POP and IMAP Clients

POP and IMAP protocols are used only for receiving mail; you must configure SMTP on the
front-end server so that POP and IMAP clients can submit mail. You do not have to run SMTP
on the Exchange front-end server. Instead, you can use another server as a dedicated SMTP
gateway.

Important:
To run SMTP on the front-end server and enable it to accept inbound mail (mail for
your domains), you must mount a mailbox store on the front-end server. This mailbox
store must not contain any mailboxes. You must mount a mailbox store on the front-
end server because any non-delivery reports (NDRs) must be routed through the
mailbox store for formatting.

To configure SMTP so that POP and IMAP clients can submit mail to external domains, you
must allow relaying.

By default, Exchange allows relaying only from authenticated clients. It is recommended that
you keep this default. Clients such as Microsoft Outlook Express 6.0 and Microsoft® Office
Outlook® 2003, and previous versions of Outlook Express and Outlook support SMTP
authentication in addition to Transport Layer Security (TLS) encryption.

You should not allow relaying in either of the following ways:

• You should not allow anonymous relaying to all IP addresses; if your front-end server
is connected to the Internet, doing this allows anyone on the Internet to use your server
to send mail.

• You should not allow relaying from specific client IP addresses. Even if you are
familiar with the subnet from which clients send mail, the Internet environment makes it
difficult to determine such a specific set of IP addresses.

Note:
If you want the front-end server to act as the bridgehead server between your
company and the Internet, it is recommended that the server on the Internet that
accepts mail for your domains has the ability to scan incoming messages for viruses.
 21

Note:
For more information, see the Exchange technical guide, Exchange Server 2003
Transport and Routing Guide.

Supporting HTTP Access

Whether generated by a browser or a specialized client, HTTP requests from the client
computer are sent to the front-end server. The front-end server uses Active Directory to
determine which back-end server to proxy the request to.

After determining the appropriate back-end server, the front-end server forwards the request
to the back-end server. Apart from specific header information that indicates the request was
passed through a front-end server, the request is almost the same as the original request
sent from the client. In particular, the HTTP host header, which matches the name of the
front-end server to which the request was sent (meaning the hostname or fully qualified
domain name that the user entered in the browser), remains unchanged. The front-end server
contacts the back-end server using the hostname of the back-end server (for example,
backend1), but in the HTTP headers of the request, the front-end server sends the host
header used by the client, for example, www.adatum.com. The host header setting ensures
that the appropriate back-end Exchange virtual server handles the request. For more
information about configuring virtual servers on a back-end server, see Configuring a Back-
End Server.

For HTTP requests, the front-end server always contacts the back-end server over TCP port
80 (the default HTTP port), regardless of whether the client contacted the front-end server
through port 80 or 443 (the SSL port). This means that:

• HTTP virtual servers on the Exchange front-end server can listen only on port 80
(HTTP) or 443 (HTTPS).

Note:
No other ports other than port 80 and port 443 can be used for HTTP virtual
servers on the Exchange front-end servers.

• SSL encryption is never used between the front-end and back-end servers, although
the client should use it to communicate with the front-end server.

• HTTP virtual servers that differentiate themselves from other servers only by port
number are not supported in a front-end and back-end topology. For example, if a back-
end server has an HTTP virtual server listening on port 8080, a client can access that
back-end server only if the client is pointed directly to the back-end server (for example,
http://backend1:8080/data). A client connecting to the front-end server cannot access this
data.
 22

The back-end server processes the HTTP request from the front-end normally, and the
response is sent unchanged through the front-end server back to the client. This whole
process is not visible to the client, which just interacts with the front-end server. The client is
unaware of how the request was handled internally.

Finding User Mailboxes

To provide access to mailbox folders through HTTP, you must have a virtual directory on both
the Exchange front-end and back-end servers that points to the mailboxes.

Note:
User mailboxes cannot be stored on the front-end server.

When you install Exchange, a virtual directory named "Exchange" is created in the default
virtual server. This directory points to the default SMTP domain for the Exchange
organization. When you configure additional virtual directories on the front-end server through
Exchange System Manager, you can select the SMTP domain name. In
Exchange 2000 Server SP3 and Exchange Server 2003, users connecting to that virtual
server must have an e-mail address in their list of SMTP proxy addresses on their object in
Active Directory with the same domain. In Exchange Server 2003 SP1, users can override
the SMTP domain by specifying the SMTP address in the URL (for explicit logon), or just use
an implicit logon. For more information see "Logging on to Outlook Web Access" later in this
topic.

In the dialog box where the SMTP domain is selected, the list of domains is a list of all
domains for which there are recipient policies. Therefore, you might see duplicates in the list;
it is not important which one you select.

When the front-end server detects a request to a location in the mailbox store (based on the
setting of the virtual server or directory), it contacts an Active Directory global catalog server
in the domain using Lightweight Directory Access Protocol (LDAP) and determines which
back-end server contains the user's mailbox.

Logging on to Outlook Web Access

Users can log on to Outlook Web Access using either implicit logon or explicit logon.

Implicit Logon
If the front-end server is configured to authenticate users, users can access their mailboxes
by omitting the username from the request, and pointing their browser to their mailbox virtual
directory. The usual URL is https://<server>/exchange/. After authenticating the user, the
authentication information is used to look up the mailbox associated with the user in Active
Directory and the back-end server on which the mailbox is located. The URL is updated with
 23

the user name and sent to the correct back-end server. This is known as implicit logon.
Implicit logon is useful only for logging on to Outlook Web Access; specialized HTTP clients
generally do not use implicit logon.

Exchange 2000 Server SP3 and Exchange Server 2003

Implicit logon makes use of the SMTP domain specified on the HTTP virtual directory to
identify the user. Therefore, users connecting to that virtual server must have an e-mail
address in their list of SMTP proxy addresses on their object in Active Directory with the same
domain.

Exchange Server 2003 SP1

Implicit logon no longer relies exclusively on the SMTP domain specified. All the user
information can be gleaned from their logon. Users can use any mailbox Exchange virtual
directory to access their e-mail messages.

Explicit Logon
There are a few URLs that users can use to connect to Outlook Web Access. The usual URL
is https://<server>/exchange/<username>/.Accessing Outlook Web Access using this URL is
referred to as explicit logon.

Explicit logon must be used when the front-end server is not configured to authenticate users
(for more information about authentication, see Authentication Mechanisms for HTTP) or
when a user is attempting to access a mailbox that is not their own but to which they have
access, for example, in the case of delegate users.

Exchange 2000 Server SP3 and Exchange Server 2003

When the front-end server receives an explicit logon request from a client, the user name is
extracted from the URL and combined with the SMTP domain name associated with the
virtual directory or virtual server to construct a fully qualified SMTP address. The front-end
server looks up this address in Active Directory and determines which back-end server has
the mailbox associated with the address. The front-end server then forwards the request to
that back-end server, which processes the request and returns it back through the front-end
server to the client.

Exchange Server 2003 SP1

The user can choose to override the SMTP domain configured on the mailbox virtual
directory, by specifying the SMTP address in the URL itself. For example;
https://<server>/exchange/[email protected]. If no SMTP domain is specified, the
SMTP domain from the virtual directory will be used.

You can prevent specific users from accessing Outlook Web Access by disallowing the HTTP
protocol for those users. To change a user's protocol settings, in Active Directory Users and
Computers, use the Exchange Advanced tab in a user's properties.
 24

Simplifying the Outlook Web Access URL

Users commonly request that a simpler URL be made available for accessing their mailbox.
For detailed instructions on simplifying the Outlook Web Access URL, see How to Simplify the
Outlook Web Access URL.

Enabling the "Change Password" Feature

If you are using Outlook Web Access, you can enable the Change Password feature in IIS to:

• Alert users when their passwords expire.

• Enable users to use the Options button in Outlook Web Access to change their
passwords.

Keep in mind that if you want to use the Change Password feature, you must also use SSL
between clients and the front-end server to secure the password during transmission.
Additionally, you must create a virtual directory named IISAdmPwd on the front-end server
and back-end servers to handle the Change Password requests.

Note:
The only time you must require SSL on a back-end server is when you want users to
be able to connect to the back-end server directly. Remember, however, that front-
end servers cannot use SSL when connecting to back-end servers. Therefore, if you
require SSL on the back-end server, ensure that you do not require SSL on the
following directories so that front-end servers can still connect to them: Exchange,
Public, ExchWeb, Exadmin, and any mailbox or public folder virtual roots.

For more information about how to configure the Change Password feature, see Microsoft
Knowledge Base article 327134, "XCCC: HOW TO: Use the Change Password Feature in
Outlook Web Access."

For more information about how to configure SSL, see Helping to Secure Communication:
Client to Front-End Server.

Finding Public Folders

Just as you must configure virtual directories for mailboxes, you must also configure virtual
directories for each of the public folder trees that are to be accessible over HTTP through the
front-end server.

When you install Exchange, a virtual directory called "public" is created under the default
Exchange HTTP virtual server to allow access to the default (MAPI-accessible) public folder
tree. When you create other public folder trees (for example, to host applications), you must
also create virtual directories in Exchange System Manager to expose these trees over
 25

HTTP. Identical virtual directories must exist on each front-end server and on all back-end
servers that host the public folder tree.

A request made to a URL in a public folder tree is handled differently when accessing the
default (or MAPI-accessible) public folder tree than when accessing general-purpose public
folders (also known as application Top-Level Hierarchies [TLH], or non-MAPI TLHs).

In both cases the goal for accessing public folders is twofold:

• For availability If data exists in an Exchange 2000 Server or Exchange

Server 2003 public folder somewhere in the Exchange organization and is accessible
over HTTP, it is available to the user.

• For consistency As long as the server is available and the user is authenticated,
the same public folder server services every request from that user. For authenticated
users, ensuring that they go to the same public folder server means that they see the
same data every time that they access the public folder trees through the front-end server
(including status of read and unread messages, which is stored on individual servers and
is not replicated between public folder servers). The fact that users always reach the
same back-end server is also important for server-based applications that maintain
session state, such as some built with Active Server Pages (ASP).

Public Folder Referrals

In Exchange, you can configure public folder replication on a per-folder basis. The actual
public folder tree hierarchy is available on all Exchange public folder servers in the
organization, but the contents of each folder may not be. This information is not stored in
Active Directory but is maintained as a property on each folder in the public folder store.
Therefore, special handling is required when the back-end server selected by the front-end
server does not contain the contents of the folder requested by the client.
The following figure illustrates how public folder referrals travel through a front-end server.
 26

Public folder referral through a front-end server

1. An HTTP client authenticates against the front-end server and requests

/public/PublicFolder2.

2. The front-end server authenticates the user against Active Directory and requests the
location of the user's default public folder store.

3. Active Directory indicates to the front-end server that the user's default public folder
store is on Server1.

4. The front-end server sends the client request to Server1.

5. Server1 tells the front-end server that it does not have the contents of
/public/PublicFolder2, but Server2 and Server3 do.

6. The front-end server performs a hashing algorithm against the list of servers with the
content (in this case, Server2 and Server3). The results of the hash in this case turn out
to be Server2, so the front-end server forwards the request to Server2.

Note:
A hashing algorithm applies a given number (in this case, the user's security
token) and uses it to generate a position in a list so that the distribution of all
possible inputs is even over the list.

7. Server2 returns the contents of /public/PublicFolder2 to the front-end server, which

then sends the contents to the HTTP client.
 27

The Default (MAPI) Public Folder Tree

When a client accesses the default public folder tree in Outlook Web Access, an attempt is
made to maintain parity with MAPI clients such as Outlook. Each mailbox store is associated
with a particular public folder store somewhere in the organization (sometimes on the same
server as the mailbox store, sometimes on a dedicated public folder server). The public folder
store associated with the user's mailbox store is the public folder store that displays the public
folder hierarchy (tree) in Outlook.

When a user requests a public folder in the default public folder tree through HTTP, the front-
end server authenticates the user and looks up the user in Active Directory to see which
public store is associated with that user's mailbox store. The front-end server then forwards
the request to the user's public folder server.

Note that if the front-end server is not configured to authenticate users, requests for public
folders are not load balanced.

General-Purpose Public Folder Trees

Default public folder tree servers have an association with mailbox stores because of their
MAPI heritage; general-purpose public folder trees do not have such an association. As a
result, requests for folders in general-purpose public folder trees are handled slightly
differently than requests for folders in the default public folder tree.

When a client makes a request to access a general-purpose public folder tree, the front-end
server first contacts Active Directory to find a list of all servers running
Exchange 2000 Server or Exchange Server 2003 in the organization that have a replica of
the particular general-purpose public folder tree that the client is attempting to access.

Note:
General-purpose public folder trees are not available in Exchange Server 5.5.

The front-end server then uses the user's authentication token in a hashing algorithm against
the list of servers to ensure that:

• Users are load-balanced across the available servers.

• Individual user requests are always processed by the same back-end server,
regardless of the HTTP client used.

Note:
If you add or remove a back-end server, the output from the hashing algorithm
changes, and users may be redirected to a different server from then on. For more
information, see "Adding or Removing Back-End Servers" later in this topic. It is also
important to note that this applies to MAPI.
 28

When Content Is Not Available on the Back-End Server

The front-end and back-end topology has special handling for times when the back-end
server receives a request for a public folder for which it does not have a replica. This handling
occurs for folders in the default public folder store in addition to folders in general-purpose
public folder trees.

When a back-end server receives such a request, it returns a list of the servers that have the
contents of the requested folder. The front-end server does not pass this information back to
the client, but runs the same hashing algorithm against the new list of servers again, to
ensure load balancing and consistent views. As a result, in organizations that use partial
replicas of public folder trees, the front-end server may have to perform two HTTP requests to
satisfy the client's single request. However, in processing the client's request, the front-end
server caches information about which servers have the content, allowing the front-end
server to avoid extra requests when data in the same folder is accessed in the future.

The caches maintained by the front-end server substantially reduce the number of queries
sent to Active Directory and back-end servers for both public and private folder accesses.
Cache information expires after ten minutes and is also reset when changes in server
configuration are detected.

Note:
Exchange 5.5 servers cannot be selected because they do not support the required
HTTP WebDAV extensions.

Back-End Server Downtime

If a back-end server is down for maintenance or is otherwise inaccessible over HTTP, the
front-end server cannot connect to it. The front-end server marks that server "unavailable" for
a period of 10 minutes and sends the request to a different server if there are other servers
available; the request fails if no other servers are available. While the back-end server is
unavailable, the front-end server automatically directs requests to other servers. Therefore,
after a back-end server returns to production, it might be inaccessible through the front-end
server for as long as 10 minutes, because the front-end server might still have that back-end
server marked as unavailable.

This process significantly increases reliability for public folder access. The front-end server
will attempt to contact multiple back-end servers for the data, whereas a client connecting
directly to a back-end server will not.

Adding or Removing Back-End Servers

The goal of the hashing algorithm is load balancing; however, a condition of the algorithm is
that the distribution of users across servers depends on the number of servers. Therefore, if
the list of servers hosting the content for a public folder changes because of the addition or
 29

removal of a server, the result of the hashing algorithm may direct the user to a new server
for future requests. Typically, when the server processing a user's request changes the user
cannot tell that anything physical changed, with the exception of the following:

• Users may observe that the read or unread state of messages is reset.

• Users of Web-based applications (running in general-purpose public folder trees) that

maintain session state may need to restart their application session if they use the
application during the transition period.

Therefore, it is recommended that administrators inform their users before adding or

removing folder content to public folder servers.

At a high level, the hashing algorithm works as follows: Two back-end servers, numbered 1
and 2, hold the contents of a public folder. Then, if six different users—A, B, C, D, E, and F—
try to access data in this folder, the front-end server distributes their requests over the two
servers as follows:

• Users A, B, and C get their data from server 1.

• Users D, E, and F get their data from server 2.

Note:
This load balancing is done transparently—users do not know which back-end server
is actually handling the request.

Then another server is added, server 3, and the folder's contents are also replicated to this
server. Now the users are distributed as follows:

• Users A and B get the data from server 1.

• Users C and D get the data from server 2.

• Users E and F get the data from server 3.

In this example, users A, B, and D did not change servers, but users C, E, and F did.

How to Simplify the Outlook Web Access

URL
Users commonly request that a simpler URL for Outlook Web Access be made available for
accessing their mailbox. This procedure configures a request sent to the root of the Web
server (http://server/) to redirect to the Exchange virtual directory. For example, a request to
https://mail/ is directed to https://mail/exchange/, which then triggers implicit logon.
 30

Before You Begin

Before you perform the procedures in this topic, it is important that you first read "How a
Front-End and Back-End Topology Works" in the Exchange Server 2003 and Exchange 2000
Server Front-End and Back-End Server Topology Guide.

To successfully complete the procedures in this topic, confirm the following:

• The front-end server has authentication enabled.

Procedure
To simplify the Outlook Web Access URL
1. Using the Internet Services Manager, open the properties for the Default Web
Site.

2. Click the Home Directory tab, and then select A redirection to a URL.

3. In Redirect to, type /<directory name>, and then click A directory below URL
entered. For example, to redirect https://mail/ requests to https://mail/exchange, in
Redirect to, you would type /exchange.

If you want your users to use SSL to access their server, you can redirect client requests
to https://mail/<directory name>. To require users to use SSL, In Redirect to, type
https://mail/<directory name>, and then click A directory below URL entered. This
setting hard codes the name of the server; therefore if you redirect client requests to
https://mail, the client must be able to resolve the name mail.

Note:
Users still must enter the full URL, including username, to access other mailboxes or
content in folders other than the inbox.

For More Information

For more information about enabling authentication on the front-end server (also known as
implicit logon), see "How a Front-End and Back-End Topology Works" in the Exchange
Server 2003 and Exchange 2000 Server Front-End and Back-End Server Topology Guide.

Authentication Mechanisms for HTTP

The front-end server handles authentication in two ways: either the front-end server
authenticates the user itself (either using Basic or forms-based authentication), or it forwards
 31

the request anonymously to the back-end server. Either way, the back-end server also
performs authentication.

Note:
Anonymous authentication on the front-end server is required when it is located in a
perimeter network and cannot use Remote Procedure Calls. This is not a
recommended scenario, as user access cannot be blocked by the front-end server.
For more information about pass-through authentication, see "Pass-Through
Authentication" later in this topic.

Important:
It is strongly recommended that you use dual authentication, in which you configure
both front-end and back-end servers to authenticate users. For more information, see
"Dual Authentication" later in this topic.

Dual Authentication
By default, dual authentication is used with front-end and back-end servers. In dual
authentication, both front-end and back-end servers are configured to authenticate users. You
should configure front-end servers to perform authentication whenever possible. If you cannot
enable authentication on the front-end server, implicit logon does not work, and you cannot
load-balance public folder requests. You can use explicit logon to gain access, regardless of
how authentication is configured.

Note:
Exchange relies on IIS to authenticate HTTP requests. IIS uses RPCs to directory
servers to do authentication. If RPCs are not allowed between the front-end server
and the directory server, you must use pass-through authentication. For more
information about how to enable pass-through authentication and the risks of doing
so, see "Pass-Through Authentication" later in this topic.

Pass-Through Authentication
In pass-through authentication, the front-end server is configured with anonymous
authentication, so it does not ask the user for an authorization header. The front-end server
forwards the user's request to the back-end server, which asks the user for authentication.
The back-end server's request for authentication and the user's response are routed
unchanged through the front-end server.

Note:
When you use pass-through authentication, anonymous HTTP requests go directly to
the back-end server where they are authenticated. You should use pass-through
authentication only if absolutely necessary. The recommended strategy is to place an
 32

advance firewall in the perimeter network and the front-end server behind the internal
firewall – so it has full RPC access to the internal network. If you do want to place the
front-end server in the perimeter network, it may be more secure to allow RPCs than
to allow anonymous requests to reach back-end servers, because pass-through
authentication allows requests from any source, valid or invalid, to be passed to your
back-end servers. For more information, see Scenarios for Deploying a Front-End
and Back-End Topology.

When pass-through authentication is used, the front-end server cannot load-balance public
folder requests, because it does not have the authentication token on which to perform a
hashing algorithm. Additionally, implicit logon will not work. Users must enter the full URL
including their user name to log on.

Authentication Methods
There are several authentication methods for your front-end and back-end server architecture
depending on the version of Exchange you are using. Additionally, authentication between the
client and front-end server has different options, in contrast to the authentication used
between the front-end and back-end servers. The following sections outline the two
authentication methods.

Client to Front-end Server Authentication

Note:
Front-end servers do not support integrated Windows authentication (which includes
both NTLM and Kerberos authentication) or HTTP 1.1 Digest authentication.

Basic Authentication
Basic authentication is a simple authentication mechanism defined by the HTTP specification
that lightly encodes the user's user name and password before sending it to the server. To
achieve real password security in a front-end and back-end topology, you should use SSL
encryption between the client and the front-end server.

Note:
Basic authentication is supported by Exchange 2000 Server and Exchange
Server 2003.

Basic authentication does not support single sign on. Single sign on is when a user logs on to
a computer that is running Windows, the user authenticates against a domain, and then the
user can access all resources and applications in the domain without re-entering their
credentials. Microsoft Internet Explorer versions 4.0 and later allow single sign on for Web
applications, including Outlook Web Access, if the server being accessed has Integrated
 33

Windows authentication enabled. Because front-end servers do not support Integrated

Windows authentication, when users access HTTP applications, the front-end server always
prompts them for authentication and they must re-enter their credentials, even if they already
used Windows to log on. Users only have to enter credentials once per browser session
however, because their credentials are cached in the browser process.

Important:
When using a kiosk, be aware that caching credentials can pose a security risk if you
cannot close the browser and end the browser process between sessions. This risk
occurs because a user's credentials remain in the cache when the next user
accesses the kiosk. To enable the use of Outlook Web Access on a kiosk, ensure that
you can close the browser between sessions and end browser processes. Otherwise,
consider using a third-party product that incorporates two-factor authentication, in
which the user must present a physical token with a password to use Outlook Web
Access on the kiosk.

Forms-Based Authentication
Note:
Forms-based authentication is supported only by Exchange Server 2003. However,
you can use an Exchange2003 Server front-end with an Exchange2000 Server back-
end and benefit from forms-based authentication.

Forms-based authentication uses a cookie to identify the user when the user has done the
initial logon. Tracking this use of this cookie allows Exchange to time out inactive sessions.
However, the initial user's name and password is still transmitted in clear text, similar to basic
authentication. This is why SSL encryption must be used with forms-based authentication.
For information about how to configure forms-based authentication, see the section titled
"Configuring Forms-Based Authentication for Exchange Server 2003" in Configuring the
Front-End Server to Assume a Default Domain.

Front-End to Back-End Authentication

The front-end server must send user credentials to the back-end server along with the Web
requests so the back-end server can allow access to the data.

Integrated Authentication
Exchange 2003 front-end servers will use Kerberos authentication to protect user credentials
between the front-end and back-end servers. If Kerberos authentication fails, a warning event
will be logged and the front-end will try NTLM instead. If NTLM fails, an error will be logged
and basic authentication will be used.
 34

To allow the front-end to use integrated authentication, the back-end virtual servers should be
configured to allow integrated authentication (which they are by default).

Note:
Both Exchange 2003 and Exchange 2000 back-end servers will support integrated
authentication from an Exchange 2003 front-end server.

Basic Authentication
The front-end proxies the basic authentication credentials to the back-end servers. To secure
this information, it is highly recommended that IPSec be used between the front-end and
back-end servers.

Note:
Basic authentication between the front-end and back-end servers is supported by
both Exchange 2000 and Exchange 2003 front-end servers.

User Logon Information

When authenticating against a front-end server, by default, the user must enter his or her
user name in the following format: domain\username. You can configure the front-end server
to assume a default domain so that users do not need to remember their domain.

An additional option for authentication is to configure a user principal name (UPN) for users.
Normally a user's UPN is set to be the same as their e-mail address. This enables users to
enter their UPN/e-mail address as their user name. For more information, see Configuring
Exchange Front-End Servers.

Remote Procedure Calls (RPCs) in the

Exchange Front-End and Back-End
Topology
DSAccess no longer uses RPCs to perform Active Directory service discovery, however, it
does use RPCs for other tasks. To disable these, see Configuring DSAccess for Perimeter
Networks. However, IIS still uses RPCs to authenticate requests on the front-end server.
Therefore, if you enable authentication on the front-end server (which is strongly
recommended), it must be able to use RPCs. The recommended scenario is for the front-end
to be behind the internal firewall, in which case this should not be a problem. However, if you
must place your front-end server in a perimeter network, you must open certain RPC ports.
 35

For more information about opening RPC ports on the intranet firewall, see Configuring an
Intranet Firewall.

Features Lost by Placing an Exchange Front-

End Server in the Perimeter Network without
RPC Access
Important:
This section applies if you place an Exchange front-end server in the perimeter
network and do not allow RPC traffic across the internal firewall.

Corporations that have perimeter networks often restrict the type of traffic that passes from
the perimeter network into the corporate intranet.

Without RPC access to Active Directory servers, the front-end server cannot authenticate
clients. Therefore, features that require authentication on the front-end server (such as
implicit logon and public folder tree load balancing) will not work. Public folder access is
possible, but the front-end server cannot load-balance the requests because the front-end
server cannot determine the identity of the user. Without the user's authentication token, the
front-end server cannot perform the load balancing hashing algorithm. As a result, all
anonymous requests for a public folder are routed to the same back-end server.

Note:
It is recommended that you use an advanced firewall server (such as ISA Server)
rather than the front-end server in the perimeter network. For more information, see
Advanced Firewall in a Perimeter Network.

Note:
IMAP and POP clients require SMTP for sending e-mail messages. If you do not
allow RPC traffic across the internal firewall, you cannot run SMTP on the front-end
server to support IMAP and POP clients because when RPC traffic is blocked,
MSExchangeIS does not run on the front-end server. However, you can set up a
separate server to perform SMTP functions for IMAP and POP clients.

If RPC ports are not allowed between the perimeter network and the corporate intranet, you
must use pass-through authentication. With pass-through authentication, the front-end server
passes requests to the back-end anonymously, and then the back-end server performs the
authentication.
 36

Considerations When Deploying a Front-

End and Back-End Topology
When deploying a front-end and back-end topology, you must account for several factors
including, expected load, hardware needs, administrative overhead, load balancing, and
security. The following sections cover these factors in more detail.

Do Not Cluster Front End Servers

Clustering the Exchange front-end servers does not offer any performance benefit. Front-end
servers are stateless so performance is much better having two separate servers sharing
connections (or Network Load Balanced) rather than clustering them.

Recommended Server Configurations and

Ratios
Server configuration depends on many factors, including the number of users for each back-
end server, the protocols used, and the expected load on the system. The configuration of
particular models of servers should be done in consultation with a hardware vendor or
consultant.

Generally, one front-end server is reasonable for every four back-end servers. However, this
number is provided only as a suggested ratio and starting point, not as a rule. Front-end
servers do not need large or particularly fast disk storage, but should have fast CPUs and a
large amount of memory. There is no need to back up the disks on the front-end server
unless you choose to enable SMTP, because SMTP commits queued mail to the local disk.
For POP, IMAP, and HTTP, no user data is stored on the drive.

For more information about hardware requirements for front-end and back-end servers, see
the following technical papers:

• Exchange 2000 Front-End Server and SMTP Gateway Hardware Scalability Guide

• Exchange 2000 Server Back-End Mailbox Scalability

Load Balancing
In a corporate or hosting environment, you may want to load-balance the front-end servers.
Windows provides load balancing through Network Load Balancing (NLB). Alternatively, other
load-balancing mechanisms can be used, including hardware load-balancing solutions.

Windows NLB works by clustering two or more servers that represent the NLB cluster with a
single IP address. Each computer receives traffic to its own unique IP address and the shared
 37

IP address. Each member of the NLB cluster performs a hashing algorithm to map incoming
clients to one of the members of the NLB cluster based on the client IP address, port, and
other information. When a packet arrives, all servers or hosts perform the same hashing
algorithm, and the output is one of the hosts. That host then responds to the packet. The
mapping does not change unless the number of hosts in the NLB cluster changes. The
configuration of every server in the NLB cluster must be same, otherwise clients may
experience different behavior depending on which server they are routed to.

Note:
NLB has no health monitoring; if the World Wide Web Publishing Service on a front-
end server is not running, for example, NLB continues to send requests to that
server. You can run Microsoft Application Center 2000 on a front-end server to set up
NLB and monitor the health of load-balanced servers. (However, you cannot manage
Exchange resources or replicate Exchange configuration information through
Application Center.) For more information about Application Center, see the Microsoft
Application Center Web site.

Although it is not required, you should ensure that each user is always sent to the same front-
end server for the duration of a session. This uses the Secure Sockets Layer (SSL)
handshake caching and connection state information already maintained on the front-end
server. Additionally, this is required for forms-based authentication, as only the front-end
server that issues the cookie can decrypt it. In NLB, this is referred to as "client affinity." Many
hardware solutions also have this ability

Note:
Advanced firewall servers may affect your ability to NLB-cluster your front-end
servers, particularly if they mask the incoming client IP address. For more
information, see the product documentation or contact your manufacturer for more
details.

Reducing Virtual Server Creation

In some circumstances, it could be important to reduce the number of virtual servers created
on the back-end servers. You should not reduce the number of virtual servers unless you fully
understand how HTTP virtual servers work. You can reduce virtual server creation by either of
two methods.

Analyze the users and data on each back-end server to determine if users will ever be
directed to that particular server. If a back-end server contains mailboxes for only
adatum.com, there is no need for that back-end server to have a virtual server for
contoso.com. If users from contoso.com are later added to that back-end server, however, an
administrator may need to create a virtual server for contoso.com.

Similarly, you only have to create virtual directories for resources your users will require
access to. On a server that has no public store, the public virtual directory is not required.
 38

Using Firewalls in a Front-End and Back-

End Topology
If your network is visible to the Internet, it is highly recommended that you use either a
software or hardware firewall solution. Firewalls control traffic to the network by using such
methods as port filtering, IP filtering, and, in advanced firewall solutions, application filtering.

There are several options for incorporating a firewall into a front-end and back-end topology;
Scenarios for Deploying a Front-End and Back-End Topology describes these options.
Generally, it is recommended that you use an advanced firewall server in your topology (for
more information about using an advanced firewall, see Advanced Firewall in a Perimeter
Network).

Port Filtering
At a minimum, any firewall you use to help protect servers from the Internet must use port
filtering. Port filtering restricts the type of network traffic that comes through the firewall by
allowing access only to information sent to specific ports. For example, you may configure the
firewall facing the Internet to accept only HTTPS traffic by opening TCP/IP port 443.

The following two sections describe two important concepts related to TCP/IP connections:
source port versus destination port, and direction of the TCP/IP connection.

Source Port versus Destination Port

When computer A opens a TCP/IP connection to computer B, two ports are used: the source
port (on computer A), and the destination port (on computer B). The network stack on the
computer that initiates the connection generally selects source ports at random. Destination
ports are the ports on which the specified service is listening (for example, port 443 for
HTTPS). In this guide, any reference to a port used by a specific service refers to the
destination port.

Direction of the TCP Connection

When you open firewall ports, most firewalls require you to specify the direction of the
connection. For example, to allow a front-end server to contact back-end servers, you must
open port 80 for HTTP traffic. However, back-end servers never initiate new TCP/IP
connections to the front-end server; they only respond to requests that were initiated by the
front-end. Therefore, on your firewall, you need to only enable allow HTTP port 80
connections from the front-end to the back-end. In this guide, such connections are referred
to as "inbound" (in other words, the connections are inbound to the corporate network).
 39

IP Filtering
Many firewall solutions also support IP filtering. IP filtering improves the reliability of the
firewall by allowing you to restrict traffic through the firewall to specific servers. For example,
in a perimeter network, you may want to configure DSAccess to use specific domain
controllers and global catalog servers, and then use IP filtering to ensure that the front-end
servers connect to only those domain controllers and global catalog servers.

Application Filtering
Advanced firewalls such as ISA Server can provide advanced inspection at the application
protocol level. This inspection allows the firewall to perform functions such as filtering RPC
interfaces and validating HTTP request syntax. Application filtering is the main reason why
using an advanced firewall in your topology provides the most security.

Helping to Secure Communication: Client

to Front-End Server
To help secure data transmitted between the client and the front-end server, it is highly
recommended that the front-end server be SSL-enabled. Additionally, to ensure that user
data is always secure, access to the front-end server without SSL should be disabled (this is
an option in the SSL configuration). When using basic authentication, it is critical to protect
the network traffic by using SSL to protect user passwords from network packet sniffing.

Note:
If you do not use SSL between clients and the front-end server, data transmission to
your front-end server will not be secure. It is highly recommended that you configure
the front-end server to require SSL.

It is recommended that you obtain an SSL certificate by purchasing a certificate from a

number of third-party certification authorities. Purchasing a certificate from a certification
authority is the preferred method because the majority of browsers already trust many of
these certification authorities.

Alternately, you can use Microsoft Certificate Server to install your own certification
authorities. Although installing your own certificate authority may be less expensive, browsers
will not trust your certificate, and users will receive a warning message indicating that the
certificate is not trusted.

For more information, see Microsoft Knowledge Base article 320291, "XCCC: Turning on SSL
for Exchange 2000 Server Outlook Web Access."
 40

Configuring SSL in a Front-End and Back-End

Topology
You do not need to configure SSL on back-end servers when using a front-end server,
because the front-end server does not support using SSL to communicate with back-end
servers. You can configure SSL on the back-end servers for use by clients that are directly
accessing them.

When HTTP is used to access data, back-end servers need to generate absolute URLs, such
as a list of URLs for the messages in a user's inbox. If SSL is used between the client and the
front-end server, the back-end server needs to know this, so it can formulate URLs using
HTTPS instead of HTTP. If SSL decryption is done on the front-end server, the front-end
server knows SSL was used, and it notifies the back-end server of this by passing an HTTP
header that says, "Front-End-Https: on" in all requests to the back-end server.

If there is a separate server between the client and the front-end server that is offloading the
SSL decryption, the front-end server is unaware that the original request was made using
SSL. In this case, that server must be able to pass the "Front-End-Https: on" header to the
front-end server, which then passes it to the back-end server. ISA Server supports this. For
information about how to enable this, see the Microsoft Knowledge Base article 307347,
"Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header."

As an alternative, you can configure SSL between the SSL decryption server and the front-
end server. However, if you added that separate server to offload the additional traffic caused
by SSL encryption and decryption, this method defeats that purpose. This method would still
allow that separate server to filter the traffic.

SSL Accelerators
There is a decrease in performance involved in setting up and tearing down SSL connections,
so you may want to investigate adding an SSL accelerator to your front-end and back-end
topology.

SSL accelerators generally come in two forms:

• An SSL accelerator network card you can place on each front-end server.

• A separate device or computer you place between the clients and the front-end
servers. An example of this is the Microsoft Internet Security and Acceleration
Server 2000 Feature Pack 1 Service Pack 1 (ISA). An accelerator such as this supports
adding the "Front-End-Https: On" header for Outlook Web Access.

Note:
For information about configuring the ISA server for Outlook Web Access, see
Microsoft Knowledge Base article 307347, "Secure OWA Publishing Behind ISA
Server May Require Custom HTTP Header."
 41

Accelerator cards are generally used directly on the front-end server, and they offload the
encryption and decryption overhead. This increases the throughput of each connection and
decreases the amount of work the software on the server must do.

External accelerator devices sit between the clients and the front-end servers. Traffic coming
from the client is decrypted on the accelerator device and sent to the front-end server
unencrypted. Likewise, traffic from the front-end server is sent to the accelerator device
unencrypted, and then it is encrypted for transmission to the client.

The most important factor to consider when choosing what type of SSL accelerator to use is
the number of front-end servers in your topology. If you have a small number of front-end
servers, adding SSL accelerator cards to each of them is a simple, cost-effective way to
offload SSL duties. Because the SSL decryption is done on the front-end server, there is no
need for extra configuration of the "Front-End-Https: on" header for Outlook Web Access.

For a large number of front-end servers, the cost of additional accelerator cards and the
administrative cost of storing and configuring SSL certificates on each server eventually is not
to be cost effective. In this case, a separate SSL accelerator device may be a more cost
effective option for your topology because it needs to be configured only once, regardless of
the number of front-end servers. These devices generally cost more than an accelerator card,
so weigh the options in your own topology to determine which to use. Keep in mind that for
Outlook Web Access, an external SSL device must have be able to notify the front-end server
that SSL was used with the "Front-End-Https: on" header.

SSL Offloading
If there is a separate server between the client and the front-end server that is offloading the
SSL decryption, the front-end server is unaware that the original request was created using
SSL. In this case, that server must be able to pass the "Front-End-Https: on" header to the
front-end server, which then passes it to the back-end server.

If your SSL offloading server does not support adding a custom header, you can install an
Internet Server Application Programming Interface (ISAPI) on the front-end server to add this
header. For information, see the Microsoft Knowledge Base article 327800, "How to configure
SSL Offloading for Outlook Web Access in Exchange 2000 Server and in Exchange Server
2003." Alternatively, you can configure SSL between the SSL decryption server and the front-
end server. However, if you added that separate server to offload the additional traffic caused
by SSL encryption and decryption, this method defeats that purpose. This method would still
allow that separate server to filter the traffic.

A separate SSL accelerator device may be a more cost-effective option for your topology
because it needs to be configured only once, regardless of the number of front-end servers.
These devices generally cost more than an accelerator card, so weigh the options in your
own topology to determine which to use. Keep in mind that for Outlook Web Access, an
external SSL device must be able to notify the front-end server that SSL was used with the
"Front-End-Https: on" header.
 42

Forms-Based Authentication
If you are using forms-based authentication with SSL offloading, you will need to configure
your Exchange front-end servers to be able to handle this scenario. For detailed instructions,
see How to Enable Forms-Based Authentication When Using SSL Offloading.

How to Enable Forms-Based

Authentication When Using SSL
Offloading
If you are using forms-based authentication with Secure Sockets Layer (SSL) offloading, you
must configure your Exchange Server front-end servers to handle this scenario.

Before You Begin

This topic contains information about editing the registry.

Caution:
Incorrectly editing the registry can cause serious problems that may require you to
reinstall your operating system. Problems resulting from editing the registry
incorrectly may not be able to be resolved. Before editing the registry, back up any
valuable data.

Procedure
To enable forms-based authentication when using SSL offloading
1. Start Registry Editor.

2. Locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\
OWA

3. On the Edit menu, point to New, and then click DWORD Value.

4. In the details pane, name the new value SSLOffloaded.

5. Click the SSLOffloaded DWORD value, and then click Modify.

6. In Edit DWORD Value, under Base, click Decimal.

7. In the Value Data box, enter the value 1.

 43

8. Click OK.

Note:
You must restart the W3SVC service for these changes to take effect.

For More Information

• For more information, see:

• Considerations When Deploying a Front-End and Back-End Topology

• "How to Enable Forms-Based Authentication" in the Exchange Server 2003

Client Access Guide.

Securing Communication: Front-End to

Other Servers
HTTP, POP, and IMAP communication between the front-end server and any server with
which the front-end server communicates (such as back-end servers, domain controllers, and
global catalog servers) is not encrypted. When the front-end and back-end servers are in a
trusted physical or switched network, this is not a concern. However, if front-end and back-
end servers are kept in separate subnets, network traffic may pass over unsecured areas of
the network. The security risk increases when there is greater physical distance between the
front-end and back-end servers. In this case, it is recommended that this traffic be encrypted
to protect passwords and data.

IP Security (IPSec)
Windows supports IPSec, which is an Internet standard that allows a server to encrypt any IP
traffic, except traffic that uses broadcast or multicast IP addresses. Generally, you use IPSec
to encrypt HTTP traffic; however, you can also use IPSec to encrypt all traffic.

With IPSec you can:

• Configure two servers that are running Windows to require trusted network access.

• Exchange data that is protected from modification (using a cryptographic checksum

on every packet).

• Encrypt any traffic between the two servers at the IP layer.

In a front-end and back-end topology, you can use IPSec to encrypt traffic between the front-
end and back-end servers that would otherwise not be encrypted.
 44

IPSec Protocols
The method in which data is secured using IPSec depends on which protocol is used:
Authentication Header (AH) or Encapsulating Security Payload (ESP). With AH, the packets
are not encrypted; AH adds a checksum to the IP packet. AH guarantees that the packet
came from the expected host, was not impersonated, and was not modified in transit. AH
uses IP protocol 51. ESP, which uses IP protocol 50, encrypts the entire contents of the IP
packet. Both forms of IPSec provide a reliable and trusted communication channel that an
attacker cannot easily insert data into or interrupt.

IPSec encryption affects the performance on both the front-end and back-end servers; the
precise extent to which it affects performance, however, depends on the type of encryption
used.

IPSec Policy
You should configure IPSec on the back-end servers so that they respond appropriately when
they receive a request for IPSec communication. However, the back-end servers should not
require that all communication from all clients be encrypted using IPSec.

Windows has three IPSec policies installed by default. Select the "Client (respond only)"
policy for the back-end server. With this policy enabled on the back-end server, the front-end
server can use IPSec to communicate safely with the back-end server, while other clients
(including earlier versions of MAPI clients like Microsoft® Office Outlook® 2002) and servers
can communicate with the back-end server without needing to use IPSec.

IPSec with Firewalls and Filtering Routers

When a firewall or filtering router is used between the front-end and back-end servers, the
filters must allow IPSec to pass through it.

Note:
IPSec does not work if there is a Network Address Translation (NAT) server between
the perimeter network and the corporate network.

When using IPSec, configure the ports as follows:

• HTTP (TCP port 80) HTTP (TCP port 80) is no longer required and should be
blocked.

• Other protocol ports If you are using IPSec to encrypt all traffic, you do not need
other protocol ports (except possibly Kerberos).

• 500/UDP Open the IPSec negotiation port at 500/UDP, which is required. 500/UDP
is the well-known Internet assigned port for the Internet Key Exchange (IKE) Standard,
which is defined in RFC 2409. This standard uses UDP and not TCP/IP to avoid
 45

the security weaknesses of relying on TCP/IP connections. IKE provides strong security
for the negotiation data packets. It establishes and maintains the IPSec connections,
named security associations.

• IP protocol 50 or 51 Allow either IP protocol 50 (AH) or IP protocol 51 (ESP),

depending on the protocol you are using.

• UDP port 88 and TCP port 88 Kerberos traffic uses UDP/TCP protocol source and
destination port 88. Kerberos is itself a security protocol, and was therefore not included
by IPSec filters in Microsoft® Windows 2000 Server, even if the filter included the IPSec
ports. Therefore, if you use IPSec on Windows 2000 Server you still need to open UDP
port 88 and TCP port 88. Alternatively, you can force Kerberos to be included in an IPSec
filter by setting the "NoDefaultExempt" registry key. In Windows Server 2003, Kerberos
will be included by IPSec filters by default. If Kerberos is included in the IPSec encryption
you cannot use Kerberos to authenticate the IPSec session itself. You need to use either
a certificate or a preshared key

• For more information about configuring IPSec with firewalls, see Microsoft
Knowledge Base article 233256, "How to Enable IPSec Traffic Through a Firewall."

• For more information about IPSec and Kerberos, see Microsoft Knowledge Base
article 810207, "IPSec Default Exemptions Are Removed in Windows Server 2003."

• In a perimeter network, you may want the increased security of IPSec without losing
the ability to filter traffic for security reasons. In this case, you can set up an IPSec tunnel
from the front-end server to the internal firewall, and then a separate tunnel from the
internal firewall to the back-end server. This approach secures the information about the
wire while allowing you to use filtering or intrusion detection software or techniques on
the traffic before it reaches your internal network.

Note:
IPSec encryption occurs after the application (in this case, Exchange) passes the
request to Windows to send to the server. So, as far as Exchange is concerned, the
request is made over HTTP using TCP/IP port 80. However, before the traffic leaves
the server, it is intercepted, possibly encrypted if ESP is configured, and sent over a
separate channel (IP protocols 50 or 51). Therefore, the encryption is transparent to
the Exchange applications that are running on each server, and the fact that the data
never used port 80 is not an issue to these applications.

Service Packs: Upgrading Front-End and

Back-End Servers
When new service packs are released, upgrading your front-end servers is a straightforward
process. It is simpler than upgrading a back-end server, because there is no user data stored
 46

on the front-end server. As long as there are multiple front-end servers, taking one server
offline does not mean an interruption in service for the user. If you have multiple front-end
servers that are load balanced, you can remove the front-end server you want to upgrade
from the load-balancing cluster, upgrade it, and add it back to the load-balancing cluster with
no interruption in service to users.

Upgrading Considerations for Outlook Web

Access
If Outlook Web Access is deployed in your organization, you should upgrade every front-end
server in the organization before you upgrade any back-end servers. This is because of the
way Outlook Web Access is built. At a high level, Outlook Web Access data is made up of two
parts: templates and controls. Templates are things such as forms (e-mail messages,
calendar items, and other forms). Controls are files such as DHTML behaviors, JScript® files,
style sheets, and images that are stored in the /exchweb virtual directory in IIS.

When a user accesses Outlook Web Access through the front-end server, the templates
actually come from the back-end server, and the controls come from the front-end server. The
templates come from the back-end for performance reasons. The controls come from the
front-end server because there is no mechanism to proxy a request for data that is not in the
Exchange store from a front-end server to a back-end server. This is not a problem as long as
the front-end and back-end servers run the same version and service pack of Exchange.

A problem arises when the servers run different versions of service packs. If a template on a
back-end server references a control on a front-end server, and the front-end server is
running an earlier service pack, the control the back-end server is referencing might not exist.
As a result, Outlook Web Access does not work for users whose mailboxes are on the
upgraded back-end server.

The reverse situation does not have the same problem. If you upgrade a front-end server
first, users see templates from the back-end server. These templates reference the earlier
versions of the controls, which still exist on the front-end server, because the files are
versioned and not removed in an upgrade. To address this issue, it is recommended that you
upgrade all front-end servers before upgrading any back-end servers.

Additionally, ensure that the required services are running before you upgrade. For Exchange
setup to run, you must install and enable (but not necessarily start) Network News Transfer
Protocol (NNTP), SMTP, W3SVC, and IIS Admin. If the MSExchangeMTA, IMAP4, POP3,
and MSExchangeIS services are disabled, Setup still runs; however, Setup will enable these
services after it starts. After setup is complete, you can disable unnecessary services.
 47

Scenarios for Deploying a Front-End and

Back-End Topology
This topic discusses common scenarios where Exchange front-end and back-end topology is
deployed. The scenarios can be broadly divided into intranet and extranet scenarios, with the
intranet scenarios focused on performance and scalability and the extranet scenarios focused
on security.

In each scenario, the following topics are discussed:

• Scenario What is the scenario, and when does it apply?

• Setup instructions How to set up the scenario, in general terms. (Specific
configuration instructions are covered later in this guide.)

• Discussion What is special about this scenario? How does it work? What additional
information is required to make decisions about this scenario?

• Issues Caveats or limitations of this scenario.

Each of the following four scenarios requires a firewall. You can use software and hardware
solutions as a firewall. Port filtering is the minimum requirement for a firewall that protects the
server from the Internet.

Advanced Firewall in a Perimeter Network

The following figure illustrates an advanced firewall scenario, in which an advanced firewall is
put inside the perimeter network, between the Internet firewall and the internal firewall. Front-
end and back-end servers are put in the same network behind the internal firewall. This is the
recommended topology for the following reasons:

• It provides security by isolating intruders from the rest of the network.

• It provides application protocol filtering.

• It performs additional verification on requests before it proxies them to the internal

network.

Note:
As an alternative to placing the advanced firewall server within a perimeter network
behind a separate Internet firewall, the advanced firewall server itself can function as
the Internet firewall.
 48

Exchange front-end server behind an advanced firewall

Scenario
A corporation places an advanced firewall such as ISA Server between two separated
firewalls. The corporation's decision to set up this advanced firewall topology is based on the
following benefits:
• Advanced firewalls provide additional security to the network by protecting against
unauthorized access, inspecting traffic, and alerting the network administrator to attacks.

• Advanced firewalls enable you to use such methods as port filtering and IP filtering to
control traffic.

• Advanced firewalls allow you to restrict access by users and groups, application type,
time of day, content type, and destination sets.

Setup Instructions
For detailed setup instructions, see How to Set Up a Front-End and Back-End Topology with
an Advanced Firewall in a Perimeter Network.For more information about ISA Server,
including product information and technical resources, see the ISA Server Web site.
 49

Discussion
ISA Server contains two types of rules:

• Server publishing rules These rules, which can apply to any protocol, inspect
incoming requests at the receiving port. If an incoming request is allowed, the protocol
rule forwards it from the receiving port to an internal IP address.

• Web publishing rules These rules apply to HTTP or HTTPS (80/443) requests only.
You can set up Web publishing rules to filter incoming requests based on the service
type, port, source computer name, and destination computer name. You can also allow
only specific servers or deny high-risk servers.

If you are supporting HTTP clients, create a Web publishing rule to handle HTTP or HTTPS
traffic. If you are supporting POP or IMAP clients, create server publishing rules to handle
these protocols.

Unlike the perimeter network scenario, the ISA server in the perimeter network does not have
to be a member server unless you configure ISA Server to authenticate requests. Generally, if
you have configured authentication on the front-end server, you do not have to configure ISA
Server to authenticate users. However, if you want to restrict incoming requests to those that
originate from specific users, you must create a Web publishing rule that specifies the users
and enables authentication on the ISA Server. In this case, the ISA server must be a member
of the Windows domain. Additionally, ISA Server does not delegate the user's credentials to
back-end servers. Therefore, although ISA Server can authenticate users and restrict access
to the network, users cannot be pre-authenticated for Outlook Web Access.

Issues
In the advanced firewall scenario, there is no need for RPC access to the internal network.
This is often regarded as an advantage because fewer ports must be open on the internal
firewall; however, regardless of the number of open ports, the potential for a security breach
exists. To avoid this security risk, ensure that the appropriate filters are set up for each open
port.

In the advanced firewall scenario, you can configure SSL in one of two ways:

• Between the client and ISA server only.

• Between the client and ISA server, and between the ISA server and the front-end
server.

The second option is typically used if customer policy dictates that e-mail traffic within the
perimeter network is encrypted. After ISA Server receives the SSL request from the client, it
ends the session and re-opens a new SSL session with a new certificate to contact the front-
end server. The name on each certificate is important. The certificate name on the incoming
request must match the name the user typed in the URL. Moreover, the certificate name on
 50

the request to the front-end server must match the name or IP address of the front-end
server.

To configure SSL in ISA Server, use the Bridging tab in the Web publishing server rule to
direct SSL traffic. If you are hosting multiple domains and want to use SSL, you must set up a
listener and a different IP address for each domain. This is because the certificates must be
named so that they match the destination names or IP addresses.

How to Set Up a Front-End and Back-End

Topology with an Advanced Firewall in a
Perimeter Network
You can create a front-end and back-end topology with an advanced firewall. The following
figure illustrates the front-end and back-end scenario with an advanced firewall. In this
scenario, you place the advanced firewall server inside the perimeter network and between
the Internet firewall and the internal firewall. You place front-end and back-end servers in the
same network behind the internal firewall.

Exchange front-end server behind an advanced firewall

 51

Before You Begin

Before you perform the procedure in this topic, it is important that you first read the following:

• Scenarios for Deploying a Front-End and Back-End Topology

• Using ISA Server 2000 with Exchange Server 2003

Procedure
To set up a front-end and back-end topology with an advanced firewall in a
perimeter network
1. If there is a firewall or port filter in front of the advanced firewall, configure it to
allow the client protocols and ports inbound: 443 (SSL HTTP), 993 (SSL POP3), 995
(SSL IMAP4), and any other ports required inbound (for example, SMTP traffic might
also go through this firewall). This firewall should limit access to only the designated
advanced firewall server.

2. (Optional) If you are using an intranet firewall between the advanced firewall and
the intranet, configure the intranet firewall to have certain ports open to support the
required network traffic from the advanced firewall server (for example, a Microsoft®
Internet Security and Acceleration (ISA) Server) to the intranet. This would be any
client protocols proxied by the advanced firewall: ports 443 or 80 (depending on
whether the advanced firewall was offloading SSL encryption), 993, and 995.
Additionally, the intranet firewall must allow access for any other protocols that are
required by the advanced firewall server, depending on its other tasks and
configuration. This could include authentication, Domain Name System (DNS), and
Active Directory access. The exact list depends on the balance of security and
features that each corporation implements.

3. Configure the advanced firewall. The following are general guidelines to follow
when deploying an ISA Server in a front-end and back-end topology. (For detailed
information about how to configure ISA Server, see the ISA Server product
documentation.)

a. Configure a listener for SSL.

b. Create a destination set that contains the external IP address of the ISA
Server. This destination set will be used in the Web publishing rule.

c. Create a Web publishing rule that redirects requests to the internal front-end
server.

d. Create protocol rules to open ports in ISA Server for outgoing traffic.

4. Configure the ISA server for Microsoft Office Outlook® Web Access. (For
information about how to configure an ISA server for Outlook Web Access, see
 52

Microsoft Knowledge Base article 307347, "Secure OWA Publishing Behind ISA
Server May Require Custom HTTP Header.")

Front-End Server behind a Firewall

The following figure illustrates a front-end and back-end topology where the front-end server
is behind the firewall.

A simple Exchange firewall topology

Scenario
To achieve security and still provide access to Outlook Web Access, POP, or IMAP from the
Internet, a corporation wants to put the Exchange system behind the corporate firewall.

Setup Instructions
For detailed setup instructions, see How to Set Up a Front-End and Back-End Topology with
a Front-End Server Behind a Firewall.
 53

Discussion
Because the whole configuration is inside the firewall, Exchange does not require any special
configuration. After a request comes through the firewall to the front-end server, the front-end
server returns a response without any configuration changes.

IP address filtering is highly recommended to limit requests through the firewall to only those
going to the front-end server (or servers) that are running Exchange and block requests
through the firewall to other servers in the organization.

How to Set Up a Front-End and Back-End

Topology with a Front-End Server
Behind a Firewall
You can create a front-end and back-end topology with a front-end server behind firewall. The
following figure illustrates the front-end and back-end scenario with a front-end server behind
a firewall.

A simple Exchange firewall topology

Before You Begin

Before you perform the procedure in this topic, it is important that you first read the following:

• Scenarios for Deploying a Front-End and Back-End Topology

 54

• Using ISA Server 2000 with Exchange Server 2003

Procedure
To set up a front-end and back-end topology with a front-end server behind a
firewall
1. Set up a standard Exchange front-end and back-end environment in the
corporation. For more information about standard Exchange front-end and back-end
environments, see Introduction to Front-End and Back-End Topologies for Exchange
Server 2003 and Exchange 2000 Server. For more information about how to
designate a front-end server, see How to Designate a Front-End Server.

2. Configure a firewall between the front-end server and the Internet. For more
information about how to configure an Internet firewall for use with a front-end server
running Exchange, see Configuring Firewalls.

Web Farm with a Firewall

The following figure illustrates a Web farm scenario.

Front-end and back-end topology in a Web farm

 55

Scenario
A corporation is deploying Outlook Web Access to 200,000 users. The goal is to have a single
namespace (for example, https://mail) in which users can reach their mailboxes. Additionally,
for performance reasons, the corporation wants to avoid having a bottleneck at the front-end
server or a single point-of-failure, so they want to spread the load over multiple front-end
servers by using Network Load Balancing (NLB). This scenario is referred to as a "Web
Farm."

Note:
Although this is the only scenario that depicts NLB, you can use NLB to distribute
load among front-end servers in any of the scenarios described in this guide.

Setup Instructions
For detailed setup instructions, see How to Set Up a Front-End and Back-End Topology with
a Web Farm Behind a Firewall.

Discussion
For information about how to set up Network Load Balancing, see the Windows online
documentation. Configuring Exchange on the front-end servers does not require any special
steps.

Issues
As previously mentioned, the load-balancing solution you use should ensure that each user is
always sent to the same front-end server for the duration of a session.

How to Set Up a Front-End and Back-End

Topology with a Web Farm Behind a
Firewall
You can create a front-end and back-end topology with a web farm behind a firewall. The
following figure illustrates the front-end and back-end scenario with a web farm behind a
firewall. In this scenario, you spread the front-end server load over multiple front-end servers.
You place multiple front-end servers behind a firewall.
 56

Front-end and back-end topology in a Web farm

Before You Begin

Before you perform the procedure in this topic, it is important that you first read the following:

• Scenarios for Deploying a Front-End and Back-End Topology

• Using ISA Server 2000 with Exchange Server 2003

Procedure
To set up a front-end and back-end topology with a web farm behind a firewall
1. Set up a group of servers as back-end servers in the same forest.

2. Distribute users over the servers.

3. Set up another group of servers as front-end servers and configure Network

Load Balancing on all these servers.

Front-End Server in a Perimeter Network

The following figure illustrates an Exchange front-end server in a perimeter network.
 57

Exchange front-end server in a perimeter network

Scenario
In this figure, the corporation places the front-end server between two separated firewalls.
The first firewall separates the front-end server from the Internet and allows requests only to
that front-end server. The second firewall separates the front-end server from the internal
network. The systems between the two firewalls lie in what is known as a perimeter network
(also known as a DMZ, demilitarized zone, and screened subnet). A perimeter network
configuration provides more security because if the front-end server is compromised, there is
still another barrier between the intruder and the rest of the network.

Note:
Placing front-end servers inside the perimeter network is one approach to deploying
front-end and back-end topology within a perimeter network. However, the
recommended approach is depicted in the first scenario, Advanced Firewall in a
Perimeter Network. This approach involves placing the front-end and back-end
servers inside the intranet and placing an advanced firewall (such as ISA Server) in
the perimeter network. The advanced firewall can provide application protocol filtering
and perform additional authentication on requests before it proxies them to the
internal network.

Setup Instructions
For detailed setup instructions, see How to Set Up a Front-End and Back-End Topology with
a Front-End Server in a Perimeter Network.
 58

Discussion
Typically, corporations that have deployed and standardized the use of a perimeter network
have restrictions on the type of network traffic allowed through the intranet firewall by limiting
the network ports that are enabled on the intranet firewall. However, the front-end server
requires certain ports to operate fully.

Issues
Some corporations that have deployed perimeter network topologies for other services have
policies that restrict computers located within the perimeter network from initiating
connections with servers inside the corporate intranet. A front-end server that is running
Exchange is not supported in this configuration because it must initiate connections.

Additionally, the front-end server must be a member of the same Windows forest as the back-
end servers. Some corporations do not allow member servers in the perimeter network; for
these corporations, deploying a front-end server in the perimeter network is not an option.

It is recommended that you completely configure the front-end server before the intranet
firewall is put in place or locked down. Configuring settings on the front-end server in
Exchange System Manager requires the System Attendant (MSExchangeSA) service to be
running so that the configuration information can replicate to the metabase. The
MSExchangeSA service requires RPC access to the back-end servers, and RPCs often are
not allowed across an intranet firewall in a perimeter network.

The DSAccess component in Exchange 2000 Server SP2 was redesigned to provide better
support for perimeter networks in which RPC traffic is not allowed across the internal firewall.
However, there are two additional registry keys that you should set on the front-end server to
disable NetLogon and the Directory Access ping:

• NetLogon DSAccess connects to Active Directory servers to check available disk

space, time synchronization, and replication participation by using NetLogon service with
RPC. If you do not allow RPC traffic across the internal firewall, you should stop the
NetLogon check by creating the DisableNetlogonCheck key on the front-end server.

• Directory Access ping By default, Directory Access uses Internet Control Message
Protocol (ICMP) to ping each server to determine whether the server is available.
However, in a perimeter network in which there is no ICMP connectivity between the
server that is running Exchange and the domain controllers, Directory Access determines
that every domain controller is unavailable. Directory Access then discards old topologies
and performs new topology discoveries, which affects server performance. To avoid these
performance issues, turn off the Directory Access ping on the front-end server by creating
the LdapKeepAliveSecs registry key for the Windows implementation of LDAP (wLDAP).

For information about how to set these registry keys, see Configuring DSAccess for
Perimeter Networks.
 59

How to Set Up a Front-End and Back-End

Topology with a Front-End Server in a
Perimeter Network
You can create a front-end and back-end topology with a front-end server in a perimeter
network. The following figure illustrates the front-end and back-end scenario with a front-end
server in a perimeter network. In this scenario, you place the front-end server between the
Internet firewall and the internal firewall.

Exchange front-end server in a perimeter network

Before You Begin

Before you perform the procedure in this topic, it is important that you first read the following:

• Scenarios for Deploying a Front-End and Back-End Topology

• Using ISA Server 2000 with Exchange Server 2003

Procedure
To set up a front-end and back-end topology with a front-end server in a perimeter
network
1. Configure the outer (Internet) firewall for a firewall in this environment, limiting
 60

access to only the ports required and to only the designated front-end server.

2. Configure the inner (intranet) firewall to have certain ports open to support
authentication, DNS, and Active Directory access. The exact list depends on the
balance of security and features that each corporation chooses.

For More Information

For information about how to configure Internet and intranet firewalls, see Configuring
Firewalls.

Configuring Exchange Front-End Servers

A front-end server is an ordinary Exchange server until it is configured as a front-end server. A
front-end server must not host any users or public folders.

A front-end server must be a member of the same Exchange organization as the back-end
servers (therefore, a member of the same Windows® forest).

For detailed instructions about how to designate an Exchange server as a front-end server,
see How to Designate a Front-End Server.

How to Designate a Front-End Server

A front-end server is an Exchange server that accepts requests from clients and proxies
them to the appropriate back-end server for processing.

Before You Begin

To successfully complete the procedures in this topic, confirm the following:

• The server that you will designate as a front-end server is a member of the same
Microsoft® Windows® forest as the back-end servers.

• The server that you will designate as a front-end server is a member of the same
Exchange organization as the back-end servers.
 61

Procedure
To designate a front-end server
1. Install the server that will be running Exchange Server in the organization.

Note:
With Exchange 2000 Server, only Enterprise Edition servers can be
configured as front-end servers. In Exchange Server 2003, both Standard
Edition and Enterprise Edition can be configured as front-end servers.

2. Use Exchange System Manager to go to the server object, right-click the server
object, and then click Properties.

3. Select This is a front-end server, and then close the page.

4. To begin using the front-end server do one of the following:

• Restart the computer.

• Stop and restart the HTTP, POP3, and IMAP4 services.

5. The default Exchange virtual directories have now been configured for you.
However, it is recommended that you also configure SSL. For detailed instructions on
how to configure SSL for POP3, IMAP4, and SMTP, see "How to Configure SSL for
POP3, IMAP4, and SMTP" in the Exchange Server 2003 and Exchange 2000 Server
Front-End and Back-End Server Topology Guide. For detailed instructions about how
to configure SSL for HTTP, see How to Configure SSL for HTTP in the Exchange
Server 2003 and Exchange 2000 Server Front-End and Back-End Server Topology
Guide.

For More Information

• For more information, see:

• "Configuring Exchange Front-end Servers" in the Exchange Server 2003 and

Exchange 2000 Server Front-End and Back-End Server Topology Guide

• "How to Set Up a Front-End and Back-End Topology with a Front-End Server

Behind a Firewall" in the Exchange Server 2003 and Exchange 2000 Server Front-
End and Back-End Server Topology Guide

• Exchange Server 2003 Client Access Guide

 62

Creating HTTP Virtual Servers

You must use Exchange System Manager, not Internet Services Manager when you create
virtual servers. When you create virtual servers in Exchange System Manager, you do not
need to simplify the URL; after you create a virtual server that points to mailboxes and set the
host headers, users can type http://<virtual server name>/ without having to type /exchange.

For detailed instructions about how to create an HTTP virtual server, see How to Create a
Virtual Server.

You can leave the IP address field at All unassigned (the default) or restrict it to the
particular IP address assigned to the server. If you know SSL will be used to connect to this
front-end server, you may want to configure a specific IP address for the virtual server.

How to Create a Virtual Server

Use this procedure to create a virtual server.

Procedure
To create a virtual server
1. In Exchange System Manager, in the HTTP Protocols container for the front-end
server, right-click HTTP, and then select New Virtual Server.

Note:
For a name, it is recommended that you use something following the form of
"adatum.com (front-end)." Consistent naming of the new virtual servers
ensures that each virtual server's purpose and associated domain can be
easily determined. The name of the virtual server is used only for
identification purposes and does not affect its operation.

2. Click Mailboxes or Public folder, click Modify, and then do one of the following:

• If the virtual server points to mailboxes, select the domain.

Note:
The list of domains in Select SMTP Domain is pulled from the domains
of the SMTP addresses in the Exchange organization's recipient policies,
so if you have more than one recipient policy for the same domain, you
will see duplicates in this dialog box. It does not matter which one you
choose.
 63

• If the virtual server points to a public folder, select the appropriate public
folder to act as the root public folder for this virtual server.

3. Click Advanced, and then add host headers that define all the names a client
might use to contact this front-end server.

Note:
If a front-end server is used internally and externally, it is recommended that
you list both a hostname and a fully qualified domain name.

Configuring Authentication
It is highly recommended that you use dual authentication, in which both front-end and back-
end servers are configured to authenticate users. By default, front-end servers are configured
to perform dual authentication.

However, if you have a locked-down perimeter network in which RPCs are not allowed across
the intranet firewall, and it is impossible for the front-end server to authenticate users, you
can use pass-through authentication.

Note:
When you use pass-through authentication, anonymous HTTP requests go directly to
the back-end server where they are authenticated. You should use pass-through
authentication only if the front-end server cannot authenticate users. For more
information, see Scenarios for Deploying a Front-End and Back-End Topology.

For detailed instructions about how to configure authentication on a front-end server, see
How to Configure Authentication on a Front-End Server.

How to Configure Authentication on a

Front-End Server
You can configure your front-end server for dual authentication or for pass-through
authentication. In dual authentication, both front-end and back-end servers are configured to
authenticate users. If you have a locked-down perimeter network in which RPCs are not
allowed across the intranet firewall, and it is impossible for the front-end server to
authenticate users, you can use pass-through authentication.
 64

Before You Begin

To successfully complete the procedures in this topic, confirm the following:

• You use pass-through authentication only if the front-end server cannot authenticate
users

• You have read Scenarios for Deploying a Front-End and Back-End Topology.

Procedure
To configure authentication on a front-end server
1. Click Start, point to Programs, point to Microsoft Exchange, and then click
System Manager.

2. Go to the "Exchange" or "Public" virtual directory.

3. Right-click the "Exchange" or "Public" virtual directory and then click Properties.

4. Click the Access tab, and then click Authentication.

5. Do one of the following:

• To configure the front-end server to authenticate users (as in dual

authentication), select the Basic authentication check box.

• To configure pass-through authentication, select the Anonymous access

check box, and then clear the Basic authentication check box.

Configuring the Front-End Server to

Assume a Default Domain
You can configure the front-end server to assume a default domain so that users do not need
to remember their domain.

After replication is complete, users can log on with just their user name and password; no
domain is required.

For detailed instructions about configuring a front-end server to assume a default domain,
see How to Configure a Front-End Server to Assume a Default Domain.
 65

Configuring Forms-Based Authentication for

Exchange Server 2003
For Exchange Server 2003, you can enable the new forms-based authentication feature for
your Microsoft® Office Outlook® Web Access clients.

Important:
In an Exchange 2003 front-end server and back-end server architecture, you must
enable forms-based authentication on the front-end server.

Forms-based authentication allows an administrator to log users off after a certain period of
inactivity. Exchange Server 2003 uses the following information to determine user activity

• Interaction between the client and the server is considered to be 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 to be activity.

• If a user enters text in Outlook Web Access items, it is not considered to be activity.
For example, if a user types in appointments, meeting requests, posts, contacts, tasks, or
other items, this is not considered to be activity.

Note:
The Outlook Web Access premium version has special code so that typing in a
message body is considered to be activity.

Important:
You must enable Secure Sockets Layer (SSL) on the server before you enable
forms-based authentication.

Important:
Exchange Server 2003 forms-based authentication does not allow you to set the
default domain setting in IIS to anything other than the default domain setting of \.
This restriction is to support user logons that use the Unified Principle Name (UPN)
format. If the default domain setting is changed, Exchange System Manager resets
the default domain setting to "\" on the server. You can change this behavior by
customizing the Logon.asp page in the Outlook Web Access virtual directory in IIS to
specify your domain or to include a list of domain names.

Note:
If you customize the Logon.asp page in the Outlook Web Access virtual directory in
IIS, your changes may be overwritten if you upgrade or re-install Exchange
Server 2003.

For detailed instructions on configuring forms-based authentication, see How to Configure

Forms-Based Authentication on Exchange Server 2003.
 66

How to Configure a Front-End Server to

Assume a Default Domain
You can configure a front-end server to assume a default domain so that users do not have to
remember their domain.

Before You Begin

Before you perform the procedures in this topic, it is important that you first read Configuring
Exchange Front-End Servers.

Procedure
To configure a front-end server to assume a default domain
1. Start Exchange System Manageron the front-end server. Click Start, point to
Programs, point to Microsoft Exchange, and then click System Manager.

2. Right-click the "Exchange" virtual directory, and then click Properties.

3. Click the Access tab, and then click Authentication.

4. Select the Basic authenticationcheck box, and then type the domain in the
Default domain box.

5. Repeat this procedure for the "Public" virtual directory.

Note:
Ensure that the System Attendant service is running so that the configuration settings
replicate from the directory to the IIS metabase (you can also restart Exchange
System Attendant to force replication).

How to Configure Forms-Based

Authentication on Exchange Server 2003
For Microsoft® Exchange Server 2003, you can enable forms-based authentication feature
for your Microsoft Office Outlook® Web Access clients. Forms-based authentication allows an
administrator to log users off after a certain period of inactivity.
 67

Before You Begin

To successfully complete the procedures in this topic, confirm the following:

• You have enabled Secure Sockets Layer (SSL) on the front-end server

Procedure
To configure forms-based authentication on Exchange Server 2003
1. On the front-end server, in Exchange System Manager, expand Administrative
Groups if administrative groups are enabled, expand Servers, and then expand the
front-end server where you want to enable forms-based authentication.

2. Expand Protocols, expand HTTP, right-click Exchange Virtual Server, and then
select Properties.

3. Select the Settings tab, and then select the check box next to Enable Forms
Based Authentication.

4. In the drop-down menu next to Compression, select the level of compression

(High, Low, None) to use.

Note:
It is recommended that you do not enable compression in a single-server
environment. Enabling compression in a single-server environment causes
additional load on the server.

5. Click OK.

6. If you receive a message that states that the IIS service must be restarted, click
OK, and then restart Microsoft Internet Information Services (IIS).

Allowing the Use of an E-Mail Address as

the Logon User Name
An additional option for authentication is to configure a user principal name (UPN) for users.
This enables users to enter their e-mail address as their user name. You must configure all
virtual servers and all virtual directories on each front-end and back-end server which will be
accessed with UPN authentication. After you configure a UPN in the properties of the virtual
servers and directories on all front-end and back-end servers, users can authenticate by
 68

using [email protected] as their user name. Additionally, users can still use the
domain\username logon.

For detailed instructions about how to allow the use of an e-mail address as the logon user
name, see How to Allow the Use of an E-mail Address as the Logon User Name.

How to Allow the Use of an E-mail Address

as the Logon User Name
You can configure Exchange Server 2003 so that users can use their e-mail address as their
logon user name. This is also known as configuring a user principal name (UPN) for users.
After you configure a UPN on a virtual server that will be accessed for UPN authentication,
users can authenticate by using [email protected] as their user name.

Before You Begin

Before you perform the procedures in this topic, consider the following:

• You must perform the procedure on all virtual servers and all virtual directories on
each front-end and back-end server that users will access with UPN authentication.

Procedure
To allow the use of an e-mail address as the logon user name
1. Click Start, point to Programs, point to Microsoft Exchange, and then click
System Manager.

2. In Exchange System Manager, expand Administrative Groups if administrative

groups are enabled, expand Servers, and then expand the server where you want to
configure the use of an e-mail address as the logon user name.

3. Expand Protocols, expand HTTP, expand the virtual directory that you want to
configure, and then select Properties.

4. Select the Access tab, and then click Authentication.

5. In the Default domain box, type a backslash (\).

 69

Disabling Unnecessary Services

Not all Exchange services are required on a front-end server, depending on the protocols
being exposed and whether you will be making configuration changes after the initial setup.
To stop and disable services, in the Microsoft Management (MMC), use the Services snap-in.
The following table shows the Exchange services required — stop and disable all other
Exchange services.

Exchange services required for client access

Client access method Services required Comments

HTTP (Outlook Web Access, World Wide Web Publishing Exchange System Attendant
WebDAV, Exchange Service (W3SVC) should also be enabled.
ActiveSync®) Allows for administration and
IIS metabase update

POP3 Microsoft Exchange POP3 Exchange System Attendant

(POP3Svc) should also be enabled.
Allows for administration and
IIS metabase update.

IMAP4 Microsoft Exchange IMAP4 Exchange System Attendant

(IMAP4Svc) should also be enabled.
Allows for administration and
IIS metabase update

SMTP Simple Mail Transfer Protocol SMTP uses the Exchange

(SMTPSVC), Microsoft Information Store for DSN
Exchange System Attendant formatting.
(MSExchangeSA), Microsoft
If a server is running SMTP,
Exchange Information Store
then it should also run the
(MSExchangeIS)
Microsoft Exchange Routing
Service (RESVC)

Generally, System Attendant should be running on a front-end server. Although not required
for several protocols, certain tasks only occur if System Attendant is running. Also, additional
services may be required depending on other roles the front-end server performs, for
example if the server is running WMI automation the Microsoft Exchange Management
service must be running.

Note:
NNTP must be enabled on a server during upgrade; however, you can disable it if
you are not offering NNTP to your users.
 70

URLSCan and IIS Lockdown Wizard

You must secure IIS before you expose servers to the Internet by turning off all features and
services except those that are required. In Windows 2003 Server, many IIS features are
already disabled unless required by the server. On Microsoft Windows 2000 Server,
download and run the IIS Lockdown Wizard.

For information about how to install and use IIS Lockdown Wizard, see Microsoft Knowledge
Base article 325864, "HOW TO: Install and Use the IIS Lockdown Wizard."

The IIS Lockdown Tool (version 2.1) is available at http://go.microsoft.com/fwlink/?

linkid=12281.

Note:
To maximize the security of your Exchange servers, apply all the required updates
before and after applying IIS Lockdown Wizard. The updates ensure that servers
remain protected against known security vulnerabilities.

The IIS Lockdown Wizard helps you disable unnecessary IIS 5.0 features and services based
on the type of server software you are running. To provide multiple layers of protection
against attackers, the IIS Lockdown Wizard also contains URLScan, which analyzes HTTP
requests as IIS receives them and rejects any suspicious requests.

IIS Lockdown Wizard also contains a configuration template for Exchange that turns off
unwanted features and services. To use this configuration template, run IIS Lockdown
Wizard, select the Exchange template, and then change or accept the default configuration
options.

Download URLScan separately if you want to run it on Windows Server 2003. A list of
URLScan features and functionality beyond those provided by IIS 6.0 is available at
http://go.microsoft.com/fwlink/?linkid=24490.

The URLScan application is installed in the folder <drive:>/<Windows

directory>/system32/inetsrv/urlscan.

URLScan must be correctly configured for use with Exchange Server. For full details about
how to configure URLScan for use with Exchange Server, see the following Microsoft
Knowledge Base articles:

• For Exchange 2000 Server, see the Microsoft Knowledge Base article 309677,
"Known issues and fine tuning when you use the IIS Lockdown Wizard in an Exchange
2000 Server environment."

• For Exchange Server 2003, see the Microsoft Knowledge Base article 823175, "Fine-
tuning and known issues when you use the Urlscan utility in an Exchange 2003
environment."
 71

The section contains further information about why certain URLScan settings are required.
Unless you configure the following settings in the Urlscan.ini file, after you run the wizard,
you could experience problems with Outlook Web Access functionality:

• Allow Dot In Path Ensure that this setting is set to "1" so that Outlook Web Access
attachments can be accessed and that earlier-version browsers can use Outlook Web
Access.

• File Extensions By default, .htr files are disabled. If this file type is disabled, the
Outlook Web Access Change Password feature does not function.

• Deny Url Sequences In the [DenyUrlSequences] section, sequences that are

explicitly blocked can potentially affect access to Outlook Web Access. Any mail item
subject or mail folder name that contains any of the following character sequences is
denied access:

• Period (.)

• Double period (..)

• Period and forward slash (./)

• Backslash (\)

• Percent sign (%)

• Ampersand (&)

If you have additional problems when you attempt Outlook Web Access requests with
URLScan enabled, check the UrlScan.log file for the list of requests that are being rejected.

Disconnecting and Deleting Public and

Mailbox Stores
If you are not using SMTP on the front-end server, disconnect and then delete the private and
public information stores. If you are using SMTP on the front-end server, a mounted mailbox
store is required because the SMTP service requires a mounted mailbox store to perform
conversions. However, this mounted mailbox store should not contain any mailboxes. A public
folder store should never be mounted on the front-end server. For more information, see
Running SMTP for POP and IMAP Clients.

The Microsoft Exchange Information Store service (MSExchangeIS) will not start unless there
is at least one storage group defined. If MSExchangeIS service must be left running, do not
delete the storage group on the front-end server after deleting the private and public stores.
 72

Note:
In Exchange 2000 Server, if the MSExchangeIS service is not running, you will not be
able to make configuration changes using Internet Services Manager (ISM). If you
must make configuration changes using ISM (for example, configuring SSL
encryption), make sure that you complete these steps before you remove the mailbox
and public folder stores. This no longer applies to Exchange Server 2003.

Configuring Network Load Balancing

You may want to load-balance the front-end servers. Do not use Windows Clustering
Services to load-balance the front-end servers because there is no data stored on the front-
end servers; each front-end is essentially a copy of every other, so failing over is not useful.
Use Network Load Balancing to evenly spread client requests across multiple front-end
servers. For more information, see Network Load Balancing Clusters.

Configuring Secure Sockets Layer

The steps to configure SSL for POP, IMAP, and SMTP differ from HTTP.

• For detailed instructions about configuring SSL for POP3, IMAP4, and SMTP, see
How to Configure SSL for POP3, IMAP4, and SMTP.

• For detailed instructions about configuring SSL for HTTP, see How to Configure SSL
for HTTP.

How to Configure SSL for POP3, IMAP4,

and SMTP
You can configure Exchange Server virtual servers to use Secure Sockets Layer (SSL).

Procedure
To configure SSL for POP3, IMAP4, and SMTP
1. In Exchange System Manager, right-click the virtual server, and then click
Properties.

2. Click the Access tab, and then click Certificate.

 73

3. Follow the instructions in the wizard, using the guidelines in online help to
request and install the SSL certificate.

How to Configure SSL for HTTP

You can configure an Exchange HTTP virtual server to use SSL.

Procedure
To configure SSL for HTTP
1. In Internet Services Manager, for the default Exchange HTTP virtual server, right-
click Default Web Site, and then click Properties.

2. Click the Directory Security tab, and then select Server Certificate.

3. Follow the instructions in the wizard, using the Internet Information Services 6.0
Product Documentation as a reference, to request and install the SSL certificate.
HTTP SSL is configured individually for each virtual server or Web site, so if you
create additional HTTP virtual servers in Exchange System Manager, you must
configure SSL for each server or Web site as it is referred to in Internet Services
Manager.

For More Information

For more information about using Internet Information Services 6.0, see Internet Information
Services 6.0 Product Documentation.

Configuring SMTP on the Front-End Server

SMTP must be available on the front-end server to allow POP and IMAP clients to submit e-
mail messages. You can install SMTP on the front-end server or set up a separate SMTP
server. To install SMTP on the front-end server, configure SMTP for internal and external
domains, as described in the following two sections.
 74

Mail for Internal Domains

For the front-end server to accept mail that is inbound from the Internet, the front-end server
needs to know the domains for which it should accept mail. Adding recipient policies for each
of your domains tells all servers in the Exchange organization to accept mail for those
domains. Additionally, you must enable anonymous access for other SMTP servers on the
Internet to successfully route mail to your organization (this is the default setting).

Mail for External Domains

In the default configuration, any SMTP mail that is submitted to your server and addressed to
external domains is denied. This occurs because relaying is turned off for all anonymous
access (however, authenticated users can still send e-mail to any external domain). Users
who try to anonymously submit e-mail to external domains receive an error, such as "550
5.7.1 Unable to relay for [email protected]." The clients must be configured to use SMTP
authentication.

Note:
Although you could allow relaying for anonymous access, it is not recommended and
should never be required. Allowing unauthenticated relaying lets anyone on the
Internet use your server to send e-mail.

If you choose to require SMTP authentication for mail submitted by your users from the
Internet, you should also require SSL for clear text or basic authentication, so that corporate
usernames and passwords are not sent out unencrypted. Configure SSL for basic
authentication in the Properties of the SMTP virtual server: On the Access tab, click
Authentication, and then select Requires TLS encryption.

For more information about SMTP, see the Exchange Server 2003 Transport and Routing
Guide.

Configuring DSAccess for Perimeter

Networks
The DSAccess component in Exchange 2000ServerSP2 was redesigned to provide better
support for perimeter networks in which RPC traffic is not allowed across the internal firewall.
However, to prevent performance problems, there are two additional registry keys that you
should set on the front-end server to disable NetLogon and the Directory Access ping.
Additionally, you can configure DSAccess so that your front-end servers contact specific
domain controllers and global catalog servers. The following sections describe how to
configure these settings.
 75

Note:
This section contains information about editing the registry. Incorrectly editing the
registry can cause serious problems that may require you to reinstall your operating
system. Problems resulting from editing the registry incorrectly may not be able to be
resolved. Before editing the registry, back up any valuable data.

Note:
Using Registry Editor incorrectly can cause serious problems that may require you to
reinstall your operating system. Microsoft cannot guarantee that problems resulting
from the incorrect use of Registry Editor can be solved. Use Registry Editor at your
own risk. For information about how to edit the registry, view the "Change Keys and
Values" Help topic in Registry Editor (regedt32.exe.exe) or the "Add and Delete
Information in the Registry" and "Edit Registry Information" Help topics in
regedt32.exe. Note that you should back up the registry before you edit it. If you are
running Microsoft Windows NT® Server or Windows 2000Server, you should also
update your Emergency Repair Disk (ERD).

Disabling the NetLogon Check

DSAccess connects to Active Directory servers to check available disk space, time
synchronization, and replication participation by using the NetLogon service with RPC. If you
do not allow RPC traffic across the internal firewall, you should stop the NetLogon check by
creating the DisableNetlogonCheck registry key on the front-end server.

For detailed instructions on how to disable the NetLogon check, see How to Disable the
NetLogon Check on a Front-End Server.

Disabling the Directory Access Ping

In a perimeter network, you must also create a registry key on the front-end server to prevent
Directory Access from pinging domain controllers.

For detailed instructions on how to disable the directory access ping, see How to Disable the
Directory Access Ping.

Specifying Domain Controllers and Global

Catalog Servers
In a perimeter network, you may want to configure DSAccess to use specific domain
controllers and global catalog servers, and then use IP filtering to ensure that the front-end
servers connect to only those domain controllers and global catalog servers. To specify
domain controllers and global catalog servers, use the Directory Access tab in the <server
 76

name> Properties dialog box. Specifying servers on the Directory Access tab sets keys in
the registry. The Directory Access tab was not available in earlier versions of Exchange; if
you have previously set registry keys to specify domain controllers and global catalog
servers, these registry keys will still work.

How to Disable the NetLogon Check on a

Front-End Server
DSAccess connects to Active Directory servers to check available disk space, time
synchronization, and replication participation by using the NetLogon service with RPC. This
procedure explains how to disable the NetLogon check.

Before You Begin

This topic contains information about editing the registry.

Caution:
Incorrectly editing the registry can cause serious problems that may require you to
reinstall your operating system. Problems resulting from editing the registry
incorrectly may not be able to be resolved. Before editing the registry, back up any
valuable data.

Procedure
To disable the NetLogon check
1. Start Registry Editor (regedit).

2. Locate and select the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAcce
ss\

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: DisableNetlogonCheck

Data type: REG_DWORD

Value data: 1
 77

How to Disable the Directory Access Ping

This procedure describes how to disable DSAccess from pinging domain controllers.

Before You Begin

This topic contains information about editing the registry.

Caution:
Incorrectly editing the registry can cause serious problems that may require you to
reinstall your operating system. Problems resulting from editing the registry
incorrectly may not be able to be resolved. Before editing the registry, back up any
valuable data.

Procedure
To disable the directory access ping
1. Start Registry Editor (Regedit.exe).

2. Locate and select the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAcce
ss\

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: LdapKeepAliveSecs

Data type: REG_DWORD

Value data: 0

Hosting Multiple Domains

In the simplest topology, you do not need to configure the front-end server beyond
designating it as a front-end server. However, if you are hosting multiple domains,
organizations, or public folder trees, you may need to create additional virtual servers or
directories.

Before Exchange Server 2003 SP1, for each domain you host, you must have a unique
virtual server or directory so that users with e-mail addresses from those domains can log on
 78

to the appropriate virtual server or directory. There are two methods you can use to configure
the HTTP virtual servers when hosting additional domains:

• Method one: Create additional virtual servers

• Method two: Create additional virtual directories

In the following methods, your default Exchange domain is microsoft.com, and you are
hosting mailboxes for adatum.com and public folders for contoso.com. The methods describe
how to configure your front-end and back-end servers for these hosted companies.

Note:
In Exchange Server 2003 Service Pack 1, you are no longer required to create
additional virtual servers and virtual directories for different SMTP domains. However,
there may be other logistical or aesthetic reasons for using multiple virtual directories
and virtual servers. For more information about the Outlook Web Access logon and
SMTP domain, see "Logging on to Outlook Web Access" in Supporting HTTP Access.

Method One: Create Additional Virtual Servers

In this method, you create a virtual server for each domain you host. For example, you have
three HTTP virtual servers on each server that is running Exchange: one is the default
Exchange virtual server, one is the virtual server for adatum.com's mailboxes, and one is the
virtual server for contoso.com's public folder tree. This method allows for maximum flexibility
in determining the resources available to each domain.

Each HTTP virtual server must have a unique combination of IP address, host header, and
port. The host header is the DNS name of your Web site. For example, if users access your
Web site by typing http://www.contoso.com/example in a browser, the host header is
www.contoso.com. By specifying the host header for the virtual server, you can host multiple
Web sites using the same port and IP address combination because the host header ensures
uniqueness. However, if you try to create a virtual server that has the same combination of
these settings as another server, the new virtual server will not start.

When additional virtual servers are set up and sessions are non-encrypted, client requests
are routed to the correct virtual server as follows:

1. The client connects to the front-end server.

2. The server receives a packet that contains the IP address, requested port, and host
header.

3. The server uses this information to find the appropriate virtual server to handle the
request.

When a user's request is routed to the correct virtual server, there is no guarantee that the
user will be able to successfully access Outlook Web Access. To log on to the virtual server,
the user must also have an e-mail address from the SMTP domain that is associated with the
 79

virtual server. Each virtual server and each virtual directory that points to mailboxes is
associated with a specific SMTP domain. Therefore, when you create additional virtual
servers that point to mailboxes, you must associate the virtual server with the appropriate
domain. (Exchange Setup associates the default Exchange HTTP virtual server with the
default Exchange domain; this default cannot be changed.)

After the user's request is routed to the correct virtual server, the process continues as
follows:

1. The virtual server uses the user's authentication credentials to look up the user in
Active Directory.

2. If the user has an e-mail address from the SMTP domain associated with this virtual
server, the virtual server allows access. Otherwise, the virtual server denies access.

Note:
Using the authentication credentials to look up the user's SMTP proxy address
works only if authentication is enabled on the front-end server. If authentication is
not enabled, the server uses the alias specified in the URL (because accessing
Outlook Web Access through a front-end server with pass-through authentication
requires the user to enter an explicit logon in the format
http://server/exchange/user). Then, to form the proxy address, the server
combines the alias with the SMTP domain on the virtual server properties.

Note:
When SSL is used, the host header is contained in the encrypted part of the packet;
only the IP address and port are available in the unencrypted part. To determine
which SSL certificate to use to decrypt the data, the server must be able to determine
the appropriate virtual server with a unique combination of IP address and port.
Therefore, when SSL is used (such as when the front-end server is deployed on the
Internet), the IP address must be specifically associated with the appropriate virtual
server.

After you create the additional virtual server, you must create the Exchange and Public virtual
directories under that virtual server.

For instructions about how to create virtual directories, see How to Add a Virtual Directory
Under an HTTP Virtual Server in Exchange Server 2003.

Note:
To enable the Change Password feature for your users, you must enable the feature
on all virtual servers on the front-end. Each virtual server must contain a virtual
directory named IISAdmPwd.
 80

Method Two: Create Additional Virtual

Directories
The second method to configure multiple hosted domains is to add a virtual directory for each
domain. For access to mailbox stores, you must specify the domain in the properties of the
virtual directory. For access to public stores, you must specify the root public folder. For your
first hosted company, adatum.com, add a virtual directory under the default Exchange HTTP
virtual server, with a name that uniquely identifies the hosted company, such as Adatum. In
the properties of the virtual directory, click Modify, and then select adatum.com as the SMTP
domain, just as you did for the virtual server. Users from adatum.com will now be able to
connect to http://mail.microsoft.com/adatum/ to access their mailboxes.

Add another virtual directory for Contoso, and this time select Public folder and specify the
public folder root for Contoso. Users from contoso.com will now be able to connect to
http://mail.microsoft.com/contoso/ to access their public folders.

The main advantage to this method pertains to SSL. SSL certificates are issued for a specific
host or domain name—in this case, mail.microsoft.com. When you have multiple virtual
servers with different domain names (for example, mail.microsoft.com and mail.adatum.com),
you need one SSL certificate for each domain, and that costs money. Because, in method
two, clients access their data through a single domain—http://mail.microsoft.com—you save
on the cost of the certificates in addition to the step of configuring SSL on each virtual server.

For detailed instructions on how to create new virtual directories, see How to Create Virtual
Directories.

If you are hosting multiple domains, as explained in the first method for adding virtual servers,
where a virtual server is created for each domain, it is recommended that you use the
standard virtual directory names—"Exchange" for mailbox access (make sure to specify the
domain again) and "public" for public folder store access. Do not create an "exadmin" virtual
directory on any additional virtual servers; this is used only by System Manager and is not
proxied by the front-end server.

How to Add a Virtual Directory Under an

HTTP Virtual Server in Exchange Server
2003
This topic explains how to add a virtual directory under an HTTP virtual server in Exchange
Server 2003.
 81

Procedure
To add a virtual directory under an HTTP virtual server in Exchange Server 2003
1. Start Exchange System Manager: Click Start, point to Programs, point to
Microsoft Exchange, and then click System Manager.

2. In Exchange System Manager, expand Administrative Groups if administrative

groups are enabled, expand Servers, and then expand the server where you want to
configure the use of an e-mail address as the logon user name.

3. Expand Protocols, expand HTTP, right-click the HTTP virtual server, click New,
and then click Virtual Directory.

4. Name the virtual directory.

Notes:
The name you use is important, because this is what the client must enter in their
browser (for example, http://mail.microsoft.com/virtualdirectoryname). Do not use the
following character sequences in the directory name because IIS blocks them:

- Period (.)

- Double period (..)

- Period and forward slash (./)

- Backslash (\)

- Percent sign (%)

- Ampersand (&)

5. Right-click the virtual directory that you just created, and then click Properties.
Specify whether the directory is for access to a mailbox or a public store. If the
directory is for access to a mailbox store, the SMTP domain must be specified. If the
virtual directory is for access to a public folder store, select the appropriate public
folder to act as the root public folder for this virtual directory.

For More Information

For more information, see Configuring Exchange Front-End Servers.

How to Create Virtual Directories

Use this procedure to create virtual directories.
 82

Procedure
To create virtual directories
1. In Exchange System Manager, right-click the HTTP virtual server, click New, and
then click Virtual Directory.

2. Name the virtual directory.

Note:
The name you use is important, because this is what the client must enter in
their browser (for example,
http://mail.microsoft.com/virtualdirectoryname). Do not use the following
character sequences in the directory name because IIS blocks them:

- Period (.)

- Double period (..)

- Period and forward slash (./)

- Backslash (\)

- Percent sign (%)

- Ampersand (&)

3. Right-click the virtual directory just created, and then click Properties. Specify
whether the directory is for access to a mailbox or a public store. If the directory is for
access to a mailbox store, the SMTP domain must be specified. If the virtual directory
is for access to a public folder store, select the appropriate public folder to act as the
root public folder for this virtual directory.

Configuring a Back-End Server

Exchange configuration is stored in Active Directory® directory server on a per-forest basis,
which means that all front-end and back-end servers must be in the same forest. Back-end
servers can be accessed directly if required, without affecting the behavior of the front-end
and back-end configuration.

If you did not configure any additional virtual servers or directories on any front-end servers,
you do not need to configure any on the back-end server. If you created additional virtual
servers or directories on any front-end servers, however, you must add matching virtual
servers and directories on the back-end servers.
 83

The specific back-end server configuration steps depend on whether the back-end server is
hosted on a cluster. The following steps describe configuration for non-clustered back-end
servers. For information about configuring clustered back-end servers, see the technical
paper Deploying Microsoft Exchange 2000 Server Clusters.

Note:
When back-end servers are clustered, you cannot access the cluster HTTP virtual
directory using the name of the actual physical clustered computer. You must use the
virtual group name.

Configuring Authentication on a Back-End

Server
By default, HTTP virtual servers on the back end are configured to allow both basic
authentication and Integrated Windows Authentication. You should use this default
configuration.

Basic authentication passes the user name and password across the network in a lightly
encoded (not encrypted) format. Integrated Windows Authentication refers to a package of
authentication mechanisms (such as NTLM and Kerberos) that are more secure and that do
not send the password across the network in clear text.

When the front-end HTTP virtual servers authenticate requests, authentication information is
requested from the user. The user sends authentication information to the front-end server,
which authenticates the user and then passes the information to the back-end server. The
back-end server then authenticates the user, but it does not need to request authentication
information from the user again.

• Exchange 2000 front-end servers will use basic authentication to the back-end server
for HTTP access

• Exchange 2003 front-end servers will use integrated authentication to the back-end
server for HTTP access

Only Internet Explorer supports Integrated Windows Authentication directly against a back-
end server.

Creating and Configuring HTTP Virtual

Servers on Back-End Servers
In Configuring Exchange Front-End Servers, two methods for configuring your front-end and
back-end topology when hosting multiple domains were discussed:
 84

• Method One involves setting up a virtual server for every hosted domain.

• Method Two involves setting up a virtual directory for every hosted domain.

Back-end configuration differs slightly depending on which method you chose. Additionally, if
you create additional virtual servers on the front-end servers for other reasons (such as to
host Web applications), you must add similarly configured virtual servers to any back-end
servers on which the Web applications will exist.

Method One: Configure Additional Virtual

Servers
If you chose to create an additional virtual server for each additional domain (with an
Exchange virtual directory beneath each additional domain), you will need to create a
matching virtual server on the back-end server. The steps are slightly different from those for
configuring the front-end server.

For detailed instructions on how to configure additional virtual servers on a back-end server,
see How to Configure Additional Virtual Servers on a Back-End Server.

Method Two: Create Additional Virtual

Directories
If you chose to create an additional virtual directory (under the default domain) for each
additional domain, configure the virtual directory structure to match the virtual directory
structure on the front-end servers. As with the front-end servers, ensure that you specify the
appropriate SMTP domain for virtual directories associated with mailbox stores.

The directory name must not contain the following character sequences in the directory name
because IIS blocks them:- Period (.)- Double period (..) - Period and forward slash (./) -
Backslash (\) - Percent sign (%) - Ampersand (&)

How to Configure Additional Virtual

Servers on a Back-End Server
If you create additional virtual servers on your Exchange front-end servers, you must add
similarly configured virtual servers to the back-end servers. This procedure describes how to
configure additional virtual servers on a back-end server.
 85

Before You Begin

Before you perform the procedures in this topic, you must create the additional virtual servers
on your front-end server. For more information about creating additional virtual servers on
your front-end server, see Configuring Exchange Front-End Servers.

Procedure
To configure an additional virtual server on a back end server
1. Start Exchange System Manager: Click Start, point to Programs, point to
Microsoft Exchange, and then click System Manager.

2. In Exchange System Manager, expand Administrative Groups if administrative

groups are enabled, expand Servers, and then expand the server where you want to
configure the use of an e-mail address as the logon user name.

3. Expand Protocols, right-click HTTP, click New, and then select HTTP Virtual
Server.

4. In the Properties dialog box, type a name for the virtual server. Give the virtual
server a consistent name, such as "adatum.com (back-end)".

5. Under Exchange Path, click Modify, select the appropriate domain from the list
(adatum.com in this case), and then click OK.

6. Click Advanced, and then add the appropriate host names (mail.adatum.com in
this case). The address through which the client browser accesses the front-end
server is forwarded by the front-end server to the back-end server, so the back-end
server must be aware of every name a client might use to reach the front-end server
(for example, http://mail, http://mail.adatum.com, and so on).

Note:
On the back-end server, the TCP port must be 80. This is the only port used
for HTTP communication between front-end and back-end servers,
regardless of the port used by the client to communicate with the front-end
server. You can leave the SSL port at the default setting.

Configuring Firewalls
This section discusses how to configure firewalls for use with an Exchange front-end and
back-end topology. The following topics provide additional configuration information for the
front-end servers in these environments.
 86

• Configuring an Internet Firewall

• Configuring an Intranet Firewall

Configuring an Internet Firewall

In Internet scenarios, a firewall is usually placed between the corporate network and the
Internet. This firewall controls the connections that are allowed between computers on the
Internet and computers in the corporate network. When you configure this firewall, it is
important to consider the direction of traffic. For a detailed discussion about port direction,
see "Port Filtering" in Using Firewalls in a Front-End and Back-End Topology.
You must configure the firewall to allow requests to certain IP addresses and over certain
TCP/IP ports. The following table lists the ports required for different services. These ports
are specific to inbound traffic (from the Internet to the front-end server).

Ports that must be open on the Internet firewall

Destination port number/transport Protocol

443/TCP inbound HTTPS (SSL-secured HTTP)

993/TCP inbound SSL-secured IMAP

995/TCP inbound SSL-secured POP

25/TCP inbound SMTP

Note:
In this table, "Inbound" means that you should configure the firewall to allow
computers outside (on the Internet, in this case) to initiate connections to the front-
end server. The front-end server never has to initiate connections to the computers
on the Internet; the front-end server responds only to connections initiated by
computers on the Internet.

Configuring ISA Server

If you are using ISA Server, you must configure it as follows. (These are general guidelines.
For detailed information about how to configure ISA Server, see the ISA Server product
documentation.)

1. Configure a listener for SSL.

2. Create a destination set that contains the external IP address of the ISA server. This
destination set will be used in the Web publishing rule.
 87

3. Create a Web publishing rule that redirects requests to the internal front-end server

4. Create protocol rules to open ports in ISA Server for outgoing traffic.

5. Configure the ISA server for Outlook Web Access. For information about how to
configure an ISA Server for Outlook Web Access, see Microsoft Knowledge Base article
307347, "Secure OWA Publishing Behind ISA Server May Require Custom HTTP
Header."

Configuring an Intranet Firewall

This topic discusses the use of a perimeter network in which you use both an external and
internal firewall. The following sections describe how to configure your perimeter network,
intranet firewall, and ISA server to allow Exchange to function correctly.

New in SP2 With the release of Microsoft® Exchange Server 2003 Service Pack 2 (SP2),
Microsoft has introduced Direct Push technology which allows Exchange ActiveSync® to
deliver e-mail messages immediately to the mobile device as soon as they arrive on the
server. With Direct Push technology, whenever the back-end server receives e-mail or data to
be transmitted to a mobile device, it sends a UDP notification to the front-end server. This
transmission requires that UDP port 2883 be open on the firewall to allow one-way traffic from
the back-end server to the front-end server.

For more information about the deployment of Direct Push technology and its effect on
firewall configuration, see the following Exchange Server blog article:

• Direct Push is just a heartbeat away.

Note:
The content of each blog and its URL are subject to change without notice.

Advanced Firewall Server in the Perimeter

Network
When your advanced firewall server (for example, ISA) is not also your intranet firewall (there
is an additional firewall between the advanced firewall and the front-end server), you must
open the required protocol ports in your intranet firewall to allow the advanced firewall server
to forward the requests.
 88

Protocol ports required to allow advanced firewall server to forward requests

Destination port number/transport Protocol

443/TCP inbound or 80/TCP inbound HTTPS (SSL-secured HTTP) or HTTP,

depending on whether the advanced firewall
(such as ISA) is offloading the SSL decryption

993/TCP inbound SSL-secured IMAP

995/TCP inbound SSL-secured POP

25/TCP inbound SMTP

Additional ports may be required if the advanced firewall is performing tasks such as
authenticating users. See your advanced firewall documentation for more information.

Note:
Other firewall vendors might recommend that you make additional configuration
settings to their individual products for IP fragmentation.

Front-end Server in Perimeter Network

If positioned in a perimeter network, the front-end server must be able to initiate connections
to back-end servers and Active Directory® directory service servers. Therefore, you would
configure the internal firewall with a rule that allows inbound port 80 traffic from the perimeter
network into the corporate network. This rule will not allow outbound port 80 traffic from inside
the corporate network to the front-end server. All the port discussions that follow refer to
inbound ports carrying traffic from the server in the perimeter network to the back-end
servers.

Note:
The preferred method of deployment is for the front-end server to be on the intranet
with the back-end servers and to use an advanced firewall as your perimeter
network. You only need to follow this section if you have certain requirements where
you must position the Exchange front-end server in the perimeter network.

Basic Protocols
In every case, all the supported protocol ports must be open on the inner firewall. The SSL
ports do not need to be open, because SSL is not used in communication between the front-
end server and the back-end servers. The following table lists the ports required for the
intranet firewall. These ports are specific to inbound traffic (from the front-end server to the
back-end servers).
 89

Protocol ports required for the intranet firewall

Port number/transport Protocol

80/TCP inbound HTTP

143/TCP inbound IMAP

110/TCP inbound POP

25/TCP inbound SMTP

691/TCP Link State-Algorithm Routing

Note:
In this table, "inbound" means that the firewall should be configured to allow
computers in the perimeter network, such as the advanced firewall server, to initiate
connections to the front-end server on the corporate network. The front-end server
never has to initiate connections to the computers in the perimeter network. The
front-end server responds only to connections initiated by the computers in the
perimeter network.

Active Directory Communication

To communicate with Active Directory, the Exchange front-end server requires LDAP ports to
be open. Both TCP and UDP are required: Windows on the front-end server will send a
389/UDP LDAP request to a domain controller to check if it is available for use; the LDAP
traffic after that uses TCP. Windows Kerberos authentication is also used; therefore, the
Kerberos ports must also be open. Both TCP and UDP are required for Kerberos as well:
Windows uses UDP/88 by default, but when the data is larger than the maximum packet size
for UDP, it uses TCP. The following table lists the ports that are required for communicating
with Active Directory and Kerberos.

Ports required for Active Directory communication and Kerberos

Port number/transport Protocol

389/TCP LDAP to Directory Service

389/UDP

3268/TCP LDAP to Global Catalog Server

88/TCP Kerberos Authentication

88/UDP
 90

There are two sets of optional ports that can be opened in the firewall. The decision to open
them depends on the policies of the corporation. Each decision involves tradeoffs in the areas
of security, ease of administration, and functionality.

Domain Name Service (DNS)

The front-end server needs access to a DNS server to correctly look up server names (for
example, to convert server names to IP addresses). The following table lists the ports
required for access.

If you do not want to open these ports, you must install a DNS server on the front-end server
and enter the appropriate name to IP mappings for all the servers it might need to contact.
Additionally, you must also configure all the Active Directory SRV records because the front-
end must be able to locate domain controllers. If you choose to install a DNS server, be sure
to keep these mappings up-to-date when changes are made to the organization.

Ports required for access to DNS server

Port number/transport Protocol

53/TCP DNS Lookup

53/UDP

Note:
Most services use UDP for DNS lookups and use TCP only when the query is larger
than the maximum packet size. The Exchange SMTP service, however, uses TCP by
default for DNS lookups. For more information, see Microsoft Knowledge Base article
263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries."

IPSec
The following table lists the requirements for allowing IPSec traffic across the intranet firewall.
You only need to enable the port that applies to the protocol you configure; for example, if you
choose to use ESP, you only need to allow IP protocol 50 across the firewall.

Ports required for IPSec

Port number/transport Protocol

IP protocol 51 Authentication Header (AH)

IP protocol 50 Encapsulating Security Payload (ESP)

500/UDP Internet Key Exchange (IKE)

 91

Port number/transport Protocol

88/TCP Kerberos

88/UDP

Remote Procedure Calls (RPCs)

DSAccess no longer uses RPCs to do Active Directory service discovery. However, because
your front-end server is configured to authenticate requests, IIS must still have RPC access
to Active Directory to authenticate the requests. Therefore, you must open the RPC ports that
are listed in the "RPC ports required for authentication" table below.

Stopping RPC Traffic

If you have a locked-down perimeter network in which it is impossible for the front-end server
to authenticate users, you might not be allowed to open the RPC ports that are listed in the
"RPC ports required for authentication" table below. Without these RPC ports, the front-end
server cannot do authentication. You can configure the front-end server to allow anonymous
access, but you should understand the risks of doing so. For more information, see
Authentication Mechanisms for HTTP.

Instead of stopping all RPC traffic, it is recommended that you restrict RPC traffic by opening
one port (as described in the next section).

Restricting RPC Traffic

If you want the features that require RPCs, such as authentication or implicit logon, but do not
want to open the wide range of ports above 1024, you can configure your domain controllers
and global catalog servers to use a single known port for all RPC traffic. For more information
about how to restrict RPC traffic, see Microsoft Knowledge Base article 224196, "Restricting
Active Directory Replication Traffic to a Specific Port."

To authenticate clients, the registry key (described in the above knowledge base article and
listed below) must be set on any server that the front-end server may contact with RPCs such
as a global catalog server. Set the following registry key to a specific port, such as 1600:

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\NTDS\Parameters

Registry Value: TCP/IP Port Value Type: REG_DWORD Value Data: (available port)

On the firewall between the perimeter network and your intranet, you need to open only two
ports for RPC communication — the RPC portmapper (135) and the port you specify (port
1600, as listed in the following table). The front-end server first attempts to contact back-end
 92

servers with RPCs over port 135, and the back-end server responds with the RPC port it is
actually using.

Note:
Exchange System Administrator uses RPCs to administer Exchange servers. It is
recommended that you do not use Exchange System Administrator on a front-end
server to administer back-end servers because this requires configuring RPC access
from the front-end to each back-end server. Instead, you should use Exchange
System Administrator from an Exchange client computer or a back-end server to
administer back-end servers. You can still use Exchange System Administrator on the
front-end server to administer the front-end server itself.

RPC ports required for authentication

Port number/transport Protocol

135/TCP RPC port endpoint mapper

1024+/TCP Random service ports

Or (Example) Specific RPC service port, if

restricted
1600/TCP

Front-End and Back-End Topology

Checklist
The following checklist summarizes the steps required to configure front-end servers, back-
end servers, and firewalls.

Note:
The following procedures contain information about editing your registry. Using
Registry Editor incorrectly can cause serious problems that may require you to
reinstall your operating system. Microsoft cannot guarantee that problems resulting
from the incorrect use of Registry Editor can be solved. Use Registry Editor at your
own risk. For information about how to edit the registry, view the "Change Keys and
Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete
Information in the Registry" and "Edit Registry Information" Help topics in
Regedt32.exe. Note that you should back up the registry before you edit it. You
should also update your Emergency Repair Disk (ERD).
 93

Note:
The following tables present the front-end and back-end topology tasks in a tabular,
checklist format.

Configuring the front-end servers

Task

Step 1. Install Exchange Server:

Install Exchange Server on the front-end server.

Step 2. Configure HTTP virtual servers or directories on the front-end server for access to
mailbox and public stores as required:
For additional virtual servers, specify the SMTP domain, IP address, and host headers or
ports. Leave the Basic authentication check box selected.

For additional virtual directories for public stores, specify the appropriate public store root.

For additional virtual directories for mailbox stores, specify the SMTP domain.

Step 3. Disable unnecessary services:

Stop any services that are not required for the protocols being used.

Step 4. Dismount and delete stores if necessary:

If you are not running SMTP, dismount and delete all mailbox stores.

If you are running SMTP, leave a mailbox store mounted, but make sure the mailbox store
does not contain any mailboxes. If you receive large amounts of external e-mail for public
folders, you can mount a public store, as this will improve mail delivery to public folders.

Step 5. Set up front-end server load balancing if necessary:

Install load balancing on all front-end servers.

(Recommended) Enable client affinity.

Step 6. Configure SSL (recommended):

Option 1: Configure SSL on the front-end server.

Option 2: Set up a server between the client and the front-end server to offload SSL
decryption.
 94

Task

Step 7. If you use a perimeter network:

Note:
It is recommended that you use an advanced firewall server (such as ISA Server)
rather than the front-end server in the perimeter network. For more information, see
Advanced Firewall in a Perimeter Network.

Create the DisableNetlogonCheck registry key and set the REG_DWORD value to 1.

Create the LdapKeepAliveSecs registry key and set the REG_DWORD value to 0.

To restrict the front-end to only contacting certain domain controllers and global catalog
servers, specify them in Exchange System Manager on the front-end server

Step 8. If you use a perimeter network and do not want to allow RPCs across the intranet
firewall:

Note:
If you disable authentication on the front-end server, you allow anonymous requests
to reach your back-end servers.

Disable authentication on the front-end server.

Step 9. If required, create an IPSec policy on the front-end servers.

Configuring the back-end servers

Tasks

1. Create and configure HTTP virtual servers or directories to match the front-end:

2. For additional virtual servers, set the host headers and IP addresses as appropriate.
The TCP port must be left at 80. Make sure the Basic authentication and Integrated
Windows Authentication check boxes are both selected.

3. For additional virtual directories for public folder stores, specify the appropriate public
folder store root, to match the root configured on the front-end server.

4. For additional virtual directories for mailbox stores, specify the SMTP domain.
 95

Configuring firewalls

Task

Step 1. Configure the Internet firewall (between the Internet and the front-end servers):

Open TCP ports on the Internet firewall for the mail protocols:

443 for HTTPS

993 for SSL-enabled IMAP

995 for SSL-enabled POP

25 for SMTP (including TLS)

Step 2. (continued) If using ISA Server, configure as follows:

Configure a listener for SSL.

Create a destination set that contains the external IP address of the ISA server. This
destination set will be used in the Web publishing rule.

Create a Web publishing rule that redirects requests to the internal front-end server.

Create protocol rules to open ports in ISA Server for outgoing traffic.

Configure the ISA server for Outlook Web Access (for more information about how to
configure an ISA server for Outlook Web Access, see Microsoft Knowledge Base article
307347, "Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header."
 96

Task

Step 3. If using a front-end server in a perimeter network, configure the intranet firewall:

Open TCP ports on the intranet firewall for the protocols you are using:

• 80 for HTTP

• 143 for IMAP

• 110 for POP

• 25 for SMTP

• 691 for Link State Algorithm routing protocol

Open ports for Active Directory Communication:

• TCP port 389 for LDAP to Directory Service

• UDP port 389 for LDAP to Directory Service

• TCP port 3268 for LDAP to Global Catalog Server

• TCP port 88 for Kerberos authentication

• UDP port 88 for Kerberos authentication

Open the ports required for access to the DNS server:

• TCP port 53

• UDP port 53

Open the appropriate ports for RPC communication:

• TCP port 135 - RPC endpoint mapper

• TCP ports 1024+ - random RPC service ports

(Optional) To limit RPCs across the intranet firewall, edit the registry on servers in the intranet
to specify RPC traffic to a specific non random port. Then, open the appropriate ports on the
internal firewall:

• TCP port 135 – RPC endpoint mapper

• TCP port 1600 (example) – RPC service port

If you use IPSec between the front-end and back-end, open the appropriate ports. If the policy
you configure only uses AH, you do not need to allow ESP, and vice versa.

• UDP port 500 – IKE

• IP protocol 51 – AH

• IP protocol 50 – ESP

• UDP port 88 and TCP port 88 – Kerberos

 97

Front-End and Back-End Topology

Troubleshooting
Problems experienced with front-end and back-end architectures are frequently caused by
the inability of network traffic to flow from the front-end server to the correct back-end servers
because of incorrect configurations on the server or the network routers. In all cases, event
log entries may help troubleshoot the particular issue. When you troubleshoot reported or
observed problems with a front-end and back-end topology, step through the issues below to
see if they might apply to your problem.

Troubleshooting Tools
When troubleshooting problems in a front-end and back-end topology, the following tools can
help you.

• Network Monitor Use Network Monitor to monitor the traffic and determine exactly
what is happening between the front-end and the other servers. Set up a client to connect
to the front-end server and monitor the traffic between the front-end servers and the
intranet servers. You can also use Network Monitor to monitor between the client and the
front-end server if SSL is not being used.

• Event Viewer Check the event logs on the front-end and back-end servers and any
other involved servers (DNS, global catalog, and other servers). There may be entries
indicate what the problem is.

• RPC Ping To test RPC connectivity between the front-end server and a global
catalog or back-end server, use the Rpings.exe tool. It is in the support directory of the
Exchange CD.

• Telnet Use telnet.exe to attempt to connect directly to the user's back-end server
using the port that the mail protocol uses. For example, if Outlook Web Access is not
working when you connect to the front-end server, try using Telnet from the front-end
server to port 80 on the back-end server.

General Troubleshooting Steps

• Make sure that all the appropriate services are started on the front-end and back-end
servers. This includes the relevant Exchange services in addition to the World Wide Web
Publishing service and SMTP service, if applicable.

• If you have a perimeter network, make sure that the appropriate ports are open on
the internal firewall as described in Configuring Firewalls.
 98

• Ensure that the front-end server can successfully connect to the global catalog
servers and DNS server. This is particularly important when the front-end server is in a
perimeter network. Use Telnet from the front-end server to the appropriate ports on the
servers in the intranet—389, 3268, 53, and other ports.

Note:
Windows Telnet uses TCP/IP and cannot be used to connect to UDP ports.

• If you cannot connect to the back-end server from the front-end server using the
hostname with any protocol, try to use the IP address. If this works, verify that you can
connect to the DNS server the front-end server is using. Also verify that the name to IP
mapping is correct in DNS.
• If the front-end server is configured with the list of domain controllers and global
catalog servers in the registry, verify that the front-end can reach each of those servers
exactly as specified in the registry entry.

• Make sure that the combination of IP address and host header is unique for each
virtual server.

• If you have a load balancing solution for the front-end servers, make sure that the
shared IP can be reached from client computers.

• Administration: If you want to use Exchange System Manager, ensure that the
System Attendant service is running. Also recall that you cannot use the Internet Services
Manager after deleting the stores on the front-end server.

• If users complain that the state of read and unread messages in public folders
fluctuates, consider the following:

• Was a back-end public folder server added or removed?

• Is authentication enabled on the front-end?

• Are any back-ends that host the folder down?

Logon Failures
If your users have problems logging on to POP, IMAP or Outlook Web Access, consider the
following common problems:

• Is the user entering the username in the correct format—domain\username,

[email protected], username?

• If UPN or a default domain is configured and the user is entering the username in the
correct format, verify that the default domain setting is correct on all virtual servers and
virtual directories in Exchange System Manager. Verify the same setting in Internet
Services Manager. If the domain is correct in Exchange System Manager but not in
Internet Services Manager, there is most likely a problem replicating settings from
 99

Exchange System Manager to Internet Services Manager. Try restarting the

MSExchangeSA service to fix this.

• Verify that the host headers for the HTTP virtual server match exactly what the client
browser is using to connect to the server. Verify that the host headers are correct and
there are no typing mistakes on the back-end and front-end virtual servers and
directories.

• If you have multiple virtual servers for multiple domains, make sure that the SMTP
domain is configured correctly.

• Ensure that the user attempting to log on has an e-mail address for the domain
configured on the virtual server the user is accessing.

Troubleshooting Outlook Web Access

For detailed information about troubleshooting Outlook Web Access for
Exchange 2000 Server, see Troubleshooting Outlook Web Access in Microsoft
Exchange 2000 Server.

Copyright
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft must
respond to changing market conditions, it should not be interpreted to be a commitment on
the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information
presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express
written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you
any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
 100

association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync,
ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN,
Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile,
Windows NT, and Windows Server System are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.