As part of your topology planning for an Exchange 2000 migration, you need to consider:

  • The deployment of front-end servers.
  • The utilization of clustering for high availability.
  • The reconfiguration of ports on routers and firewalls.

Let’s take a look at each of these issues in turn.

Carol Bailey’s series on Exchange 2000 planning

Deploying front-end servers
Front-end servers are new in Exchange 2000 and typically exist on the DMZ to simply route traffic and decrypt data. They do not have mailboxes or public folder stores—these belong on the back-end servers, which usually exist on your private network.

You need to decide whether your topology needs front-end servers as part of your Exchange 2000 deployment. Front-end servers provide a number of security, availability, and scalability benefits. Of course, you will have to be able to justify the additional hardware and licensing costs.

Front-end servers are easy to configure. You simply activate a check box and then delete or move any data stores from that server. Their purpose is to focus on security, load balancing, and scalability (using DNS RR or NLB; for differences between the two, see this article). Front-end servers also allow you to give users a simplified and unified namespace so that everyone can be set up to access the same server name, even when their mailboxes are hosted on different servers.

Note that Integrated Windows authentication cannot be used with front-end servers, so you will need to use SSL with the appropriate protocol to ensure that usernames and passwords are kept secure. It’s also important to remember that front-end servers cannot be used with MAPI clients (e.g., Outlook) but can be used with clients that use IMAP4, POP3, NNTP (e.g., Outlook Express), or Outlook Web Access. See this article for more information on front-end servers.

Clustering for high availability
Microsoft typically talks about clustering Exchange 2000 with back-end servers in the front-end/back-end server deployment. But of course you can enjoy the benefits of clustering without having front-end servers.

Consider clustering the back-end data stores to help ensure availability at the resource level (but remember clustering does not protect data). Exchange 2000 is fully cluster-aware and supports Active/Active clustering—meaning you can simultaneously run multiple instances of Exchange within the cluster by creating a cluster group that acts as a stand-alone server (referred to as an Exchange Virtual Server, or EVS).

Each EVS can host multiple storage groups, but the maximum number of storage groups per node is four. So, for example, you can have two storage groups on each active node to ensure full redundancy if either one of the servers fails. However, if you had three storage groups on each active node, neither server could support full redundancy in the event of a failure, so plan your clusters and storage groups carefully.

There are two main differences in Exchange 2000 operation when running on a cluster:

  • Cluster Service makes IsAlive calls to resources to ensure that they are responding.
  • Since each EVS acts as a stand-alone server, messages between separate EVSs are transported by SMTP.

In a planned failover (e.g., for maintenance downtime), the information store removes the storage groups and stops the virtual Exchange servers. The resources are failed over and the information store on the new node assumes the storage groups and starts the protocols needed. In an unplanned failover, typically the resources will be restarted in an attempt to bring them back online. If a restart fails, the resources are failed over and the new node will read the transaction logs in an effort to synchronize the databases.

Interestingly, RAM requirements for Exchange 2000 will be smaller than on a nonclustered server because RAM on a cluster is dynamically allocated or released to each cluster node as needed. The amount of physical storage required for virtual memory will also be less.

Although Exchange 2000 resources support clustering, the level of support varies, so it’s important to be aware of exactly which resources support high availability and in what configuration. Here is a brief rundown:

  • System Attendant: Active/Active
  • Information Store: Active/Active
  • Message Tracking Agent: Active/Passive
  • POP3/IMAP4/SMTP/HTTP: Active/Active
  • NNTP: Not supported
  • Key Management Service: Not supported
  • Full Text Indexing: Active/Active
  • Instant Messaging: Not Supported
  • Chat: Active/Passive
  • Conferencing Services: Not supported

Reconfiguration of router and firewall ports
When you’ve decided what Exchange 2000 components you are going to use and determined your server placement, you’ll need to check whether intervening routers and firewalls need reconfiguration to support additional traffic between servers and/or from clients to servers. Table A lists the possible ports used with Exchange 2000.

Table A
Function Port
Link State Protocol within a Routing Group TCP port 691
Link State Protocol between Routing Groups TCP port 25
RVP for Instant Messenger (note that HTTPS is not supported with IM, so consider using IPSec or VPNs for additional security) TCP port 80
Domain Controller lookups LDAP TCP port 389
Global Catalog lookups LDAP TCP port 3268
NetBIOS TCP 135, 139, 1024+
DNS TCP and UDP port 53
Remote Procedure Calls TCP ports 111.135, 1024+
Netlogon UDP port 445
Kerberos TCP and UDP port 88
SRS (Site Replication Service for E5.5 sites) TCP port 379 by default on ADC CA
Outlook Web Access (OWA) TCP port 80 for HTTP, TCP port 443 for HTTPS
IMAP4 TCP port 143, TCP port 993 if using with SSL
POP3 TCP port 110, TCP port 995 if using with SSL
SMTP TCP port 25

Summary
These three topology issues represent another important step in your premigration Exchange 2000 planning. My next article, the last in this series, will delve into Exchange configuration issues, such as data stores and storage groups, indexing, policies, delegating control, and other configuration parameters.