Front-End Server in a Perimeter Network

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

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.

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.

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.