Choosing Roles

Before you can reasonably expect to install Exchange 2007 on a server, you need to know what that server is going to be used for. As you remember from the section "Server Roles Overview" in Chapter 2, Exchange 2007 no longer installs the same set of binaries and services to every Exchange server (requiring you to then remove and shut down unnecessary features and services). Instead, it defines five separate roles: Edge Transport, Hub Transport, Client Access, Mailbox, and Unified Messaging.

Some of these roles are required in your organization, while others are optional. Others are required depending on how you plan to place your servers. Some roles can be colocated on the same physical server, while others must be stand-alone. You must factor a number of program dependencies, deployment best practices, and economic-driven compromises into your Exchange 2007 design. It can be overwhelming to untangle this web on your own.

Instead of leaving you to guess, we offer the following discussions to help you determine which roles you need and where you need to place them. Although we can't account for every factor, we can help you sort out the ones that are driven by Exchange 2007 requirements and which ones are under your control.

Note 

One of the key factors in determining which roles can be colocated, how many servers you need with a given role, and where to locate those servers is how many users you plan to support. Unfortunately, as this book is being written, we don't yet have a lot of published real-world sizing data. This is the kind of information that is likely to be showing up on the Microsoft Exchange 2007 website in the months following the release of Exchange 2007.

Edge Transport

If you're looking at using the Edge Transport role, you have a pretty easy deployment decision: it must be installed on its own physical server and cannot be colocated with any other role. Contrary to rumors already floating around the Microsoft technical community, you will not be able to colocate the Edge Transport role and Microsoft ISA Server 2006 on the same physical server using the release to manufacturing (RTM) versions of Exchange 2007 and ISA 2006 - at least not without pulling weird tricks using virtual servers, which would be less than secure and possibly take you outside the boundaries of Microsoft-supported configuration.

Note 

Why can't you install the Edge Transport role and ISA 2006 on the same server? Very simply, ISA 2006 cannot be installed on any 64-bit version of Windows Server - and if you remember, you can only run your production Exchange 2007 servers on x64 Windows Server 2003 or later. Microsoft may address this problem in future service packs, but at least for now, this is how it is.

Warning 

And don't try to fudge it by using the 32-bit version of Exchange 2007 on your Edge Transport server. That violates the licensing restrictions for Exchange and could end up costing you far more than buying a separate machine for ISA 2006 would. If that's not enough to dissuade you, the 32-bit version is a 180-day trial version; you'd have to rebuild your Edge Transport servers every six months. You also lose the automatic anti-spam definition updates (which aren't provided to 32-bit machines).

The real question is do you need to deploy the Edge Transport role? The answer is simple: you are not required to have an Edge Transport server in your organization in order to successfully use Exchange 2007, although it offers a lot of advantages that the alternatives don't. Remember that the Edge Transport role is specifically designed to be installed in your perimeter network, with no requirements for connectivity to Active Directory. In fact, Microsoft strongly recommends that you not join your Edge Transport servers to the same Active Directory forest (or forests, in a multiforest organization) that your internal Exchange servers are joined to. You can join the Edge Transport server to a management forest in your perimeter network or leave it as a stand-alone workgroup member and still get all of the new functionality without compromising your inner network security or driving your firewall administrator mad. The new Edge Subscription feature allows your Edge Transport servers to still receive all of the necessary updates they need to fully protect your organization.

Tip 

The term perimeter network is Microsoft's preferred terminology for the network concept of the DMZ: a separate network segment that allows you to provide a degree of isolation between your protected internal servers and your servers (such as web servers or mail gateways) that need to accept incoming connections from untrusted hosts on the Internet. The two terms mean the same thing, but Microsoft is phasing out the use of DMZ in their documentation.

