When planning for a Microsoft Exchange 2000 enterprise deployment, one of the most critical steps to a successful implementation is selecting the placement of bridgehead servers. To facilitate the process, we’ve created a group of diagrams available for free download that provides a sample bridgehead placement strategy. We have also included a worksheet you can use to plan the placement of your own Exchange 2000 bridgehead servers. This article will provide a link to the download and explain how to use it.
The sample bridgehead placement diagram is based on a fictitious organization: Sample Technologies, Inc (STI). For the purpose of this example, STI is a diversified manufacturer of electronic components and end products for various industries, including IT. STI’s bridgehead location has approximately 7,250 mailboxes. STI has taken the initiative to migrate to Exchange 2000. The company is currently running Exchange 5.5 in a 14-site enterprise configuration.
Download the Exchange 2000 bridgehead server diagrams
This download includes two Microsoft Visio 2000 diagrams. The first is our “Sample Exchange 2000 Bridgehead Server Strategy,” which provides you with a sample topology for placing bridgehead servers. The second is our “Exchange 2000 Bridgehead Server Worksheet,” which provides you with space to fill in information for planning the placement of your own bridgehead servers. If you don’t have Visio, you can print out the included TIF images of both of these diagrams.
Key concepts of the bridgehead placement diagram
Our bridgehead placement diagram takes advantage of some of the new features of Exchange 2000. These features can bring greater flexibility, stability, and scalability to your Exchange organization.
Exchange 2000 allows you to denote a server as a front-end or a back-end server. The front-end servers will perform Active Directory lookups to point to the resource (data) on a back-end server. This model is beneficial to the enterprise if a resource is moved within the Exchange site (new server added to site, mailbox moved to another server, etc.) because the front-end server automatically updates the client configuration. Some of the front-end servers also serve as the routing groups for the STI site in our example. They exist with the Exchange 2000 SMTP Connector to the other Exchange sites in the organization over VPN or the WAN, as well as Internet mail.
In the STI diagram, you’ll notice that none of the front-end servers has information stores. In this network topology, the back-end servers store data (public and private information stores), and the front-end servers perform a specific function (connection, client lookup, Outlook Web Access, etc.).
In Exchange 2000, the database arrangement has changed to allow IT pros greater flexibility in administrating data. Exchange 5.5 provides for up to three databases per server in a site: a public information store, a private information store, and the Exchange Directory. In Exchange 2000, the Exchange Directory database is absorbed into Windows 2000 Active Directory. The private and public information stores remain, but a server can have multiple information stores. This can allow databases to be smaller, segmented, or otherwise arranged to best balance needs and resources.
Servers used in this diagram
The STI diagram has 12 Exchange 2000 servers for this bridgehead site. Each one serves a specific role, as shown in Table A.
|Front-End #1||S-STI-EX-FE1||Routing group to WAN||On WAN DMZ|
|Front-End #2||S-STI-EX-FE2||Routing group to VPN||On DMZ|
|Front-End #3||S-STI-EX-FE3||Routing group to VPN||On DMZ|
|Front-End #4||S-STI-EX-FE4||Internet at large SMTP||On DMZ|
|Front-End #5||S-STI-EX-FE5||Client locator|
|Front-End #6||S-STI-EX-FE6||Outlook Web Access||Load Balanced|
|Front-End #7||S-STI-EX-FE7||Outlook Web Access||Load Balanced|
|Back-End #1||S-STI-EX-BE1||Public and private IS|
|Back-End #2||S-STI-EX-BE2||Private IS|
|Back-End #3||S-STI-EX-BE3||Private IS|
|Back-End #4||S-STI-EX-BE4||Private IS|
|Back-End #5||S-STI-EX-BE5||Private IS|
Private information store groupings
The private information store groupings are represented in the diagram generally by department. Smaller departments are consolidated into a database with other small departments. This segmentation of the private information stores provides a number of benefits to the Exchange administrator:
- Migration—Regardless of migration strategy, a large migration will operate in Exchange 2000 mixed mode for some period of time. The distributed information stores can denote manageable, segmented phases for the migration.
- Risk distribution—Exchange 2000 allows each of the separate information stores to be online or offline. If there is an issue with a particular database, fewer mailboxes are affected. Also notice in the diagram that the sales department (STI’s largest collection of employees) spans three databases on three servers. This means that if a problem were to arise on any one database, no more than 33 percent of the sales force would be disrupted.
- Backup and restore—This distributed model allows backup and restore procedures to be more flexible, as they are backing up and restoring smaller databases.
Outlook Web Access
Part of STI’s remote access strategy includes Outlook Web Access for Exchange 2000. Outlook Web Access is a perfect fit for the STI intranet for users at home via VPN, individuals at another STI facility, and the employees at the Caribbean locations that have antiquated hardware. However, some VPN clients, telecommuters, and other clients still choose full Outlook functionality.
There are two front-end servers providing Outlook Web Access. These servers are running Windows 2000’s Network Load Balancing and are using round-robin DNS, so the http://owa.sti-internal.net will load-balance across the two servers.
Exchange 2000 uses the SMTP Connector to handle communication across sites in an Exchange organization. In the diagram, front-end servers #1–#3 are responsible for site-to-site communication, while front-end server #4 handles e-mail coming in and going out to the Internet at large (domains other than sti.com). The other Exchange sites in the organization have a significantly smaller number of resources and therefore operate in a one- or two-server model.
Device naming conventions and DNS
Each computer in the diagram is named in accordance with a naming convention that identifies its role. (This nomenclature is used in all named devices in STI.) For example, consider the name S-STI-EX-FE3:
- S—Identifies the device as a server (vs. P—Printer, W—Workstation, L—laptop, etc.)
- STI—Identifies the site/organization (STI denotes its headquarters)
- EX—Denotes the type of server, in this case Exchange
- FE3—Denotes the role and number for the type of server, in this case front-end number 3
The nomenclature for networked devices, domains, users, and every object is critical to a successful implementation of Exchange 2000, as it relies on the Windows 2000 Active Directory namespace to look up resources.
Internally, each Active Directory object’s DNS name is as follows:
For services that require DNS resolution on the Internet for the purpose of this document, the MX record (mail.sti.com or @sti.com) points to the STI firewall, which has an SMTP-IN to direct inbound mail to the S-STI-EX-FE4 server.
Working with the diagrams
Our diagrams detail STI’s bridgehead server placement, server roles, network topology, and interaction with other business units.
The sample diagram details STI’s server arrangements. The following is a description of the five pages of this diagram:
- P.1 Network layout—This provides an overview of the Exchange servers in the SAMPLTECH-CMH site. There are a total of 12 Exchange servers in the site, five of which house data (back-end servers). The rest provide connections, Outlook Web Access, or a client configuration pointer.
- P.2 Routing group configuration—This page provides an analysis of front-end servers #1-#4. These four servers have specific roles in transporting mail in and out of the site to the other business units via a WAN or VPN and in receiving and sending e-mail via the Internet. These servers perform well in the routing group, as they do not directly manage any public or private information stores. Their dedication to having easy, direct connections to the other Exchange sites and to the Internet allow them to form the routing groups. These servers use the SMTP connector as their transport (which is analogous to the Internet Mail Service in version 5.5).
- P.3 Front- and back-end server map—This page details the role that each front-end server has to external connections and what each information store contains for back-end servers. There are three information stores per server (a completely arbitrary number). This mainly highlights Exchange 2000’s ability to have multiple public and private information stores.
- P.4 Exchange site information—Each Exchange site is represented on this page by its site name, location, and number of mailboxes.
- P.5 Map of business units—This provides a geographic map of the business units and their roles. These maps could help set up a hub-and-spoke system for the Exchange organization if we wanted to manage more resources across the geographical spread of the organization.
Mapping your organization’s requirements
Every organization’s approach to a technology like Exchange will be different. However, our sample diagram provides a framework for planning an enterprise deployment of Exchange 2000. Our main purpose in this article and the diagram has been to help you plan the bridgehead server placement for your Exchange 2000 deployment. However, it should also be helpful for designing the general topology of your Exchange 2000 infrastructure in order to take full advantage of the new features offered by Exchange 2000, such as the ability to create multiple information stores.
With these things in mind, you should be able to take our “Exchange 2000 Bridgehead Server Worksheet” and start mapping out your topology based on the requirements of your organization. If you haven’t already downloaded these diagrams, you can click here to get them.
Did you find this download helpful?
Do you have tips or suggestions for Exchange 2000 bridgehead placement? We look forward to getting your input and hearing about your experiences regarding this topic. Join the discussion below or send the editor an e-mail.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.