Typical Exchange 2003 Topologies

Now that you have had a quick run-through of some of the different server components available in Exchange 2003, it's time to examine some of the most commonly deployed topologies. What follows is by no means a comprehensive or exhaustive list, but it does reflect some of the more common Exchange topologies found in real-world implementations.

Single Server

Smaller organizations might choose to deploy Exchange 2003 on a single server. This has the advantage of providing a single server to configure and administer and, for organizations that are running Exchange 2003 Standard Edition, this is a common setup.

The options for a single-server implementation in Exchange 2003 are the same as with Exchange 2000. The one significant difference is that making a connection to the Internet has been made easier with the new Internet Connection Wizard (which is covered in Chapter 4, "Configuration"). The Internet Connection Wizard allows administrators or organizations that are new to Exchange to quickly install and configure Exchange 2003.

Internal Front-End and Back-End Servers

Organizations that want to add some scalability to their Exchange implementation might want to consider using front-end and back-end servers within their organization. This topology, shown in Figure 2.1, can have several front-end servers that handle client requests and many back-end servers that manage the information store and process any requests.

Figure 2.1. Utilizing internal front- and back-end servers.

The advantage of this topology is that it can grow as your organization grows and you can add more servers to handle additional connections or processing requests. Again, this implementation method has changed little from Exchange 2000. The exception is that now the authentication protocol between servers is Kerberos by default, which means it's not necessary to configure IPSec.

For more information on Kerberos and other security improvements for Exchange servers, check out Chapter 8, page 101.

External Front-End and Back-End Servers

If you need to provide access to Exchange to users who are external to your network or domain, you might want to consider adding some additional front-end servers to the topology you just looked at. To give access to users who are outside of your organization (including users who might want to remotely access their Mailbox), you need to have a front-end server positioned to handle these requests.

The most simple solution would be something similar to the configuration shown in Figure 2.2, where an Exchange front-end server is "exposed" to the rest of the world.

Figure 2.2. Utilizing external front-end and back-end servers.

FRONT-END SERVERS

Remember, front-end servers are domain members and a significant amount of traffic on a variety of ports is required for them to talk to domain controllers. As a result, front-end servers should be located entirely within the intranet and firewalls should be used to open ports or reverse-proxy incoming POP/IMAP/HTTP traffic to the front-end servers.

Any incoming client connections are made to this server and then routed to the appropriate back-end server. This configuration has all the advantages found in a normal front-end/back-end configuration, but it also provides an easy method for external users to access information that is held on Exchange.

If you want to deploy a more secure solution, consider creating this topology in conjunction with a firewall or DMZ, like the solutions shown in Figure 2.3. Both of these methods allow external users to connect to your front-end server but still protect your internal network from potential exploit.

Figure 2.3. Utilizing external front-end and back-end servers with a firewall.

Again, this type of configuration or topology has not changed from Exchange 2000, so you shouldn't have to reinvent your Exchange topology when you upgrade to Exchange 2003. (If anything, you should be looking to rid yourself of a few servers in the process.)

Make sure when planning your topology that you protect your front-end servers and use firewalls to get the traffic from the outside world to the front-end servers.

The best practice for implementing Exchange with a firewall includes reverse proxying (as opposed to simply opening ports), which allows the firewall to analyze incoming traffic for common packet-level attacks, further protecting your front-end servers. It also makes the firewall the attack point for Denial of Service (DoS) attacks, rather than the mail server.

And, as if I had to tell you, under no circumstances should an Exchange server be directly exposed to the Internet!

Now that you have some idea of what type of Exchange configuration you would like to create using the updated server components, it's time to look at how you would actually install and then configure these components, which is where the next chapter picks up.