With legacy versions of Exchange, if you placed them directly in your perimeter network, you'd find that you had stepped directly into a nightmare of firewall configuration. Prior to 2007, all Exchange 2000 and 2003 servers were required to be full member servers in an Active Directory forest; in order to get them to work correctly in the perimeter, you had to poke so many holes in the firewall for the various protocols that you ended up with no real increase in protection. While this was the recommended deployment for Exchange 2000 front-end servers for a time, Microsoft eventually solved this problem by using ISA Server in the perimeter.

With the Edge Transport role, Exchange 2007 solves this problem the same way that it's solved by other edge mail router solutions, such as specialized messaging appliances or software mail applications such as Postfix, Sendmail, and Exim: place the Edge Transport server in the perimeter network without requiring it to have full access to Active Directory on the interior network. Like these other solutions, Edge is designed to do two things:

• Route SMTP traffic between your trusted Exchange servers and untrusted Internet hosts, using a best-practice perimeter network placement with full integration into your Exchange organization.

• Provide a "safe" platform for performing message hygiene functions (anti-spam, antivirus, and other forms of content inspection) in the perimeter network before your full Exchange servers (and Windows domain controllers) have to handle the extra load caused by unwanted message traffic. It also sanitizes messages going out from your organization to the Internet so that you're not contributing pollution to the Internet.

An Edge server's main advantage is that it offers most, if not all, of the same message hygiene features you can find on other solutions - if not out-of-the-box, then at least via add-ins that you can purchase or download from third-party vendors (or even develop yourself). And it does this while offering an unparalleled level of integration with your Exchange organization:

• Although the Edge server should never be joined to the same Active Directory forest as your Exchange org, it can be joined to a separate management forest in your perimeter network if your perimeter is large enough to incur the overhead of an additional Active Directory deployment to secure and manage.

• The Edge Transport role requires a Hub Transport instance in your organization, both for SMTP routing and optionally for Edge Subscription configuration. This really isn't a problem because you have to have at least one Hub Transport instances, but it may affect placement of your Hub Transport instances and Edge Transport servers to ensure good network connectivity between them.

• Using the Edge Subscription feature, your Hub Transport instances can be easily configured to automatically update your Edge Transport servers with the specific subset of information they need to effectively process incoming mail. Since this is a push process from Hub Transport instances to your Edge Transport servers, you don't need to open additional holes in your firewall (unlike mail router solutions that offer Exchange "integration" through LDAP lookups back into your domain controllers). Even though this step is not done as part of the install, you should consider it to be a required deployment step because you lose a lot of functionality (including the ability to manage your entire organization from inside the firewall) by not doing it.

• The Edge Transport server can be managed from within your organization using the Exchange Management Shell and the Exchange Management Console, just as you manage any other Exchange server. Again, this simplifies management and makes it easier to script bulk operations (although many of the common types of activities you might want to script are already automatically updated using Edge Subscriptions).

• An Edge Transport server comes with a host of existing anti-spam components out of the box. While some of these components can also be deployed on a Hub Transport instance, many can't. See Chapter 18, "Delivering E-mail," for more details.

• An Edge Transport server easily integrates with the Microsoft Forefront Security for Exchange Server, a multi-engine malware scanner developed from the Antigen line of products that Microsoft acquired from Sybari.

• The Exchange 2007 organization can collect some of the per-user settings from user mailboxes, such as blocked and allowed sender lists, and propagate them out to the Edge Transport server. This allows the Edge Transport server to intelligently accept and deny incoming messages based on who they're addressed to without requiring any additional work from the users or the Exchange administrators - a feature we've seen in no other message gateway solution.

Tip 

Do remember that the Edge Transport role is designed only for SMTP traffic. It does not handle any other protocols, such as client access protocols like HTTP, POP3, IMAP, or MAPI. The Edge Transport role is purely for SMTP connections between your organization and mail servers out on the Internet.

Client Access

If you only ever plan to have MAPI users connect to your Exchange mailboxes, then you don't need to have a Client Access server in your Exchange organization.

Tip 

The Microsoft documentation refers to the Client Access role by the abbreviation CAS. How come the abbreviation for the Client Access role isn't CA? Easy; that acronym is already used to signify certificate authority, a key component of a public key infrastructure. If you're using SSL or S/MIME, then you already deal with certificate authorities. Since it's common to deal with digital certificates and certificate authorities when configuring and managing Client Access servers, Microsoft wisely avoided potential confusion by not reusing the acronym.

These days, it's the rare organization that offers only MAPI access to mailboxes. While Outlook is the only full MAPI client that accesses Exchange mailboxes using MAPI Remote Procedure Calls (RPCs) protocol, it's not convenient or possible to use Outlook all the time:

• Microsoft's Entourage client for Mac OS X uses WebDAV (HTTP/HTTPS), as does Novell's Evolution client for Linux.

• Almost all other mail clients offer at least IMAP, POP3, or HTTP/HTTPS. Some of the more common ones out there are Apple Mail, Eudora, Mozilla Thunderbird; there are a vast number of others in use. Some clients will also offer NNTP access to Exchange public folders.

• Outlook Anywhere (the new name for RPC over HTTPS) uses HTTP or HTTPS.

• Exchange ActiveSync uses HTTP/HTTPS.

• Of course, Outlook Web Access uses HTTP/HTTPS.

Warning 

Exchange 2007 no longer offers Network News Transport Protocol (NNTP) access, even if you implement public folders. You must use an Exchange 2000 or 2003 server in your organization to provide NNTP support if you wish to continue offering it. NNTP access is outside the scope of this book.

Clearly, if you have any need to offer HTTP, IMAP, or POP3 access to your users, you're going to need the Client Access role in your organization. Lest you be tempted to think of it as "just" a renamed front-end Exchange server, remember that the Client Access role does not offer the capability to handle SMTP. In the Exchange 2003 world, a front-end server still had the SMTP service running by default and would frequently be used as an SMTP bridgehead as well as a front-end server, to the point that many people became confused as to what exactly a front-end server was supposed to do! With Exchange 2007, the separation is very real: the Client Access role handles client access protocols, the Hub Transport role handles SMTP. If you need to put these roles onto separate machines, you can; if you need to combine them, you can.

Now you just need to know how many Client Access servers you need and where you need to locate them. At a minimum, keep the following rules of thumb in mind:

• You need at least one Client Access role in every site and domain in which you have Exchange Mailbox servers.

• The Client Access role needs to have good network connectivity (good available bandwidth and low latency, usually a 100Mbps Ethernet connection or better) with the Mailbox servers it serves.

• The Client Access role is required to allow any HTTP access to mailboxes, whether from internal clients or from outside of your organization.

• You may wish to have one set of Client Access servers deal with external connections and another service internal clients. The POP3 and IMAP protocols allow mailbox access only; they do not provide any way for the client to submit messages back to the server. These clients must use SMTP. As a result, you may wish to colocate the Client Access and Hub Transport roles onto servers you use to handle external client access.

Tip 

Although you might think you can place the Client Access role in your perimeter network to deal with traffic coming from the Internet, suddenly you're back in the middle of the firewall configuration nightmare of trying to keep a member server in the perimeter. Instead, you should keep the Client Access role in your protected network and place an ISA 2006 server (or a Blue Coat appliance, a Linux Squid proxy server, or some other equivalent reverse proxy solution) in the perimeter to accept outside connections. Your firewall administrators will thank you. Also remember that with Exchange 2007, Microsoft does not support placing Client Access role in the perimeter network. Getting this configuration to work securely means not only that you have a lot of extra work to do to secure your servers and connections, but also that you are risking going without full Microsoft product support when problems develop.

Hub Transport

Since all messages in an Exchange organization must travel through a server running the Hub Transport role you must have at least one Hub Transport role in your organization. That's the easy part. Unless you have a small organization, though, you may want to have more than one Hub Transport role to remove the single point of weakness.

Note 

If you think it's inefficient for Exchange 2007 to require all messages to be handled by the Hub Transport role, you need to consider the growing role of regulatory and policy compliance. This new architecture allows Exchange to easily inspect every single message and apply policies uniformly. See Chapter 13, "Managing Messages in Transit," for more details on the new transport rule and policy features.

Depending on the level of traffic that your Mailbox servers and network have to deal with, you may want to colocate your Hub Transport and Mailbox roles on the same physical servers. Then again, you may want to have multiple Mailbox servers in each site, with only a pair of Hub Transport servers to provide the necessary message routing for the site. Regardless of where the roles are located, the Hub Transport and Mailbox roles communicate using MAPI RPCs.

As long as you meet the necessary minimum placement guidelines and take care to provide enough Hub Transport capacity close enough to your Mailbox servers to keep message traffic from getting caught in bottlenecks, you have an amazing degree of flexibility in how you actually deploy Hub Transport roles. Exchange 2007 servers running the Mailbox role will automatically discover the Hub Transport roles in your organization and attempt to use the ones in the same Active Directory site. If there are multiple Hub Transport instances in the site, the Mailbox servers will intelligently load-balance traffic between them without any extra effort on your part. If one of your Hub Transport instances becomes inaccessible, the Mailbox servers will automatically switch to another Hub Transport instances.

When deciding which physical servers to place the Hub Transport role on, keep in mind the following conditions:

• You need at least one Hub Transport role in every site and domain in which you have the Mailbox role. Servers running the Mailbox role can only connect to Hub Transport roles in the same site. If all of the Hub Transport instances in a site go down, Mailbox servers in that site will not be able to fail over to using a Hub Transport role in a neighboring site and all message traffic in the affected site will come to a grinding halt.

• If you colocate the Hub Transport role with the Mailbox role, that Mailbox instance will always try to use the local Hub Transport instance before talking to other Hub Transport instances in the site. This breaks the natural load-balancing behavior we mentioned previously and is a good reason to separate the Hub Transport and Mailbox roles in larger organizations or sites. Remember that you can't put the Hub Transport role on a cluster, so if you're going to deploy clustered Mailbox servers, you have to put the Hub Transport role on a separate server.

• The Hub Transport role needs to have good network connectivity (good available bandwidth and low latency, usually a 100Mbps Ethernet connection or better) with the Mailbox instances it serves.

• At least one Hub Transport instance is required to allow any SMTP access to your organization, whether from non-Exchange mail machines inside of your organization, from Edge Transport servers, or from some other mail routing solution that brings external mail into your organization.

• The Edge Transport role requires a Hub Transport instance in your organization, both for SMTP routing and optionally for Edge Subscription configuration. This really isn't a problem because you have to have at least one Hub Transport instances, but it may affect placement of your Hub Transport instances and Edge Transport servers to ensure good network connectivity between them.

• You may wish to have one set of Hub Transport instances to handle external connections and another to service internal clients. The POP3 and IMAP protocols allow mailbox access only; they do not provide any way for the client to submit messages back to the server. These clients must use SMTP. As a result, you may wish to colocate the Client Access and Hub Transport roles onto servers you use to handle external client access.

Tip 

If you're thinking about putting a Hub Transport instance in your perimeter network, don't. As with the Client Access role, you will go through a lot of effort to make it work, complicate your firewall configuration, and end up with an unsupported Exchange configuration. Use the Edge Transport role (recommended) or some other mail gateway solution instead.

Mailbox

Strictly speaking, you aren't required to have a single Mailbox server role in your organization. Of course, the resulting organization can have no mailboxes and is pretty darn pointless. Mailbox servers are the heart and soul of Exchange; as a result, you will probably spend more time installing and configuring the Mailbox role than any other.

Users have come to depend on the ubiquitous and near-instantaneous transmission of e-mail. Ten years ago, it was not uncommon to send an e-mail and know that it would be 10 to 15 minutes at a minimum before it was spooled off of the local mail server and head out to the recipient. Today, that kind of delay is considered to be unacceptable unless there are special concerns regarding limited bandwidth or Internet connectivity. Even then, these types of concerns are considered the exception to the rule rather than the norm.

Modern e-mail users will start calling the help desk, or badgering the mail administrators, if they aren't receiving a steady stream of mail throughout the day. Imagine for a moment the reaction these same users are likely to have if they cannot access their Mailbox server. Cached copies of their mailbox in Outlook aren't going to cut it; they're going to riot. It's not surprising, therefore, that a lot of money and time is spent ensuring the high availability of Mailbox servers. Since Outlook MAPI clients connect directly to the user's Mailbox server, the user can be the first to know if something's not right on the server.

In Exchange 2007, Microsoft tries to provide for high levels of availability for all of the server roles. The Mailbox role, however, is the only one that offers options for traditional clustering solutions, now called Single Copy Clusters (SCCs). It also offers two new availability options: Clustered Continuous Replication (CCR) and local Continuous Replication (LCR). These availability options are designed to keep the mailbox data available even if the server hardware fails and are explained in more detail in Chapter 15, "Reliability and Availability 101." Because traditional clustering is only supported on the Mailbox role, you cannot colocate other roles on a clustered Mailbox server.

It should not be a surprise that the Mailbox server role storage requirements are potentially far more enormous than for the other roles. As a result, the disk configuration for your Mailbox instances is far more important than for any other role. Exchange 2000 and Exchange 2003 lived and died around their disk I/O requirements; Exchange 2007 still requires you to carefully plan, design, and test your disk subsystem, even with the I/O performance improvements provided by the 64-bit architecture.

When designing your Mailbox servers roles, here are the relevant guidelines to keep in mind:

• All other factors being equal, the closer your users are to their Mailbox servers, the better. This is not to downplay the impact of Outlook cached mode and server consolidation, however, because most of the time not all other factors are equal.

• Those other factors include but by no means are limited to the following: the overhead cost of the server hardware, the level of hardware redundancy (the failure of a single power supply or disk controller can really ruin your day), the per-server power consumption, the server room's cooling capacity, the cost of disks, the effects on backup and restore policies and SLAs, the cost of training and maintaining administrative personnel, the cost of software licensing, and the physical shelving and racking requirements.

• If you're planning on doing single copy clustering, your Mailbox server hardware must be on Microsoft's Cluster Hardware Compatibility List. If you're going to do clustered continuous replication, however, your hardware only has to be on the Windows Hardware Compatibility List, which can be significantly cheaper.

• The Hub Transport role needs to have good network connectivity (good available bandwidth and low latency, usually a 100Mbps Ethernet connection or better) with the Mailbox instances it serves.

• If you colocate the Hub Transport role with the Mailbox server role, that Mailbox role instance will always try to use the local Hub Transport instance before talking to other Hub Transport instances in the site. This breaks the natural load-balancing behavior we mentioned previously and is a good reason to separate the Hub Transport and Mailbox server roles in larger organizations or sites. Remember that you can't put the Hub Transport server role on a cluster, so if you're going to deploy clustered Mailbox servers, you have to put the Hub Transport role on a separate server.

• The Mailbox role no longer uses the SMTP protocol to communicate with other Exchange servers in the organization. They use RPC to communicate with other roles in their site; all communications with servers in other sites take place through intermediary Hub Transport instances.

Unified Messaging

We're not going to spend a lot of time talking about the Unified Messaging role because it requires an advanced set of equipment and skills to properly implement. If you're planning to deploy this role in your organization, you will require the services of experienced telephony personnel, whether in-house or contractors.

We've heard Microsoft personnel say that you can colocate the Unified Messaging role on the same physical server as other roles as long as your organization is very small and there is plenty of extra capacity on your server. The catch is, though, determining what they mean by "very small." We have seen no specific guidance for determining how to size a Unified Messaging server and how to tell when it can safely coexist with some other server roles.

Tip 

Unless you are hosting a handful of users - no more than 30 - on a single Exchange 2007 server that is running other roles, we highly recommend that you consider buying a separate server to use for Unified Messaging. If e-mail is mission critical, voicemail is often as critical or more so. The cost of buying separate hardware and software licenses will more than pay for itself in the trouble you save by not having your single server overloaded on a constant basis, dropping both e-mail and voicemails. If you can't afford that cost, you probably need to rethink whether your organization will truly derive any real benefit from the features the Unified Messaging role provides.

Management Tools

There is a not-so-hidden sixth role in Exchange 2007: the management tools role, consisting of the Exchange Management Shell (EMS) and the Exchange Management Console (EMC). This role is the sole exception to the "no 32-bit Exchange 2007 on your production network" rule. You are allowed to install the 32-bit version of the Exchange management tools on your administrative workstation if you're still running 32-bit version Windows XP. In fact, Microsoft has provided the 32-bit version of the Exchange 2007 management tools as a separate download from their website.

Recommended Order of Installation

Now that you've decided which roles you're installing on your servers, which order are you going to install them in? If you're deploying a combined function server, you don't have to answer this question. When you have multiple physical servers, though, you need to figure out in what order you're going to deploy them. Which servers you deploy first is determined by what roles they have installed. The official Microsoft-recommended order is as follows:

1. Directory preparation

2. Edge Transport (optional)

3. Client Access

4. Hub Transport

5. Mailbox

6. Unified Messaging (optional)

Tip 

Remember that before is a relative term; if you're combining the Client Access, Hub Transport, and Mailbox roles on one server, you're following the outlined order, even if it's the first Exchange server in the organization.

We'll be honest - we think this list is good, but we're convinced that it's aimed at the organization upgrading from Exchange 2003 or 2000 to Exchange 2007. We really don't think it's the right fit for someone who is installing a brand-new Exchange 2007 organization; we recommend holding off on your Edge installation at least until after you've got an HT server in place, and possibly after you've got Mailbox servers up and running.

Why would we think that? There are a several reasons:

• The first is aesthetics. Microsoft's order works from the outside layers of an organization into the crunchy nougat center. Our preferred order of deployment for just about any software is to first establish the core functionality (in this case, the ability for your users to e-mail each other within your organization) and then go after the extras like Outlook Web Access ActiveSync, Unified Messaging, and Edge Transport.

• If you recall, the Edge Transport role requires a Hub Transport role to talk to, both for SMTP and for the Edge Subscription feature to allow centralized provisioning and configuration. You don't need to configure Edge Subscription, but then you lose nice functionality such as recipient filtering and per-user blocked/allowed sender lists - and you have to manage your Edge Transport server manually. Given our preferences, we'd rather install the Edge Transport server and be able to immediately configure the Edge Subscription as opposed to have to come back to it later.

• Finally, we tend to think that anyone who is installing Windows Server 2007 from scratch (as opposed to upgrading from a previous version of Exchange) is probably migrating from some other messaging system, whatever it may be. Sure, there are going to be new companies just getting started or existing companies transitioning from hosted e-mail scenarios, but the bulk of these "new" installations are already going to have an existing e-mail service. These companies probably already have some sort of messaging gateway in place, and unless that's the major pain point driving their migration to Exchange 2007, they probably want to concentrate on getting users shifted over rather than fiddling with an Edge Transport server. Their existing spam appliance or Linux mail gateway is doing a fine enough job for the time being.

There's nothing wrong with Microsoft's recommended order of installation, and you won't be doing a bad thing by following it. Just be aware that it is a recommendation, not a rule; the installer won't refuse to install the HT role until it detects a CAS in the org. If you have a good reason for altering the order to meet the needs of your organization, then by all means do it.

Tip 

The only two guidelines that we hesitate to recommend violating are these: install a Hub Transport instance in the site before you install your Mailbox instances, and wait to install the Unified Messaging role until everything else is installed and mostly working. You won't be able to test mail flow without a working Hub Transport instance in the site, and Unified Messaging is complicated enough to be worth giving it all your attention.